( ESNUG 365 Item 12 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #14 ) Why Not Use PKS Instead Of Cadence PBOPT ?
> I read Chris' article on ESNUG 363 with interest as I have been working in
> the area of hierarchical physical design timing closure for a few years
> now. I have a few questions for my own clarification and some suggestions
> that may help...
>
> - Lee Keep
> 3Com UK
From: Chris Simon <Chris.H.Simon@gd-is.com>
John,
This is to thank Lee for the response and advice. Since this is the first
time through a hierarchical design we are still learning, and what he's
written will certainly help. The designs we are working on are 125 MHz
using IBM 0.25 um CMOS. Not exactly bleeding-edge but still a challenge for
our Cadence tools, it seems. As we've refined our results I discovered that
the constraints on paths between blocks did allow for my 1.2 ns per 5mm, but
the paths to the I/Os did not. I am fixing this.
We did not do top level routing before designing the blocks on the first
chip, but we are in the process of doing just that for the next chips. We
also discovered the need for buffers at the outputs of all blocks, as near
to the ports as possible. We will look into how we can force the placer to
put these near the ports in every block. To try to make this easier on
ourselves we established the rule early on that all block outputs and inputs
are from registers. There is no logic allowed (other than a buffer) between
any block input and the input register, or between an output register Q pin
and the output port.
The pin optimization on the first chip was done manually, but it was a
simpler chip (i.e., fewer blocks.) On the next chips we will attempt to
have the tools do pin optimization.
- Chris Simon
General Dynamics Information Systems
---- ---- ---- ---- ---- ---- ----
From: Thad McCracken <thad@geocast.com>
Hi John,
I've got a few comments on Chris' repeater-insertion problem that will
hopefully be of some use. We transitioned from Ambit Buildgates to PKS some
time ago, and use that to do top-level repeater insertion now. We used to
use a similar flow to Chris, though, so I'll try to comment from memory on
that first. Finally I include a short description of our experiences
with PKS in this regard mostly for the future reference of Chris and other
ESNUG readers.
1.) "Black-box" timing models for your P&R blocks. We use black-box
timing models for our P&R blocks to drive top-level repeater insertion
as well. I have found it important to include in these blocks not
only timing characteristics (setup/hold, clock-q), but also all
applicable design-rule constraints (max input transition and pin
capacitance for all inputs, worst-case transition and max-capacitance
for all outputs).
These can sometimes help drive insertion of top-level repeaters.
2.) We've had similar dissapointments with QPOPT. On the last chip
we taped out w/o PKS we ended up putting top-level repeaters in our
netlist by hand, and controlling their placement with placement
regions.
In general I've found it to be helpful to put top-level standard cell
rows everywhere possible - don't depend on QPOPT or any other tool to
find the *one* place to put a repeater. We've found PKS to work reasonably
well for top-level repeater insertion, given the following inputs:
- top-level flooplan (we use .def format) that places all the IOs,
P&R blocks, top-level standard-cell rows, power grid, etc.
- .lib black-box timing models for all P&R blocks (as well as IOs, etc.)
Using this and top-level timing constraints, we run a quick optimation to
insert and place repeaters. Different types of optimization seem to work
better for some designs -- sometimes just "do_optimize -pks" works fine.
Other times specifically targeting design rule violations is better. I've
found setting the steiner mode to 1 or 2 (set_steiner_mode 1 or 2) to
generally yield better results for designs with lots of "macros." We also
found that tweaking with the following global variables helped for
top-level repeater insertion:
smoothen_area_gap (% of placement bin space that must be left
un-utilized after placement spreading)
extra_space_for_opt (amount by which optimization may overfill a
placement bin)
In v4.x PKS these default to 1 and 0. We found that setting the former
to 0 and the latter to a very high number (80 in one case) seemed to
help placement of top-level repeaters on one chip. I don't fully
understand why this works, but suspect it has something to do with
placement bins having mostly "un-usable" area. I'd like to understand
it more in the future. There are other knobs you could try in PKS
that might help as well, but I haven't played with them enough to say.
- Thad McCracken
Geocast Networks Systems, Inc. Beaverton, OR
|
|
