Comparing counters in two different clock domains

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

  1. nfirtaps

    nfirtaps Guest

    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
    #1
    1. Advertising

  2. 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
    #2
    1. Advertising

  3. nfirtaps

    nfirtaps Guest

    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


    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
    #3
  4. 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
     
    Nicolas Matringe, Nov 30, 2006
    #4
  5. nfirtaps

    Ray Andraka Guest

    nfirtaps wrote:

    > 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
    >
    >
    > 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
    #5
  6. 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
    #6
  7. nfirtaps

    nfirtaps Guest

    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,
    > > 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
     
    nfirtaps, Nov 30, 2006
    #7
  8. nfirtaps

    Ray Andraka Guest

    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
    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, Nov 30, 2006
    #8
  9. nfirtaps

    Ray Andraka Guest

    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
    #9
  10. nfirtaps

    nfirtaps Guest

    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
    #10
  11. nfirtaps

    Ray Andraka Guest

    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
    #11
  12. 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
    #12
  13. 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
    #13
  14. nfirtaps

    nfirtaps Guest

    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
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang

    Signals across two clock domains

    Weng Tianxiang, Dec 17, 2003, in forum: VHDL
    Replies:
    9
    Views:
    5,036
    Mike Treseler
    Dec 22, 2003
  2. JK
    Replies:
    1
    Views:
    836
    Mike Treseler
    Mar 24, 2007
  3. himassk
    Replies:
    1
    Views:
    1,255
    Paul Uiterlinden
    May 16, 2007
  4. bharath_r

    Show Pages from two different Domains

    bharath_r, Apr 3, 2009, in forum: ASP .Net
    Replies:
    5
    Views:
    631
    Alexey Smirnov
    Apr 3, 2009
  5. Beppe
    Replies:
    24
    Views:
    3,075
    rickman
    Dec 17, 2010
Loading...

Share This Page