Async reset

Discussion in 'VHDL' started by Jason Berringer, Oct 20, 2004.

  1. Hello all,

    I have a general question regarding asynchronous and synchronous resets.
    Does an async. reset slow down the speed of a circuit? Is it better to use a
    synchronous reset, or if possible no reset at all to speed up a design? I'm
    just curious as I have a larger project which has a single async reset to a
    lot of different blocks using the typical:

    if (reset = '0') then
    ....
    elsif (rising_edge(clk)) then
    ....
    else
    ....
    end if;

    Not all block require the reset since they are downstream of earlier ones
    with a reset and their state isn't critical, I have just always included
    them. That being said I want to speed up the design, and in one block I took
    out the reset and it seemed to boost the performance slightly.

    Any comments would be appreciated.

    Jason
     
    Jason Berringer, Oct 20, 2004
    #1
    1. Advertising

  2. Jason Berringer wrote:

    > I have a general question regarding asynchronous and synchronous resets.
    > Does an async. reset slow down the speed of a circuit? Is it better to use a
    > synchronous reset, or if possible no reset at all to speed up a design? I'm
    > just curious as I have a larger project which has a single async reset to a
    > lot of different blocks using the typical:


    If the target logic has an asynchronous reset, which I believe
    all FPGAs have, then it is already there and all you need to do
    is wire it up.

    Synchronous reset will be done using logic resources. It might
    be that there are enough CLB inputs not to add more, though it
    might need another column, depending on the function.

    A separate question is that asynchronous reset needs not to be
    too close to the clock edge, so it might need to be synchronized
    (even though not synchronous).

    -- glen
     
    glen herrmannsfeldt, Oct 21, 2004
    #2
    1. Advertising

  3. On Wed, 2004-10-20 at 18:41 -0400, Jason Berringer wrote:
    > Hello all,
    >
    > I have a general question regarding asynchronous and synchronous resets.
    > Does an async. reset slow down the speed of a circuit? Is it better to use a
    > synchronous reset, or if possible no reset at all to speed up a design? I'm
    > just curious as I have a larger project which has a single async reset to a
    > lot of different blocks using the typical:
    >
    > if (reset = '0') then
    > ...
    > elsif (rising_edge(clk)) then
    > ...
    > else
    > ...
    > end if;
    >
    > Not all block require the reset since they are downstream of earlier ones
    > with a reset and their state isn't critical, I have just always included
    > them. That being said I want to speed up the design, and in one block I took
    > out the reset and it seemed to boost the performance slightly.
    >
    > Any comments would be appreciated.
    >
    > Jason
    >
    >


    If you are using Xilinx FPGAs then they have a nice techxclusives
    article about just this.

    http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?
    sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset
     
    Prasanth Kumar, Oct 21, 2004
    #3
  4. Jason Berringer

    Hendra Guest

    "Jason Berringer" <> wrote
    > Does an async. reset slow down the speed of a circuit?


    I guess synchronous reset need extra logic, so it may speed up a
    little if you use asynchronous reset.

    > Is it better to use a
    > synchronous reset, or if possible no reset at all to speed up a design?


    Yes, it is possible to have no reset at all in an FPGA since FPGA will
    automatically clear all FFs inside the chip during downloading from
    the bitstream. However, not having the reset will make it harder to
    simulate since some simulators require all the FFs to be resetted
    before you can do any simulation. Moreover, what would happen when for
    some reason your FFs go to undesired state, then you can not get out
    of the loop!

    There are some articles regarding sync vs async at
    http://www.sunburst-design.com/papers/

    Hendra
     
    Hendra, Oct 21, 2004
    #4
  5. Jason Berringer

    mk Guest

    On Wed, 20 Oct 2004 18:41:08 -0400, "Jason Berringer"
    <> wrote:

    >Hello all,
    >
    >I have a general question regarding asynchronous and synchronous resets.
    >Does an async. reset slow down the speed of a circuit? Is it better to use a
    >synchronous reset, or if possible no reset at all to speed up a design? I'm
    >just curious as I have a larger project which has a single async reset to a
    >lot of different blocks using the typical:
    >
    >if (reset = '0') then
    >...
    >elsif (rising_edge(clk)) then
    >...
    >else
    >...
    >end if;
    >
    >Not all block require the reset since they are downstream of earlier ones
    >with a reset and their state isn't critical, I have just always included
    >them. That being said I want to speed up the design, and in one block I took
    >out the reset and it seemed to boost the performance slightly.
    >
    >Any comments would be appreciated.
    >
    >Jason
    >


    For standard cell based designs, flops without async resets are almost
    always faster than the ones which do (and they are smaller as an added
    bonus), so if you don't need them don't use them. For FPGAs, when
    programmed not have an async reset a flop might have a different clk
    to Q delay (or a faster setup) which would make the design faster. One
    method would be to use async resets only for the registers which you
    know would need them and then add the ones later if you have to.
    Of course you should never let an async reset reach a flop without
    being synchronized to its clock, at least the release of the reset
    signal. Not doing so would cause unmentionable heart-ache in a
    real-life design.
     
    mk, Oct 21, 2004
    #5
  6. Jason Berringer

    John_H Guest

    "Jason Berringer" <> wrote in message
    news:5QBdd.26143$...
    > Any comments would be appreciated.


    I'd like to point out that async resets aren't free in all FPGAs.
    I've been producing reset-free designs for years in the Xilinx parts having
    started with reset-free designs in Altera.

    The FPGAs have power-up states that are or can be predefined to specific
    values. The S/R pins can be used as *either* sync or async but cannot be
    used as both. There are no resources needed for a synchronous reset above
    and beyond what an asynchronous reset uses in those devices. What about
    when the system goes haywaire and the device needs to be reset? If the
    system is in need of serious reset, just reprogram the part.

    Some logic can be sped up by using the integrated synchronous S/R
    functionality as long as your synthesizer knows how to use it. Synplify
    does a great job of adding additional logic through the S/R ports often
    providing a slightly shorter path in timing sensitive designs. The one
    negative from this practice is that the S/R logic integration tends to be
    more widespread than I would like, typically locking out the adjacent
    register in a slice from use; both registers need the same S/R, clk, and CE
    signals.

    How does more logic get in through a set/reset? The FDR primitive can be
    used as an OR gate (Q = D & !R where the inversion is free) and an FDS can
    be used as an OR gate (Q = D | S) with the FDRS providing a little more
    functionality. Throw the clock enable in there and things get more flexible
    but keep in mind (as the synthesis does) that the reset is higher precedence
    than the set which is higher than the clock enable. This "logic
    integration" into the register has saved my designs with respect to I/O
    timing by allowing live signals to feed the CE, and S/R directly from other
    I/Os allowing a very short setup plus output time for the same clock edge.
    Without this functionality, getting on and off the logic fabric without
    global routing killed my timing.
     
    John_H, Oct 21, 2004
    #6
  7. Jason Berringer

    Peter Alfke Guest


    > From: mk<>
    > Organization: SBC http://yahoo.sbc.com
    > Newsgroups: comp.arch.fpga,comp.lang.vhdl
    > Date: Thu, 21 Oct 2004 05:20:35 GMT
    > Subject: Re: Async reset
    >
    > On Wed, 20 Oct 2004 18:41:08 -0400, "Jason Berringer"
    > <> wrote:
    >
    >> For FPGAs, when

    > programmed not have an async reset a flop might have a different clk
    > to Q delay (or a faster setup) which would make the design faster.

    I disagree.
    In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
    slices) are the same. They all have a Reset input, whether you use it or
    not, and the clock-to-Q delay is unaffected by the way the user configures
    the design and uses or not uses asynchronous or synchronous Reset or Clear.

    Regarding the basic need for reset, Ken Chapman published an interesting
    (and perhaps provocative) article 3 years ago ( Oct 2001, but it is still on
    the Xilinx website under TechXclusives), and here is his conclusion:

    "Summary
    "A design implemented in a Xilinx FPGA does not require you to insert a
    global reset network. For the vast majority of any design, the
    initialisation state of all flip-flops and RAM following configuration is
    more comprehensive than any logical reset will ever be. There is no
    requirement to insert a reset for simulation because nothing will be
    undefined. Since a Xilinx FPGA is already fully tested silicon, you won't be
    inserting scan logic in your design and running test vectors, so you will
    not need a global reset as part of this process either.

    "Inserting a global reset will impact your development time and final
    product costs even if these factors can not be easily quantified. With the
    trend towards higher speed clocks and complete systems on a chip, the
    reliability issues must be taken seriously. The critical parts of a system
    that must truly be reset should be identified and the release of those
    resets on start up, or during operation, must be controlled as carefully as
    any other signal within a synchronous circuit.

    As you are creating each section of your next design, simply ask yourself:
    "Does this bit need to be reset"?
    from the TechXlusives paper by Ken Chapman, Xilinx

    Peter Alfke
     
    Peter Alfke, Oct 21, 2004
    #7
  8. Hendra wrote:

    (snip)

    > Yes, it is possible to have no reset at all in an FPGA since FPGA will
    > automatically clear all FFs inside the chip during downloading from
    > the bitstream. However, not having the reset will make it harder to
    > simulate since some simulators require all the FFs to be resetted
    > before you can do any simulation. Moreover, what would happen when for
    > some reason your FFs go to undesired state, then you can not get out
    > of the loop!


    I don't believe they are guaranteed to be cleared, as far as user
    logic is concerned. The synthesis often moves inverters around,
    and many signals, including ones through FF's, are actually the
    inverse of the expected signal. I have seen warning messages from
    Quartus for FF's that don't have a reset or preset input that the
    initial state is not guaranteed.

    > There are some articles regarding sync vs async at
    > http://www.sunburst-design.com/papers/


    -- glen
     
    glen herrmannsfeldt, Oct 21, 2004
    #8
  9. Jason Berringer

    mk Guest

    On Thu, 21 Oct 2004 10:02:02 -0700, Peter Alfke <>
    wrote:
    >>
    >>> For FPGAs, when

    >> programmed not have an async reset a flop might have a different clk
    >> to Q delay (or a faster setup) which would make the design faster.

    >I disagree.
    >In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
    >slices) are the same. They all have a Reset input, whether you use it or
    >not, and the clock-to-Q delay is unaffected by the way the user configures
    >the design and uses or not uses asynchronous or synchronous Reset or Clear.


    There is nothing to disagree about. I was just trying to suggest an
    explanation for the observed behavior. You being from xilinx, I'll
    take your statement over my speculation about a xilinx design.

    Also there is one case where one can't really depend on an FPGA to do
    all the resetting for you and that's when you're prototyping an ASIC.
    That's my main focus right now.
     
    mk, Oct 21, 2004
    #9
  10. Jason Berringer

    Tom Verbeure Guest

    In theory, it's perfectly fine not to reset a bunch of FF's if you can
    guarantee that a reset value will ripple through or if you really don't
    care about a state. In practise, we tend to reset all our FF's
    (synchronously, though it doesn't really make a difference) and then
    remove the reset for those FF's for which we can guarantee that it will
    get a defined state after we toggle the clock for a few cycles while
    reset remains asserted. We prefer not to have any FFs with an unknown
    condition when going out of reset. The risk is just to high that we
    overlook cases where we DO get into an unknown state. Reset behavior is
    one of the cases for which we still run a gatelevel simulation.

    As for speed, a case can be made that synchronous reset will eat some
    of your setup time because it puts an AND port in between the
    functional logic and the D input. But asynchronous FFs can have slower
    clock-to-Q times, which may or may not compensate. You'll have to check
    your datasheet.

    As for area: there's no fixed rule. Some libraries have FF's where the
    synchronous reset FFs has the same area as a similar FF without any
    reset at all. Again, check you databook.
    FPGA is another story alltogether. Check the other answers. :)

    Tom
     
    Tom Verbeure, Oct 21, 2004
    #10
  11. Jason Berringer

    Ray Andraka Guest

    This is not entirely true. Xilinx Virtex and later families can have the
    flip-flops with either synchronous or asynchronous (re)sets, but not both unless
    you use the LUT for the sync reset. The wiring to the built in reset pins on the
    flip-flop can be connected to the global reset net. The flip-flops come up in a
    known state at the end of configuration.

    Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use
    an async reset in the FPGA. The issue is that the release of reset is
    asynchronous to the clock, so you will get a situation where some flip-flops see
    the release on one clock cycle where others see the release on the next cycle when
    the reset is released close to the clock edge. The other issue is that an async
    reset propagates through the flip-flop making a timing path that does not end at
    the flip-flop. The timing tools historically have missed this timing path
    (thinking back to the 4000 series tools), so there is a possibly hidden danger to
    using async resets as well.

    As far as resetting every flip flop in the design: it is not necessary. As long
    as you break every synchronous feedback look in the design when you apply reset,
    you can get your design to a known state in a known number of clocks. I described
    this technique here within the past two weeks.

    glen herrmannsfeldt wrote:

    >
    > Synchronous reset will be done using logic resources. It might
    > be that there are enough CLB inputs not to add more, though it
    > might need another column, depending on the function.
    >
    > A separate question is that asynchronous reset needs not to be
    > too close to the clock edge, so it might need to be synchronized
    > (even though not synchronous).
    >
    > -- glen


    --
    --Ray Andraka, P.E.
    President, the Andraka Consulting Group, Inc.
    401/884-7930 Fax 401/884-7950
    email
    http://www.andraka.com

    "They that give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."
    -Benjamin Franklin, 1759
     
    Ray Andraka, Oct 22, 2004
    #11
  12. Ray Andraka wrote:

    > This is not entirely true. Xilinx Virtex and later families can have the
    > flip-flops with either synchronous or asynchronous (re)sets, but not both unless
    > you use the LUT for the sync reset. The wiring to the built in reset pins on the
    > flip-flop can be connected to the global reset net. The flip-flops come up in a
    > known state at the end of configuration.


    My current project is with Altera ACEX, so I now looked up more exactly
    what it does.

    It seems that they provide asynchronous CLEAR and LOAD. If you specify
    only CLEAR (RESET) it is fine. If you specify only PRESET it will
    invert the logic and use CLEAR. If you use both, it needs one LUT
    input (DATA3) to be used for that function. So, it is a little
    more efficient to invert the logic if preset is used, and in that
    case the global reset will act as a preset.

    If neither is used, Quartus seems to be free to do it either
    way, and gives a warning to tell you that.

    I don't see that ACEX supplies a synchronous preset or clear,
    so I believe that would be done through LUT logic.

    It would seem that one should know the details for the logic
    family being used.

    -- glen
     
    glen herrmannsfeldt, Oct 22, 2004
    #12
  13. Jason Berringer

    rickman Guest

    Ray Andraka wrote:
    >
    > This is not entirely true. Xilinx Virtex and later families can have the
    > flip-flops with either synchronous or asynchronous (re)sets, but not both unless
    > you use the LUT for the sync reset. The wiring to the built in reset pins on the
    > flip-flop can be connected to the global reset net. The flip-flops come up in a
    > known state at the end of configuration.
    >
    > Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use
    > an async reset in the FPGA. The issue is that the release of reset is
    > asynchronous to the clock, so you will get a situation where some flip-flops see
    > the release on one clock cycle where others see the release on the next cycle when
    > the reset is released close to the clock edge. The other issue is that an async
    > reset propagates through the flip-flop making a timing path that does not end at
    > the flip-flop. The timing tools historically have missed this timing path
    > (thinking back to the 4000 series tools), so there is a possibly hidden danger to
    > using async resets as well.


    I think advising against using an async reset is a bit strong. With
    attention to the issue, an async reset will work just fine. You just
    can't assume that all FFs will be released on the same clock edge.

    As to the timing issue, that timing condition applies to the assertion
    of the reset. If you are using the async input to reset the entire
    chip, I don't think the propagation time is an issue.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
     
    rickman, Oct 22, 2004
    #13
  14. Thanks to all who have posted here, I have read all of the helpful
    information pointed out on the Xilinx site. Very interesting, and has made
    me rethink my coding style significantly with regards to the reset signal.

    Jason
     
    Jason Berringer, Oct 26, 2004
    #14
  15. "glen herrmannsfeldt" <> wrote in message
    news:cl8qle$uk8$...
    >

    I have seen warning messages from
    > Quartus for FF's that don't have a reset or preset input that the
    > initial state is not guaranteed.
    >
    >> There are some articles regarding sync vs async at
    >> http://www.sunburst-design.com/papers/

    >
    > -- glen
    >
    >

    Quartus synthesis will take advantage of registers which do not specify a
    power-up condition in don't care optimizations. Note that this can often
    result in registers being synthesized away because they are stuck-at in one
    power-up state, so it is important for designers to read the messages as
    warnings, not info. The assignment editor allows one to protect a register
    from this optimization, or specifically give a power-up value to a register
    or set of registers.

    Hope this helps.

    - Subroto Datta
    Altera Corp.
     
    Subroto Datta, Oct 26, 2004
    #15
    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. dong seok huh

    [Q] : async event counter

    dong seok huh, Oct 1, 2003, in forum: VHDL
    Replies:
    6
    Views:
    761
    Renaud Pacalet
    Oct 6, 2003
  2. ALuPin

    Discussion "Async Reset"

    ALuPin, Oct 25, 2004, in forum: VHDL
    Replies:
    2
    Views:
    664
    Raghavendra
    Oct 27, 2004
  3. Niv
    Replies:
    9
    Views:
    829
    Mike Treseler
    Jan 5, 2006
  4. Bryan Johnson

    homework: flipflips with async reset

    Bryan Johnson, Jul 6, 2006, in forum: VHDL
    Replies:
    11
    Views:
    781
    Jonathan Bromley
    Jul 7, 2006
  5. Steven
    Replies:
    0
    Views:
    372
    Steven
    Nov 30, 2005
Loading...

Share This Page