Comparing counters in two different clock domains

[nfirtaps]

Without getting into gruesome detail here, I am trying to find the
difference between counters in two different clock domains. I want to
ensure this difference is always valid in one of the clock domains. Is
there a way that I can do this sort of thing?

 

[Kim Enkovaara]

Without getting into gruesome detail here, I am trying to find the
difference between counters in two different clock domains. I want to
ensure this difference is always valid in one of the clock domains. Is
there a way that I can do this sort of thing?

There are many ways, but it depends on how accurate the result has to be,
what are the clock differences between the domains etc.

One way to do that is to gray code the counter in one domain and transfer
that to the other domain. Just remember the synchronizing flops in the
receiving domain. That ensures that the error is at maximum 1 and
the result is few clocks delayed from the real status. This is normally
used in fifos.

If the receiving clock is much faster than the other one then you can
also do for example oversampling of the signal and for example use voting
decide when the value has stabilized.

--Kim

 

[nfirtaps]

Kim,
Thanks for your reply.

The write side operates at 625KHz, and the read side at 48MHz. This
memory structure has 4 words written on a write cycle and 1 word is
removed every read cycle.

Would this be a grey code diagnosis?

Thanks,
Lloyd

 

[Nicolas Matringe]

nfirtaps a écrit :

Kim,
Thanks for your reply.

The write side operates at 625KHz, and the read side at 48MHz. This
memory structure has 4 words written on a write cycle and 1 word is
removed every read cycle.

Would this be a grey code diagnosis?

The simplest way would be to oversample the write counter with the 48MHz
clock and use the resync'ed value to compute the difference.
The write enable signal can be used to generate a flag which, once
sync'ed with the 48MHz clock, will indicate when the value is valid.

Nicolas

 

[Ray Andraka]

Kim,
Thanks for your reply.

The write side operates at 625KHz, and the read side at 48MHz. This
memory structure has 4 words written on a write cycle and 1 word is
removed every read cycle.

Would this be a grey code diagnosis?

Thanks,
Lloyd

Another option is to put both counters in the faster clock domain and
then resync and synchronous edge detect the count enable for the counter
associated with the slower domain.

 

[Nicolas Matringe]

Ray Andraka a écrit :

Another option is to put both counters in the faster clock domain and
then resync and synchronous edge detect the count enable for the counter
associated with the slower domain.

It may not be very practical if the slow counter is also used in the
slow clock domain, but it's definitely much simpler if it is not.

Nicolas

 

[nfirtaps]

Just to clarify oversampling the write counter means

process(fastclock)
if (fastclock'event and fastclock = '1') then
wcounterfastdomain <= wcounterslowdomain;
end if;
end process;

And I am to see no glitches with the wcounterfastdomain when using it?

 

[Ray Andraka]

Ray Andraka a écrit :



It may not be very practical if the slow counter is also used in the
slow clock domain, but it's definitely much simpler if it is not.

Nicolas

In that case, it is often easiest to maintain two counters (counters are
cheap in FPGAs), one in each domain. If this is for a buffer memory,
then it might be best to have an address counter in each domain plus an
up-down population counter in the fast domain, which would eliminate the
compare. The compare is the same cost as a counter, so you get the best
of all that way, and synchronization is kept simple.

 

[Ray Andraka]

Just to clarify oversampling the write counter means

process(fastclock)
if (fastclock'event and fastclock = '1') then
wcounterfastdomain <= wcounterslowdomain;
end if;
end process;

And I am to see no glitches with the wcounterfastdomain when using it?

Oversampling needs a qualifier with it to make sure you aren't sampling
the count while it is changing. If the clocks are not synchronous, you
WILL get bogus counts occasionally with this method because of it
sampling while the count is changing. Without a qualifier, this is not
a good approach.

 

[nfirtaps]

What sort of qualifier will I need? I cant think of a way to latch the
oversampled counter in only when it is valid.

Thanks,
Lloyd

 

[Ray Andraka]

What sort of qualifier will I need? I cant think of a way to latch the
oversampled counter in only when it is valid.

Thanks,
Lloyd

Synchronize the count enable or perhaps the counter's LSB to the faster
domain, and then synchronously edge detect that to obtain a one clock
wide valid pulse that is delayed from the counter transition.

 

[Mike Treseler]

What sort of qualifier will I need? I cant think of a way to latch the
oversampled counter in only when it is valid.

To the fast domain, the slow clock is just an asynch input, say
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,1,1,1,1,
Just synchronize it, count a couple fast ticks and make a
single clock enable strobe the width of the fast clock period.

-- Mike Treseler

 

[Mike Treseler]

To the fast domain, the slow clock is just an asynch input, say
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,1,1,1,1,
Just synchronize it, count a couple fast ticks^and make a

^
after a synch edge detect

 

[nfirtaps]

Thanks for your input guys, I hope to have this thing working soon.
Writing an asynchronous fifo memory structure is more tricky than I
thought it would be considering my background.

Take Care,
Lloyd