( ESNUG 468 Item 2 ) -------------------------------------------- [09/13/07]
Subject: ( ESNUG 467 #13 ) PT-SI and VCS must have different timing models
> These days pretty much every design that is sub 130 um gets analyzed using
> OCV mode. So when PT-SI times a path for setup or hold, it tries to
> figure out the variation in timing among the path elements and applies
> them to find the worst case scenario. For setup checks, it makes the
> launch path the slowest and the capture path the fastest to determine the
> worst possible case and vice-versa for hold checks.
>
> This data is captured accordingly in an SDF where every timing arc has a
> min delay and a max delay for rise and fall. But when VCS reads this SDF,
> I am told that it can read either max values or min values for a given
> arc, but not both. This means that VCS' timing numbers would always be
> optimistic compared to PT-SI. Isn't this a big discrepancy?
>
> - Jay Pragasam
> PLX Technology Sunnyvale, CA
From: Laurent Claudel <laurent.claudel=user domain=arteris not calm>
Hi John,
Unless I'm missing something here, I actually don't see how VCS could take
OCV into account for back-annotated simulation. The problem is completely
different.
What PrimeTime does is a static timing analysis where VCS is dynamic.
When PrimeTime analyzes a path (from a reg to another reg for instance) to
find the worst case, it takes into account the delay of *all* the elements
on that path and works out the combination of min/max that gives you the
worst case for setup and for hold. But the min/max combination chosen will
be different for hold and for setup as you can see it the timing report.
So for a given cell, some timing reports will use the min delay and some
others the max.
Now for VCS, it cannot choose min in one case and max in another case.
VCS doesn't propagates values (0/1) on a global path (from a reg to a
reg) with the worst case delay. It just propagates the value element per
element of any cell/net to the next element in the path with the min or
the max delay found in the SDF file. For a given cell, it cannot use its
min delay on one path and it's max delay on another path, there is only
one simulation running. If you want to do that, in a design with N elements
(a cell or a net), you've got 2**N combinations and therefore 2**N sims to
run!!! And you've got to run all of them because one configuration is the
worst case for one path and another one for another path.
- Laurent Claudel
Arteris SA Paris, France
---- ---- ---- ---- ---- ---- ----
From: Eng Han <enghan=user domain=eda-utilities not calm>
Hi John,
The derating of the delay on an instance due to OCV depends on the paths and
the type of timing anaysis.
a. no derating if it is in the launching clock path, and for hold analysis.
b. slower if it is in the receiving clock path, and for hold analysis.
c. no derating if it is in the receiving clock path, and for setup analysis.
d. faster if it is in the lauching clock path, and for setup analysis.
Now, simulation cannot support OCV because:
a. how can the simulator know that the simulation is for what type of
anaysis?
b. the delay of an instance can be faster/slower/unchanged depending on if
it is launching or receiving clock path. But most instance in the clock
path are both at the same time. The simulator cannot simulate an
instance with different timing. If it do so, there will be a lot of
possible outcome in term of the waveform of the design.
Actually this is not something new. This also happen when we start to use
input slew to calculate the delay of a cell (in the early day only the total
output load is used). The delay from the STA is for the worst input slew
(at WC, it is slower slew, and for BC, it is faster slew). But an input
pin can be driven from may possible paths and hence can have many possible
input slew.
Same thing for SI crosstalk delay.
- Eng Han
EDA Utilities, Inc. Singapore
Index
Next->Item
|
|
