RAM or FIFO with AXI and Native ports?

[Morocco_Brittany56]

Hello,

I'm very new at this forum, this is my first question.

While working on a project, a arrived at a point where I need some Ram or Fifo on which I can write using microblaze (AXI) and getting data from it using a Native port (In my case I will write UART code to read data from Fifo).

Does this type of IP Exist? or did someone developped it before? I'm very lost can I get some help please.

I will attach a picture debriefing my project.

 

AFASSI.

[zygot]

Ignoring the frequencies, parts of your proposed diagram, like a MicroBlaze subsystem certainly can be implemented using the IPI design flow. You don't mention what platform you intend to implement this project on, and that's an important consideration that qualifies any useful answer.

Let's start at the end, where a 16 Mbaud UART is spitting out data. Where is this going to? There are devices that have UARTs capable of such rates, though once you get into the design you will likely find that the last 10% of the implementation requires a lot more than 10% of the effort. If the data sink is a PC, I don't know of any USB UART devices capable 16 Mbaud; 12 Mbaud is certainly achievable, with a bit of effort.

A true UART at 16 Mbaud isn't trivial to design, though a USRT ( the asynchronous receiver/transmitter's synchronous cousin ) might be, depending on a what's receiving the data. You aren't going to find ready made free IP in the Vivado IP catalog for such a thing.

I've posted  couple of projects with HDL source code in various sections of the Digilent Forums if you want to understand how "simple" serial communications work.

The nice thing about the IPI flow is that you can do a number of things "quickly" using the free IP provided by tools like VIvado. The not so nice thing about the IPI flow is that it's an impediment to developing project like the one that you propose when there isn't the free IP supporting it. A case in point is a UART, or Ethernet, or really any useful serial interface that isn't connected to a complicated bus like AXI (Vivado).

Edited June 14, 2023 by zygot

[Morocco_Brittany56]

23 hours ago, zygot said:

Ignoring the frequencies, parts of your proposed diagram, like a MicroBlaze subsystem certainly can be implemented using the IPI design flow. You don't mention what platform you intend to implement this project on, and that's an important consideration that qualifies any useful answer.

Let's start at the end, where a 16 Mbaud UART is spitting out data. Where is this going to? There are devices that have UARTs capable of such rates, though once you get into the design you will likely find that the last 10% of the implementation requires a lot more than 10% of the effort. If the data sink is a PC, I don't know of any USB UART devices capable 16 Mbaud; 12 Mbaud is certainly achievable, with a bit of effort.

A true UART at 16 Mbaud isn't trivial to design, though a USRT ( the asynchronous receiver/transmitter's synchronous cousin ) might be, depending on a what's receiving the data. You aren't going to find ready made free IP in the Vivado IP catalog for such a thing.

I've posted  couple of projects with HDL source code in various sections of the Digilent Forums if you want to understand how "simple" serial communications work.

The nice thing about the IPI flow is that you can do a number of things "quickly" using the free IP provided by tools like VIvado. The not so nice thing about the IPI flow is that it's an impediment to developing project like the one that you propose when there isn't the free IP supporting it. A case in point is a UART, or Ethernet, or really any useful serial interface that isn't connected to a complicated bus like AXI (Vivado).

Hello thank you for your response,

So Firstly Im working on a nexys video powered by artix 7 platform and I'm designing a testing board for a client in the automotive field, and their card's UART Decoder has a trigger at 13.7M so anything beneath that wouldn't be detected.

I will take a look into your HDL projects thank you.

 

For now I think i will implement a DMA (controlled by the microblaze) that writes into a stream data fifo and then with my custon UART I will read data from the FIFO

[zygot]

11 hours ago, Morocco_Brittany56 said:

their card's UART Decoder has a trigger at 13.7M

I don't understand what that sentence means. Are you sure that you understand or have enough information to understand what you are designing to?

At high baud rates there is usually hardware flow control as elastic storage isn't generally very deep. Something on the order of 12-13 Mbaud for a UART implemented in logic for the Artiix is about the upper limit, if you logic is clocked at 100 Mhz. For the typical 10-bit/baud period UART a 10 Mbaud rate translates to about 1 MiB/s tops.

[D@n]

@Morocco_Brittany56,

Quote

While working on a project, a arrived at a point where I need some Ram or Fifo on which I can write using microblaze (AXI) and getting data from it using a Native port (In my case I will write UART code to read data from Fifo).

@zygot has a point.  Why would you use Vivado generated IP for this?  Their generated designs are typically broken.  Not only that, this is easy enough to do.

