# minimum depth for data streaming through async fifo

1. ## minimum depth for data streaming through async fifo

Suppose read/write clk frequencies are EQUAL but are async. What is the minimum depth of async fifo required to stream data through it and why?

Thanks!

2. ## Re: minimum depth for data streaming through async fifo

When you say frequency, do you mean ratio of writes to reads? Or are you referring to a FIFO being used to cross clock domains and therefore actually has two clock frequencies?

3. ## Re: minimum depth for data streaming through async fifo

Originally Posted by ThisIsNotSam
When you say frequency, do you mean ratio of writes to reads? Or are you referring to a FIFO being used to cross clock domains and therefore actually has two clock frequencies?
you want to write every clk and read every clk. it is transferring data through async fifo every clk. write and read clk are equal in freq but async.

4. ## Re: minimum depth for data streaming through async fifo

Suppose read/write clk frequencies are EQUAL but are async. What is the minimum depth of async fifo required to stream data through it and why?
What are the widths of the data bus on the write side and read side?

To determine fifo depth the data rate for the read and write side must be determined. In your question this info is missing!

•

5. ## Re: minimum depth for data streaming through async fifo

Hi,

The important question:
When the clocks are the same frequency ... why are they async? Canīt you use the same clock and avoid FIFO at all?

If not possible:
How are they synced?
If PLL or DLL it needs some feedback... how is the feedback signal generated?

***
The FIFO depth: Iīd say it depends on the absolute phase_deviation_range.

***

Example CD player. (Not knowing if realistic)
* The motor spins --> data is read from CD --> data is stored in a FIFO.
* with a fixed data rate (44100 Sampl/s) the data is read from FIFO.
* The motor RPM is controlled (feedback) with the number of data stored in FIFO
letīs say the designer decided to keep the data of two complete revolutions (at 200 RPM) in the FIFO to be accessed in case of read errors.
200RPM = 300ms
2 time = 600ms
at 44100Sampl/s --> 26460 samples. (ignoring channel count and data width)

This is the setpoint for the motor RPM regulation loop.

But during regulation the motor will spin temporarily faster, thus maybe it is half a revolution ahead.
This means 150ms which causes 6615 additional samples.

Thus one would need a FIFO with about 33k Samples depth.

***
Even if you have a more "fixed" data rate: Either the READ or THE WRITE frequency needs to be adjusted (feedacked) to avoid an unknown constant number of data in the FIFO.

Klaus

6. ## Re: minimum depth for data streaming through async fifo

I think the question is about the necessary delay from input to output for an async FIFO. It takes a few clock cycles (read clock domain) before written data appear on the read side, and this delay corresponds to the minimum necessary FIFO size.
The delay depends on the implementation of the internal clock domain crossings in the FIFO, but I think 3-4 clock cycles is normal.
A simulation should be done with the FIFO to see the delay from input to output.

7. ## Re: minimum depth for data streaming through async fifo

I read "frequencies are EQUAL but async" as CLK2 is derived from CLK1 with fixed delay. Write and read is either interleaved or worst case simultaneous. The minimum depth depends on the FIFO design details like synchronizer delay, depth of 2 is minimum without considering extra delay. My FIFO IP can be configure for depth of 4 minimal.

8. ## Re: minimum depth for data streaming through async fifo

I hate these threads. Everyone assumed a wildly different scenario. All answers might be right, all answers might be wrong. Sigh.

9. ## Re: minimum depth for data streaming through async fifo

Hi,

Maybe some members hate me because I always request specifications....

Without specifications we have to guess. And guessing means - one canīt be sure.
Itīs not much more better than trial and error.

Klaus

10. ## Re: minimum depth for data streaming through async fifo

Maybe some members hate me because I always request specifications....
It is a good thing to do. But how much patience do you have to push the OP such that he/she comes out with the right question supplying the right amount amount of info.

