Re: Why doesn't this situation generate a latch?

Discussion in 'VHDL' started by Andy, Mar 11, 2010.

  1. Andy

    Andy Guest

    On Mar 10, 1:24 pm, Ed McGettigan <> wrote:
    > On Mar 10, 10:06 am, Andy <> wrote:
    >
    > > On Mar 9, 12:15 pm, Ed McGettigan <> wrote:

    >
    > > > I would strongly encourage you to change the RESET function from
    > > > asynchronous to synchronous.

    >
    > > On what basis do you make this recommendation, and what does this have
    > > to do with latches?

    >
    > > Andy

    >
    > Synchronous versus asynchronous resets have been discussed at length
    > in other threads.
    >
    > Asynchronous resets have their place in a designer's toolbox, however
    > they should be used sparingly.  Some reasons to use these are for
    > handshakes crossing clock domains, anticipated loss of clock and
    > asynchronous inputs to the synchronous domain.
    >
    > In a synchronous domain, such as the original state machine example,
    > the asynchronous functionality offers no additional benefit in FPGAs
    > as the area cost is identical for both.
    >
    > Asynchronously asserting and de-asserting a reset across multiple
    > registers may/will result in the registers being released before and
    > after a clock edge due to large net delay and skew on the reset net.
    > This will result in different parts of a design coming out of reset
    > across clock boundaries and being out of sync with each other.
    >
    > Synchronous resets simplify timing analysis and timing closure without
    > having to worry about the consequences of the asynchronous functions
    > and how to correctly constrain them.
    >
    > I often see problems with FPGA designs that are built with
    > asynchronous resets, but I have yet to see a problem with a FPGA
    > design that was traced to a synchronous reset.
    >
    > In an FPGA there is no downside to a synchronous reset, but there are
    > many pitfalls with an asynchronous reset.
    >
    > None of this has anything to do with a latch, which you also want to
    > avoid using in an FPGA.
    >
    > Ed McGettigan
    > --
    > Xilinx Inc.


    Given that most sources of reset signals are not already synchronized
    to the clock domain(s) that need resetting, both asynchronous and
    syncrhonous resets require at least the deasserting edge to be
    synchronized. Proper syncrhonization for each case takes the same
    amount of design effort and resources.

    I will agree that getting the constraints set to make sure that the
    synchronous deassertion path meets timing in an asynchronously reset
    system can be non-obvious, but that is a tools issue, not a design
    issue (in other words, fix the tools!)

    Given that an asynchronous reset reliably resets the circuit,
    regardless of the presence or stability of the clock signal, when an
    asynchronous reset is correctly designed, it is a more reliable reset
    than a synchronous one.

    Andy
    Andy, Mar 11, 2010
    #1
    1. Advertising

  2. On Mar 10, 4:25 pm, Andy <> wrote:
    > On Mar 10, 1:24 pm, Ed McGettigan <> wrote:
    >
    >
    >
    >
    >
    > > On Mar 10, 10:06 am, Andy <> wrote:

    >
    > > > On Mar 9, 12:15 pm, Ed McGettigan <> wrote:

    >
    > > > > I would strongly encourage you to change the RESET function from
    > > > > asynchronous to synchronous.

    >
    > > > On what basis do you make this recommendation, and what does this have
    > > > to do with latches?

    >
    > > > Andy

    >
    > > Synchronous versus asynchronous resets have been discussed at length
    > > in other threads.

    >
    > > Asynchronous resets have their place in a designer's toolbox, however
    > > they should be used sparingly.  Some reasons to use these are for
    > > handshakes crossing clock domains, anticipated loss of clock and
    > > asynchronous inputs to the synchronous domain.

    >
    > > In a synchronous domain, such as the original state machine example,
    > > the asynchronous functionality offers no additional benefit in FPGAs
    > > as the area cost is identical for both.

    >
    > > Asynchronously asserting and de-asserting a reset across multiple
    > > registers may/will result in the registers being released before and
    > > after a clock edge due to large net delay and skew on the reset net.
    > > This will result in different parts of a design coming out of reset
    > > across clock boundaries and being out of sync with each other.

    >
    > > Synchronous resets simplify timing analysis and timing closure without
    > > having to worry about the consequences of the asynchronous functions
    > > and how to correctly constrain them.

    >
    > > I often see problems with FPGA designs that are built with
    > > asynchronous resets, but I have yet to see a problem with a FPGA
    > > design that was traced to a synchronous reset.

    >
    > > In an FPGA there is no downside to a synchronous reset, but there are
    > > many pitfalls with an asynchronous reset.

    >
    > > None of this has anything to do with a latch, which you also want to
    > > avoid using in an FPGA.

    >
    > > Ed McGettigan
    > > --
    > > Xilinx Inc.

    >
    > Given that most sources of reset signals are not already synchronized
    > to the clock domain(s) that need resetting, both asynchronous and
    > syncrhonous resets require at least the deasserting edge to be
    > synchronized. Proper syncrhonization for each case takes the same
    > amount of design effort and resources.
    >
    > I will agree that getting the constraints set to make sure that the
    > synchronous deassertion path meets timing in an asynchronously reset
    > system can be non-obvious, but that is a tools issue, not a design
    > issue (in other words, fix the tools!)
    >
    > Given that an asynchronous reset reliably resets the circuit,
    > regardless of the presence or stability of the clock signal, when an
    > asynchronous reset is correctly designed, it is a more reliable reset
    > than a synchronous one.
    >
    > Andy- Hide quoted text -
    >
    > - Show quoted text -


    I wouldn't take it as a given that most resets are not already
    synchronized to the clock domains. Resets are routinely used based on
    termination count, end of packet, return to state0 from other states
    or invalid states, etc.... All of these cases would be within the
    same clock domain.

    Placing the onus of creating a reliable design on software tools to
    correctly determine the designer's intent for timing paths that are
    "non-obvious" is not a working solution IMHO.

    The cons of an asynchronous reset significantly outweigh the single
    pro that the reset will occur in the absence of clock.

    Ed McGettigan
    --
    Xilinx Inc.
    Ed McGettigan, Mar 11, 2010
    #2
    1. Advertising

  3. Andy

    -jg Guest

    On Mar 11, 2:01 pm, Ed McGettigan <> wrote:

    > The cons of an asynchronous reset significantly outweigh the single
    > pro that the reset will occur in the absence of clock.


    For Logic 'buried deep', that would be correct, but
    for pin-drive logic, having a defined state BEFORE the clock, can be
    quite mission-critical.

    -jg
    -jg, Mar 11, 2010
    #3
  4. On Mar 10, 5:10 pm, -jg <> wrote:
    > On Mar 11, 2:01 pm, Ed McGettigan <> wrote:
    >
    > > The cons of an asynchronous reset significantly outweigh the single
    > > pro that the reset will occur in the absence of clock.

    >
    >  For Logic 'buried deep', that would be correct, but
    > for pin-drive logic, having a defined state BEFORE the clock, can be
    > quite mission-critical.
    >
    >  -jg


    I absolutely agree that asynchronous resets have a very valid use in
    certain cases. My position is that should be avoided in the general
    case.

    FPGAs with the asynchronous global set/reset can also get you into
    that known state before any clocks are applied.

    Ed McGettigan
    --
    Xilinx Inc.
    Ed McGettigan, Mar 11, 2010
    #4
  5. On Mar 10, 5:42 pm, Ed McGettigan <> wrote:
    > On Mar 10, 5:10 pm, -jg <> wrote:
    >
    > > On Mar 11, 2:01 pm, Ed McGettigan <> wrote:

    >
    > > > The cons of an asynchronous reset significantly outweigh the single
    > > > pro that the reset will occur in the absence of clock.

    >
    > >  For Logic 'buried deep', that would be correct, but
    > > for pin-drive logic, having a defined state BEFORE the clock, can be
    > > quite mission-critical.

    >
    > >  -jg

    >
    > I absolutely agree that asynchronous resets have a very valid use in
    > certain cases.  My position is that should be avoided in the general
    > case.
    >
    > FPGAs with the asynchronous global set/reset can also get you into
    > that known state before any clocks are applied.
    >
    > Ed McGettigan
    > --
    > Xilinx Inc.


    Andy,
    "Some synthesis tools may be getting smart enough to optimize an
    inferred latch from a combinatorial process into a clock enable on
    the
    corresponding register implied by the clocked process. But if there
    are any other combinatorial processes that use that latched output of
    the first combinatorial process, then the latch cannot be replaced by
    a clock enable on a register. "

    I am interested in above your comment. Can you list an example to show
    "the latch cannot be replaced by
    a clock enable on a register"

    My opinion is that you never will find an example to support your
    claim.

    1. Whether generating a latch for a intermediate data or not doesn't
    change a state machine's behavior. Do you agree?

    2. In a synchronous system, signal's data is valid and used near the
    clock triggering edge: between set-up time and hold time. Generating a
    latch for intermediate data for a state machine would make system
    slower, not faster in any situation.

    3. Timing for other signals may be affected, of course.

    Weng








    Andy
    Weng Tianxiang, Mar 11, 2010
    #5
  6. Andy

    Andy Guest

    On Mar 10, 7:01 pm, Ed McGettigan <> wrote:
    >
    > I wouldn't take it as a given that most resets are not already
    > synchronized to the clock domains.  Resets are routinely used based on
    > termination count, end of packet, return to state0 from other states
    > or invalid states, etc....  All of these cases would be within the
    > same clock domain.


    OK, now I see where we're missing each other: in the definition of
    what constitutes a reset function. When I say reset, I mean "device
    initialization", either upon power up, power failure, BIT failure,
    system watchdog event, etc. that resets darn near the whole device.
    When you say "reset" you mean anytime the logic loads a zero or other
    static value into a counter, etc.

    Our best practice policies forbid combining local, functional
    "restarts" like you mentioned, with the reset (initialization)
    circuit, or from using asynchronous (causal) reset/preset controls for
    them. If a register is not reset for initialization, it is acceptable
    to use a synchronous reset control on a register for functional
    restarts, etc. There are a few cases where asynchronous controls are
    acceptable in sync boundaries, etc. but they are subject to specific
    review and approval. These "restart" functions are, as you say, often
    triggered by synchronous signals anyway, and are part of the
    functional nature of the design, not part of the initialization.

    But for device initialization, our best practices recommend the use of
    asynchronous resets where possible (subject to device support).

    > Placing the onus of creating a reliable design on software tools to
    > correctly determine the designer's intent for timing paths that are
    > "non-obvious" is not a working solution IMHO.


    Why is it not obvious that an output from a same clocked register,
    driving an asynchronous reset input to another same-clocked register,
    should be checked for the timing relative to that clock? Every
    asynchronously reset register still has a setup and hold requirement
    for the deasserting edge of that reset input, so check it the same way
    you check synchronous inputs (i.e. depending upon the clock domain of
    the driven input). You don't even have to check any asyncrhonous paths
    through the registers to do this.

    Thanks,

    Andy
    Andy, Mar 11, 2010
    #6
  7. Andy

    Andy Guest

    On Mar 10, 8:44 pm, Weng Tianxiang <> wrote:
    > Andy,
    > "Some synthesis tools may be getting smart enough to optimize an
    > inferred latch from a combinatorial process into a clock enable on
    > the
    > corresponding register implied by the clocked process. But if there
    > are any other combinatorial processes that use that latched output of
    > the first combinatorial process, then the latch cannot be replaced by
    > a clock enable on a register. "
    >
    > I am interested in above your comment. Can you list an example to show
    > "the latch cannot be replaced by
    > a clock enable on a register"


    Example:

    A <= B when ENABLE; -- implies a latch for A
    C <= A when rising_edge(CLK); -- a register using A
    E <= A or D; -- another combinatorial function using A

    If not for E, the latch could be replaced by a clock enable on the C
    register. I suppose C could still use a clock enable and the B input
    directly, but it does not wholly "replace" the latch, because the
    latch is still needed to derive E.

    Andy
    Andy, Mar 11, 2010
    #7
  8. On Mar 11, 9:29 am, Andy <> wrote:
    > On Mar 10, 8:44 pm, Weng Tianxiang <> wrote:
    >
    > > Andy,
    > > "Some synthesis tools may be getting smart enough to optimize an
    > > inferred latch from a combinatorial process into a clock enable on
    > > the
    > > corresponding register implied by the clocked process. But if there
    > > are any other combinatorial processes that use that latched output of
    > > the first combinatorial process, then the latch cannot be replaced by
    > > a clock enable on a register. "

    >
    > > I am interested in above your comment. Can you list an example to show
    > > "the latch cannot be replaced by
    > > a clock enable on a register"

    >
    > Example:
    >
    > A <= B when ENABLE; -- implies a latch for A
    > C <= A when rising_edge(CLK); -- a register using A
    > E <= A or D; -- another combinatorial function using A
    >
    > If not for E, the latch could be replaced by a clock enable on the C
    > register. I suppose C could still use a clock enable and the B input
    > directly, but it does not wholly "replace" the latch, because the
    > latch is still needed to derive E.
    >
    > Andy


    Andy,
    We don't argue about the latch replacement as you show. What we argue
    about is when a fast next state signal StateA_NS is replaced by a
    slower latched version.
    It occurs if a condition in an if statement misses a signal assignment
    statement as we have been discussing about.

    Weng
    Weng Tianxiang, Mar 11, 2010
    #8
  9. Andy

    Andy Guest

    On Mar 11, 1:38 pm, Weng Tianxiang <> wrote:
    > On Mar 11, 9:29 am, Andy <> wrote:
    >
    >
    >
    >
    >
    > > On Mar 10, 8:44 pm, Weng Tianxiang <> wrote:

    >
    > > > Andy,
    > > > "Some synthesis tools may be getting smart enough to optimize an
    > > > inferred latch from a combinatorial process into a clock enable on
    > > > the
    > > > corresponding register implied by the clocked process. But if there
    > > > are any other combinatorial processes that use that latched output of
    > > > the first combinatorial process, then the latch cannot be replaced by
    > > > a clock enable on a register. "

    >
    > > > I am interested in above your comment. Can you list an example to show
    > > > "the latch cannot be replaced by
    > > > a clock enable on a register"

    >
    > > Example:

    >
    > > A <= B when ENABLE; -- implies a latch for A
    > > C <= A when rising_edge(CLK); -- a register using A
    > > E <= A or D; -- another combinatorial function using A

    >
    > > If not for E, the latch could be replaced by a clock enable on the C
    > > register. I suppose C could still use a clock enable and the B input
    > > directly, but it does not wholly "replace" the latch, because the
    > > latch is still needed to derive E.

    >
    > > Andy

    >
    > Andy,
    > We don't argue about the latch replacement as you show. What we argue
    > about is when a fast next state signal StateA_NS is replaced by a
    > slower latched version.
    > It occurs if a condition in an if statement misses a signal assignment
    > statement as we have been discussing about.
    >
    > Weng- Hide quoted text -
    >
    > - Show quoted text -


    I'm not sure why you are concerned about this. Everyone seems to agree
    that inferring latches is not a good idea. The fact that it slows
    performance (at least in FPGA's, see below) is just one more reason to
    avoid them.

    It just so happens that in FPGAs, the clock enable mux is always there
    on the front of the flip-flop, so there is no timing penalty whether
    you actually use it or not, and adding a latch in front of it is
    always slower.

    In other technologies, you have a choice of having a clock enabled or
    regular flip-flop, with the latter being faster. Now the question is,
    in such a technology, is the latch plus regular flop faster than the
    clock enabled flop?

    Andy
    Andy, Mar 11, 2010
    #9
  10. On Mar 11, 12:08 pm, Andy <> wrote:
    > On Mar 11, 1:38 pm, Weng Tianxiang <> wrote:
    >
    >
    >
    >
    >
    > > On Mar 11, 9:29 am, Andy <> wrote:

    >
    > > > On Mar 10, 8:44 pm, Weng Tianxiang <> wrote:

    >
    > > > > Andy,
    > > > > "Some synthesis tools may be getting smart enough to optimize an
    > > > > inferred latch from a combinatorial process into a clock enable on
    > > > > the
    > > > > corresponding register implied by the clocked process. But if there
    > > > > are any other combinatorial processes that use that latched output of
    > > > > the first combinatorial process, then the latch cannot be replaced by
    > > > > a clock enable on a register. "

    >
    > > > > I am interested in above your comment. Can you list an example to show
    > > > > "the latch cannot be replaced by
    > > > > a clock enable on a register"

    >
    > > > Example:

    >
    > > > A <= B when ENABLE; -- implies a latch for A
    > > > C <= A when rising_edge(CLK); -- a register using A
    > > > E <= A or D; -- another combinatorial function using A

    >
    > > > If not for E, the latch could be replaced by a clock enable on the C
    > > > register. I suppose C could still use a clock enable and the B input
    > > > directly, but it does not wholly "replace" the latch, because the
    > > > latch is still needed to derive E.

    >
    > > > Andy

    >
    > > Andy,
    > > We don't argue about the latch replacement as you show. What we argue
    > > about is when a fast next state signal StateA_NS is replaced by a
    > > slower latched version.
    > > It occurs if a condition in an if statement misses a signal assignment
    > > statement as we have been discussing about.

    >
    > > Weng- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > I'm not sure why you are concerned about this. Everyone seems to agree
    > that inferring latches is not a good idea. The fact that it slows
    > performance (at least in FPGA's, see below) is just one more reason to
    > avoid them.
    >
    > It just so happens that in FPGAs, the clock enable mux is always there
    > on the front of the flip-flop, so there is no timing penalty whether
    > you actually use it or not, and adding a latch in front of it is
    > always slower.
    >
    > In other technologies, you have a choice of having a clock enabled or
    > regular flip-flop, with the latter being faster. Now the question is,
    > in such a technology, is the latch plus regular flop faster than the
    > clock enabled flop?
    >
    > Andy


    Andy,
    Thank you for your comments.

    Weng
    Weng Tianxiang, Mar 12, 2010
    #10
  11. Andy

    rickman Guest

    On Mar 10, 8:01 pm, Ed McGettigan <> wrote:
    > On Mar 10, 4:25 pm, Andy <> wrote:
    >
    >
    >
    > > On Mar 10, 1:24 pm, Ed McGettigan <> wrote:

    >
    > > > On Mar 10, 10:06 am, Andy <> wrote:

    >
    > > > > On Mar 9, 12:15 pm, Ed McGettigan <> wrote:

    >
    > > > > > I would strongly encourage you to change the RESET function from
    > > > > > asynchronous to synchronous.

    >
    > > > > On what basis do you make this recommendation, and what does this have
    > > > > to do with latches?

    >
    > > > > Andy

    >
    > > > Synchronous versus asynchronous resets have been discussed at length
    > > > in other threads.

    >
    > > > Asynchronous resets have their place in a designer's toolbox, however
    > > > they should be used sparingly.  Some reasons to use these are for
    > > > handshakes crossing clock domains, anticipated loss of clock and
    > > > asynchronous inputs to the synchronous domain.

    >
    > > > In a synchronous domain, such as the original state machine example,
    > > > the asynchronous functionality offers no additional benefit in FPGAs
    > > > as the area cost is identical for both.

    >
    > > > Asynchronously asserting and de-asserting a reset across multiple
    > > > registers may/will result in the registers being released before and
    > > > after a clock edge due to large net delay and skew on the reset net.
    > > > This will result in different parts of a design coming out of reset
    > > > across clock boundaries and being out of sync with each other.

    >
    > > > Synchronous resets simplify timing analysis and timing closure without
    > > > having to worry about the consequences of the asynchronous functions
    > > > and how to correctly constrain them.

    >
    > > > I often see problems with FPGA designs that are built with
    > > > asynchronous resets, but I have yet to see a problem with a FPGA
    > > > design that was traced to a synchronous reset.

    >
    > > > In an FPGA there is no downside to a synchronous reset, but there are
    > > > many pitfalls with an asynchronous reset.

    >
    > > > None of this has anything to do with a latch, which you also want to
    > > > avoid using in an FPGA.

    >
    > > > Ed McGettigan
    > > > --
    > > > Xilinx Inc.

    >
    > > Given that most sources of reset signals are not already synchronized
    > > to the clock domain(s) that need resetting, both asynchronous and
    > > syncrhonous resets require at least the deasserting edge to be
    > > synchronized. Proper syncrhonization for each case takes the same
    > > amount of design effort and resources.

    >
    > > I will agree that getting the constraints set to make sure that the
    > > synchronous deassertion path meets timing in an asynchronously reset
    > > system can be non-obvious, but that is a tools issue, not a design
    > > issue (in other words, fix the tools!)

    >
    > > Given that an asynchronous reset reliably resets the circuit,
    > > regardless of the presence or stability of the clock signal, when an
    > > asynchronous reset is correctly designed, it is a more reliable reset
    > > than a synchronous one.

    >
    > > Andy- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > I wouldn't take it as a given that most resets are not already
    > synchronized to the clock domains.  Resets are routinely used based on
    > termination count, end of packet, return to state0 from other states
    > or invalid states, etc....  All of these cases would be within the
    > same clock domain.
    >
    > Placing the onus of creating a reliable design on software tools to
    > correctly determine the designer's intent for timing paths that are
    > "non-obvious" is not a working solution IMHO.
    >
    > The cons of an asynchronous reset significantly outweigh the single
    > pro that the reset will occur in the absence of clock.
    >
    > Ed McGettigan
    > --
    > Xilinx Inc.


    I don't follow that at all. I use async resets all the time, but I
    use them appropriately. I don't expect them to release all FFs at the
    same time and design that way. That's all it takes. No magic, mo
    complex design techniques. I just don't assume a counter will have
    all bits start at the same clock cycle, give or take one cycle. But a
    binary counter will only increment the lsb if started at count 0. So
    it will start correctly if the rest of the bits are released in the
    next clock cycle or the one before. My state machine designs include
    a start state that is just to allow the state machine to release from
    reset. The list goes on. But nothing on the list is hard to
    understand or to implement. More importantly, an async reset and the
    small amount of logic required to release FFs from the async reset is
    less logic than adding a sync reset to every FF in the design. AND
    it will operate irrespective of the state of the clock!

    Rick
    rickman, Mar 13, 2010
    #11
  12. Andy

    rickman Guest

    On Mar 10, 8:42 pm, Ed McGettigan <> wrote:
    > On Mar 10, 5:10 pm, -jg <> wrote:
    >
    > > On Mar 11, 2:01 pm, Ed McGettigan <> wrote:

    >
    > > > The cons of an asynchronous reset significantly outweigh the single
    > > > pro that the reset will occur in the absence of clock.

    >
    > >  For Logic 'buried deep', that would be correct, but
    > > for pin-drive logic, having a defined state BEFORE the clock, can be
    > > quite mission-critical.

    >
    > >  -jg

    >
    > I absolutely agree that asynchronous resets have a very valid use in
    > certain cases.  My position is that should be avoided in the general
    > case.
    >
    > FPGAs with the asynchronous global set/reset can also get you into
    > that known state before any clocks are applied.
    >
    > Ed McGettigan


    My understanding is the global set/reset is what we are talking about
    when we say "async reset". That is what it is mapped to in all of my
    designs.

    Rick
    rickman, Mar 13, 2010
    #12
  13. rickman wrote:
    > On Mar 10, 8:01 pm, Ed McGettigan <> wrote:
    >> On Mar 10, 4:25 pm, Andy <> wrote:
    >>
    >>
    >>
    >>> On Mar 10, 1:24 pm, Ed McGettigan <> wrote:
    >>>> On Mar 10, 10:06 am, Andy <> wrote:
    >>>>> On Mar 9, 12:15 pm, Ed McGettigan <> wrote:
    >>>>>> I would strongly encourage you to change the RESET function from
    >>>>>> asynchronous to synchronous.
    >>>>> On what basis do you make this recommendation, and what does this have
    >>>>> to do with latches?
    >>>>> Andy
    >>>> Synchronous versus asynchronous resets have been discussed at length
    >>>> in other threads.
    >>>> Asynchronous resets have their place in a designer's toolbox, however
    >>>> they should be used sparingly. Some reasons to use these are for
    >>>> handshakes crossing clock domains, anticipated loss of clock and
    >>>> asynchronous inputs to the synchronous domain.
    >>>> In a synchronous domain, such as the original state machine example,
    >>>> the asynchronous functionality offers no additional benefit in FPGAs
    >>>> as the area cost is identical for both.
    >>>> Asynchronously asserting and de-asserting a reset across multiple
    >>>> registers may/will result in the registers being released before and
    >>>> after a clock edge due to large net delay and skew on the reset net.
    >>>> This will result in different parts of a design coming out of reset
    >>>> across clock boundaries and being out of sync with each other.
    >>>> Synchronous resets simplify timing analysis and timing closure without
    >>>> having to worry about the consequences of the asynchronous functions
    >>>> and how to correctly constrain them.
    >>>> I often see problems with FPGA designs that are built with
    >>>> asynchronous resets, but I have yet to see a problem with a FPGA
    >>>> design that was traced to a synchronous reset.
    >>>> In an FPGA there is no downside to a synchronous reset, but there are
    >>>> many pitfalls with an asynchronous reset.
    >>>> None of this has anything to do with a latch, which you also want to
    >>>> avoid using in an FPGA.
    >>>> Ed McGettigan
    >>>> --
    >>>> Xilinx Inc.
    >>> Given that most sources of reset signals are not already synchronized
    >>> to the clock domain(s) that need resetting, both asynchronous and
    >>> syncrhonous resets require at least the deasserting edge to be
    >>> synchronized. Proper syncrhonization for each case takes the same
    >>> amount of design effort and resources.
    >>> I will agree that getting the constraints set to make sure that the
    >>> synchronous deassertion path meets timing in an asynchronously reset
    >>> system can be non-obvious, but that is a tools issue, not a design
    >>> issue (in other words, fix the tools!)
    >>> Given that an asynchronous reset reliably resets the circuit,
    >>> regardless of the presence or stability of the clock signal, when an
    >>> asynchronous reset is correctly designed, it is a more reliable reset
    >>> than a synchronous one.
    >>> Andy- Hide quoted text -
    >>> - Show quoted text -

    >> I wouldn't take it as a given that most resets are not already
    >> synchronized to the clock domains. Resets are routinely used based on
    >> termination count, end of packet, return to state0 from other states
    >> or invalid states, etc.... All of these cases would be within the
    >> same clock domain.
    >>
    >> Placing the onus of creating a reliable design on software tools to
    >> correctly determine the designer's intent for timing paths that are
    >> "non-obvious" is not a working solution IMHO.
    >>
    >> The cons of an asynchronous reset significantly outweigh the single
    >> pro that the reset will occur in the absence of clock.
    >>
    >> Ed McGettigan
    >> --
    >> Xilinx Inc.

    >
    > I don't follow that at all. I use async resets all the time, but I
    > use them appropriately. I don't expect them to release all FFs at the
    > same time and design that way. That's all it takes. No magic, mo
    > complex design techniques. I just don't assume a counter will have
    > all bits start at the same clock cycle, give or take one cycle. But a
    > binary counter will only increment the lsb if started at count 0. So
    > it will start correctly if the rest of the bits are released in the
    > next clock cycle or the one before. My state machine designs include
    > a start state that is just to allow the state machine to release from
    > reset. The list goes on. But nothing on the list is hard to
    > understand or to implement. More importantly, an async reset and the
    > small amount of logic required to release FFs from the async reset is
    > less logic than adding a sync reset to every FF in the design. AND
    > it will operate irrespective of the state of the clock!
    >
    > Rick

    AFAIK, the reset and set ports in flip flops in Xilinx FPGAs can be
    configured to be either asynchronous or synchronous. So there is no
    extra logic required to implement synchronous resets.
    In fact, if you don't specify a reset for a register, the reset and set
    ports can be used as logic inputs, so you can put more logic in a slice.

    If your design has outputs that are critical you can use async reset on
    the output registers or use logic to set the output asynchronously.

    I use a reset circuit that holds the design in reset until the DCM/PLL's
    locked output is asserted, and then some cycles. Then I know I have a
    stable clock before the design starts up.

    Magne
    Magne Munkejord, Mar 15, 2010
    #13
  14. Andy

    rickman Guest

    On Mar 15, 8:14 am, Magne Munkejord <> wrote:
    > rickman wrote:
    > > On Mar 10, 8:01 pm, Ed McGettigan <> wrote:
    > >> On Mar 10, 4:25 pm, Andy <> wrote:

    >
    > >>> On Mar 10, 1:24 pm, Ed McGettigan <> wrote:
    > >>>> On Mar 10, 10:06 am, Andy <> wrote:
    > >>>>> On Mar 9, 12:15 pm, Ed McGettigan <> wrote:
    > >>>>>> I would strongly encourage you to change the RESET function from
    > >>>>>> asynchronous to synchronous.
    > >>>>> On what basis do you make this recommendation, and what does this have
    > >>>>> to do with latches?
    > >>>>> Andy
    > >>>> Synchronous versus asynchronous resets have been discussed at length
    > >>>> in other threads.
    > >>>> Asynchronous resets have their place in a designer's toolbox, however
    > >>>> they should be used sparingly.  Some reasons to use these are for
    > >>>> handshakes crossing clock domains, anticipated loss of clock and
    > >>>> asynchronous inputs to the synchronous domain.
    > >>>> In a synchronous domain, such as the original state machine example,
    > >>>> the asynchronous functionality offers no additional benefit in FPGAs
    > >>>> as the area cost is identical for both.
    > >>>> Asynchronously asserting and de-asserting a reset across multiple
    > >>>> registers may/will result in the registers being released before and
    > >>>> after a clock edge due to large net delay and skew on the reset net.
    > >>>> This will result in different parts of a design coming out of reset
    > >>>> across clock boundaries and being out of sync with each other.
    > >>>> Synchronous resets simplify timing analysis and timing closure without
    > >>>> having to worry about the consequences of the asynchronous functions
    > >>>> and how to correctly constrain them.
    > >>>> I often see problems with FPGA designs that are built with
    > >>>> asynchronous resets, but I have yet to see a problem with a FPGA
    > >>>> design that was traced to a synchronous reset.
    > >>>> In an FPGA there is no downside to a synchronous reset, but there are
    > >>>> many pitfalls with an asynchronous reset.
    > >>>> None of this has anything to do with a latch, which you also want to
    > >>>> avoid using in an FPGA.
    > >>>> Ed McGettigan
    > >>>> --
    > >>>> Xilinx Inc.
    > >>> Given that most sources of reset signals are not already synchronized
    > >>> to the clock domain(s) that need resetting, both asynchronous and
    > >>> syncrhonous resets require at least the deasserting edge to be
    > >>> synchronized. Proper syncrhonization for each case takes the same
    > >>> amount of design effort and resources.
    > >>> I will agree that getting the constraints set to make sure that the
    > >>> synchronous deassertion path meets timing in an asynchronously reset
    > >>> system can be non-obvious, but that is a tools issue, not a design
    > >>> issue (in other words, fix the tools!)
    > >>> Given that an asynchronous reset reliably resets the circuit,
    > >>> regardless of the presence or stability of the clock signal, when an
    > >>> asynchronous reset is correctly designed, it is a more reliable reset
    > >>> than a synchronous one.
    > >>> Andy- Hide quoted text -
    > >>> - Show quoted text -
    > >> I wouldn't take it as a given that most resets are not already
    > >> synchronized to the clock domains.  Resets are routinely used based on
    > >> termination count, end of packet, return to state0 from other states
    > >> or invalid states, etc....  All of these cases would be within the
    > >> same clock domain.

    >
    > >> Placing the onus of creating a reliable design on software tools to
    > >> correctly determine the designer's intent for timing paths that are
    > >> "non-obvious" is not a working solution IMHO.

    >
    > >> The cons of an asynchronous reset significantly outweigh the single
    > >> pro that the reset will occur in the absence of clock.

    >
    > >> Ed McGettigan
    > >> --
    > >> Xilinx Inc.

    >
    > > I don't follow that at all.  I use async resets all the time, but I
    > > use them appropriately.  I don't expect them to release all FFs at the
    > > same time and design that way.  That's all it takes.  No magic, mo
    > > complex design techniques.  I just don't assume a counter will have
    > > all bits start at the same clock cycle, give or take one cycle.  But a
    > > binary counter will only increment the lsb if started at count 0.  So
    > > it will start correctly if the rest of the bits are released in the
    > > next clock cycle or the one before.  My state machine designs include
    > > a start state that is just to allow the state machine to release from
    > > reset.  The list goes on.  But nothing on the list is hard to
    > > understand or to implement.  More importantly, an async reset and the
    > > small amount of logic required to release FFs from the async reset is
    > > less logic than adding a sync reset to every FF in the design.   AND
    > > it will operate irrespective of the state of the clock!

    >
    > > Rick

    >
    > AFAIK, the reset and set ports in flip flops in Xilinx FPGAs can be
    > configured to be either asynchronous or synchronous. So there is no
    > extra logic required to implement synchronous resets.
    > In fact, if you don't specify a reset for a register, the reset and set
    > ports can be used as logic inputs, so you can put more logic in a slice.


    You would think that. I just had to change some code to eliminate a
    sync reset on a register to get rid of one level of LUTs in a Lattice
    design which has a similar if not same FF structure with the dedicated
    LSR input (Local Set/Reset). Synplify seems to not know how to use
    that. Maybe this would get changed by the mapper, but I don't think
    it does that. I was looking at it in the synthesis tool. Have you
    tried an example? Does Synplify do a better job with the Xilinx parts
    than they do with Lattice parts? I'm not convinced they do a good job
    with the arithmetic units. It is more than once I've seen an adder
    chain duplicated to get the carry out of the top!

    > If your design has outputs that are critical you can use async reset on
    > the output registers or use logic to set the output asynchronously.
    >
    > I use a reset circuit that holds the design in reset until the DCM/PLL's
    > locked output is asserted, and then some cycles. Then I know I have a
    > stable clock before the design starts up.


    This issue is very complex in the real world. Once you find a
    solution you like, most people stick with it regardless. I haven't
    found a problem with the async reset and it always starts the chip in
    the same state no matter what! I just pay a little attention to how
    my circuits come out of an async reset which I don't find difficult at
    all. I haven't tried the PLL yet. That may be in a later design, so
    I may have to change my methods.

    Rick
    rickman, Mar 15, 2010
    #14
  15. rickman wrote:

    > You would think that. I just had to change some code to eliminate a
    > sync reset on a register to get rid of one level of LUTs in a Lattice
    > design which has a similar if not same FF structure with the dedicated
    > LSR input (Local Set/Reset). Synplify seems to not know how to use
    > that. Maybe this would get changed by the mapper, but I don't think
    > it does that. I was looking at it in the synthesis tool. Have you
    > tried an example? Does Synplify do a better job with the Xilinx parts
    > than they do with Lattice parts? I'm not convinced they do a good job
    > with the arithmetic units. It is more than once I've seen an adder
    > chain duplicated to get the carry out of the top!


    Hi Rick,

    I tried 5-input registered OR, like this:

    p_sync_or : process (clk) is
    begin
    if rising_edge(clk) then
    q <= a or b or c or d or e;
    end if;
    end process p_sync_or;

    In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
    port of the register, and so does not require two LUTs to implement the
    gate.

    When it comes to Synplify I only have the actel edition ( only actel
    parts supported(?)) and I have hardly ever used it.

    I think actel parts only support async resets for their registers, in
    which case it is true as you say, that designing synchronous resets will
    generate extra logic in front of the registers. Maybe this is true for
    Lattice as well. In that case I would prefer using an async reset to
    avoid the extra logic and performance penalty.

    If the reset signal is synchronously deasserted, it can be constrained
    so that one is certain it will reach each register at a proper time.

    Magne
    Magne Munkejord, Mar 16, 2010
    #15
  16. On Mar 16, 2:04 am, Magne Munkejord <> wrote:
    > rickman wrote:
    > > You would think that.  I just had to change some code to eliminate a
    > > sync reset on a register to get rid of one level of LUTs in a Lattice
    > > design which has a similar if not same FF structure with the dedicated
    > > LSR input (Local Set/Reset).  Synplify seems to not know how to use
    > > that.  Maybe this would get changed by the mapper, but I don't think
    > > it does that.  I was looking at it in the synthesis tool.  Have you
    > > tried an example?  Does Synplify do a better job with the Xilinx parts
    > > than they do with Lattice parts?  I'm not convinced they do a good job
    > > with the arithmetic units.  It is more than once I've seen an adder
    > > chain duplicated to get the carry out of the top!

    >
    > Hi Rick,
    >
    > I tried 5-input registered OR, like this:
    >
    >      p_sync_or : process (clk) is
    >      begin
    >          if rising_edge(clk) then
    >              q <= a or b or c or d or e;
    >          end if;
    >      end process p_sync_or;
    >
    > In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
    > port of the register, and so does not require two LUTs to implement the
    > gate.
    >
    > When it comes to Synplify I only have the actel edition ( only actel
    > parts supported(?)) and I have hardly ever used it.
    >
    > I think actel parts only support async resets for their registers, in
    > which case it is true as you say, that designing synchronous resets will
    > generate extra logic in front of the registers. Maybe this is true for
    > Lattice as well. In that case I would prefer using an async reset to
    > avoid the extra logic and performance penalty.
    >
    > If the reset signal is synchronously deasserted, it can be constrained
    > so that one is certain it will reach each register at a proper time.
    >
    > Magne


    Magne,
    Your method is wrong !

    You cannot connect 'e' to the set port of the register. It may
    compromise a new data which uses 'q'.

    Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
    and changes a data 'New" which uses 'q' during setup or hold time
    around the next clock triggering edge.Next 'New' signal data may be
    invalid.

    p_sync_or : process (clk) is
    begin
    if rising_edge(clk) then
    q <= a or b or c or d or e;
    end if;
    end process p_sync_or;

    A : process(clk)
    begin
    if rising_edge(clk) then
    New <= a and q;
    end if;
    end process A;

    Weng
    Weng Tianxiang, Mar 17, 2010
    #16
  17. Andy

    rickman Guest

    On Mar 16, 8:24 pm, Weng Tianxiang <> wrote:
    > On Mar 16, 2:04 am, Magne Munkejord <> wrote:
    >
    >
    >
    >
    >
    >
    >
    > > rickman wrote:
    > > > You would think that.  I just had to change some code to eliminate a
    > > > sync reset on a register to get rid of one level of LUTs in a Lattice
    > > > design which has a similar if not same FF structure with the dedicated
    > > > LSR input (Local Set/Reset).  Synplify seems to not know how to use
    > > > that.  Maybe this would get changed by the mapper, but I don't think
    > > > it does that.  I was looking at it in the synthesis tool.  Have you
    > > > tried an example?  Does Synplify do a better job with the Xilinx parts
    > > > than they do with Lattice parts?  I'm not convinced they do a good job
    > > > with the arithmetic units.  It is more than once I've seen an adder
    > > > chain duplicated to get the carry out of the top!

    >
    > > Hi Rick,

    >
    > > I tried 5-input registered OR, like this:

    >
    > >      p_sync_or : process (clk) is
    > >      begin
    > >          if rising_edge(clk) then
    > >              q <= a or b or c or d or e;
    > >          end if;
    > >      end process p_sync_or;

    >
    > > In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
    > > port of the register, and so does not require two LUTs to implement the
    > > gate.

    >
    > > When it comes to Synplify I only have the actel edition ( only actel
    > > parts supported(?)) and I have hardly ever used it.

    >
    > > I think actel parts only support async resets for their registers, in
    > > which case it is true as you say, that designing synchronous resets will
    > > generate extra logic in front of the registers. Maybe this is true for
    > > Lattice as well. In that case I would prefer using an async reset to
    > > avoid the extra logic and performance penalty.

    >
    > > If the reset signal is synchronously deasserted, it can be constrained
    > > so that one is certain it will reach each register at a proper time.

    >
    > > Magne

    >
    > Magne,
    > Your method is wrong !
    >
    > You cannot connect 'e' to the set port of the register. It may
    > compromise a new data which uses 'q'.
    >
    > Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
    > and changes a data 'New" which uses 'q' during setup or hold time
    > around the next clock triggering edge.Next 'New' signal data may be
    > invalid.
    >
    > p_sync_or : process (clk) is
    >      begin
    >          if rising_edge(clk) then
    >              q <= a or b or c or d or e;
    >          end if;
    >      end process p_sync_or;
    >
    > A : process(clk)
    >      begin
    >          if rising_edge(clk) then
    >              New <= a and q;
    >          end if;
    >      end process A;
    >
    > Weng


    I'm not clear on what your concern is. Perhaps you are thinging Magne
    is talking about e being connected to an async set? He is describing
    a FF with an async set which will do exactly the same thing as an OR
    of signal e with the rest of the inputs.

    Rick
    rickman, Mar 17, 2010
    #17
  18. rickman wrote:
    > On Mar 16, 8:24 pm, Weng Tianxiang <> wrote:
    >> On Mar 16, 2:04 am, Magne Munkejord <> wrote:
    >>
    >>
    >>
    >>
    >>
    >>
    >>
    >>> rickman wrote:
    >>>> You would think that. I just had to change some code to eliminate a
    >>>> sync reset on a register to get rid of one level of LUTs in a Lattice
    >>>> design which has a similar if not same FF structure with the dedicated
    >>>> LSR input (Local Set/Reset). Synplify seems to not know how to use
    >>>> that. Maybe this would get changed by the mapper, but I don't think
    >>>> it does that. I was looking at it in the synthesis tool. Have you
    >>>> tried an example? Does Synplify do a better job with the Xilinx parts
    >>>> than they do with Lattice parts? I'm not convinced they do a good job
    >>>> with the arithmetic units. It is more than once I've seen an adder
    >>>> chain duplicated to get the carry out of the top!
    >>> Hi Rick,
    >>> I tried 5-input registered OR, like this:
    >>> p_sync_or : process (clk) is
    >>> begin
    >>> if rising_edge(clk) then
    >>> q <= a or b or c or d or e;
    >>> end if;
    >>> end process p_sync_or;
    >>> In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
    >>> port of the register, and so does not require two LUTs to implement the
    >>> gate.
    >>> When it comes to Synplify I only have the actel edition ( only actel
    >>> parts supported(?)) and I have hardly ever used it.
    >>> I think actel parts only support async resets for their registers, in
    >>> which case it is true as you say, that designing synchronous resets will
    >>> generate extra logic in front of the registers. Maybe this is true for
    >>> Lattice as well. In that case I would prefer using an async reset to
    >>> avoid the extra logic and performance penalty.
    >>> If the reset signal is synchronously deasserted, it can be constrained
    >>> so that one is certain it will reach each register at a proper time.
    >>> Magne

    >> Magne,
    >> Your method is wrong !
    >>
    >> You cannot connect 'e' to the set port of the register. It may
    >> compromise a new data which uses 'q'.

    It wasn't me, XST did it!
    >>
    >> Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
    >> and changes a data 'New" which uses 'q' during setup or hold time
    >> around the next clock triggering edge.Next 'New' signal data may be
    >> invalid.
    >>
    >> p_sync_or : process (clk) is
    >> begin
    >> if rising_edge(clk) then
    >> q <= a or b or c or d or e;
    >> end if;
    >> end process p_sync_or;
    >>
    >> A : process(clk)
    >> begin
    >> if rising_edge(clk) then
    >> New <= a and q;
    >> end if;
    >> end process A;
    >>
    >> Weng

    Since the 'set' port of the register is synchronous the circuit will
    behave as your code above describes it. q will not change state before
    rising edge of clk even if e is asserted earlier. I would think the
    timing tools knows the required setup time for the synchronous set/reset
    ports, and cover their paths as any other synchronous elements.
    >
    > I'm not clear on what your concern is. Perhaps you are thinging Magne
    > is talking about e being connected to an async set? He is describing
    > a FF with an async set which will do exactly the same thing as an OR
    > of signal e with the rest of the inputs.
    >
    > Rick

    The second instance of 'async' I would correct to 'sync', but I guess
    that was a typo.

    Magne
    Magne Munkejord, Mar 17, 2010
    #18
  19. Andy

    rickman Guest

    On Mar 17, 6:24 am, Magne Munkejord <> wrote:
    > rickman wrote:
    > > On Mar 16, 8:24 pm, Weng Tianxiang <> wrote:
    > >> On Mar 16, 2:04 am, Magne Munkejord <> wrote:

    >
    > >>> rickman wrote:
    > >>>> You would think that.  I just had to change some code to eliminate a
    > >>>> sync reset on a register to get rid of one level of LUTs in a Lattice
    > >>>> design which has a similar if not same FF structure with the dedicated
    > >>>> LSR input (Local Set/Reset).  Synplify seems to not know how to use
    > >>>> that.  Maybe this would get changed by the mapper, but I don't think
    > >>>> it does that.  I was looking at it in the synthesis tool.  Have you
    > >>>> tried an example?  Does Synplify do a better job with the Xilinx parts
    > >>>> than they do with Lattice parts?  I'm not convinced they do a good job
    > >>>> with the arithmetic units.  It is more than once I've seen an adder
    > >>>> chain duplicated to get the carry out of the top!
    > >>> Hi Rick,
    > >>> I tried 5-input registered OR, like this:
    > >>>      p_sync_or : process (clk) is
    > >>>      begin
    > >>>          if rising_edge(clk) then
    > >>>              q <= a or b or c or d or e;
    > >>>          end if;
    > >>>      end process p_sync_or;
    > >>> In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
    > >>> port of the register, and so does not require two LUTs to implement the
    > >>> gate.
    > >>> When it comes to Synplify I only have the actel edition ( only actel
    > >>> parts supported(?)) and I have hardly ever used it.
    > >>> I think actel parts only support async resets for their registers, in
    > >>> which case it is true as you say, that designing synchronous resets will
    > >>> generate extra logic in front of the registers. Maybe this is true for
    > >>> Lattice as well. In that case I would prefer using an async reset to
    > >>> avoid the extra logic and performance penalty.
    > >>> If the reset signal is synchronously deasserted, it can be constrained
    > >>> so that one is certain it will reach each register at a proper time.
    > >>> Magne
    > >> Magne,
    > >> Your method is wrong !

    >
    > >> You cannot connect 'e' to the set port of the register. It may
    > >> compromise a new data which uses 'q'.

    >
    > It wasn't me, XST did it!
    >
    >
    >
    > >> Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
    > >> and changes a data 'New" which uses 'q' during setup or hold time
    > >> around the next clock triggering edge.Next 'New' signal data may be
    > >> invalid.

    >
    > >> p_sync_or : process (clk) is
    > >>      begin
    > >>          if rising_edge(clk) then
    > >>              q <= a or b or c or d or e;
    > >>          end if;
    > >>      end process p_sync_or;

    >
    > >> A : process(clk)
    > >>      begin
    > >>          if rising_edge(clk) then
    > >>              New <= a and q;
    > >>          end if;
    > >>      end process A;

    >
    > >> Weng

    >
    > Since the 'set' port of the register is synchronous the circuit will
    > behave as your code above describes it. q will not change state before
    > rising edge of clk even if e is asserted earlier. I would think the
    > timing tools knows the required setup time for the synchronous set/reset
    > ports, and cover their paths as any other synchronous elements.
    >
    > > I'm not clear on what your concern is.  Perhaps you are thinging Magne
    > > is talking about e being connected to an async set?  He is describing
    > > a FF with an async set which will do exactly the same thing as an OR
    > > of signal e with the rest of the inputs.

    >
    > > Rick

    >
    > The second instance of 'async' I would correct to 'sync', but I guess
    > that was a typo.
    >
    > Magne


    Yes, it was a typo... in other words, a mistake... Why do they call
    it a "typo". It was a mistake regardless of how you categorize it.

    Rick
    rickman, Mar 19, 2010
    #19
  20. Andy

    Andy Peters Guest

    On Mar 19, 6:32 am, rickman <> wrote:

    > Yes, it was a typo... in other words, a mistake...  Why do they call
    > it a "typo".  It was a mistake regardless of how you categorize it.


    "typographical error," in other words, a mistake made by the
    typesetter, back in the days when such jobs existed.

    -a
    Andy Peters, Mar 22, 2010
    #20
    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. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,849
    Smokey Grindel
    Dec 2, 2006
  2. Weng Tianxiang
    Replies:
    14
    Views:
    1,087
    Martin Thompson
    Mar 11, 2010
  3. Ed McGettigan
    Replies:
    0
    Views:
    475
    Ed McGettigan
    Mar 10, 2010
  4. fpgabuilder
    Replies:
    3
    Views:
    602
    rickman
    Mar 20, 2010
  5. Andy
    Replies:
    3
    Views:
    492
    fpgabuilder
    Mar 19, 2010
Loading...

Share This Page