# minimum depth for data streaming through async fifo

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

Originally Posted by FvM
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.
#3 already says the two clks are frequency locked. for 100MHz, 2 flops are sufficient for sync. what other info is missing?

•

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

Originally Posted by stanford
#3 already says the two clks are frequency locked. for 100MHz, 2 flops are sufficient for sync. what other info is missing?
This post #3 does not say the clocks are frequency locked
Originally Posted by stanford
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.
It says they are equal in frequency (a vague description of clocks if you ask me).

Clocks in many systems maybe the same nominal frequency, but are NOT locked to each other and therefore exhibit an absolute difference in their frequencies that can result in phase drift between the two clocks. There are no 0 PPM clock sources.

Unless you specifically state that the clocks are PHASE and/or FREQUENCY locked we can be sure if they are or not, hence all the questions and assumptions made.

If they are frequency locked you might not even need a FIFO (depends on why there is a phase difference) and can treat it as a synchronous transfer.

•

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

This post #3 does not say the clocks are frequency locked

It says they are equal in frequency (a vague description of clocks if you ask me).

Clocks in many systems maybe the same nominal frequency, but are NOT locked to each other and therefore exhibit an absolute difference in their frequencies that can result in phase drift between the two clocks. There are no 0 PPM clock sources.

Unless you specifically state that the clocks are PHASE and/or FREQUENCY locked we can be sure if they are or not, hence all the questions and assumptions made.

If they are frequency locked you might not even need a FIFO (depends on why there is a phase difference) and can treat it as a synchronous transfer.
3. the two clks are frequency clocked but they are considered async to each other.

This #3 is mentioned in another post.

You should take the description as is. When I said equal, this should imply that their frequencies are absolutely the same. Why would you go assume they are not, though it may not be practical?

•

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

Originally Posted by stanford
You should take the description as is. When I said equal, this should imply that their frequencies are absolutely the same. Why would you go assume they are not, though it may not be practical?
Take two clock oscillators and they are both 100 MHz then they have equal frequencies yes? According to your logic they are absolutely the same, which is absolutely wrong.

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

Hi,

even "locked" clock signals will move.

But how much?

It depends on
* the stability of the input clock
* the division and multiplication factors (if analog PLL)
* the lock mode
* the feedback filter
* the VCO stability

I won´t be surprised if it will move more than "several x 360°" (several output full waves). Yes, in "locked" state!
(high division factor, high multiplication factor, unstable input)
... because the phase comparator just sees the divided phase.
With a multiplication factor of 1000 (for example) the phase comparator just sees 0.36° when the output clock is shifted by 360°....

But how can we know?

Klaus

--[[ ]]--