why to use FIFO on FPGA?

Unfortunatly you cannot use shift registers where you need to transfer data from a high speed input to a low speed output for example.The uses of fifos are too numerous to list here but they are very useful so thats why people use them,and have done for many years its just that xilinx have them as part of some of their FPGAs.

FIFOs,

Are useful as a means to synchronize the passing of data between asynchronous clock domains. If you need to communicate both data, and when the data is ready, between two clock domains that are not the same in both frequency and/or phase, a FIFO is a universal means to allow the two clock domains to communicate without error.

To synchonize events in one domain, to another domain requires the use of synchronizing circuits which are notorious in that engineers often get them wrong (they implement ones that do not work). At Intel, there are only a handful of senior engineers who are allowed to do synchronizer circuits.

One of my first ever crisis cases at Xilinx was one where a cutomer had occasional errors in their application, which seemed to come and go at random. They blamed it on different lots of our silicon. Some lots they claimed, were worse, and some were not as bad.

Well, it turned out that the bad lots were slightly slower (but well within specifications), and the good lots (which still had the problem, but not as often) were slightly faster.

The speed difference made a poor FIFO design using CLBs have more (or less) frequent problems. In no case was their FIFO design good. It was always capable of failing, as they spun their own control, without regard to what an incredibly difficult problem it is.

For example, what if the FIFO says it is ready with data to read, when it is not? That leads to a failure. What if it says it is ready to accept data on a write, when it is full? Also, a failure.

Think about your gas gauge saying that you have gas, when you do not: not acceptable.

But, there is a way to design a FIFO to be foolproof, even though in theory, that is impossible (without latency). So, if we do it for you (in hard logic), it saves you from making a very common mistake.

By the way, the secret to low latency synchronization in FIFOs is that the gas gauge could say the tank was empty, when it was not, and then go back to being less than empty without causing any problems (thanks to Peter for this analogy).

If you used our soft core FIFO (previous to V4), you would also be safe. But many looked at the FIFO IP, and said to themselves "I am smarter than that -- look at all the wasted logic to do such a simple job!"

Sadly, it is not a simple job. Peter and I were in a 2 day class just last week on just this subject (asynchronous design, and communications between clock domains in large systems). Heck, Peter 'invented' the FIFO back at Fairchild!

Even us "more experinced" engineers realize that we can (must) learn new things.

Since the FIFO is built into the hardware, I imagine it is trivial to instantiate. Let us know if the HDL primitives are in Webpack. It would make no sense to Xilinx not to promote their use, as they prevent engineers from doing things the wrong way, and allow you to pack more into your design, and achieve higher performance.

Austin

snipped-for-privacy@gmail.com wrote:

And even if you only have a single clock domain you use a FIFO in hardware for all applications that you use a FIFO in software, albeit in software the name Queue is more often used.

snipped-for-privacy@gmail.com wrote >If it's more like temporary memory, then why not just use intermediate >signals to store input signals and delay them (use shift register) a >specific number of clocks if needed?

In a shift register you delay data for N cycles. In a FIFO you delay up to N data words as long as necessary.

Kolja Sulimma

Here are my 2 cents: I call a FIFO an ideal "Black Box", where you clock data in on one side, and pull it out with a different clock on the other side. And you need not worry about frequency or phase differences between the clock, and how much or how little data is in the FIFO (until you reach full or empty.) What makes a FIFO with independent clocks so attractive to the user (its simplicity), makes it really tough on the black box designer, for whom all problems stem from the unknown phase relationship between the two clocks. That's why there are Gray-coded counters and sneaky resynchronization circuits that are (almost) immune to metastable problems. Metastability is covered up by extra latency that releases empty a clock tick later than theoretically possible...

Long answers to a short question. Each BlockRAM in Virtex-4 has a FIFO controller buried in the BlockRAM. Not very big since it is done in dedicated hard logic, but saves the user all the work and also all the thinking. And we tested it with 10e14 resynchronizing cycles at 500 MHz clock rate, with no failure. Peter Alfke, Xilinx Applications (from home on a rainy Saturdey)

Well, sometimes it is the case. Have a look at Altera's NCO/DDC megafunction and related examples. They explicitly generate a pair of sine and cosine waves and then pass it to a mixer composed of two rapid multipliers. This consumes many LEs, even on Stratix, if the NCO uses the CORDIC approach. I have done a better and smaller DDC/DUC without multipliers on Cyclone. Simply, the algorithmic approach is a bit more sophisticated.

Best regards Piotr Wyderski

Piotr,

A comment on the soft cores (IP) of Altera, or Xilinx in general.

Basically, soft IP (cores, or functions) need to be:

• bullet-proof (fool-proof)

• easy to use

• versatile

• configurable

What these constrains lead to are cores that are generally not optimal for any specific function, but do the job.

Any given core can probably be trimmed, modified, sped up, and improved.

The FIFO core is one where that would be very dangerous, unless you were familiar with FIFO design, synchronizers, and asynchronous logic fundamentals.

Many engineers are very smart, and can do a better job on any specific function (for their particular application). I would caution against it when dealing with synchronizing elements, like FIFOs.

But, I would also caution that if you think you can do a better job, remember that verification is 90% of the work. Anything you modify, or improve makes you responsible for its verification.

As I design for the next technology node, I look at what others did before me, and if I think I can improve upon it, I first ask:

- why did they do it this way?

- what may be other functions of this block that I am ignoring?

- is there something I am not considering?

- am I prepared to verify what I have changed?

- do I have access to the test benches and simulations that were done by the prior owners?

- what will I accomplish by my changes?

- am I better off working on something else?

- does it make business sense?

Remember the classic engineering maxim:

"If it ain't broke, don't fix it."

Austin

Piotr Wyderski wrote:

In addition to async clock domains as other have mentioned, I have a case where a data stream is split into MSBs and LSBs. The LSBs undergo some processing that takes several hunded clock cycles. The MSBs pass through, but need to be aligned with the output associated with the original LSBs with which they were paired. I *could* make 500 F/F long shift registers, but a block RAM based FIFO is must more efficient.

I had another case where a PC would send commands to a FIFO, and the circuitry would fetch and process the commands in its own time, but gueess that's just another example of async clock.

I have one case now where the clock is the same frequency on both sides of the FIFO, but the input clock is a fairly low quality (unavoidable... long story) while the output clock is a low phase noise uberclock divided from a faster clock. The clocks are coherent, but only through a large external loop involving a fractional-N PLL and other synthesis. Rather than trying to time up two clocks like this, it's far easier to just pass the data through a FIFO and not even worry about it. So it serves two functions: reclocking to a *cleaner* clock domain and avoiding a gnarly timing situation.

The real fun is if you have a situation like one of my designs where the data propagation delay through the FIFO of has to be identical from reset to reset within a certain spec.

Synchronous reset of input and output pointers? Synchronous to which clock? Say you use the input clock. When that reset deasserts, the rising edge of the output clock can be anywhere within the period of the input clock (it's *asynchronous*) thus causing a prop delay uncertainty of one period on the input clock.

Does not seem a big deal unitl I realize the clock period is 40 ns and my uncertainty spec is 5 ns. :(

I did solve it, BTW, but as it might be patentable, I cannot speak of it. :)