02-06-2019 07:15 AM
I have a question concerning the internal machinery of an AXIS Data FIFO.
I inserted such a FIFO between a producer that writes bytes at a constant speed of 100 MB/s,
and a consumer that reads bytes at an average (non-constant) speed of 150 or 200 MB/s
(its clock is still an option, but it is strictly greater than that of the producer).
Therefore, the FIFO works with two different clocks, and its depth is chosen so that it is
guaranteed that it will never become full, and there will always be room to accept data from
the producer (I don't care about exceptions, such as a reset, or during startup).
In this scenario, there is no reason for the slave interface to lower TREADY and block the
producer, so the question is:
Is it guaranteed *by design* that, in a standard FIFO, S_TREADY will be *always* high if
the slave clock is faster that the master clock (at least by a sensible factor, like 1.5 or grater) ?
Or could it be possible that some internal FIFO housekeeping may block the producer anyway ?
But for how many cycles, and with what frequency ?
I have never seen a not-TREADY cycle during a simulation of a FIFO configured like that,
but that means nothing, may be it can never happen during a simulation, or may be it is a quite
The problem seems critical to me, since there are producers that cannot be stopped
(such as a serial transceiver receiving data): if I don't want to loose data, I have to insert
a buffer between the transceiver and the inconstant consumer. A standard FIFO could be fine,
but only if it is always ready to accept data.
If not, some custom structure must be built, which is guaranteed to accept data without inserting
any wait states.
Thanks for helping.
02-12-2019 04:23 PM
I need to check with engineering on your question. Could you confirm a few things for me:
1. You are asking about the AXI4-Stream Data FIFO in PG085, correct?
2. Which version of Vivado are you targeting?
02-12-2019 11:32 PM
thanks for helping.
I use the standard FIFO of PG085 Infrastructure IP Suite v3.0, under Vivado 2018.3. I don't plan to go back to earlier versions.
I would like to add a remark to what I asked. A 'dual' scenario is possible, which prompts for the same question.
If I insert an asynchronous FIFO between a (fast) producer at 200 MB/s, and a (slow) consumer at 100 MB/s that cannot be stopped, is it guaranteed that, at the master FIFO interface, a datum will always be valid (that is, available to the consumer), if the FIFO is not empty (I can guarantee by design that it will always be almost full)? Always valid means that TVALID will never become low (because of internal housekeeping, for example), leaving the consumer without input data.
02-26-2019 04:21 PM - edited 02-26-2019 05:34 PM
If your consumer is always faster than the producer you should never encounter a not-ready condition (that is, have backpressure) from the FIFO slave port. But, you haven't told how long the consumer idle times are. The bigger these are, the bigger your FIFO will need to be to cover over those cases.
You can check this behavior by inserting a System ILA into your design on the slave port. If the FIFO is sized appropriately, you should always see TREADY be high. If the FIFO is too small, it will fill and stall during one of the consumer's idle periods.
Here's a link that shows an example FIFO depth calculation: http://www.asic-world.com/tidbits/fifo_depth.html. I'm sure there are others, but this gives a starting point.
02-26-2019 11:42 PM - edited 02-26-2019 11:48 PM
Hello @vortex1601 ,
thanks for your answer. As I said, I can guarantee by (my) design that the FIFO will never be full (or empty), what I'd like to know is:
Of course, it is obvious that the not ready/not valid condition, should it happen, will be very short in time, like one or two clock cycles, and possibly rare, say one every 10^12 transfer, or 10^15.
These are questions that should have a definite answer (yes, it happens sometimes, or no, it never happens) looking into the internal machinery of the FIFO (with or without different clocks). If the failure is rare, I'll probably never see it with a ILA, but I need to know if it can happen or not.
02-27-2019 08:05 AM - edited 02-27-2019 08:12 AM
The FIFO should never give TVALID unless there’s data in it. It *may* bring it low during an almost-empty case depending on how the flag logic works and how it interacts with pipelining.
Likewise, with TREADY and the almost-full case.
If this is of concern, and you see it occurring, you can use the almost-empty and almost-full comparators for flow control. These indicators would replace master TREADY and slave TVALID, respectively.
Or, verify by simulation, taking note of how the FIFO pipelining and clocking is configured.