Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
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 ?