Let's start at the top.  You want some kind of "Ram or Fifo".  Building a RAM or a FIFO is a first year beginner project.  It's not something that should require Vivado IP.  You should have a "Ram or Fifo" in your own back pocket that you've tested, verified and trust.  Here is one of mine, for example.  Frankly, they're a lot easier to work with in RTL than when using Vivado IP.  Among other things, you can debug your own.  You can't very well debug Vivado's IPs.  (I know ... I submitted some bug requests back in 2018, and they still haven't been fixed the last I checked ...)

Quote

Does this type of IP Exist? or did someone developped it before?

Absolutely!  I even have my own AXI-Lite UART and it has an integrated FIFO within it.  I built it years ago, and I would encourage you to continue doing the same.

In my case, though, I merged the FIFO into the UART.  That way the CPU has a consistent interface.  It can read/write the UART registers, or the UART FIFO, and they're both in (roughly) the same spot.  I mean, you could keep the two separate if you wanted to, but why would  you?  The UART software driver would then need to interact with two IPs (the UART and the FIFO) just to send anything.  It just makes more sense to give them both the same register map.

As for the comments about a 13MBaud UART ... I'm all ears.  Sometimes I can get mine to operate at/near 4MBaud, but 1-2MBaud is more common with the FTDI chips I find in most FPGAs.  (On the other hand, on one project I replaced the UART with a Gb Ethernet IP and was just shocked at how fast the interface went in comparison ...)

Dan

 

[zygot]

3 hours ago, D@n said:

As for the comments about a 13MBaud UART ... I'm all ears.  Sometimes I can get mine to operate at/near 4MBaud, but 1-2MBaud is more common with the FTDI chips I find in most FPGAs. 

This comment represents experience in experimentation for a typical approach to an HDL UART implemented in logic. Really, it can be worked out by math, as it comes down to how many samples, in an asynchronous over-sampled approach to determining the center of a baud period, can one get at a particular Fs for a particular baud period. Again, we're talking about a UART, not an USRT. In this case the empirical testing is probably a bit more realistic than a back-of-the-envelope calculation as all of the factors in a physical implementation have been taken into account; factors such as IO buffer slew and delay, relative clock accuracy errors, etc. For the experiments I'm referring to an HDL UART on one board communicating with an HDL UART on another board. An HDL UART connected to a USB UART bridge device is another matter. FTDI USB bridge devices use a low accuracy 60 or 120 MHz oscillator for timing. The relative Fs for sampling Tx/Rx transitions is important.

For anyone interested here is a proect and a tutorial that I've published on the Digilent Forums:

https://forum.digilent.com/topic/20479-inter-board-data-transfer-project/

[edit] I corrected the link above that was pointing to the wrong project. Apologies to anyone who was confused.

https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/

Both of these are based on the general idea of asynchronous logic design for serial communications where clocking on both ends of the interface are independent ( that is an wide baud period error with respect to the Tx and Rx ends can be tolerated); that's the whole concept of a UART. Both projects have HDL source code and can be built on an arbitrary FPGA platform(s). Both designs can be fully simulated using VIvado ISIM.

In the FTDI tutorial, we do the maximum 12 Mbaud that the FTDI 'H' devices are capable of.

As for using a 1 GbE PHY as a modem to connect FPGA boards together, or even an FPGA board and a PC together for data transport, this is an almost ideal approach ( at least from a hardware perspective ), as long as you eschew FPGA tool vendor IP and use the all HDL approach. I've been using both UARTs and Ethernet extensively for such purposed for years.

Edited June 16, 2023 by zygot

[D@n]

Quote

As for using a 1 GbE PHY as a modem to connect FPGA boards together, or even an FPGA board and a PC together for data transport, this is an almost ideal approach ( at least from a hardware perspective ), as long as you eschew FPGA tool vendor IP and use the all HDL approach. I've been using both UARTs and Ethernet extensively for such purposed for years.

I'm still new to this party as of this past year, and ... No, I am not using any FPGA tool vendor IP beyond the required IO hardware macro blocks.  (IDDR, OSERDES, etc).  Yes, it took a bit more work to do--especially since I handled almost all of the network via RTL.  Still, I find your quote, "... this is almost ideal approach", encouraging.  Thank you.

Dan

[zygot]

4 hours ago, D@n said:

I'm still new to this party as of this past year, and ... No, I am not using any FPGA tool vendor IP beyond the required IO hardware macro blocks.  (IDDR, OSERDES, etc). 

Let me make a clarification of sorts. I use the Ethernet PHY as a data pipe only for point to point communications. That is, I don't try, or even want to, support all of the features such as fragmentation, collision detection and recovery, internet connectivity etc. But a more constrained approach is very useful, and not at all a security risk. ( In fact I believe that an FPGA based internet appliance has great potential as an internet security product... any takers out there? ). You can even connect multiple nodes through a switch by implementing the discovery and broadcast modes of the ARP packet. A node can be another FPGA  or software running on a PC. Data packets can be anything that you want or need to define them as. It's all very doable in a slow grade Artix or Spartan 6 grade device. When I say ideal, I'm mostly referring to the physical connectivity which is full duplex, magnetically isolated, and has cheap cabling available at the local hardware store. The older generation of 1 GbE PHYs are  remarkably robust for packets with payloads < 16 KB over 2-3 meter CAT5 cables, even without error checking. It's almost too good to be true. Kudos to Digilent for designing their boards with a 1 GbE Ethernet PHY that comes up ready to rock.

Another aspect of Ethernet verses other serial interfaces like USB is that packet size is variable, packet definition is a blank slate ( past the synchronizing preamble ) and software doesn't affect its performance. USB performance is very dependent on OS kernel performance and driver/application design; and latencies are unpredictable and generally very long. You can have  synchronization timing in the 10s of ns range over Ethernet. If you have a PCIe FPGA board with a 1 GbE PHY in your PC you don't even have to think about packets ( in the software application ); you can just DMA streams of data. Ideal for someone like me who hates writing software applications. The catch there is the OS driver.

It does take a bit of work to figure out. UltraScale devices make the PHY interface more complicated and the Vivado IP is total nonsense. It's well worth the effort and hours spent learning. A lot of the learning for me was spent creating experiments. Playing for fun and education is even more useful for competent FPGA developers than it is for those just trying to learn it.

 

Edited June 20, 2023 by zygot

[zygot]

If I wasn't clear about FPGA applications for internet security, I'm referring to an entire design implemented in HDL logic with no processor involved.