( ESNUG 339 Item 1 ) --------------------------------------------- [1/13/00]
Subject: ( ESNUG 335 #1 ) IPOfix - A Freeware IPO Buffer Resizing Program
> Using this flow, layout partitions typically took 6 to 10 passes to
> achieve timing. Each pass could take 2 to 3 days. Our main headache was
> that Reoptimize Design would make timing by disturbing a large percentage
> of the netlist. Then we'd get caught up in a chicken & egg loop where the
> incremental P&R required to fix the reoptimized design would cause enough
> P&R disturbance to require another major pass in DC reoptimize design.
>
> We often discovered that going through a large number of reoptimize design
> passes would result in an unroutable layout. Reoptimize design, by
> running outside of the layout environment, just did not have enough
> information to make good IPO decisions.
>
> - Bob Prevett, Design Engineer
> NVIDIA Santa Clara, CA
From: Jeff Winston <jwinston@maker.com>
Hi John.
We recently finished taking a fairly large, complicated, fast chip thru
to tape out. One of the biggest roadblocks was that we were unable to run
Design Compiler IPO to our satisfaction. It took many days to run (on
360MHz UltraSparcs), was repeatably crash-prone, and didn't produce good
results. (We tried both 1998.08-1 "normal" IPO, and 1999.05-2 Floorplan
Manager IPO). While we watched the tool slowly crunch our design, I did
a little C programming and developed what may be a better way...
I wrote a program that reads the Primetime output and upsizes gates
whose individual delays exceed user-specified limits. That is, it
looks for and speeds up all the slow gates in the failing paths. It
applies these changes to the netlist, and adds a suffix to the names of
the changed gates to force Primetime to re-calculate the delays (the
suffix can be easily removed later). It is very careful to change only
the characters it needs to in the netlist, allowing before/after
comparisons using UNIX diff. For our design, an entire IPO interation
took about 5 minutes to run the program, and then 2 hours to re-run
PT. This admittedly brute-force approach allowed us to completely IPO
our chip very quickly, adding only 0.3% to the gatecount (well within
Avant's ECO capabilities). Before we were done I had enhanced the
program to read the PT transition-violation output and upsize as needed,
and to read the PT min-delay violation output and add hold buffers as
needed (and generate an estimated .SDF file for the newly-created
hold-buffer nodes). Though not perfect, and possibly a little wasteful,
this program solved nearly all of our timing-closure problems (the rest
required placement changes), and ran in minutes rather than days. We
intend to use this methodology on future designs here.
I'm happy to make my source code available to anyone who wants to use
it, though with no promise of support (I'm by no means a polished
software engineer but the code is commented and fairly readable). The
program is optimized for use with VLSI Technology's libraries, but could
be changed to work with gates from another vendor. The only request I
make is that I have free access to any enhanced versions of the code.
- Jeff Winston
Maker Communications, Framingham, MA
[ Editor's Note: To get IPOfix, go to http://www.DeepChip.com and you'll
be able to easily download it from there. Good job, Jeff! - John ]
|
|
