# Comparing counters in two different clock domains

Discussion in 'VHDL' started by nfirtaps, Nov 30, 2006.

1. ### nfirtapsGuest

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?

nfirtaps, Nov 30, 2006

2. ### Kim EnkovaaraGuest

nfirtaps wrote:

> 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

Kim Enkovaara, Nov 30, 2006

3. ### nfirtapsGuest

Kim,

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

Would this be a grey code diagnosis?

Thanks,
Lloyd

Kim Enkovaara wrote:
> nfirtaps wrote:
>
> > 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, Nov 30, 2006
4. ### Nicolas MatringeGuest

nfirtaps a écrit :
> Kim,
>
> 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
>
> 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

Nicolas Matringe, Nov 30, 2006
5. ### Ray AndrakaGuest

nfirtaps wrote:

> Kim,
>
> 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
>
> Would this be a grey code diagnosis?
>
> Thanks,
> Lloyd
>
>
> Kim Enkovaara wrote:
>
>>nfirtaps wrote:
>>
>>
>>>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

>
>

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.

Ray Andraka, Nov 30, 2006
6. ### Nicolas MatringeGuest

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

Nicolas Matringe, Nov 30, 2006
7. ### nfirtapsGuest

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?

Nicolas Matringe wrote:
> nfirtaps a écrit :
> > Kim,
> >
> > 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

nfirtaps, Nov 30, 2006
8. ### Ray AndrakaGuest

Nicolas Matringe wrote:

> 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

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
of all that way, and synchronization is kept simple.

Ray Andraka, Nov 30, 2006
9. ### Ray AndrakaGuest

nfirtaps wrote:
> 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.

Ray Andraka, Nov 30, 2006
10. ### nfirtapsGuest

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 wrote:
> nfirtaps wrote:
> > 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, Nov 30, 2006
11. ### Ray AndrakaGuest

nfirtaps wrote:

> 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.

Ray Andraka, Dec 1, 2006
12. ### Mike TreselerGuest

nfirtaps wrote:
> 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, Dec 1, 2006
13. ### Mike TreselerGuest

Mike Treseler wrote:

> 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
> single clock enable strobe the width of the fast clock period.
>
> -- Mike Treseler
>

Mike Treseler, Dec 1, 2006
14. ### nfirtapsGuest

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

Mike Treseler wrote:
> Mike Treseler wrote:
>
> > 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
> > single clock enable strobe the width of the fast clock period.
> >
> > -- Mike Treseler
> >

nfirtaps, Dec 1, 2006