There is a simple way of avoiding "mysterious glitches" when using
binary counters: freeze the counter in a second register in the first
clock domain and do a one bit handshake across the two domains. Since
the counter (copy) is frozen during the handshaking, the other clock
domain's FFs will have ample setup time until the strobe propagates
through the resync.

With a fully resync'd handshake, this approach does introduce up to 3x
clock1 + 1.5x clock2 cycles delay between update, which is certainly not
suitable for low-latency and small high-speed FIFOs, especially if there
is a large difference in clock speeds. It works well as long as one can
live with long status delays for the first (read) and last (write) few
FIFO words.

The design is nice as long as clocks are of similar frequencies but the
delay may become an issue for large read:write (and vice-versa) clock
ratios. At 10:1, the status update may have a latency exceeding 40 fast
clock cycles.

So, binary counters can be safely used by using frozen copies and
handshaking. The caveat is higher latency than gray counters due to
handshaking and register copies that add extra dependencies upon the
other clock domain.

As always, designers are free to pick their poison.

Peter Alfke wrote:
> In an asynchronous FIFO, reading and writing is controlled by two
> counters with independent clocks.
> If you need to detect FULL or EMPTY, you compare the two counters for
> identity.
> If you do that with binary counters, you are vulnerable to strange
> decoding glitches, while multiple binary bits change (almost, but not
> quite, simultaneously). You never have that problem with Gray counters,
> where only one bit changes, from one state to the next.
> Peter Alfke
> =============
> RCIngham wrote:
>>> There is a wrong way and a right way to convert binary to Gray count
>>> values:
>>> The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
>>> on the binary outputs. That does you no good, since the Gray code will
>>> just reflect the binary transient errors.
>>> The right way takes the D inputs of the binary counter (, converts them
>>> independently to Gray and registers them in their own flip-flops. Now
>>> you have two parallel rgisters, both counting in step, the first in
>>> binary, the other in Gray, and there are no funny decoding spikes.
>>> BTW, only Gray counter outputs have the feature that you can compare
>>> two asynchronous counters for identity, without transient errors.
>>> If the Gray code does not come from a counter, it might change multiple
>>> bits per transition...
>> <snip />
>> Whether that is the right answer rather depends on WHY the OP "has" to use
>> Gray Code, which is still not fully established.
>>
>> BTW, there is a quite interesting article on Gray Code just posted at:
>> http://www.pldesignline.com/showArti...leID=196604078
>