Resynchronization - important?

Discussion in 'VHDL' started by Preben Holm, Mar 20, 2005.

  1. Preben Holm

    Preben Holm Guest

    Hi everyone..


    I read that resyncrhonization of signals is important, but is it
    important, if the module is part of a larger design inside the same
    FPGA? It causes a lot of delays in the overall design to make these
    resynchronizations and results in hard-to-track delays of the signals?


    / Preben
    Preben Holm, Mar 20, 2005
    #1
    1. Advertising

  2. HI,


    Preben Holm wrote:
    > I read that resyncrhonization of signals is important, but is it
    > important, if the module is part of a larger design inside the same
    > FPGA? It causes a lot of delays in the overall design to make these
    > resynchronizations and results in hard-to-track delays of the signals?


    You need resynchronisation when ever you change between two independend
    clock domains. When doing very large designs where the wire delay between
    two distant modules is nearly the normal delay between two clock edges you
    should also insert FF between the modules to meet timing constraints.
    Between two adjacent modules within the same clock domain there is no need
    to resynchronise signals.

    bye Thomas

    --
    Emailantworten bitte an thomas[at]obige_domain.
    Usenet_10 ist für Viren und Spam reserviert
    Thomas Stanka, Mar 20, 2005
    #2
    1. Advertising

  3. Preben Holm

    info_ Guest

    Preben Holm wrote:

    > I read that resyncrhonization of signals is important, but is it
    > important, if the module is part of a larger design inside the same
    > FPGA? It causes a lot of delays in the overall design to make these
    > resynchronizations and results in hard-to-track delays of the signals?


    You _NEED_ resynch when your input is _A_synchronous and used by more than
    one FlipFlop. (But you need resynch also against timing violations).
    The big issue is that due to different delays between you input pad
    and your FlipFlops, one FF could see a 1 and the other a 0, and would
    take a seemingly "impossible" decision !!!! and this can happen even
    without a timing violation.
    Usual symptom is a one-hot state machine becoming all zero (stuck)
    or "multiple-hot". But other variants of this are common, like
    counters skipping values, etc etc...
    It's probably the most frequent design error I seen in code
    from "experts". We do insist a lot about this in our training courses.

    Clock domain crossing is another issue especially when you need
    to transport busses or group of intercorrelated signals !
    Resynchronization FlipFlops stages is NOT the answer in this case.
    (Try a small Fifo instead or a mailbox scheme)

    In a single domain synchronous design, you only need resynchronization
    for external asynchronous signal.
    Internal signals will be synchronous and verified by Static Timing Analysis.
    External Synchronous inputs are also verified by Static timing Analysis
    (Tsu/Th).


    Bert Cuzeau
    info_, Mar 20, 2005
    #3
  4. Preben Holm

    Hal Murray Guest


    >You _NEED_ resynch when your input is _A_synchronous and used by more than
    >one FlipFlop.


    You can get in trouble even if you have only one FF.
    Consider metastability.

    --
    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.
    Hal Murray, Mar 20, 2005
    #4
  5. Preben Holm

    info_ Guest

    Hal Murray wrote:
    >>You _NEED_ resynch when your input is _A_synchronous and used by more than
    >>one FlipFlop.

    >
    >
    > You can get in trouble even if you have only one FF.
    > Consider metastability.
    >

    My sentence was :
    You _NEED_ resynch when your input is _A_synchronous and used by more than
    one FlipFlop. (But you need resynch also against timing violations).

    The last part said that precisely. (I thought)
    Timing violations potentially create metastability, though the real
    issue is usually the complete lack of resynchronization which IS
    a killer as I explained !
    Since old ages, the "official" solution against metastability was
    two cascaded FFs...
    It seems now agreed by the FPGA vendors that in usual situations and recent
    FPGAs, a single FF should be enough for getting away from metastability
    issues, but don't take my word for it. Check with your FPGA vendor's
    metastability measurements reports. To be accurate, there is a mtbf
    calculation involving FF clock frequency and input change rate and
    other physical factors.

    I would be VERY happy the day I will see a resync FF resynchronizing
    every asynchronous FPGA input from every design...
    I keep hammering this during our training courses :)


    Bert Cuzeau
    info_, Mar 20, 2005
    #5
  6. Preben Holm

    Preben Holm Guest

    info_ wrote:
    > Preben Holm wrote:
    >
    >> I read that resyncrhonization of signals is important, but is it
    >> important, if the module is part of a larger design inside the same
    >> FPGA? It causes a lot of delays in the overall design to make these
    >> resynchronizations and results in hard-to-track delays of the signals?

    >
    >
    > You _NEED_ resynch when your input is _A_synchronous and used by more than
    > one FlipFlop. (But you need resynch also against timing violations).
    > The big issue is that due to different delays between you input pad
    > and your FlipFlops, one FF could see a 1 and the other a 0, and would
    > take a seemingly "impossible" decision !!!! and this can happen even
    > without a timing violation.
    > Usual symptom is a one-hot state machine becoming all zero (stuck)
    > or "multiple-hot". But other variants of this are common, like
    > counters skipping values, etc etc...


    It actually happens in the post-map simulation of one of my statemachine
    discussed in the comp.arch.fpga-group. But only for a short time and it
    settles within the next rising edge of the clock - should I take care of
    this some how?

    > It's probably the most frequent design error I seen in code
    > from "experts". We do insist a lot about this in our training courses.
    >
    > Clock domain crossing is another issue especially when you need
    > to transport busses or group of intercorrelated signals !


    intercorrelated signals?

    > Resynchronization FlipFlops stages is NOT the answer in this case.
    > (Try a small Fifo instead or a mailbox scheme)
    >
    > In a single domain synchronous design, you only need resynchronization
    > for external asynchronous signal.
    > Internal signals will be synchronous and verified by Static Timing
    > Analysis.
    > External Synchronous inputs are also verified by Static timing Analysis
    > (Tsu/Th).


    Okay, I find this rather logic anyway so!!
    Preben Holm, Mar 22, 2005
    #6
  7. Preben Holm <> writes:

    > info_ wrote:
    >> Preben Holm wrote:
    >>
    >>> I read that resyncrhonization of signals is important, but is it
    >>> important, if the module is part of a larger design inside the same
    >>> FPGA? It causes a lot of delays in the overall design to make these
    >>> resynchronizations and results in hard-to-track delays of the
    >>> signals?

    >> You _NEED_ resynch when your input is _A_synchronous and used by
    >> more than
    >> one FlipFlop. (But you need resynch also against timing violations).
    >> The big issue is that due to different delays between you input pad
    >> and your FlipFlops, one FF could see a 1 and the other a 0, and would
    >> take a seemingly "impossible" decision !!!! and this can happen even
    >> without a timing violation.
    >> Usual symptom is a one-hot state machine becoming all zero (stuck)
    >> or "multiple-hot". But other variants of this are common, like
    >> counters skipping values, etc etc...

    >
    > It actually happens in the post-map simulation of one of my
    > statemachine discussed in the comp.arch.fpga-group. But only for a
    > short time and it settles within the next rising edge of the clock -
    > should I take care of this some how?


    Sounds like that you're just seeing the delay within the device in
    your simulation. In that case, no worries.

    >> It's probably the most frequent design error I seen in code
    >> from "experts". We do insist a lot about this in our training courses.
    >> Clock domain crossing is another issue especially when you need
    >> to transport busses or group of intercorrelated signals !

    >
    > intercorrelated signals?


    Multiple bits that *must* be sampled simultaneously. E.g. a databus,
    where sampling some bits in slot N and the rest in slot N+1 really
    bad.

    At work, it has been an official rule that if you want a databus to
    cross a clock boundary, you *must* use one of the existing
    resynchronization buffers. We have a selection of resync buffers that
    have been scrutinized and tested in real designs.

    Basically, they all consist of a number of buffers, and two gray-coded
    read/write pointers, which are then double-synced across the clock
    boundary. Some variants have full and empty flags as well. Other
    variants can only transfer data at approx 1/8th clock rate, for
    "seldomly-updated" status information.


    Kai
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
    Kai Harrekilde-Petersen, Mar 22, 2005
    #7
  8. Preben Holm

    Bert Cuzeau Guest

    Thank Kai !!!

    I was away from the office (or home) but you explained
    it perfectly.

    My grief is why those basic issues are (almost) never taught
    properly ???


    Kai Harrekilde-Petersen wrote:

    > Preben Holm <> writes:
    >
    >
    >>info_ wrote:
    >>
    >>>Preben Holm wrote:
    >>>
    >>>
    >>>>I read that resyncrhonization of signals is important, but is it
    >>>>important, if the module is part of a larger design inside the same
    >>>>FPGA? It causes a lot of delays in the overall design to make these
    >>>>resynchronizations and results in hard-to-track delays of the
    >>>>signals?
    >>>
    >>>You _NEED_ resynch when your input is _A_synchronous and used by
    >>>more than
    >>>one FlipFlop. (But you need resynch also against timing violations).
    >>>The big issue is that due to different delays between you input pad
    >>>and your FlipFlops, one FF could see a 1 and the other a 0, and would
    >>>take a seemingly "impossible" decision !!!! and this can happen even
    >>>without a timing violation.
    >>>Usual symptom is a one-hot state machine becoming all zero (stuck)
    >>>or "multiple-hot". But other variants of this are common, like
    >>>counters skipping values, etc etc...

    >>
    >>It actually happens in the post-map simulation of one of my
    >>statemachine discussed in the comp.arch.fpga-group. But only for a
    >>short time and it settles within the next rising edge of the clock -
    >>should I take care of this some how?

    >
    >
    > Sounds like that you're just seeing the delay within the device in
    > your simulation. In that case, no worries.
    >
    >
    >>>It's probably the most frequent design error I seen in code
    >>>from "experts". We do insist a lot about this in our training courses.
    >>>Clock domain crossing is another issue especially when you need
    >>>to transport busses or group of intercorrelated signals !

    >>
    >>intercorrelated signals?

    >
    >
    > Multiple bits that *must* be sampled simultaneously. E.g. a databus,
    > where sampling some bits in slot N and the rest in slot N+1 really
    > bad.
    >
    > At work, it has been an official rule that if you want a databus to
    > cross a clock boundary, you *must* use one of the existing
    > resynchronization buffers. We have a selection of resync buffers that
    > have been scrutinized and tested in real designs.
    >
    > Basically, they all consist of a number of buffers, and two gray-coded
    > read/write pointers, which are then double-synced across the clock
    > boundary. Some variants have full and empty flags as well. Other
    > variants can only transfer data at approx 1/8th clock rate, for
    > "seldomly-updated" status information.
    >
    >
    > Kai
    Bert Cuzeau, Mar 24, 2005
    #8
    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. Kevin Spencer

    Re: Important Newsgroup Virus Information

    Kevin Spencer, Sep 2, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,380
    William Ryan
    Sep 2, 2003
  2. Alex Yu
    Replies:
    1
    Views:
    1,378
    Tom Vande Stouwe MCSD.net
    Sep 3, 2003
  3. Yair Cohen
    Replies:
    0
    Views:
    2,022
    Yair Cohen
    Sep 4, 2003
  4. Miha Markic

    Install this important update

    Miha Markic, Sep 27, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    451
    Martin Robins
    Sep 27, 2003
  5. Spur
    Replies:
    2
    Views:
    590
    VhdlCohen
    Oct 27, 2003
Loading...

Share This Page