Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

minimum depth for data streaming through async fifo

Status
Not open for further replies.

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Activity points
2,223
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!
 
Last edited:

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?
 

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.
 

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!
 

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
 

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.
 

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.
 

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

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
 

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.
 
Last edited:

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.
 

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.
 

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.
 

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.

Thus we asked for clarification.

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

Klaus
 

Hi,


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

Thus we asked for clarification.

****

Just think about this information.
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?
 

Hi,

please understand, it's impossible to give a good answer without knowing details about your both clocks.

If you need answer:
Please clarify all the doubts and questions we have written..

Klaus
 

Hi,

please understand, it's impossible to give a good answer without knowing details about your both clocks.

If you need answer:
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?
 

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top