Why doesn't this situation generate a latch?
in [FPGA]
|
Prev: Some Active-HDL questions
Next: Call for Papers Reminder (extended): The World Congress on Engineering WCE 2010
From: Andy on 11 Mar 2010 12:15 On Mar 10, 7:01 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> 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
From: Andy on 11 Mar 2010 12:29 On Mar 10, 8:44 pm, Weng Tianxiang <wtx...(a)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 <= 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
From: Weng Tianxiang on 11 Mar 2010 14:38 On Mar 11, 9:29 am, Andy <jonesa...(a)comcast.net> wrote: > On Mar 10, 8:44 pm, Weng Tianxiang <wtx...(a)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 <= 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
From: Andy on 11 Mar 2010 15:08 On Mar 11, 1:38 pm, Weng Tianxiang <wtx...(a)gmail.com> wrote: > On Mar 11, 9:29 am, Andy <jonesa...(a)comcast.net> wrote: > > > > > > > On Mar 10, 8:44 pm, Weng Tianxiang <wtx...(a)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 <= 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
From: Weng Tianxiang on 11 Mar 2010 22:11
On Mar 11, 12:08 pm, Andy <jonesa...(a)comcast.net> wrote: > On Mar 11, 1:38 pm, Weng Tianxiang <wtx...(a)gmail.com> wrote: > > > > > > > On Mar 11, 9:29 am, Andy <jonesa...(a)comcast.net> wrote: > > > > On Mar 10, 8:44 pm, Weng Tianxiang <wtx...(a)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 <= 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 |