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

On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> 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. =A0Some 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

On Mar 10, 4:25=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> 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 hav=
e
> > > 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. =A0Some 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.

On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> 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

On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > The cons of an asynchronous reset significantly outweigh the single
> > pro that the reset will occur in the absence of clock.
>
> =A0For Logic 'buried deep', that would be correct, but
> for pin-drive logic, having a defined state BEFORE the clock, can be
> quite mission-critical.
>
> =A0-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.

On Mar 10, 5:42=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> > On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > The cons of an asynchronous reset significantly outweigh the single
> > > pro that the reset will occur in the absence of clock.
>
> > =A0For Logic 'buried deep', that would be correct, but
> > for pin-drive logic, having a defined state BEFORE the clock, can be
> > quite mission-critical.
>
> > =A0-jg
>
> I absolutely agree that asynchronous resets have a very valid use in
> certain cases. =A0My 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

On Mar 10, 7:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> I wouldn't take it as a given that most resets are not already
> synchronized to the clock domains. =A0Resets are routinely used based on
> termination count, end of packet, return to state0 from other states
> or invalid states, etc.... =A0All 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

On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> 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 <=3D B when ENABLE; -- implies a latch for A
C <=3D A when rising_edge(CLK); -- a register using A
E <=3D 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

On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote:
> On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> 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 <=3D B when ENABLE; -- implies a latch for A
> C <=3D A when rising_edge(CLK); -- a register using A
> E <=3D 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

On Mar 11, 1:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote:
>
>
>
>
>
> > On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> 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 sho=
w
> > > "the latch cannot be replaced by
> > > a clock enable on a register"
>
> > Example:
>
> > A <=3D B when ENABLE; -- implies a latch for A
> > C <=3D A when rising_edge(CLK); -- a register using A
> > E <=3D 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

On Mar 11, 12:08=A0pm, Andy <jonesa...@comcast.net> wrote:
> On Mar 11, 1:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote:
>
> > > On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> 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 s=
how
> > > > "the latch cannot be replaced by
> > > > a clock enable on a register"
>
> > > Example:
>
> > > A <=3D B when ENABLE; -- implies a latch for A
> > > C <=3D A when rising_edge(CLK); -- a register using A
> > > E <=3D 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