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
- this is manifested in the RTL itself. E.g. a cross-bar switch design tends to
be more congested than a basic processor design.
- 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:
is really a manifestation of placement and synthesis tools have stayed away
floorplan is not available at synthesis stage or tools don't support reading
tools have been weak in supporting multi-objective optimizations
to estimate congestion in front-end (e.g. pin count, net-count etc.) have been
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
- 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
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.
congestion analysis features using a physical viewer. Not only can one analyze, but
also drive congestion optimization using the RC-Physical GUI.
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.