Resynchronize external signals

Discussion in 'VHDL' started by Weddick, Apr 1, 2005.

  1. Weddick

    Weddick Guest

    What is meant by the statement - Resynchronize external signals - when using
    them is a state machine? What's it do, how do you do it and why?

    Thanks,
     
    Weddick, Apr 1, 2005
    #1
    1. Advertising

  2. Weddick

    Bert Cuzeau Guest

    Weddick wrote:

    > What is meant by the statement - Resynchronize external signals - when using
    > them is a state machine? What's it do, how do you do it and why?
    >
    > Thanks,
    >
    >

    I guess you got that in my Coding Style Guide.

    A good practice is to always resynchronize asynchronous inputs.
    You just have to make them traverse a D FlipFlop, or two FlipFlops if
    you're scared.

    As one can easily understand, this is extremely critical when the async
    signal is driving several FFs (some may see a 1 and others a 0 and take
    "impossible" decisions (and drive an FSM crazy for example). This can
    happen without even a timing violation !
    It's a major source of buggy designs which simply don't work reliably or
    at all, yet it's usually not taught properly.

    When in doubt, follow the guide ;-)
    But I agree that it's better to understand the reasons behind the rules.

    Bert Cuzeau
     
    Bert Cuzeau, Apr 1, 2005
    #2
    1. Advertising

  3. Weddick

    Ken Guest

    > A good practice is to always resynchronize asynchronous inputs.
    > You just have to make them traverse a D FlipFlop, or two FlipFlops if
    > you're scared.


    This is to avoid metastability I believe?

    Also, resynching using the flops only *reduces* the probability of
    metastability to acceptable levels (reduced further by using 2) - it does
    not completely eliminate it - correct?

    Cheers,

    Ken
     
    Ken, Apr 1, 2005
    #3
  4. Weddick

    Bert Cuzeau Guest

    Ken wrote:
    >>A good practice is to always resynchronize asynchronous inputs.
    >>You just have to make them traverse a D FlipFlop, or two FlipFlops if
    >>you're scared.

    >
    >
    > This is to avoid metastability I believe?


    The main issue is what I explained : related to temporal incoherence of
    the same signal distributed to several paths.

    Metastability is another issue, but it's much less severe than sometimes
    believed. _Every_ time I inspected failures that were believed to be
    related with metastability, the issue was a (more or less) simple lack
    of resynchronization...

    >
    > Also, resynching using the flops only *reduces* the probability of
    > metastability to acceptable levels (reduced further by using 2) - it does
    > not completely eliminate it - correct?


    What would your suggestion be ?

    The correct answer (if any) is an mtbf calculation, but it's often
    difficult to get all the parameters related with a given technology.
    Usually, knowing your technology, the input change rate and your
    sampling clock frequency gives you an idea of whether you should get
    concerned by metastability through a single Flop or not. Indeed, the
    type of application can make lots of difference. Failues may have much
    different consequences according to the design. A set-top box is less
    critical than a plane.

    In most current situations, the mtbf through 2 flops is simply well
    above other mtbfs sourcing from other factors.
     
    Bert Cuzeau, Apr 1, 2005
    #4
  5. Weddick

    Dave Higton Guest

    In message <424d8ebb$0$28527$>
    Bert Cuzeau <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote:

    > Metastability is another issue, but it's much less severe than sometimes
    > believed. _Every_ time I inspected failures that were believed to be
    > related with metastability, the issue was a (more or less) simple lack
    > of resynchronization...


    Hmm. I /believe/ I've seen metastability in an FPGA design I did a few
    years ago. There were 4 identically programmed FPGAs to a PCB, each
    FPGA with 4 channels (16 channels total). The channels were all identical
    instantiations, as you'd expect. They sampled two asynchronous inputs
    each, and resynchronised them through one DFF each. Resynchronisation
    was present, therefore, on all 16 channels, with 1 level.

    However, 4 channels suffered badly from noise, and 4 channels less badly.
    It was the same channel in each FPGA that was affected, to the same
    extent. The noise went away when I did nothing more than add a second
    level of resynchronisation, with a second DFF. Nowadays I tend to do
    the same sort of design with 4 stages - they're a free resource, why
    take the risk?

    It's very hard to prove one way or the other, I grant you.

    Dave
     
    Dave Higton, Apr 1, 2005
    #5
  6. Weddick

    Weddick Guest

    Thank you all for your inputs. I think I have the picture now.

    Thanks,
    Joel


    "Bert Cuzeau" <_no_spa_m_info_no_underscore_@alse-fr___.com> wrote in
    message news:424cee24$0$26387$...
    > Weddick wrote:
    >
    >> What is meant by the statement - Resynchronize external signals - when
    >> using them is a state machine? What's it do, how do you do it and why?
    >>
    >> Thanks,
    >>
    >>

    > I guess you got that in my Coding Style Guide.
    >
    > A good practice is to always resynchronize asynchronous inputs.
    > You just have to make them traverse a D FlipFlop, or two FlipFlops if
    > you're scared.
    >
    > As one can easily understand, this is extremely critical when the async
    > signal is driving several FFs (some may see a 1 and others a 0 and take
    > "impossible" decisions (and drive an FSM crazy for example). This can
    > happen without even a timing violation !
    > It's a major source of buggy designs which simply don't work reliably or
    > at all, yet it's usually not taught properly.
    >
    > When in doubt, follow the guide ;-)
    > But I agree that it's better to understand the reasons behind the rules.
    >
    > Bert Cuzeau
    >
    >
    >
     
    Weddick, Apr 2, 2005
    #6
  7. Dave Higton wrote:
    .. . .
    > However, 4 channels suffered badly from noise, and 4 channels less badly.
    > It was the same channel in each FPGA that was affected, to the same
    > extent. The noise went away when I did nothing more than add a second
    > level of resynchronisation, with a second DFF. Nowadays I tend to do
    > the same sort of design with 4 stages


    There is a very logical reason to describe
    at least three synchronization stages in
    the source code. Synthesis can and often
    does branch an n-state shifter to multiple
    D or CE inputs at stage n-1.

    I might expect this:
    /-->
    >---[DQ]--[DQ]--[DQ]-|--->

    1 2 3 \-->

    But I might actually get this:

    /-[DQ]-->
    >---[DQ]--[DQ]-|--[DQ]-->

    1 2 \-[DQ]-->


    This effectively eliminates one stage
    of synchronization, even though the
    functional sim is the same.

    -- Mike Treseler
     
    Mike Treseler, Apr 2, 2005
    #7
    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. Scott Allen
    Replies:
    8
    Views:
    10,984
    Scott Allen
    May 2, 2004
  2. Eli Bendersky
    Replies:
    15
    Views:
    3,020
    Jonathan Bromley
    Apr 28, 2007
  3. hhanff
    Replies:
    8
    Views:
    985
    hhanff
    Jul 23, 2010
  4. MiguelM
    Replies:
    0
    Views:
    1,302
    MiguelM
    Feb 5, 2011
  5. Mellow Crow
    Replies:
    6
    Views:
    425
    Richard Cornford
    Nov 4, 2005
Loading...

Share This Page