( ESNUG 338 Item 4 ) --------------------------------------------- [12/3/99]
Subject: ( ESNUG 337 #1 ) ICCAD'99 Gurus Say "Flat P&R Is Where It's At!"
> I know it's very common for some companies to do layout as a process on
> one big flat design. We considered flat, but these five "hells" came up:
>
> - big flat designs are run-time hell
> - big flat designs are extraction hell
> - big flat designs are back-annotation hell
> - big flat designs are clock tree hell
> - big flat designs are timing closure hell
>
> In practical terms, with engineers here running around tweaking & pumping
> netlists out of Design Compiler every day, some way to compartmentalize
> their work is a MUST. So, we chose the hierarchical approach.
>
> - Sam Appleton
> SGI Moutain View, CA
From: Pat Eichenseer <patrick.eichenseer@amd.com>
Hi John,
I wanted to relate a few items concerning this discussion about hierarchacal
vs. flat P&R.
First of all, in a tutorial at the recent ICCAD confernece, Andrew Kahng and
Majid Saffrafzadeh conclude that flat is the future. They say that the
physical hierarchy created has no relation to high-quality in regards to
timing and routability. Furthermore, they claim that the physical hierarchy
created is somewhat artifical and that the core region is naturally
homogeneous, i.e., leave things flat. Additionally, the logic hierarchy is
function driven, while the physical world is minimum wire length driven.
Thus, by imposing physical hierarchy, which is typically based upon logic
partitioning, you have forced the placement engines to work on a subset of
the problem, rather than on the entire problem.
One other observation that I have made is that hierarchical designs consume
more die area. This is mostly due to over designing of the power/ground
topology.
On the pro-side for physical hierarchy, everyone knows that by having
physical hierarchy, blocks can be divided up into design teams. This also
allows for blocks to be worked on at different stages. Addtionally, block
budgets can be assigned early accounting for the top-level interconnect.
Another benefit is engineering change orders (ECOs) are much easier to
implement on a block rather than the entire design.
> But as to doing flat layout on a 750k instance design - really? I am
> mystified by a couple of statements
>
> "Sam could have intelligently partitioned his 750 K instance design
> into four parts by hand and Avanti could take it from there."
>
> How do you "intelligently partition" a design into 4 pieces in the tool?
> Does it magically fit together? Does Avanti support this? Cadence
> doesn't. Do you arbitrary break the design along a global placement, or
> do you BREAK THE DESIGN BY LOGICAL HIERACHY? If you break the design by
> logical hierachy, then it certainly sounds like you're doing hierachial
> physical design, and you'll have to do pin assignment, interconnect
> routing etc between the pieces.
>
> - Sam Appleton
> SGI Moutain View, CA
Now, in regards to Sam Appleton, and by the way I do not want to get into
a flame war here, I have pros and cons for hierarchical and flat. As for
750K instances flat, sure this should doable for Avanti as I am placing
80K cells with 83 pre-placed macros in 9 minutes (I have done much larger
designs in reasonable times, I just don't have the numbers). If Avanti
can't do it, then Silicon Perspective can. As for doing the design
hierarchically, yes you would partition the design by logical hierarchy,
and do pin assignment and then route the blocks together. There's no
magic to it. As for Sam's issues, clock insertion is handled via a
bottom-up approach, i.e., you CTS the blocks first, then CTS at the
top-level, though I am aware, Avanti is working on a top-down CTS
algorithm. As for the 2D estimates, I agree with Sam that the estimates
use to be way off, but with recent integration of part of Avanti's
extraction engine. I have found reasonable correlation with final
extraction.
As for signal integrity, this mostly has to do with obtaining a good
floorplan with very good pin assignments. This sounds trivial, but it can
make or break a design. With larger die repeaters are required. You can
let Avanti's Jupiter program instantiate them, or you can implement buffer
block planning as suggested by Jason Cong, Tianming Kong & David Zhiang Pan
in their 'Buffer Block Planning for Interconnect-Driven Floorplanning'
paper. Finally, as for extraction, Star-RCXT. We are seeing excellent
run times for huge flat designs.
- Pat Eichenseer
AMD Austin, TX
|
|
