Combinational elements in Global Reset Trees

Discussion in 'VHDL' started by Ponceludon de Malavoy, Jan 10, 2008.

  1. Hi,
    I wanted to know if it is advisable to insert combinational elements
    into Reset trees. I realize that inserting logic into clock paths is a
    nightmare for timing. Is it that bad for reset paths too?

    I'll explain how I got here. I have a flop (I'll call it FF1) in my
    design that has an asynchronous reset (I'll call this async reset
    input of the flop, reset_n). The async reset is generated by logic
    (I'll call this signal FF1_async_reset) driven by other flops. All the
    other flops also have async resets with the difference that they're
    all driven by the global reset (I'll call this global_reset). Now, I
    don't want to leave FF1 out of the global reset path either. So, I was
    thinking of something along these lines:

    reset_n <= global_reset when global_reset = '1' else --connect either
    the global or the local reset to FF1
    FF1_async_reset;

    Obviously, I'm messing with the reset path to FF1. Is this going to
    create problems?

    Thank you for your help.
     
    Ponceludon de Malavoy, Jan 10, 2008
    #1
    1. Advertising

  2. Ponceludon de Malavoy

    KJ Guest

    "Ponceludon de Malavoy" <> wrote in message
    news:...
    > Hi,
    > I wanted to know if it is advisable to insert combinational elements
    > into Reset trees. I realize that inserting logic into clock paths is a
    > nightmare for timing. Is it that bad for reset paths too?


    It is bad for asynchronous resets in FPGAs. Remember that FPGAs use memory
    look up tables to generate their outputs. These can glitch depending on
    your reset logic. A glitch on an asynchronous reset signal will cause some
    of the FFs in a design to get reset, others maybe not.

    The solution is either of the following....
    1. Clock the reset signal so that it is no longer the result of a
    combinatorial logic path. Generally speaking, it really doesn't matter if a
    flip flop gets reset on 'this' clock cycle or 'this+1'.


    2. Use only synchronous resets on your FFs.

    >
    > I'll explain how I got here. I have a flop (I'll call it FF1) in my
    > design that has an asynchronous reset (I'll call this async reset
    > input of the flop, reset_n). The async reset is generated by logic
    > (I'll call this signal FF1_async_reset) driven by other flops. All the
    > other flops also have async resets with the difference that they're
    > all driven by the global reset (I'll call this global_reset). Now, I
    > don't want to leave FF1 out of the global reset path either. So, I was
    > thinking of something along these lines:
    >
    > reset_n <= global_reset when global_reset = '1' else --connect either
    > the global or the local reset to FF1
    > FF1_async_reset;
    >
    > Obviously, I'm messing with the reset path to FF1. Is this going to
    > create problems?


    Probably. Even worse it might appear to work for you at first and lead you
    to believe that this technique is OK but some time later it will start
    failing and take a long time to debug down to the root cause. Make the
    'reset_n' signal (and any other signals that are used to asynchronously set
    or reset any flip flops) be the output of a flip flop....flip flop outputs
    don't glitch.

    Kevin Jennings
     
    KJ, Jan 10, 2008
    #2
    1. Advertising

  3. Ponceludon de Malavoy

    Dave Pollum Guest

    On Jan 10, 3:39 am, Ponceludon de Malavoy <>
    wrote:
    > Hi,
    > I wanted to know if it is advisable to insert combinational elements
    > into Reset trees. I realize that inserting logic into clock paths is a
    > nightmare for timing. Is it that bad for reset paths too?
    >
    > I'll explain how I got here. I have a flop (I'll call it FF1) in my
    > design that has an asynchronous reset (I'll call this async reset
    > input of the flop, reset_n). The async reset is generated by logic
    > (I'll call this signal FF1_async_reset) driven by other flops. All the
    > other flops also have async resets with the difference that they're
    > all driven by the global reset (I'll call this global_reset). Now, I
    > don't want to leave FF1 out of the global reset path either. So, I was
    > thinking of something along these lines:
    >
    > reset_n <= global_reset when global_reset = '1' else --connect either
    > the global or the local reset to FF1
    > FF1_async_reset;
    >
    > Obviously, I'm messing with the reset path to FF1. Is this going to
    > create problems?
    >
    > Thank you for your help.


    From what I've read, if you have an asynchronous reset, the preferred
    method is to feed that async reset into a 2 or 3 stage synchronizer.
    When the async reset is de-asserted, it is sync'd to the clock. So,
    async reset in, synch'd reset out to all FF's that need to be reset.

    -Dave Pollum
     
    Dave Pollum, Jan 11, 2008
    #3
  4. Ponceludon de Malavoy

    Guest

    On Jan 11, 4:29 pm, Dave Pollum <> wrote:
    > On Jan 10, 3:39 am, Ponceludon de Malavoy <>
    > wrote:
    >
    >
    >
    > > Hi,
    > > I wanted to know if it is advisable to insert combinational elements
    > > into Reset trees. I realize that inserting logic into clock paths is a
    > > nightmare for timing. Is it that bad for reset paths too?

    >
    > > I'll explain how I got here. I have a flop (I'll call it FF1) in my
    > > design that has an asynchronous reset (I'll call this async reset
    > > input of the flop, reset_n). The async reset is generated by logic
    > > (I'll call this signal FF1_async_reset) driven by other flops. All the
    > > other flops also have async resets with the difference that they're
    > > all driven by the global reset (I'll call this global_reset). Now, I
    > > don't want to leave FF1 out of the global reset path either. So, I was
    > > thinking of something along these lines:

    >
    > > reset_n <= global_reset when global_reset = '1' else --connect either
    > > the global or the local reset to FF1
    > > FF1_async_reset;

    >
    > > Obviously, I'm messing with the reset path to FF1. Is this going to
    > > create problems?

    >
    > > Thank you for your help.

    >
    > From what I've read, if you have an asynchronous reset, the preferred
    > method is to feed that async reset into a 2 or 3 stage synchronizer.
    > When the async reset is de-asserted, it is sync'd to the clock. So,
    > async reset in, synch'd reset out to all FF's that need to be reset.
    >
    > -Dave Pollum


    It also depends what you need the reset to do. If the reset has to be
    a clock-accurate reset with well-defined behaviour in the immediate
    next cycle (say a reset of a functional unit before the next work item
    is to be precessed) then you should go fully synchronous, both with
    the reset generator and with the logic that uses the reset.

    If, on the other hand, the reset has to just get your logic into some
    known state after a brownout or PLL unlock or power-up, then you can
    often get away with sloppier async resets. However, this is easier
    said than done. There are two common mistakes that people make when
    doing this.

    Mistake 1 is to forget that when the reset drives clocked logic, that
    you have to guarantee that the reset *de-asserts* synchronously to
    clock edge to prevent different flops from seeing the reset complete
    on different clock edges due to skew, etc. This is what Dave Pollum's
    solution helps you achieve. Having an async reset is often an
    invitation for race conditions coming out of reset; many people will
    ignore FPGA PAR timing errors around the reset line. thinking "it's
    OK, it's supposed to be asynchronous" :-(

    Mistake 2 is to assume that clocks are stable during reset; in
    brownout or PLL unlock conditions, this may not always be true. This
    would prevent the simple synchronizer from working properly, you might
    actually delay your reset assertion unwantedly until clocks recover.
    For example, some PLL gating logic may hold the clock solid low until
    the PLL is locked.

    A more robust solution is to use an multi-flop synchronizer chain
    where all flops get asynchronously reset by the global reset (ensuring
    immediate response), then starts clocking through a "valid" (reset
    done, clock valid, or conjunction of both). The "valid" (ie reset de-
    assert) will come out 2 or 3 clocks after the initial condition
    clears. This will ensure that when the reset condition eventually
    clears, then your output reset line gets de-asserted on a known good
    clock edge (required to avoid race conditions), and that some small
    number of known good clocks have elapsed before reset de-asserts
    (required when the reset is used to do a synchronous reset of block
    that are not implemented with async resets).

    There are, as always, many more options. But these two mistakes are
    aspects that I've seen hurt designs in the past; you should consider
    these when you think about modifying your reset tree.

    Cheers,

    - Kenn
     
    , Jan 12, 2008
    #4
    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. ALuPin

    Combinational Loop?

    ALuPin, Aug 30, 2004, in forum: VHDL
    Replies:
    5
    Views:
    6,875
    Ken Smith
    Aug 31, 2004
  2. GuitarNerd
    Replies:
    8
    Views:
    3,804
    Andy Peters
    May 19, 2005
  3. Taras_96
    Replies:
    2
    Views:
    948
    Taras_96
    Aug 22, 2005
  4. krzyg

    combinational division

    krzyg, Aug 24, 2005, in forum: VHDL
    Replies:
    5
    Views:
    1,480
    Duane Clark
    Aug 25, 2005
  5. jacob navia

    Binary search trees (AVL trees)

    jacob navia, Jan 3, 2010, in forum: C Programming
    Replies:
    34
    Views:
    1,430
    Dann Corbit
    Jan 8, 2010
Loading...

Share This Page