Why gray counters work?

[shaiko]

Hello,

When designing an asynchronous FIFO - Gray counters are used for the pointers.
This is because - Gray has the benefit of not more than a single bit is changed between adjacent count values.

But what if the frequency ratio between clock domains is so big that more than one value is incremented during one period of the slow clock domain?

Won't the slow clock domain again see more than one bit change between cycles (the same problem that exists with binary counters)?

 

[std_match]

No, the reading side always takes a "snapshot" of the counter value, so it will see a stable value or a transition between two adjacent values.
It doesn't matter how often the snapshot is taken.

 

[shaiko]

Please elaborate...
The write clock domain is 10 times faster than the read clock domain.
Suppose no writes occurred for a long time (the value of the counter on the write domain is the same as in the read domain) and it's decimal 3 (which is 00000010 in code gray)
Now, 2 consecutive writes occur - the counter value on the write side increments very quickly to decimal 4 and then to decimal 5 (which is 00000111 in code gray).
The read clock domain has a 00000010 snapshot and it changes immediately to 5 00000111 - effectively a double bit change.

 

[FvM]

If more than one bit changes during a slow clock period, the gray counter isn't reliable any more.

 

[shaiko]

If more than one bit changes during a slow clock period, the gray counter isn't reliable any more.

As I think of it - perhaps it's not the value between snapshots that's important...
But instead, the value of the gray counter as it's presented to the read clock domain by the combinatorial logic that generates it.

What I mean is, that the value held by the snapshot plays no role here.
Even if we'll see a 2 bit change in the snapshot - it's irrelevant.
The only important thing is that the logic that creates the gray code - will change one bit at a time.
In this case, the sampling registers will see the input changing from 4 to 5 (not from 3 to 5) - even if the old snapshot is 3.

What do you think?

 

[FvM]

In the present example, transition from 3 (gray 010) to 5 (gray 111), the problem is that you may also see an intermediate gray code of 011 (value 2), which is outside the transition range.

 

[shaiko]

In the present example, transition from 3 (gray 010) to 5 (gray 111), the problem is that you may also see an intermediate gray code of 011 (value 2),

Not if the output of the combinatorial logic is also registered...

- - - Updated - - -

I.E - if you take away the hazards by registering the output of the gray generation block and watch the output of that register - you'll see only single bit changes every write domain cycle.

 

[std_match]

If more than one bit changes during a slow clock period, the gray counter isn't reliable any more.

This is not true. The clock period of the reader doesn't matter, but of course some values will be missed/skipped if it is longer than the counter period.
The Gray coding ensures that only one bit can be uncertain when the counter is sampled by the reader, and both values can be considered "correct" (after metastability elimination).

To get into trouble, the counter period must be so short that the skew between the bits must be considered, but this has nothing to do with the clock period of the reader.

The Gray coded counter values are generated by a "normal" counter followed by some combinatorial xor logic. The resulting value must be registered before it is routed to another clock domain, otherwise the Gray coding is meaningless. Before the register, multiple bits can change (glitches) when the counter value changes, but after register only one bit will change.

 

[FvM]

O.K., I see your point. Due to the single bit transition, the receiver is either sampling the previous or the new counter value (after synchronization) but never a different one. So he can't get a wrong counter value.

Sorry for causing confusion. Thanks!