0

enter image description here

In the FIFO design, to compare the rptr and wptr, we are feeding one signal into another clock domain.

The rptr which is coming from the slow clock domain to faster one can be synchronized with sync Flip-flop logic explained in the beginning.

However, the wptr which is coming from fast clock domain to slower clock domain and it cannot be synchronized.

For example, If Write clock faster 10 times than Read Clock, then sync_w2r doesn't sample the wptr which is based on wclk.

enter image description here AS you can see the above waveform, din[10:0] on the write(fast) clock is sampled by read clk clock(slow). and the din is a write pointer which is encoded by Gray. and dout[10:0] is a signal synchronized signal by read clock(slow)

Actually Gray Encoded pointer signal(dout[10:0]) looks not having a continuously sampled by read clock. you can see the dout[10:0]. It causes a race condition problem. Even Gray encoded signal is synchronized by 2 stage flip-flops. but gray encoded signal does not work to avoid race condition issue at the each of edge sample clock. 1(sampled)-3-2-6(sampled)..go on.. it's actually 2 bits signals were changed from 2'b001 to 2'b110.

how can we explain the Gray encoded signal can be used to avoid a race-condition problem?

How is the problem solved?

Carter
  • 581
  • 2
  • 6
  • 23
  • What do you mean by "doesn't sample"? – user253751 Feb 16 '21 at 15:53
  • @user253751 sync_w2r sampled by rclk. it's slow for sampling a wptr – Carter Feb 17 '21 at 01:12
  • 1
    There is a whole paper on this by Cummings. + There are many resources in online. Closing. – Mitu Raj Feb 17 '21 at 04:54
  • There is no 'missing'. Even if write clock is 10 times faster, read clock will sample it at some point in future. Suppose, by the time read clock arrived, write pointer has just counted up to 3 from 0. The read clock will never sample a 'wrong' value because of gray encoding. It will either be the older value of the write pointer, 2 or the current value of the write pointer, 3. – Mitu Raj Feb 17 '21 at 06:49
  • Metastability is a different issue than clock-domain crossing. – Ben Feb 18 '21 at 13:48
  • @Ben Metastability is caused by setup-hold timing violation. and also it happens in CDC domain. Usually, to prevent x propagation problem in CDC domain eventually we use 2 stage flip-flop. these came from the same issue and idea. – Carter Feb 18 '21 at 14:08
  • The gray encoding is used to prevent race conditions from CDC, not prevent metastability. Simply my point. – Ben Feb 18 '21 at 14:23
  • @Ben Good point. Yes. gray encoding is used for preventing race condition. but maybe you saw the waveform, the sampled gray encoded signal at clock edge does not have a continuous of gray encoded code at the 2 stage flip-flop. it means that the race condition signal might can go into 2 stage flip-flop. In other word, gray encoder doesn't need it. this my question. and also missing some numbers during a process – Carter Feb 18 '21 at 15:06
  • 1
    @Carter, Dave Tweed has already answered your question about missing sequence numbers, i.e. a slow clock will always miss some clock events of a faster clock no matter whether it's sampling a Gray counter or a binary counter (and the sync buffer will ensure a valid sample whether delayed or current). As for races, the frequency of `wclk` needs to be lower than `FMAX` of the design to ensure timing closure, i.e. to prevent unfinished combinational logic that generates `wptr` overlapping setup and hold times of the sync buffer flip flops. – tim Feb 18 '21 at 15:58

1 Answers1

4

Obviously, the slow side of the FIFO is not going to see every state of the fast-side counter when it is counting at full speed. Fortunately, with proper design, such as using Gray code to transfer the values between clock domains, this doesn't matter at all. When the slow sample occurs, it will get some valid value of the fast counter, or at worst, one of two adjacent values if a bit happens to go metastable.

And of course, once the fast side pauses in its counting, the slow side will get the correct final value of the counter after the synchronizer delay.

I wrote this up in a lot more detail here: gray code clock domain crossing FIFO fast to slow

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393