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: rickman on 12 Mar 2010 22:32 On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > 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. 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
From: rickman on 12 Mar 2010 22:34 On Mar 10, 8: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 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
From: Magne Munkejord on 15 Mar 2010 08:14 rickman wrote: > On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: >> 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. > > 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
From: rickman on 15 Mar 2010 15:21 On Mar 15, 8:14 am, Magne Munkejord <magnem...(a)yahoo.no> wrote: > rickman wrote: > > On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...(a)xilinx.com> wrote: > >> 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. > > > 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
From: Magne Munkejord on 16 Mar 2010 05:04
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 |