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: Ed McGettigan on 10 Mar 2010 20:01 On Mar 10, 4:25 pm, Andy <jonesa...(a)comcast.net> wrote: > On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > > > > > > > On Mar 10, 10:06 am, Andy <jonesa...(a)comcast.net> wrote: > > > > On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...(a)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. 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.
From: -jg on 10 Mar 2010 20:10 On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...(a)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
From: Ed McGettigan on 10 Mar 2010 20:42 On Mar 10, 5:10 pm, -jg <jim.granvi...(a)gmail.com> wrote: > On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...(a)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 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.
From: Weng Tianxiang on 10 Mar 2010 21:44 On Mar 10, 5:42 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > On Mar 10, 5:10 pm, -jg <jim.granvi...(a)gmail.com> wrote: > > > On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...(a)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 > > 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
From: Martin Thompson on 11 Mar 2010 06:48
Peter Alfke <alfke(a)sbcglobal.net> writes: > Use Xilinx FPGAs. I know for sure that Virtex 5, and probably also 4 > and 6 can configure each flip-flop as a latch, although this is a > rarely-used feature. > (How fast I forget such exotic facts). And the Microblaze core uses 3 (yes a whole 3 :) of them as well! Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html |