Re: [sv-bc] negative delays

 
-----Non-member submission from João Geada-----

Just an FYI, negative delay can (and does) actually happen in reality. There are two interesting cases:

CASE 1:
It occasionally shows up as an artifact of the timing models that most of the industry currently uses to represent delay across cell.

Specifically: cell delay is abstracted away in timing models into the notion of a delay/slope input causing a delay/slope output from the cell at a particular load condition. This is, of course, an abstraction away from the true analog behavior of cells.
Delay in this abstraction is measured at the point where the input waveform crosses the 50% point to where the output waveform crosses its 50% point.
It can happen that, if the input to a gate has a very slow slope and under the right loading conditions, that the output of the gate crosses the 50% point before the input has crossed that same point. And thus, from the measurement perspective of this abstraction, this appears as a negative delay across the cell for that particular input slope. And, yes, it is just a measurement artifact of the abstraction.

But this particular case is not common and, the loading/driving characteristics that are needed to set this up are usually in violation of the electric rule checks that most physical design teams impose to ensure proper behavior & manufacturability.

CASE 2:

A much more common case occurs when dealing with cross-talk delay. Cross-talk noise can cause
a) positive delay, ie causing a signal to arrive at the other end of the interconnect
   later than in the non-noise case
but also
b) negative delay ie causing signal to arrive at the other end of the interconnect earlier than 
   it would have in the non-noise case. In this type of situation the noise acts somewhat like a
   pre-charge pulse

These conditions are a very common occurrence. And in many design flows the effect of noise on delay is captured by an SDF file, and thus it is relatively common to see negative annotations in such a file (particularly when capturing min delay, which is needed for hold checks)

Joao
==============================================================================
Dr João Geada                                            CLK Design Automation
Chief Architect                                   295 Foster Street, Suite 102
978-486 1056 x204                                          Littleton, MA 01460
==============================================================================


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.