regarding synchronization

Discussion in 'VHDL' started by prav, Feb 18, 2004.

  1. prav

    prav Guest

    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
    prav, Feb 18, 2004
    #1
    1. Advertising

  2. You're going to have problems doing this no matter how you try.

    Don't forget Nyquist theorem, you should sample a signal at least twice as
    fast as it itself is expected to change. (i.e. 100MHz in your case)

    Anyways - What's the purpose of your project?

    Ben

    "prav" <> wrote in message
    news:...
    > 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
    Benjamin Todd, Feb 18, 2004
    #2
    1. Advertising

  3. "Benjamin Todd" <> wrote in message
    news:c0v7n3$ldk$...

    > > I have a counter running at 50 Mhz. Now i have to
    > > sample that counter at 77 Mhz.


    > You're going to have problems doing this no matter how you try.


    Agreed.

    > Don't forget Nyquist theorem, you should sample a signal at least twice as
    > fast as it itself is expected to change. (i.e. 100MHz in your case)


    I think we're OK - if the OP is sampling the *output* (count value)
    of a counter clocked at 50MHz, then 77MHz is enough. Nyquist would
    get in the way if he were trying to sample the 50MHz *clock*.

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


    Presumably you don't need to see the counter's value on EVERY edge
    of the 77MHz clock?

    > > what are the effects if i don't the sample the 50 Mhz counter and i
    > > directly sample with 77 Mhz.


    Think about the timing diagram, complete with the counter's
    clock-to-output delays. Your 77MHz clock will sample at essentially
    a random point in the 50MHz cycle. For some part of that 20ns 50MHz
    cycle, the counter output will be changing as the result of a recent
    clock pulse - let's guess that this will happen for up to 3ns after
    the clock. Therefore, you have a 3 in 20 (15%) chance that the
    77MHz clock will sample a value that's in transition, and therefore
    completely unreliable.

    It is not good enough simply to sample your counter into the 77MHz
    clock domain before reading it, because that sampling process
    suffers exactly the same problems that I've already mentioned.

    You need either a handshaking mechanism, or else an asynchronous
    FIFO. I guess that in your case the FIFO is probably overkill.

    There are many possible handshake schemes. In any case you will
    need a temporary holding register, clocked by the 50MHz clock.
    When the 77MHz side wants a value, it sets a flag which causes
    the 50MHz holding register to be enabled. As a result of this
    flag, the 50MHz side must:
    - wait for one 50MHz clock, to protect against the possibility
    that the flag was set very close to a clock edge
    - on the following 50MHz clock, copy the counter into the holding
    register: note that this all happens in the 50MHz domain so it's OK
    - on that same clock, clear the handshake flag
    Meanwhile the 77MHz side, having set the flag, waits for it to clear;
    as soon as the flag is cleared again, it can take a copy of the
    holding register because that register is then known to be stable.

    The big problem with this scheme is that the flag must be set by the
    77MHz clock, but cleared by the 50MHz clock. Everything else is
    purely synchronous logic in one or the other clock domain. For
    a good idea on how to do this set/clear flag, do a Google search
    for "Weinstein Flancter" and enjoy :)

    Finally, the scheme I've suggested gives quite long latency,
    and you may want to reduce that. This is possible by using a
    FIFO, triple swinging buffer, or various other ideas. For a
    good discussion of the problems you encounter when designing
    such things, take a look at the paper on FIFO design by
    Peter Alfke and Cliff Cummings:
    www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2_rev1_1.pdf

    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
    Tel: +44 (0)1425 471223 mail:
    Fax: +44 (0)1425 471573 Web: http://www.doulos.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Feb 18, 2004
    #3
  4. Jonathan Bromley wrote:

    > "Benjamin Todd" <> wrote in message
    > news:c0v7n3$ldk$...
    >
    >> > I have a counter running at 50 Mhz. Now i have to
    >> > sample that counter at 77 Mhz.

    >
    >> You're going to have problems doing this no matter how you try.

    >
    > Agreed.


    In the general case, agreed. It all depends on what OP wants to achieve.

    >
    >> Don't forget Nyquist theorem, you should sample a signal at least twice
    >> as fast as it itself is expected to change. (i.e. 100MHz in your case)

    >
    > I think we're OK - if the OP is sampling the *output* (count value)
    > of a counter clocked at 50MHz, then 77MHz is enough. Nyquist would
    > get in the way if he were trying to sample the 50MHz *clock*.
    >
    >> > 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.

    >
    > Presumably you don't need to see the counter's value on EVERY edge
    > of the 77MHz clock?
    >
    >> > what are the effects if i don't the sample the 50 Mhz counter and i
    >> > directly sample with 77 Mhz.

    >
    > Think about the timing diagram, complete with the counter's
    > clock-to-output delays. Your 77MHz clock will sample at essentially
    > a random point in the 50MHz cycle. For some part of that 20ns 50MHz
    > cycle, the counter output will be changing as the result of a recent
    > clock pulse - let's guess that this will happen for up to 3ns after
    > the clock. Therefore, you have a 3 in 20 (15%) chance that the
    > 77MHz clock will sample a value that's in transition, and therefore
    > completely unreliable.


    Not necessarily _completely_ unreliable. Remember the Gray coding of
    a counter in which only one bit changes at a time ? In that case
    you have a reliable sampling which is N or N+1 at the transition.
    (still need some timing margin for recovering from metastability though)

    >
    > It is not good enough simply to sample your counter into the 77MHz
    > clock domain before reading it, because that sampling process
    > suffers exactly the same problems that I've already mentioned.
    >
    > You need either a handshaking mechanism, or else an asynchronous
    > FIFO. I guess that in your case the FIFO is probably overkill.
    >


    Or a Gray code thus.

    > There are many possible handshake schemes. In any case you will
    > need a temporary holding register, clocked by the 50MHz clock.
    > When the 77MHz side wants a value, it sets a flag which causes
    > the 50MHz holding register to be enabled. As a result of this
    > flag, the 50MHz side must:
    > - wait for one 50MHz clock, to protect against the possibility
    > that the flag was set very close to a clock edge
    > - on the following 50MHz clock, copy the counter into the holding
    > register: note that this all happens in the 50MHz domain so it's OK
    > - on that same clock, clear the handshake flag
    > Meanwhile the 77MHz side, having set the flag, waits for it to clear;
    > as soon as the flag is cleared again, it can take a copy of the
    > holding register because that register is then known to be stable.
    >
    > The big problem with this scheme is that the flag must be set by the
    > 77MHz clock, but cleared by the 50MHz clock. Everything else is
    > purely synchronous logic in one or the other clock domain. For
    > a good idea on how to do this set/clear flag, do a Google search
    > for "Weinstein Flancter" and enjoy :)


    But thats for newsgroups on electronics :p

    >
    > Finally, the scheme I've suggested gives quite long latency,
    > and you may want to reduce that. This is possible by using a
    > FIFO, triple swinging buffer, or various other ideas. For a
    > good discussion of the problems you encounter when designing
    > such things, take a look at the paper on FIFO design by
    > Peter Alfke and Cliff Cummings:
    > www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO2_rev1_1.pdf
    >
    > --
    > Jonathan Bromley, Consultant
    >
    > DOULOS - Developing Design Know-how
    > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
    >
    > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW,
    > UK
    > Tel: +44 (0)1425 471223 mail:
    >
    > Fax: +44 (0)1425 471573 Web:
    > http://www.doulos.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.


    --
    Jos De Laender
    Jos De Laender, Feb 19, 2004
    #4
  5. hi Jos,

    "Jos De Laender" <>
    wrote in message news:skaZb.7300$-ops.be...

    [...]
    > > Think about the timing diagram [...]
    > > you have a 3 in 20 (15%) chance that the
    > > 77MHz clock will sample a value that's in transition, and therefore
    > > completely unreliable.

    >
    > Not necessarily _completely_ unreliable. Remember the Gray coding of
    > a counter in which only one bit changes at a time ? In that case
    > you have a reliable sampling which is N or N+1 at the transition.
    > (still need some timing margin for recovering from metastability though)


    I have to admit that when I wrote the reply I didn't think about
    Gray coding. But there were two good reasons for that:

    1) Someone suggested converting the binary count to Gray, shipping
    it across the clock boundary and converting back. This doesn't
    work unless the binary-to-gray conversion is registered; if you
    take an incoherent binary count and re-code it as a Gray code,
    it will remain incoherent. I do indeed know that no professional
    would ever make this mistake, but a newbie reading the suggestion
    might easily do so.

    2) As you point out, the Gray solution is not general. I've been
    bitten too many times by someone taking a special-purpose
    solution ("It's worked for years, it must be OK") and then
    mistakenly applying it to a new situation ("It's only a tiny
    change, just that the counter counts up in steps of 19 now").

    [...]
    > > For
    > > a good idea on how to do this set/clear flag, do a Google search
    > > for "Weinstein Flancter" and enjoy :)

    >
    > But thats for newsgroups on electronics :p


    Pah. They wouldn't know a clock domain if they tripped over
    its boundary ;-)
    --

    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
    Tel: +44 (0)1425 471223 mail:
    Fax: +44 (0)1425 471573 Web: http://www.doulos.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Feb 20, 2004
    #5
  6. Jonathan Bromley wrote:

    > hi Jos,
    >


    <snip>

    > 2) As you point out, the Gray solution is not general. I've been
    > bitten too many times by someone taking a special-purpose
    > solution ("It's worked for years, it must be OK") and then
    > mistakenly applying it to a new situation ("It's only a tiny
    > change, just that the counter counts up in steps of 19 now").


    But for sure OP , just as all of us , would document into boring detail and
    linked into an unseparatable way from the design code, what were his
    assumptions at design time , what are the limitations of its implementation
    etc. So the problem you mention is unlikely :p Why did I bump nevertheless
    in comparable problems ? :)

    >
    > [...]
    >> > For
    >> > a good idea on how to do this set/clear flag, do a Google search
    >> > for "Weinstein Flancter" and enjoy :)

    >>
    >> But thats for newsgroups on electronics :p

    >
    > Pah. They wouldn't know a clock domain if they tripped over
    > its boundary ;-)


    :))))))

    --
    Jos De Laender
    Jos De Laender, Feb 21, 2004
    #6
    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. arcvonz

    System Time synchronization

    arcvonz, Aug 23, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    482
    Sam Santiago
    Aug 23, 2004
  2. John

    Flip Flop Synchronization

    John, Jan 3, 2004, in forum: VHDL
    Replies:
    3
    Views:
    9,695
    valentin tihomirov
    Jan 5, 2004
  3. Simon
    Replies:
    1
    Views:
    623
    tbx135
    Jan 9, 2004
  4. deep
    Replies:
    0
    Views:
    472
  5. Francis
    Replies:
    1
    Views:
    633
    Ronald Hecht
    Apr 27, 2004
Loading...

Share This Page