Home > Community > Blogs > Logic Design > physically aware synthesis this time it s different
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Logic Design blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Physically-Aware Synthesis: This Time it’s Different

Comments(0)Filed under: Logic Design, Physical timing closure, ple physical global, Physical Prediction, RTL compiler, RC-Physical, Jack Erickson, Physical Synthesis

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


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.