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 18 Mar 2010 11:41 On Mar 18, 8:00 am, Andy <jonesa...(a)comcast.net> wrote: > 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 fpgabuilder, From Sun code documents of OpenSparc CPU T2, there are 6 types of reset signals, a situation much more complexer than we think. Weng
From: rickman on 19 Mar 2010 09:32 On Mar 17, 6:24 am, Magne Munkejord <magnem...(a)yahoo.no> wrote: > 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 Yes, it was a typo... in other words, a mistake... Why do they call it a "typo". It was a mistake regardless of how you categorize it. Rick
From: rickman on 19 Mar 2010 09:32 On Mar 18, 11:41 am, Weng Tianxiang <wtx...(a)gmail.com> wrote: > On Mar 18, 8:00 am, Andy <jonesa...(a)comcast.net> wrote: > > > 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 > > fpgabuilder, > > From Sun code documents of OpenSparc CPU T2, there are 6 types of > reset signals, a situation much more complexer than we think. > > Weng Ok, go ahead and tease us! Or are you going to share with us what the six types are? Rick
From: fpgabuilder on 19 Mar 2010 13:17 On Mar 19, 6:32 am, rickman <gnu...(a)gmail.com> wrote: > On Mar 18, 11:41 am, Weng Tianxiang <wtx...(a)gmail.com> wrote: > > > > > On Mar 18, 8:00 am, Andy <jonesa...(a)comcast.net> wrote: > > > > 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 > > > fpgabuilder, > > > From Sun code documents of OpenSparc CPU T2, there are 6 types of > > reset signals, a situation much more complexer than we think. > > > Weng > > Ok, go ahead and tease us! Or are you going to share with us what the > six types are? > > Rick Yeah! What are those?
From: Jonathan Bromley on 19 Mar 2010 17:31
On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote: [Weng] >> there are 6 types of >> reset signals, a situation much more complexer than we think. >Ok, go ahead and tease us! Or are you going to share with us what the >six types are? 1. Reset that is asserted at the right time, but has the wrong polarity, thus holding the design in reset throughout your test. 2. Reset with the right polarity that is not asserted reliably at power-up, because you were too cheap to spend $0.70 on a power monitor/watchdog chip. 3. Reset that is triggered at random times during operation because it is laid out on the PCB too close to a data bus. Capacitive coupling causes reset to be momentarily asserted when more than 80% of the data lines transition simultaneously. 4. Reset that is asserted correctly, but is released too close to a clock edge and causes the design to go into an illegal state because some flops respond to the clock and others don't. 5. Reset of a counter, used by a designer who thought it would be a cool way to make the counter go back to zero when it overflows some programmed limit. 6. Reset that is triggered by the operation of a system-level watchdog. It causes the CPU to stop operating roughly a millisecond before emitting the debug message that would have allowed you to diagnose the problem. Just in case you thought I was fooling, I should point out that I have had to debug and correct each of these at some point in my career. One or two of them were someone else's fault :-) -- Jonathan Bromley |