I hate these threads. Everyone assumed a wildly different scenario. All answers might be right, all answers might be wrong. Sigh.
+1
The OP should have been specific else the thread can easily deviate out of topic.

Suppose read/write clk frequencies are EQUAL but are async
That is perfectly legal. Two clocks can only be sync only if they have the same source and no modification in between. In any other scenario they should be considered async.

•

11. ## Re: minimum depth for data streaming through async fifo

Another question is...
Are the clocks frequency locked, but skewed or truly asynchronous and have the same nominal frequency?

If the clocks are the same nominal frequency but are not from the same source clock then they will drift and your FIFO when written/read from on every clock cycle will eventually over/under flow, which translates to no depth is adequate.

This lack of specifications is an ongoing problem with questions on edaboard. It's the same with many companies and customers. I think it's rare to find someone who asks a "smart question" with enough detail to actually answer their question.

12. ## Re: minimum depth for data streaming through async fifo

Another question is...
Are the clocks frequency locked, but skewed or truly asynchronous and have the same nominal frequency?

If the clocks are the same nominal frequency but are not from the same source clock then they will drift and your FIFO when written/read from on every clock cycle will eventually over/under flow, which translates to no depth is adequate.

This lack of specifications is an ongoing problem with questions on edaboard. It's the same with many companies and customers. I think it's rare to find someone who asks a "smart question" with enough detail to actually answer their question.
Right. Another issue is that I don't know how experienced the OP is. I might come up with a super complex answer that relates to clock drift, domain crossing, glitches, etc. while the OP just wanted to know if his homework is going to get an A. Sigh. Triple sigh.

13. ## Re: minimum depth for data streaming through async fifo

So it sounds like you want depth of 3/4 to account for random sync delay.

I thought I've given enough info, not sure why you guys are making assumptions on top of it.

14. ## Re: minimum depth for data streaming through async fifo

Hi,

I thought I've given enough info,
Maybe you have .. but some things still aren`t clear to us because we donīt know all the details of your application.

****
Suppose read/write clk frequencies are EQUAL but are async
Isnīt this information true for every FIFO application? Otherwise you get overflow or underflow...which means data loss.

Klaus

15. ## Re: minimum depth for data streaming through async fifo

Originally Posted by KlausST
Hi,

Maybe you have .. but some things still aren`t clear to us because we donīt know all the details of your application.

****

Isnīt this information true for every FIFO application? Otherwise you get overflow or underflow...which means data loss.

Klaus
sorry, I meant to say the clk frequencies of read/write side of the fifo. You will always be writing/reading (streaming) data through the fifo at every edge. with the clk frequencies being the same, but async to each other, what is the minimum depth required?

16. ## Re: minimum depth for data streaming through async fifo

Hi,

Please clarify all the doubts and questions we have written..

Klaus

17. ## Re: minimum depth for data streaming through async fifo

Originally Posted by KlausST
Hi,

Please clarify all the doubts and questions we have written..

Klaus
1. write clock freq: 100 MHz
2. read clock freq: 100 MHz
3. the two clks are frequency clocked but they are considered async to each other.
4. uses async fifo to move data from write clk domain to read clk domain
5. data is written every clk edge to the fifo, and read every edge clk from the fifo i.e continuous stream of data forever
6. assume data is 8 bit wide (not relevant but someone asked)

What is the minimum depth required of the async fifo to achieve this?

•

19. ## Re: minimum depth for data streaming through async fifo

Originally Posted by FvM
why did you say depth of 4?

20. ## Re: minimum depth for data streaming through async fifo

Can you assure that the read clock will never overtake the write clock or vice versa? If not, you need to implement a mechanism for substituting respectively dropping some samples.

- - - Updated - - -

std_match has explained in detail. Not less than two, more likely three or four. Depending on the synchronizer design details.

- - - Updated - - -

If it's a real design question, you can simulate the existing logic. If it's an exercise problem, some information is apparently missing. Or it's an intentionally vague interview question.

--[[ ]]--