>From: "Seligman, Erik" <erik.seligman@intel.com> >Can you remind me again what it is you are referring to by "finite time >pulse reject"? I believe that Doug is referring to adding a mechanism to delay the reporting of a violation until a clocking event occurs or a simulation time delay has passed. Until the violation is reported, it can still be "flushed". The idea would be that you could specify (say) a 1ns delay, and a violation caused by a glitch shorter than 1ns would not get reported. The idea of delaying the reporting until the observed or postponed region is already a form of this, which filters out zero-delay glitches. I think that the time delay version of this has a significant flaw. Suppose that there is an input signal to the block that is currently a don't-care (i.e. it does not affect the output or whether there is a violation). If it toggles more frequently than the reporting delay, then no violation will get reported, even though the violation remains present for longer than the delay. Each toggle will cause a new evaluation and flush the previous report and schedule a new one. 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 Thu Oct 18 16:29:43 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 18 2007 - 16:29:56 PDT