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: Weng Tianxiang on 16 Mar 2010 20:24 On Mar 16, 2:04 am, Magne Munkejord <magnem...(a)yahoo.no> 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
From: rickman on 17 Mar 2010 00:07 On Mar 16, 8:24 pm, Weng Tianxiang <wtx...(a)gmail.com> wrote: > On Mar 16, 2:04 am, Magne Munkejord <magnem...(a)yahoo.no> 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
From: Magne Munkejord on 17 Mar 2010 06:24 rickman wrote: > On Mar 16, 8:24 pm, Weng Tianxiang <wtx...(a)gmail.com> wrote: >> On Mar 16, 2:04 am, Magne Munkejord <magnem...(a)yahoo.no> 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
From: fpgabuilder on 17 Mar 2010 14:29 On Mar 10, 12: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. I know Altera's Quartus Timing Analyzer has recovery/removal analysis. > > 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 have not used Xilinx devices with Synchronous resets. I am curious is it ever possible that the clock may stop before the reset event and then subsequently the clock appears after the reset event passes thereby not initializing the logic? > > 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.
From: Andy on 18 Mar 2010 11:00
Andy "ever possible"? Yes. That's one reason why I prefer async resets for device initialization (but not for simply setting a counter back to zero during its normal course of operation, etc.) Andy |