( ESNUG 394 Item 5 ) --------------------------------------------- [05/29/02]
Subject: ( SNUG 02 #14 ) PrimeTime-SI, Celestry Nautilus-SI, Cadence SE-SI
> Hierarchical Physical Synthesis with ILM Models
>
> + Interface Logic Models (ILM) allow PrimeTime/DC/PhysOpt to run faster
> using less memory.
> + PrimeTime ILMs are flat with no phyiscal information, written out as
> flat Verilog netlist and support back annotation.
> + DC/PhysOpt ILMs contain original hierarchy and physical info, in DB
> format and support back annotation.
> + DC/PhysOpt ILMs will allow top-level optimizations/routing to be run
> on the full-chip without having to load entire design.
>
> Q: How well will ILMs interface with 3rd party tools?"
>
> - Kent Ng of Microsoft/XBox
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Hi, John,
Using ILMs and ETMs for hierarchical STA is supposed to improve memory and
runtime up to 4X. The suggested flow is to use ILMs (Interface Logic
Models) for in-house IP blocks, and use ETMs (Extracted Timing Models) for
3rd party IP. Paths between top-level blocks can be analyzed accurately
using ILMs while avoiding the overhead of a full chip netlist. Each top-
level block can then be analyzed independently to complete the picture.
PrimeTime 2002.03 adds validation for ETMs and ILMs. The procedure is to
use the write_interface_timing command to create interface timing files for
both the original gate level block and the ETM or ILM, and then use the
compare_interface_timing command to verify missing arcs, slack, output
transition input capacitance and design rules.
The overview of PrimeTime-SI at SNUG'02 gave me the Synopsys views about
crosstalk effects, and PrimeTime's capabilities to analyze them. The
Binary Parasitic Format feature is used to save runtime on subsequent runs
after the initial conversion to SBPF. This feature can be used in standard
PrimeTime as well.
Because I've worked with Celestry's Nautilus-SI and Millennium-SI tools, I
was particularly interested in comparing PrimeTime-SI's capabilities. It
seems that if I had both sets of tools I would have a complete solution.
While the Celestry tools were great with extraction, delay calculation, and
crosstalk magnitude calculation, they are lacking in timing window creation
and net selection capabilities. They had the mechanisms in place, but they
just weren't quite ready yet. As a result, I had to settle for overly
pessimistic crosstalk analysis with infinite timing windows where all
aggressors on a given net are assumed to act at once.
Based on what I saw at this SNUG'02, PrimeTime-SI has it all over Celestry
in the timing window department. I had read several articles in ISD a while
back talking about performing multiple iterations of STA to refine the
timing windows and successively increase accuracy, with 2-3 iterations being
optimal. The PrimeTime-SI SNUG session talked about this, and said that 2
iterations are typically sufficient. These iterations are performed with a
single update_timing command, and there is a variable to set the number of
iterations (trading off runtime for accuracy). PrimeTime-SI takes windowing
a step further with two cool features: Logical Correlation and Temporal (in
time) Correlation.
Once the timing window functionality has determined whether or not aggressor
nets switch close enough in time to the victim net switching to effect its
timing, logical correlation kicks in as well. Let's say aggressor net 1 is
attached to the input of an inverter, and the output of the inverter drives
aggressor net 2, and both of these nets switch within the timing window of
the victim net. Because the 2 aggressor nets switch in opposite directions,
their effects on the victim net effectively cancel each other out.
PrimeTime-SI is able to understand this and eliminate false pessimism. This
feature works with buffers and inverters only.
Temporal correlation has to do with partial overlapping switching windows
between victims and aggressors. With no overlap between the windows, the
aggressor has no contribution to the victims timing. With full overlap
between the windows, the aggressor has full contribution to the victim's
timing. With a partial overlap between the windows, only a portion of the
aggressors switching waveform will have an effect on the victim's timing.
PrimeTime-SI is able to recognize and handle this situation.
There is, however, a very important part two of the story. What happens
when an aggressor (or several aggressors) acts on a non-switching victim?
The result is a 'bump' or glitch on the victim. If that glitch crosses the
switching threshold of the gate input pin it drives, that glitch could get
through the gate. This produces a glitch on the net connected to the output
of the gate, making a new switching aggressor. My understanding is that
none of the available tools today (with the possible exception of Celtic by
CadMos/Cadence) can deal with this scenario. Therefore, in order to believe
any crosstalk related timing information you obtain from the tools, you must
first verify the prime directive has not been violated - that no glitches
get through any gates and become additional aggressors. This is
accomplished with a peak noise or glitch report.
Celestry's Millennium-SI was able to generate a very detailed peak noise
report, showing the total contribution of all aggressors on a given victim
in terms of a percentage of VDD, and the breakdown of each aggressor's
contribution. Due to the timing window difficulties, this report was
pessimistic. If five aggressors each caused a 10% VDD spike, it was assumed
they all happened at once to create a 50% VDD spike. It was up to us to
determine where the real problems were. It was also up to us to determine
if the glitch crossed a threshold to let the glitch through. Using .tlf
libraries that supported Cadence's SE-SI (Silicon Ensemble with Signal
Integrity), we were able to use the ct_tolerance values for this metric. At
the time, Millennium-SI did not compare its peak noise values against the
ct_tolerance values to determine violations, but my understanding is that
this capability is now supported, and some of my timing window issues may
have been addressed by now as well.
PrimeTime-SI presently does not support peak noise reporting capability, but
it is planned toward the end of the year. They are presently in discussions
with library vendors to come up with a standard metric in the library. How
about ct_tolerance? It exists today.
Of course, all this describes an analysis and repair type methodology, where
the ideal scenario is to build it right the first time. SNUG'02 indicated
that the PT-SI capabilities were also being merged into PhysOpt. Once peak
noise capability is integrated, this could be a sweet solution. Of course,
the Holy Grail would be to also have a timing driven crosstalk aware router.
- Bob Wiegand
NxtWave Communications Langhorne, PA
|
|
