>From: Greg Jaxon <Greg.Jaxon@synopsys.com> > Your scheme seems like it would remove more of what I'd call "glitch" >failures. Is it possible to come up with a more precise definition of >"glitch"? While Greg didn't go there, this starts to hint at being the first step down a slippery slope. As long as everything is zero-delay, with a sufficiently short "zero", this approach filters glitches. But if you have any delays, then it might not. Then you start wanting to have more general filtering that will filter out non-zero-width hardware glitches. After all, the violation really only matters at the clock, when you actually latch the value. This is presumably why concurrent assertions are clocked. So you want to have the same kind of capabilities here. I'm not convinced that the more limited capabilities of this suggested approach are worth the complexity. There are other ways of avoiding this kind of combinational glitches. One synthesizable coding style combines the combinational logic with the sequential logic in a sequential block. The combinational logic is only evaluated on the clock, when the data is being latched. This gives you a clocked check and avoids glitch problems. I'm sure Cliff will have some opinions about the advantages and disadvantages of this coding style, and will let us know about them :-) Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 12 19:21:22 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 19:21:33 PDT