( DAC 04 Item 20 ) --------------------------------------------- [ 02/09/05 ]
Subject: ReShape pdBuilder, pdPlanner, and pdOptimizer
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 toolset 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.
Yes, I did see the ReShape demo at DAC and returned to ask many
questions. Yes also, ReShape visited me and accepted a test case
from me to prove out their technology.
In short, I still today have not seen the software in house.
pdBuilder is awesome! The Sourceforge dependency matrix allowing the
scripting and repeatability of each implementation step is exactly
what I need, right now, and would greatly improve productivity for our
implementation team. The matrix is nothing more than a GUI with either
predefined or user defined scripts and dependencies built into the
intersecting blocks. The scripts run user tools and not necessarily
ReShape tools. The primary benefit of having such a GUI is the
improvement of iteration speed and repeatability. New columns and
rows can be added to the matrix at will to run new steps or compare
one result against the other.
pdPlanner runs a planner from some other tool (Cadence or maybe soon
Magma) and is actually not a floorplanner but a floorplan manager. At
the time I looked at the tool, it was not able to perform timing based
macro placement. This tool will do an excellent job of managing virtual
interfaces between RTL hierarchical blocks that are usually placed and
routed flat. pdPlanner is most useful for designs >500K instances.
These virtual interfaces actually define individual blocks, subdividing
the "flat" process into manageable parallel processes. The results are
achieved much sooner (at the expense of requiring more software
licenses) and if signals migrate across the virtual boundaries due to
driver or clock buffer placements, pdPlanner continues to manage the
interfaces without additional user input.
pdOptimizer did not do well on our testcase (under 500K instances) to
the tune of 2X. However, the objective of the evaluation was to show
the capability of the tool and not necessarily the best use of it.
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.
- [ An Anon Engineer ]
We were focused only on pdBuilder, and the last time I saw the demo was
in fall of last year, tool may have had enhancements added. Here is
what I remember:
Strengths:
1. pdBuilder is UI based, and status can be checked on the web. Web
page is dynamically updated and shows run status.
2. Reports are HTML based. Anyone can check the progress or check
log files of finished or failed runs.
3. pdBuilder is neatly divided into sections:
Flows/StageTemplates/Sections/SubFlows
The sections are written in XML, easy to modify. Tool has a wrapper
script where user can specify which version of tool to use (may be
different versions of tool at different stages - I forget.)
4. Each command is split into procs - compartmentalized.
5. Commands that are used often can be written to a file and included
in the run.
pdBuilder has an option to use LSF or scripts to port jobs.
Weaknesses:
1. pdBuilder needs libraries to be rebuilt to its internal database
format at start stage. (ReShape may have decoupled this style.)
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.
I like regular approach, once setup pdBuilder is easy to use with an
added advantage of UI, and visual reports.
- Jay Yanamandala of OKI SemiConductor
Well, this turned out to be a novel, but I felt that I needed to make
a fair and complete comparison. Sorry if it's too much.
ReShape pdOptimizer vs. First Encounter, a Basic Comparison
-----------------------------------------------------------
I'll be referring to pdOptimizer as PDO, and Encounter as FE. First,
let me say that I'm comparing the 4.1 version of FE (only a few months
old) to a version of PDO that's about 10 months old. Much has changed
with both tools since then, and it would be nice to have a more
up-to-date comparison. Sorry, those are the versions of code that I've
used. The basic ideas and usability should still be close enough to
compare. If newer version of the tools have made my observations
obsolete, I'm sure you'll see rebuttals. :)
For those of you who just want the bottom line, or don't have time to
read the details, PDO is geared for the script-oriented "power user"
(it's interface is built on Perl) and offers very precise control and a
more powerful set of floorplanning commands, but is more difficult to
use. FE is easier to use and geared toward the engineer who prefers a
more GUI driven approach to floorplanning, although an engineer that is
willing to put forth the effort in developing some custom Tcl code (that
utilize FE's db commands) can take a more "power user" approach to
floorplanning in FE.
Let's compare these tools by looking in detail at parts of a design flow
example that I've taped out several chips with:
Database Prep:
One of the major tasks of any project is to prepare all of the needed
databases for all of the IP that is used. So you say, "Isn't this guy
talking about floorplanning? What does IP preparation have to do with
that?". The answer is simple. 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.
Netlist Prep:
I can't remember that last time I received a netlist that needed no
modifications at all prior to layout. I've worked on projects that
required hundreds or even thousands of lines of code to get the netlist
ready. Aside from hierarchy manipulation, my favorite example of this
manipulation was needed for the last two chips that I worked on. Our
chips were approximately 40% memory by area, and for several reasons,
such as LVS and ease of ECO application, we wanted that memory
(comprised of several large instances) in it's own partition. For area
efficiency, we needed the partition to be rectilinear, and it basically
had to be the same size as the memory footprint, which meant that the
pins of those memory instances were basically right up against the edge
of the partition boundary (using a fully abutted floorplan). Since
these memories obstructed all but one routing layer, for the most part,
that meant that none of the instances could share connectivity, because
there simply were no routing resources. Of course, the frontend
designers had many of the address busses, BIST related signals, clocks,
etc, all connected in parallel. PDO's netlist manipulation capabilities
allowed us to easily isolate each pin on each RAM (or sometimes RAMs
who's pins were directly across from each other could share signal with
each other, but not the other RAMs), and place the resulting buffers in
a region within the neighboring partition, directly across from the RAM
pins. FE can do the same thing, but the code is more involved, and
reveals tcl's inherent limitation that it does not support multi-
dimensional datastructures (even though they can be "faked"), so the
coding was easier in Perl.
Occasionally, you might need to change a netlist's hierarchy structure.
PDO allows you to perform any number of arbitrary "pushes" and "pops",
meaning that you can take any module from any other module, and push it
into yet another module. Not only that, it will keep track of that, so
that when it comes time to write out timing constraints that match the
new hierarchy, PDO can do that. FE can not do the netlist regrouping as
easily. You have to create a new hierarchy to move modules into, rather
than moving modules from one to the other. Also, FE will invoke PKS to
do the regrouping, and PKS has different requirements for the LEF than
FE, so a LEF that worked just fine for floorplanning, might cause a
crash when trying to regroup. I've been affected by that in the past.
Because of this capability, along with the number of built in commands
for database browsing and netlist manipulation within PDO, it's much
easier to both analyze connectivity and edit as needed. Many things
that require 10 or more lines of Tcl in FE can be done with one
command in PDO.
Initial Floorplan:
This is where FE shines. As I mentioned before, I haven't used PDO in
about 10 months, and PDO's GUI has improved, but there was simply no
comparison (don't get me wrong, I think there is plenty of room for
improvement with FE's GUI). However, being able to iterate the
floorplan many times with changes to size and shape, and with minimal
effort, may be important to you. If it is, PDO does this very well,
and in that sense, FE doesn't compare. PDO does this with commands
that support fully-relative floorplanning.
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.
I should also note that a fully-relative approach can actually be
achieved within FE, but since many of the commands you'll need don't
exist in the native code (for example, a command that will find you the
upper right hand corner of an instance, the location of a pin on an
instance, the width of a macro, etc. These are called "convenience
macros" in PDO), you'll be writing some custom code yourself.
Now let's look at a few floorplanning tasks in more detail:
Pad placement -- Both tools do this easily, but FE's format is easier
to deal with. PDO's format was written to deal with a spreadsheet for
an input, making it much more complicated unless your pad placement
information is a spreadsheet (which happens to be ReShape's format).
Partition placement -- FE makes it easier to get started with this,
and to size and shape the partitions and check their utilization, but
this is where PDO's relative floorplanning can start to make future
changes more effortless.
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
relativetly with a script. Setting up the initial floorplan definitely
takes more time and effort in PDO.
Power planning -- Both tools have very similar functionality here, but
PDO has the ability to create power structures relative to other objects
in the floorplan, giving it a big advantage. I've also been able to get
cleaner structures out of PDO (especially regarding the "followpin"
connection, and the connections from macros to the power grid).
Floorplan Feasibility:
Because of FE's virtual prototyping capabilities and ease of setting up
the first floorplan, I give it the advantage here. Within a few hours,
you can place and route the design and get a rough idea if the floorplan
will work or not. However, unless you plan to use the resulting cell
placement as a starting point for partition optimization and routing,
the congestion maps you see in FE most likely will not represent the
congestion you will see once you use your "production" partition place
and route flow, especially if you run non-timing driven at the toplevel
(if you don't have toplevel constraints, or your design is very large).
I've seen this before, and oddly enough, I see it most often in the
case where FE tells me a floorplan is *not* routeable, yet by using a
timing driven flow (including optimizations like area recovery) in the
partition, routeability might be achievable. PDO simply relies on that
"production" quality place and route flow from the beginning. It will
take longer to get initial feasibility feedback, but depending on your
flow, it may be more accurate. This brings up a major drawback to PDO
in that 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.
Initial Partition Place & Route:
Once we've decided on the first floorplan, the next step we do is to run
a full quality placement, optimization, and routing at the partition
level. Also, the partition owner can make adjustments to the macro
placements if needed. This information will provide vital feedback to
the toplevel before the floorplan can be refined to it's final state.
Both tools write out the necessary files for this step. Since we use
timing driven P&R, we need timing constraints, but at this point, the
quality of them doesn't matter too much, as long as the clocks and false
paths are constrained properly. Both tools can provide timing budgets,
assuming you had timing constraints for the toplevel, but in my
experience, both tools produced constraints that needed to be reviewed
and revised, particularly the input and output delay constraints. This
generally occurs after the first toplevel timing analysis that reveals
partition-to-partition timing problems.
Feedback from Initial Partition P&R:
Both tools can accept this feedback, although the method by which they
do it is quite different. We return a TDF or .fp file to FE, while PDO
will use its own database format.
Refine Floorplan:
Here's where PDO starts to really shine. It has many built-in commands
to make the below steps easier, and its native commands support fully
relative floorplanning, which can be a big advantage.
Preroutes -- PDO's set of command to create preroutes is more
powerful. As an example, it takes just a few lines of code to find an
output pin of a given pad, like an analog power pad, route a power
signal from that pin relative to an existing structure that must be
avoided, relative to any other number of floorplan objects, then to the
input pin of another object, like a PLL. B eing able to script such
things can be a real time saver. FE does have wire editor that I've
also used to get the job done, but it's more difficult to script.
Custom interfaces -- If you've got interfaces that are somewhat timing
critical and need some special attention, PDO has some functionality
that can help. For example, a source-synchronous interface that
needs to be skew balanced within a few hundred pico seconds, but the
pads stretch out over several millimeters. With just a few lines of
code, using PDO's built in commands, you can insure that your datapaths
have the same number of repeaters in them from the source partition to
the pads, and can be skewed relative to the clock. You can also make
sure that each path has the same wire distance between repeaters,
thereby roughly matching cell delay and wire delay from path to path.
Of course, some interfaces require a full-custom layout approach, but
for something less timing critical, this may be all you need. I don't
know of any such commands in FE.
Clock distribution -- In the past, I've used the same commands in PDO
that were discussed above for the custom interfaces to distribute clocks
evenly among partitions. The same idea applies, where we want a given
clock to arrive at each partition at the same time. Chances are very
good that you will be tuning clocks with ECO's late in the design
process, but PDO can help get you close. Again, to my knowledge, this
would all be custom code in FE.
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.
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.
Refined Partition Place & Route:
Typically, once the feedthroughs are in and the floorplan has been
refined, there could be a few more iterations of partition macro
placement, and it's best to "promote" the most recent cell placement
information back to the toplevel before it is built for the final
time, and just like initial feedback, both tools can handle it.
Assembly of Partitions for Tapeout Preparation:
What I mean by this is to bring all of the partitions back into the
toplevel, where we can then write out the necessary files and prepare
for final analysis and ECO's. FE wins this one hands down. PDO itself
is not capable of doing this, but ReShape does offer software that
will. FE can read the partition information, and then un-partition
to get the toplevel view.
Summary:
This was a very basic comparison, based on my experience in the past
with a 3 month old version and a 10 month old version of the tools:
PDO FE
----- ----
Command-line interface GUI interface
Fully-relative floorplanning Quick floorplan
Convenience macros Protoyping/quick feedback
Database browsing Overall ease of use
Netlist manipulation Tcl interface
Clock balancing
Perl interface
PDO is a tool that was built to solve very detailed floorplanning
problems, using a fully relative floorplanning approach. As such, it
offers very surgical control, but in turn, requires more control from
the user to operate it. FE takes a completely different approach to
floorpanning, relying heavily on the GUI as a means to gather input,
with fewer commands for the script based approach.
- [ An Anon Engineer ]
The ReShape guys have been developing real tools for hierarchical
design with full abutment for a while. We've been using them on
our chips.
pdOptimizer:
- They use a "design aware" approach rather than doing an upfront
flat placement, the tool uses feedback from previous builds to
re-optimize top level global routing and timing budgets. The tool
attempts to 'react' to block level placement changes, timing issues
and congestion and shift global routing on the next build to
improve things.
This approach seems to produce high quality results in my test
designs as well as all the chip photos I've seen.
This approach also means that new inter-block nets in an incremental
netlist release can be optimized while old nets are kept stable
(rather than having to worry that slight pin/budget changes will
change everything at the block level).
- Complex top-level net topologies that bother other tools are handled
(repeatered and pure-wired feedthroughs, multi-pin nets, and top
level repeater trees).
- In the latest version, the global router's ability to do
simultaneous repeater and routing (to handle nasty complex
placement and routing blockages) is good.
- Quick, early timing feedback and budgeting. The timing engine uses
"Design Aware" feedback to optimize budgets. They used to support
only their internal constraint format, which was on the clunky side.
But the new version directly reads SDF which makes a big difference
to us. So far there do not seem to be any correlation issues.
I expect to be banging on this part of the tool quite a bit more
in the near future, so I'll have a better feel for the accuracy soon.
One thing to realize is that this tool is intended to drive a set of
3rd party place and route tools. ReShape has a global router that they
use during repeater placement and to perform optimization analysis, but
the actual placement and routing results come from Cadence, Synopsys,
Magma tools.
pdBuilder:
This is a flow management system that handles the entire chip build
employing 3rd party physical tools (e.g. FE place, CTS, NanoRoute,
Fire&Ice QX, etc.), from library management/build, to partition
construction, to top level assembly (all including resource
management). It now also allows easy custom flow development, which
is important to us.
I like the fact that once a flow is developed, generating numerous full
chip builds becomes very manageable.
Although it works with a few server-farm systems (e.g. lsf, etc.), I
can't comment on which are not supported yet.
pdPlanner:
I have also been working with their pdPlanner floorplanning tool. It
appears to be a pretty powerful hierarchical, relational floorplanning
system that gives me flexibility/control I don't have in other tools.
- Edson Gomersall of Stretch, Inc.
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.
- [ An Anon Engineer ]
Index
Next->Item
|
|
