If you ask design groups what the biggest challenges are to getting a chip out on time, then the top two are usually verification, and getting closure after physical design. Not just timing closure, but power and area. One of the big drivers of this is predicting and avoiding excessive routing congestion, which is something that has only downside: area, timing and power are all worse (unless additional metal layers are used which is obviously increases cost).
A typical SoC today is actually more of an assembly of IP blocks, perhaps with a network-on-chip (NoC) infrastructure to tie it all together, itself an approach partially motivated by better routability aka less routing congestion.
Some routing congestion, physical congestion, is caused by how the chip floorplan is created. Like playing tic-tac-toe where you always want to start by grabbing the middle square, routing resources in the middle of the chip are at a premium and creating a floorplan that minimizes the number of wires that need to go through there is almost always a good idea. The ideal floorplan, never truly achieved in practice, has roughly even routing congestion across the whole chip.
But other routing congestion is logical congestion, inherent in the design. This comes in two flavors: core congestion and peripheral congestion.
Core congestion is inherent in the structure of the IP block. For example, very high fanout muxes will bring a large number of routes into the area of the mux causing congestion. This is inherent in the way the RTL is written and is not something that a good floorplan or a clever router can correct. Other common culprits are high fanout nets, high fanin nets and cells that have a large number of pins in a small area.
Peripheral congestion is caused when certain IP blocks have large numbers of I/O ports converging on a small number of logic gates. This is not really visible at module development time (because the module has yet to be hooked up to its environment) but becomes so when the block is integrated into the next level up the hierarchy.
The challenge with logical congestion is that it is baked-in when the RTL is created, but generally RTL tools and groups are not considering congestion. For example, high-level synthesis is focused on hitting a performance/area (and perhaps power) sweet spot. IP development groups don’t know the environment in which their block will be used.
The traditional solution to this problem has been to ignore it until problems show up in physical design, and then attempt to fix them there. This works fine for physical congestion, but logical congestion really requires changes to the RTL and in ways which are hard to comprehend when down in the guts of place and route. This process can be short-circuited by doing trial layouts during RTL development, but a the RTL must be largely complete for this so it is still late in the design cycle.
An alternative is to use “rules of thumb” and the production synthesis tool. But these days, synthesis is not a quick push-button process and the rules-of-thumb (high fanout muxes are bad) tend to be very noisy and produce a lot of false positives, structures that are called as bad when they are benign.
What is required is a tool that can be used during RTL authoring. It needs to have several attributes. Firstly, it needs to give quick feedback during RTL authoring, not later in the design cycle when the authoring teams have moved on. Second, it needs to minimize the number of false errors that cause time to be wasted fixing non-problems. And thirdly, the tool must do a good job of cross-probing, identifying the culprit RTL not just identifying some routing congestion at the gate-level.
Products are starting to emerge in EDA to address this problem, including SpyGlass Physical, aimed (despite Physical in the name) at RTL authoring. It offers many capabilities to resolve logical congestion issues up-front, has easy to use physical rules and debug capabilities to pin-point roout causes so that they can be fixed early, along iwth simple reports on the congestion status of entire RTL blocks.
The Atrenta white-paper on SpyGlass Physical can be downloaded here.
