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.
Actually its a long story.
Take an example where say n bit data is comming from a block A running at 100MHz, and going to a block B running at 133MHz. So to send the data from one clock domain to the other, ppl use Fifos. Now to reliably tell how much data is in the fifo which is being clocked by A clock i.e 100MHz, the write pointer of the fifo(which is also clocked at 100MHz in this example) would have to be read by a block B running at 133MHz. So I will use gray coded counters for this fifo pointer instead of normal binary coded counters, so that bclk B running at 133MHz could relibly capture the vlue of this pointer, which is being clocked at 100MHz. Since only one bit is going to change, for every count change these codes are very reliable. To know more do a google search for "async clock domains"
Actually I had written this before and I have just copy+pasted it from there, so if you want to find out more pls see:
You simplified the problem too much. The problem is that we don't know which clock is faster.I.E: clk_A can be 125Mhz and Clk_B is say 30Mhz or vis-a-versa. We don't know! I am familiar with async handshaking techniques which usually deal with handshaking data from a faster domain to a slower or from a slower domain to faster one. This problem is for passing data from an unknown clock domain to another unknown domain. Interesting huh?
The frequency numbers I have stated are just examples. In fact a fifo with gray address counters, would work in your scenario as well. Why would you think its not going to work,
lets say CLK_A is the sending clock and is running 10 times faster than CLK_B. Then regardless of gray coding, CLK_A could send 10 data and clock B only sees one data. I think what you were eluding to was to grey code the counter, send it over and use it to latch the data in the receiving block but this is risky too because a noise on the line could corrupt the data.