RE: [sv-bc] negative delays

From: Premduth Vidyanandan <premduth.vidyanandan_at_.....>
Date: Wed Jun 27 2007 - 10:32:41 PDT
Hi Everyone,

Just to add another perspective. Negative delay is quite common in Xilinx FPGAs as well. Especially with using the Hard blocks such as the PPC and MGT, we end up having to compensate for clock insertion delay. These are conditions where it is probable that the clock tree is slower than the data when it comes to these blocks that are inside the FPGA.

We have come up with a hack workaround for this, due to lack of EDA simulator support, although it would be a good time to discuss this for the future languages.

Thanks
Duth


-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
Sent: Wednesday, June 27, 2007 11:27 AM
To: sv-bc@server.eda.org
Subject: 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.





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Jun 27 10:33:10 2007

This archive was generated by hypermail 2.1.8 : Wed Jun 27 2007 - 10:33:22 PDT