will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST). login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Logic Design > automatically identifying fixing and preventing congestion with rtl compiler physical
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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: *

Automatically Identify, Fix, and Prevent Congestion With RTL Compiler Physical

Comments(2)Filed under: Logic Design, Synthesis, congestion, RTL Compiler 9.1, RC-Physical, Ankush Sood

By Ankush Sood
Principal Product Engineer

Congestion is at the heart of the design closure challenge today. With smaller cell dimensions, increased chip-size and an inclination of design houses to reduce metal layers available for routing (to save costs), designs are getting more congested. The normal approach to solve congestion has been to increase the die size which increases design cost. Hence it is desirable to have a comprehensive implementation flow in place which tackles congestion from RTL to detailed routing.

Congestion is caused primarily due to two reasons:

  • Connectivity - this is manifested in the RTL itself. E.g. a cross-bar switch design tends to be more congested than a basic processor design.
  • Floorplan - essentially how your hard macros are placed. Since the macro placement is sometimes a direct outcome of higher-level chip planning, one has no option but to live with sub-optimal macro placement.

Traditionally congestion has not been something front-end designers have worried about and nor have the commercially available front-end synthesis tools addressed the problem.

There are many reasons for this:

  • Congestion is really a manifestation of placement and synthesis tools have stayed away from placement
  • A floorplan is not available at synthesis stage or tools don't support reading one
  • Synthesis tools have been weak in supporting multi-objective optimizations
  • Techniques to estimate congestion in front-end (e.g. pin count, net-count etc.) have been generally ineffective

But, the fact of the matter is that synthesis tools create the circuit topology and connectivity and hence have a significant impact on how congested a design will be in the back-end.

Why should the front-end engineer care?

The front-end designer is the only link between the RTL developer and the implementation team. As described above congestion in the design core is a direct result of the RTL architecture. Although there are various techniques designed to alleviate congestion in the implementation tools, it often requires a RTL change. Back-end tools do not provide links to the RTL and it makes it extremely difficult to analyze and identify the root cause. Hence, it is desirable that the front-end designer be able to identify congestion hot-spots and give feedback to the RTL designer early in the development cycle. In addition, the front-end engineer really doesn't want to spend time doing DFT, verification etc. on a RTL code which would be changed frequently. Early identification of congestion saves a lot of effort and design cycles.

RTL Compiler Physical has a comprehensive set of technologies to estimate, analyze and optimize congestion at various stages in the design flow from RTL to placed gates. It looks at congestion both in global terms during RTL synthesis and also at the local level post placement.

Global estimate for congestion:

At the global level, pin-count, net-count etc. have been used before to estimate congestion but they are not nearly enough. A much better estimate is net-length. RC uses patented PLE (physical layout estimation) technology to estimate net-length even before placement. RC-Physical uses PLE to estimate total net-length and uses it as a cost factor in the technology mapping phase. In our internal benchmarks this methodology has proved a lot more effective than other global cost functions.

Post Placement:

A real congestion map can only be generated post-placement. This is very design- and floorplan-specific and hence the first requirement is to have a production quality placement engine. RC-Physical uses Encounter placement which allows it to give an accurate view of congestion. There are various techniques which are employed for a congestion analysis and optimization:

  • Native routing technology allows RC-Physical to estimate congestion natively. It identifies both core logic congestion and macro placement related congestion.  Being able to dynamically update the congestion information is crucial in driving optimization
  • Congestion-aware placement using Encounter placement engine
  • Congestion optimization during incremental placement to relieve local hot-spots. RC-Physical uses a unique "Global Whitespace Redistribution" methodology to create and distribute whitespace around standard cells based on various parameters like local congestion, pin density and global interconnect.
  • Congestion-aware incremental optimization - a unique ability to cost each incremental optimization move for congestion.
  • Advanced congestion analysis features using a physical viewer. Not only can one analyze, but also drive congestion optimization using the RC-Physical GUI.
  • Cross-probing of congested regions in the design with the RTL code to find opportunities for better RTL coding.
  • RC-Physical can also remove cells which have been identified as bad for congestion from congested areas automatically.

The back-end engineer lives and breathes congestion, but with these new techniques, front-end engineers can start looking at more of the physical characteristics of a design, especially congestion. Catching congestion early in the design process will allow for huge turnaround time savings. One would require less iteration between front-end and back-end due to better convergence of the flows.


By sakshi Gupta on July 24, 2012
Can you  tell me in detail the Congestion related checks that are available in RC, that Frontend designer must perform ?

By David Stratman on August 7, 2012
There are a number of congested related techniques we can apply in RC Physical in order to identify and relieve congestion during physical synthesis in order to have a cleaner run through P&R.
Please take a look at the this webinar ( for an overview of the types of techniques we use in RCP (morphing, whitespace distribution, ATPG compression/decompression congestion spreading, etc.). None of these features are mandatory, but can be enabled to deal with suspected or known congestion problem area in your design.

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.