( ESNUG 440 Item 8 ) -------------------------------------------- [03/03/05]
Subject: ( DAC 04 #20 ) ReShape Responds To User Technical Complaints
> AUTOPILOT -- ReShape takes the words "design automation" to a whole new
> level by making tools that actually drive your P&R runs. Basically it
> rides on top of your Synopsys/Avanti or Cadence tools and hierarchically
> runs all of the tools for you -- sort of the mother of all "make" files.
> ReShape's nearest rival appears to be Manhattan Routing, Inc.
From: Paul Rodman <rodman=user domain=reshape spot gone>
Hi, John,
Actually, the paragraph above is summarizing only PDBuilder and Openflows.
PDBuilder is infrastructure for our flow creation and execution, Openflows
is our library of flows for Cadence/Synopsys tools.
To finish the story, PDOptimizer (and it's GUI, PDPlanner) are separate
tools used for block optimization and floorplanning of hierarchical
chips. (As is clear below from the user comments.) It has a particular
strength on complex abutted designs.
> I would buy pdBuilder in a heart beat, however ReShape seems to be more
> interested in selling the full package (for a lot of money)... dragging
> out the relationship, delaying the benefit I could be receiving
> from pdBuilder.
PDBuilder is now available 'stand-alone'. You don't need PDOptimizer or
Openflows to use it. Engineers can enter and execute their own existing
flows on its client/server infrastructure.
> 1. pdBuilder needs libraries to be rebuilt to its internal database
> format at start stage. (ReShape may have decoupled this style.)
The creation of silo libraries was a function of Openflows, not the
PDBuilder infrastructure... if your flow does not use our other Reshape
tools you do not need these libraries.
> 2. If user changes any values, Server has to be restarted.
>
> 3. If user changes a variable or cmd in a file that has not been
> sourced, Server needs to be restarted.
The server no longer needs to be restarted in these cases. You can search
for and edit change flow parameters, or you can change command file
templates for any or all blocks while the server is running your flow.
> Maintaining IP databases is a pain, so the fact that PDO requires you to
> build another database in addition to all of the .lef, .lib, milkyway
> (if needed) etc., is a drawback to using the tool. Even though ReShape
> can provide some automation to build the database, it still has to be
> built and maintained.
This has been fixed. You can read in LEF, lib and avoid making silo
libraries if desired. Of course it can is still not a bad idea to use
flow automation to maintain all your libraries. ;)
> I should note that a fully-relative approach takes a considerable
> amount of additional effort to set up. In my experience, it could take
> a couple of days to define the proper relationships between all of the
> partitions, macros, power grids, preroutes, etc. So one must evaluate
> that additional effort that's required versus the benefit of being able
> replay that floorplan script as changes are made during the iteration
> process. You'll have to replay that floorplan quite a few times before
> that investment will start to pay off, since the initial setup and each
> change with a non-relative, GUI driven approach can take a matter of
> hours, not days.
Our initial creation of relational floorplans has been improved with a
full GUI capability to express relations (called 'attaches'). All of
the relations are persistent in the silo database which makes for speed in
editing them over time. You can also 'write_floorplan' the floorplan out
as relational pdshell commands re-expressing the relations any time you
want.
Relational objects also include the concept called 'keystones'. These
are user named 'anchor points' that you can use for simplification of
your floorplan and ease of change.
ReShape is the only tool with hierarchical, relational GUI/script duality
for all floorplannable objects.
> Macro placement -- With FE, I typically do a prototype quality
> placement to get a general idea of where macros should go, then refine
> that manually. With PDO, this is more difficult. Because it doesn't
> have a placer, you must make the initial macro placement decisions on
> your own, and as of 10 months ago, your best bet was to place them
> relatively with a script. Setting up the initial floorplan definitely
> takes more time and effort in PDO.
PDO now has a macro placement engine, especially designed to work with
difficult rectilinear block boundaries. This placer automatically adds
relational 'attaches' that express the placement. You can then gui
edit these relations, or dump out and text edit...your choice.
> This brings up a major drawback to PDO -- it requires your production
> place and route flow to be up and running. In my current project, which
> will use a Synopsys-based place and route flow, our Milkyway libraries
> weren't built until just recently, whereas the LEF and .lib files have
> been available for some time, allowing us to progress with FE.
If you used PDBuilder and it's library building flow, PDlib, you can
automate the creation of Milkway dbs from lef/lib in a few hours, even
for many hundreds of cells.
> Global repeatering -- PDO's concept of repeatering is quite different
> from FE's. At this point, I haven't used FE's enough to compare, but I
> can say the PDO's strategy works very well.
>
> Feedthrough insertion -- Both tools do it well enough, but in my
> experience, they both needed guidance to achieve my objectives.
>
> Pin placement -- Again, both tools need some help through this process
> to give the quality of pin placement that I needed. The ability
> to change PDO's GCELL size has helped me achieve route ability in the
> past, on partition edges where routing resources were scarce.
All of these operations are really the output of chip level global routing.
PDO uses congestion, timing, placement feedback from your design to create
new top level global routing.
Because PDO was engineered from from the ground up for a hierarchical
environment it has successfully taped out chips with large numbers of
fully abutted arbitrarily rectilinear shaped blocks. It's proprietary
combined repeater-router uses information from previous builds to
minimize global timing, minimimze impact of global routing on block
congestion, and maintain stability from build to build with
incremental netlist releases.
If you look at designs taped out with PDO you can see the difference
visually. All top level net topologies are support "as-if flat".
> Timing budgeting -- Both tools can do this, but as I mentioned before,
> PDO can track hierarchy changes, which, depending upon your flow, can
> be a big advantage.
ReShapes re-budgeter now supports metrics that show you how your budgets
are changing from the previous iteration and it also handles fixed delays
due to repeater chains, etc properly when allocating slack.
> I know more about putting together a working flow than the people I
> worked with from ReShape, so I wouldn't touch their tools for this.
I'm sure you do, so for this reason, we have separated Openflow and
PDBuilder. You can create any flow you desire and run it with PDBuilder.
However, I will say that progressing versions of Openflow have been used
to tape out many complex, full abutted SOCs at 180, 130 and 90 nm. These
chips have all worked; so our flow ain't no chopped liver. ;)
- Paul Rodman
ReShape San Jose, CA
Index
Next->Item
|
|
