hi all,
I have a counter running at 50 Mhz . Now i have to sample that counter at 77 Mhz.
My question is can i sample the counter running at 50 mhz directly with 77 mhz clock or should i synchronize the 50 mhz counter to 77 mhz clock domain and then only sample it.
what are the effects if i don't the sample the 50 Mhz counter and i directly sample with 77 Mhz.
rgds, prav
Hi Prav,
what do you mean with 'sample the counter'? Can you explain what you mean more in detail?
Rgds Andre
Problem is that no matter how you re-sample it, you are sending multiple data bits (the counter output word) across clock domains, and you have the potential of getting incorrect data. I faced a similar problem, and I chose to convert the counter output to grey code, sample it in the new clock domain, and then convert back to binary. With grey encoding, only one bit changes at a time as you count up or down, so you cannot get incorrect data, even when there is a race condition when you re-sample.
Barry Brown
If you do not want to convert to Gray code, you can also sample it continuously and always compare the new sampled value with the previous one. If they are identical, they are both good, if not, just continue until you get a valid pair. This method may have a problem when your (continuous?) count rate and sample rate are so close together. There are several ways to solve your problem, but you must realize that this is a complex issue, not to be ignored.
Peter Alfke ===========================
What do you expect to happen? Are you meeting setup and hold times? If not, you might get any sort of answer, including metastability.
I don't know of any easy way to do what I think you want to do.
I would probably make a duplicate counter running off the 77 MHz clock and only enable it at 50 MHz. That is, send the LSB of the
50 MHz counter through the classic double FF synchronizer and then use any change in that signal as an enable pulse for the 77 MHz counter.That will give you several cycles of delay. You can reduce that some with a bit of work. Or figure out how much delay there is and correct in software. Or ...
-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
As others have said, you can't sample the counter directly because doing so is inevitably going to result in some samples grabbing some bits from the previous count and some from the current count (due to sampling right as the count advances), which will generate some corrupted count values (consider the case where the counter goes from "01111111" to "10000000": all the bits are changing.
There are several valid ways to attack this. One is using grey code so that only one bit changes at a time where you cross the clock domains. You can also use a holding register and semaphores, or use a small FIFO, or ....
prav wrote:
--
--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
Here's an idea that I had. You'll have to be able to tolerate several clocks of delay though.
1) Run the output of the counter to a set of D flip-flops clocked at 50MHz so the counter is continuously sampled.2) Take a signal from the 77MHz clock domain that indicates you want to sample the count and run it through a couple of DFFs clocked at 50MHz to convert it to that clock domain.
3) Use this output to disable the DFFs sampling the counter.4) Take this disable signal, and run it back though a couple more DFFs, this time clocked at 77MHz, to generate a data valid signal in the 77MHz clock domain.
Good luck. Let us know ultimately what ended up work> If you do not want to convert to Gray code, you can also sample it
Hello, Prav.
The best way is to go with gray code conversion before sampling it with 77 MHz.
Vladislav
Converting to Gray code will work, although I think it's overkill. When I do this kind of thing, I use the holding register/semaphore approach mentioned by Ray.
However, if you do decide to use the Gray code approach, BE CAREFUL! Yes, successive Gray codes differ by only one bit. But if you feed a binary counter into a combinatorial binary-to-Gray-code converter, you may see decoding glitches at the output of the converter when the counter increments. Take a look at the typical binary-to-excess-3-gray-code converter--which is just a bunch of XORs of successive binary bit pairs--and it's easy to see how glitches can happen. For example, the LSB of the Gray code is the XOR of binary bits 0 and 1. What happens to the Gray code LSB if the binary LSBs change from 01 to 10, or from 11 to 00? (As I write this, I'm looking at a diagram of the converter on page 5-44 of National's 1987 FAST Applications Handbook, based on material written by one Mr. P. Alfke. The man is everywhere.)
There are any number of ways to get around the problem, such as using a Gray code counter in the first place, or clocking the converted value into a 50 MHz register before sampling it with the 77 MHz register. The take-home point is this: unless you've done something very clever, a binary-to-gray-code converter driven by a binary counter is not guaranteed to be glitchless, and you cannot safely sample it with an asynchronous clock.
Bob Perlman Cambrian Design Works
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.