RTL Compiler Physical has been available for about 2 years
now, and we're getting more customers all the time. But we still get the
question - how is this different from physical synthesis tools like PKS or
Physical Compiler?
Those of you that were around 10 years ago when physical
synthesis was launched, and in the years leading up to that, certainly remember
the promise that these tools would eliminate iterations with physical design.
Of course they would accomplish this by bringing physical knowledge into the
synthesis engine (Physically Knowledgeable Synthesis!). Isn't that what
RC-Physical does?
At a high-level, I suppose you could say it does. So how is
that different from what the previous generation did? The devil is in the
details. Let's look at some differences:
1) When
the physical information is applied.
In the old tools, the physical
information was applied only after a netlist was created. This is why the vast
majority of usage started with a netlist. Sure, the vendors claimed to start
from RTL, but the reality is that the RTL-to-gates process used a default
wireload model (which is why most folks saw worse results when starting from
RTL). These tools even did a lot of incremental optimization with the wireload
models before going into placement and doing more incremental optimization. So
even though the story was that these tools removed the barriers between logical
and physical optimization, the barriers still existed within the tools
themselves and thus would often not converge quickly enough.
In RC-Physical, physical
interconnect modeling takes place right from the start, by using Physical
Layout Estimation (PLE) and considering congestion as a cost function during
the RTL-to-gates phase, to create a better netlist. Once you have the netlist,
then it can be placed in the floorplan and global incremental optimization can proceed
with the more detailed physical interconnect. In this solution, the logical-physical barriers have truly been removed.
2) The
amount of optimization.
Because the old tools basically
tacked placement onto the end of the traditional synthesis flow, the amount of
optimization available at that point was limited because much of the
implementation was already committed. Thus any optimization that occurred after
that was by necessity restricted to very local, incremental moves. Think of the
last stages of incremental optimization, when the tool looks at a failing
path's endpoint and works backwards, optimizing a couple gates at a time (this
is how all synthesis tools outside of RTL Compiler work). These optimizations
were more powerful than anything physical designers had available to them, but for
logic synthesis users were really just the fine-tuning at the end of the
process.
Because RC-Physical applies only
the appropriate amount of physical detail for each step, its optimization is
never restricted. Using PLE for the RTL-to-gates process, its full global
synthesis optimizations are possible, now with physical awareness. Even after
the gates are placed, RC-Physical's incremental optimization can perform larger
moves because global synthesis looks at the entire path, as well as adjacent
paths, as well as multiple objectives (performance, power, area) during
optimization. And whereas traditional physical synthesis tools were much more
limited in terms of incremental placement, which causes problems when there are
placement density "hot spots", RC-Physical's global placement can morph and
spread cell placement during optimization in these cases. This capability helps
converge on the optimal logic structure and physical topology in order to ease
closure during physical implementation.
3) Capacity/Runtime
This is another shortcoming
inherent in the old synthesis engines - because they operate a path at-a-time,
a couple gates at-a-time, runtimes increase exponentially with the amount of
timing-critical paths in a design. Couple this with adding in the overhead of
the physical data, and now your runtime and memory capacity limit block sizes
to roughly 100k instances. This is fine if a failing path is contained within
that block, but don't most long wires extend beyond that 100k instance block?
Because RC-Physical is built on RTL
Compiler's global synthesis, its runtime scales linearly with design size. RC
has synthesized designs of over 1.4M instances on 32-bit machines, and has
synthesized a couple designs of 20M+ instances on 64-bit. And RC-Physical uses
the Encounter Digital Implementation System's fast high-capacity placement
technology. This combination of fast high-capacity engines enables global
optimization of the true long wire problems on a chip.
4) Use
model
The old tools started out by
embedding placement inside of synthesis. Because of many of the shortcomings
listed above, much of the initial adoption was by physical design teams. It
provided them with more powerful optimization, albeit within a more localized
and targeted context. Thus they wanted more physical accuracy - global routing,
clock tree synthesis, etc. were added. This was fine in the physical design
context, but it pushed the use model to be even more physically-oriented.
RC-Physical was architected by
folks who had experience using PKS and Physical Compiler. They were determined
to keep the synthesis use model. Yes, you still need a production floorplan in
order to get the accuracy you desire out of RC-Physical. You still need
physical libraries, and those need to match the timing libraries. But now the
physical tasks are much more automated. The restrictions associated with the
physical models have been removed, allowing full synthesis optimization. And
the reporting and GUI are logic design oriented, only presenting the physical
information as it affects timing and other care-abouts for the logic designer.
This all required a tremendous amount of innovation, but this was necessary in
order to make this usable by engineers accustomed to logic synthesis.
Hopefully that outlines the high-level differences. Reading
through that, you should get a sense as to why the old physical synthesis tools
ended up being adopted by the physical design teams and eventually integrated
into physical implementation systems. And you should see why RC-Physical is
different.
This is critical because in today's geometries and economic
climate, we can no longer afford to sacrifice power and die size for the sake
of over-margining performance to ensure physical closure. All synthesis today
should have some level of physical awareness built-in. And we're seeing that -
almost all of our RTL Compiler customers utilize at least the PLE models, and
more and more are adopting the placement-based RC-Physical solution.
Jack Erickson