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
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:
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
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.
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
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.
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 (cadence.com/cadence/events/Pages/event.aspx?eventid=289) 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.
Can you tell me in detail the Congestion related checks that are available in RC, that Frontend designer must perform ?