( ESNUG 366 Item 4 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #2 ) User Having Trouble Closing Timing Using PKS
> Our dual PhysOpt/PKS tape-out was done because we ran into some run-time
> issues with PKS on that core. It was taking 6 days to compile and we
> couldn't get any debug/improvement cycles in. The PhysOpt run took about
> 1 day but had about 10% larger area. So, I used Ambit to get an initial
> netlist with the area savings and PhysOpt to get a placement. I then
> returned to PKS after our internal scan insertion tool and clock tree
> generation to do the final timing tweaks. This allowed me to use the SE
> compatible global router in PKS, do incremental optimization based on that
> global route, and get less than 2% difference in pre- and post- final
> route timing in SE. With a PhysOpt placement, we see 5-10% difference in
> pre- and post- route timing.
>
> - Jay McDougal
> Agilent Corvallis, OR
From: Mark Warren" <mwarren@xtremespectrum.com>
John,
I'm having a heckuva time closing timing using PKS. Has anyone had any
experience with these?
1. I optimize and timing report looks good. I write out a netlist,
DEF, and ADB. I close the tool and read in the netlist, DEF, and
my constraints. Now the timing is no longer good -all I did was
write it out and read it back in. But, wait, there's more. I then
try reading in the ADB and it doesn't match either timing reports
from the original run, or the reread of the netlist. What's happening
here? My setup is the same for all three runs - same script. I'm
running version 4.0-s5 of PKS. The Cadence AE tried to tell me I
changed my setup variables for each of the runs. So, I ran through
as many combinations of steiner_mode, slew_propagation_mode, etc
that I could think of and I never got a timing report that matched
the first good one.
2. The Silicon Ensemble Crosstalk fixer. This is another cool tool to
try to fit into a flow. Any advice?
Thanks.
- Mark Warren
XtremeSpectrum, Inc. Vienna, VA
|
|
