asynchronous signal problem

Discussion in 'VHDL' started by The Weiss Family, Jul 29, 2004.

  1. I have an asynchronous signal coming into my chip.
    I route it through two back-to-back flip-flops to synchronize it to the
    system clock.
    However, when I simulate (post place and route) the design in ModelSim I see
    problems.
    Whenever an asynchronous input edge coincides (within a few tens of ps) with
    the system clock, the simulator says there is a timing violation and puts an
    'X' on the signal. Thus, everything that is derived from that signal also
    gets an 'X'.

    I'm wondering if this is truly what will happen, or if the simulator does
    not properly model the synchronizer circuit.
    The probablility of a metastable condition is supposed to be extremely low
    by using two flip-flops.
    Is it possible that ModelSim simply propagates the 'X' as soon as it detects
    a timing violation?

    I would try it on real hardware, but I don't have it yet ;-)

    Any ideas?

    Adam
    The Weiss Family, Jul 29, 2004
    #1
    1. Advertising

  2. The Weiss Family

    Wallclimber Guest

    > I have an asynchronous signal coming into my chip.
    > I route it through two back-to-back flip-flops to synchronize it to the
    > system clock.
    > However, when I simulate (post place and route) the design in ModelSim I see
    > problems.
    > Whenever an asynchronous input edge coincides (within a few tens of ps) with
    > the system clock, the simulator says there is a timing violation and puts an
    > 'X' on the signal. Thus, everything that is derived from that signal also
    > gets an 'X'.


    This is one of the standard problems of asynchronous design.
    Basically, the simulator does exactly what it's told to do: complain
    when a signal violates setup and hold requirements. Except, of course,
    that in this case you have taken the right precautions.

    I don't really know about a solution to this that doesn't look like a
    hack.
    What I have done in the past (and this seems to be a common fix), is
    hack the SDF file and set the setup and hold requirements for the
    first FF to zero. This way, the simulator won't complain...
    Another one (that comes down to the same thing), is to replace the
    verilog model of that particular FF with another one that doesn't do
    setup and hold checking.
    In some cases, when the overall interface is simple, you solve it by
    forcing valid values on the output of the first FF.

    I'd love to hear about better solutions!

    Tom Verbeure
    Wallclimber, Jul 29, 2004
    #2
    1. Advertising

  3. "The Weiss Family" <> wrote in message news:<>...
    > I have an asynchronous signal coming into my chip.
    > I route it through two back-to-back flip-flops to synchronize it to the
    > system clock.
    > However, when I simulate (post place and route) the design in ModelSim I see
    > problems.
    > Whenever an asynchronous input edge coincides (within a few tens of ps) with
    > the system clock, the simulator says there is a timing violation and puts an
    > 'X' on the signal. Thus, everything that is derived from that signal also
    > gets an 'X'.
    >
    > I'm wondering if this is truly what will happen, or if the simulator does
    > not properly model the synchronizer circuit.
    > The probablility of a metastable condition is supposed to be extremely low
    > by using two flip-flops.
    > Is it possible that ModelSim simply propagates the 'X' as soon as it detects
    > a timing violation?
    >
    > I would try it on real hardware, but I don't have it yet ;-)
    >
    > Any ideas?
    >
    > Adam

    Adam,

    I have had similar problems with my Aldec simulator. It doesn't do
    probabilites, so there will almost certainly be timing violations with
    some asynchronous inputs. In the real world, the 2 flip-flop
    synchronizers work quite well. I have used a number of schemes to
    avoid this problem in simulation. All involve modifying the
    asynchronous input in some way. One scheme is to instantiate a d
    flip-flop or a synchronous register that is clocked with the UUT's
    clock and to feed your stimulus signal to the input(s) and then use
    the output(s) of the flop or register as the "asynchronous" input(s)
    to the UUT. In other cases, I have used a "wait until" statement to
    force the asynchronous input to change only when the UUT's clock is
    '0' (preferably not too close to the rising edge of the clock).
    Anyway, I'm sure you get the idea.

    Good Luck and Best Regards,

    Charles
    Charles M. Elias, Jul 29, 2004
    #3
  4. Thanks for the input guys.
    I had a feeling that it was just the simulator.
    I'll try forcing the setup time on that first FF to 0.
    Thanks again,

    Adam
    The Weiss Family, Jul 29, 2004
    #4
  5. "The Weiss Family" <> wrote in message news:<>...
    > I have an asynchronous signal coming into my chip.
    > I route it through two back-to-back flip-flops to synchronize it to the
    > system clock.
    > However, when I simulate (post place and route) the design in ModelSim I see
    > problems.



    http://groups.google.com/groups?q=charles dqdq

    -- Mike Treseler
    Mike Treseler, Jul 29, 2004
    #5
  6. On Wed, 28 Jul 2004 23:26:58 -0700, "The Weiss Family"
    <> wrote:

    >I have an asynchronous signal coming into my chip.

    [...]

    >Is it possible that ModelSim simply propagates the 'X'
    > as soon as it detects a timing violation?


    Not ModelSim, but perhaps the flip-flop model, is behaving
    like this.

    You've made, and received, some sensible suggestions. You can
    also try to solve the problem by making your models as realistic
    as possible. All this depends on being able to replace the
    "synchroniser" instances of flip-flop library models with
    a different model.

    One useful possibility is to make a really good model of
    a flip-flop's metastability. To do this, you need to model
    some of the FF's internal delays, and measure the setup
    or hold time relative to the effective clock that decides
    when the FF samples. Then the flip-flop output is
    modelled using something like

    q <= 'X' after Q_hold_time,
    D after propagation_delay;

    where "propagation_delay" is calculated as a function of
    the setup time - the nearer this is to zero, the longer
    the propagation delay.

    A second possibility is to avoid X propagation completely,
    but instead to get the flip-flop to settle to a random
    value if setup/hold times are violated. However, it's
    tough to get useful results from this sort of thing.

    In general, though, there's no substitute for very
    careful theoretical analysis of what's happening at
    the asynchronous interface. If you can be completely
    confident that your resynchroniser behaves correctly in
    all possible situations, it's then legitimate to replace
    it with an idealised model that doesn't propagate X.
    --
    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, 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, Jul 30, 2004
    #6
  7. > In general, though, there's no substitute for very
    > careful theoretical analysis of what's happening at
    > the asynchronous interface. If you can be completely
    > confident that your resynchroniser behaves correctly in
    > all possible situations, it's then legitimate to replace
    > it with an idealised model that doesn't propagate X.


    Today, I just received a memec proto board with the Xilinx chip that I am
    using on it.
    It turns out that my design works great.
    Can you suggest any ways I might stress the sync circuit?
    I tried sweeping the frequency of the asynchronous signal throughout its
    valid range.
    No problems there.
    I don't want to miss that one case that will cause the chip to lock up, so
    any suggestions are extremely welcome.

    thanks,

    Adam
    The Weiss Family, Jul 31, 2004
    #7
  8. The Weiss Family

    Ronald Hecht Guest

    Good practice is to disable timing checks at (and only at!) synchronizer
    flops. This can be done with VHDL configuration for example. Here is a
    part of an example for Xilinx flops:

    library simprim;
    use simprim.vcomponents.all;

    configuration hdlc_layer_tb_ba_cfg of hdlc_layer_tb is
    for beh
    for DUT : hdlc_layer
    -- ....

    -- These dedicated FFs may go metastable by design!
    -- Therefore, timing checks must be turned of here selectively!
    for STRUCTURE
    for
    -- FIFO gray pointer synchronizer
    hl_tx_fifo_rd_wr_ptr_gray_sync_0_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_1_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_2_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_3_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_4_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_5_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_6_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_7_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_8_q,
    hl_tx_fifo_rd_wr_ptr_gray_sync_9_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_0_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_1_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_2_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_3_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_4_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_5_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_6_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_7_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_8_q,
    hl_rx_fifo_rd_wr_ptr_gray_sync_9_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_0_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_1_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_2_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_3_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_4_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_5_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_6_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_7_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_8_q,
    hl_tx_fifo_wr_rd_ptr_gray_sync_9_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_0_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_1_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_2_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_3_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_4_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_5_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_6_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_7_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_8_q,
    hl_rx_fifo_wr_rd_ptr_gray_sync_9_q : X_SFF
    use entity simprim.X_SFF(X_SFF_V)
    generic map (TimingChecksOn => false);
    end for;
    end for;
    end for;
    end for;
    end hdlc_layer_tb_ba_cfg;

    The Weiss Family wrote:
    > I have an asynchronous signal coming into my chip.
    > I route it through two back-to-back flip-flops to synchronize it to the
    > system clock.
    > However, when I simulate (post place and route) the design in ModelSim I see
    > problems.
    > Whenever an asynchronous input edge coincides (within a few tens of ps) with
    > the system clock, the simulator says there is a timing violation and puts an
    > 'X' on the signal. Thus, everything that is derived from that signal also
    > gets an 'X'.
    >
    > I'm wondering if this is truly what will happen, or if the simulator does
    > not properly model the synchronizer circuit.
    > The probablility of a metastable condition is supposed to be extremely low
    > by using two flip-flops.
    > Is it possible that ModelSim simply propagates the 'X' as soon as it detects
    > a timing violation?
    >
    > I would try it on real hardware, but I don't have it yet ;-)
    >
    > Any ideas?
    >
    > Adam
    >
    >
    >
    Ronald Hecht, Aug 2, 2004
    #8
  9. The Weiss Family

    scary_jeff

    Joined:
    Dec 6, 2007
    Messages:
    1
    This is the top result for 'vhdl asynchronous inputs' on google, so I thought I would post a solution (I didn't follow the previous post, and the one before that doesn't tell you how to actually turn off X propogation).

    In Xilinx ISE (9.1, maybe earlier):

    Edit > Language templates > VHDL > Synthesis Constructs > Coding Examples > Misc > Asynchronus Input Synchronization

    It uses attributes ASYNC_REG and TIG on the two registers in order to prevent X propogation.
    scary_jeff, Dec 6, 2007
    #9
    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. Michael Pronath
    Replies:
    1
    Views:
    1,166
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    463
    Jack Orenstein
    Sep 18, 2005
  3. Mike Treseler
    Replies:
    0
    Views:
    470
    Mike Treseler
    May 29, 2010
  4. Tricky
    Replies:
    0
    Views:
    411
    Tricky
    May 30, 2010
  5. Tricky
    Replies:
    0
    Views:
    519
    Tricky
    May 30, 2010
Loading...

Share This Page