( ESNUG 390 Item 5 ) --------------------------------------------- [03/20/02]
Subject: ( ESNUG 389 #12 ) PrimeTime/PrimeTime-SI Core Dump On Reduced SPEF
> We spent the first half of the Mindy PrimeTime-SI evaluation debugging
> problems caused by the reduced SPEF from Star-RCXT. The runtime using
> this SPEF was very good; just a few hours. However, the timing results
> were sketchy. Some delays due to coupling were over 900 nsec! Further
> investigation revealed that PrimeTime-SI didn't fully support reduced
> SPEF (RSPEF) from Star-RCXT.
>
> - Ryan Hyma
> AMD Austin, TX
From: Khris Kofford <kkofford@amis.com>
Hi, John,
Just a note on ESNUG 389 #12 regarding problems Ryan had with Reduced
SPEF (RSPEF) in PrimeTime-SI.
I've had similar problems reading RSPEF into non-SI PrimeTime. In one
situation, I was working on a .25 um, 1 M gate design last May/June. I was
having some problems with timing convergence at post-layout. In one
testcase I had written RSPEF from Apollo. PrimeTime was coredumping with
the RSPEF! My guess is they both have the same parasitic parser (so
PrimeTime-SI probably also core dumps when reading the RSPEF) and the
general timing engines are the same. The corresponding DSPEF annotated
fine. Synopsys filed a STAR but I haven't heard anything from them since.
I have been using the DSPEF without any problems. The SDF generated from
DSPF and DSPEF correlates very well and DSPEF file sizes have been up to
about 65% smaller.
I guess what I'm saying is that RSPEF is evidently not handled very well
in either Synopsys tool, but they claim it's a supported format.
On a somewhat similar note, I just ran into a situation in PrimeTime 2001.08
when calculating delays using DSPEF with short nets having a resistance
value less than 0.1 ohms. Avanti Star-RCXT extracts short nets using a
shorting resistor w/ a default value of .001 ohms. PrimeTime 2001.08 blows
up when trying to use the .001 ohms during delay calculation. Two things
happen:
(1) When writing SDF in min/max mode, the min cell timing arc is about
the same as the max cell timing arc, which is INCORRECT.
(2) The min SDF value for the same cell arc is inconsistent with that
reported by report_delay_calculation.
For example, the SDF for a buffer driving a short net looks like:
(IOPATH I Z (3.021::3.030) (3.029::3.043))
The corresponding delays reported by report_delay_calculation are:
(-7259372.000000 ::3.030126) (-13308844.000000::3.042605)
Notice those huge negative numbers. Ugly.
The correct delays for this buffer should look something close to:
(IOPATH I Z (1.39::3.030) (1.42::3.043))
I had to write a script to post-process the DSPEF and change the .001 ohm
resistance values to .01 to clean up the delay calcuation in PrimeTime.
I filed a star on this issue (Star 137745).
Another problem I found with PrimeTime 2001.08 is writing SDF in min/max
mode. The min delay is incorrect. This is probably related to (1) above
but it doesn't fall into the short net issue. Here's an example. This is
what I get in min/max mode for a buffer after annotating the DSPEF:
(IOPATH I Z (0.121::0.477) (0.223::0.473))
This is what I get in min mode:
(IOPATH I Z (0.136:0.136:0.136) (0.203:0.203:0.203))
This is what I get in max mode:
(IOPATH I Z (0.477:0.477:0.477) (0.473:0.473:0.473))
Notice the max arcs are the same but the min arcs differ. It *should* be:
(IOPATH I Z (0.136::0.477) (0.203::0.473))
A star has also been filed on this issue (Star 138238).
If you are depending on the SDF for any type of verification, the safest
thing is to write two SDF files rather than a single SDF file containg both
min and max timing. And I wouldn't be too surprised if this same thing were
happening in PrimeTime-SI.
Bottom-line is RSPEF is difficult to work with using any flavor of PrimeTime
(SI or non-SI), SDF is tricky, & DSPF files are 3X larger than DSPEF files.
- Khris Kofford
AMI Semiconductor
|
|
