Eliminating Routing Congestion Issues With Logic Synthesis
Eliminating Routing Congestion Issues With Logic Synthesis
Routing congestion, which results when too many routes need to go through an area with insufficient routing tracks, can cause devastating delays to a project schedule. Logic design teams can avoid this problem and achieve greater success by adopting a physically aware and congestion-aware synthesis methodology that reduces iterations between front-end and back-end teams and positively impacts die size and schedule time.
Contents
What is Routing Congestion and Why Should You Care? ................ 1 Fixing Congestion ........................ 4 Preventing Congestion ................. 7
The following scenario has happened to a lot of logic designers; has it happened to you? You work hard to design a chip, make sure it meets the specifications, verify it, and hand it off to be physically implemented. You go on your merry way, planning your next project, when your phone rings in the middle of the night. It is the physical implementation team telling you that your chip cannot be routed because of congestion issues. And the chip might not be able to meet either the schedule or the spec. This is every chip designers nightmare!
Given the delay impact of wires in todays process geometries, modern timing-aware routers will try as much as possible to detour only those routes on non-timing-critical paths. But this is not always possible. And given the prominence of physical wire delays in todays geometries, it is likely that a non-critical path becomes critical after its route is detoured. Further compounding the problem, physical tools tend to buffer those detoured routes in an attempt to speed them up, and this can create further congestion.
Buffer insertion
The unfortunate effect of this is a non-linear increase in routing difficulty. Just a small increase in congestion can cause this, and because of this it is often called the red zone.
Incomplete routes or timing violations Less than 5% makes a big difference
% Die utilization
Figure 2: The red zone
So congestion creates more timing failures than the logic design team would anticipate because the only reason these paths fail is due to long physical wires that result from detoured routes. This is difficult for the logic designer to fix. And because the physical design team is not as familiar with the design and its timing requirements, fixing these issues takes time during physical implementation, which is often on the critical path of the chips schedule. Thus, the projects overall schedule can be negatively affected by something that is beyond the logic designers control.
www.cadence.com
Global Congestion
Global interconnect congestion. This occurs when there are a lot of chip-level or inter-block wires that need to cross an area. For instance, interconnect between cells and I/O pins or memory ports will be very dependent on both the floorplan as well as where those cells are placed within the floorplan. Global interconnect congestion can occur even when there is low placement densityin fact, in some cases low placement density can even cause congestion because of the need for long connections and additional buffering. Finally, chips with a limited number of routing layers for cost reasons can also cause global congestion. All of these reasons are why it is so important to use the production floorplan and legalized production placement.
Local Congestion
Floorplan congestion. This occurs when the floorplan has macros and other routing blockages that are too close together to get enough routes through to connect to the macros. For instance, the congestion can occur in slots between memories or around corners of memories. Identifying this type of congestion obviously requires that a production floorplan be used as an input. Here is an example of floorplan congestion:
1.
Placement density congestion. Placement utilization is basically how densely the cells are placed. When there are too many cells too close together (high placement utilization), then routing all the connections between them creates congestion. This can be the result of the entire designs utilization being too high, or perhaps it is localized to a block or region. Often this happens when timing is tightly (or too tightly) constrained, causing
www.cadence.com
timing-driven placement to place these cells closer together. Even more likely is that the netlist was poorly constructed. In other words, the netlist was created either without taking wire impact into account or was optimized with excessive incremental buffering and sizing. Identifying this type of congestion is dependent on the quality of the netlist, a production floorplan, and production placement. 2. Logic-induced congestion. Logic structure and cell selection can create congestion. A high amount of connectivity contained within a small physical area can overwhelm available routing resources. A common example is an extremely large multiplexor. There are just too many connections that need to be made in too small a space. Another example is high pin density (pin count divided by total cell area) caused by using smaller cells that require more routes to pins in a small area, such as decomposed complex cells or even low-drive cells.
The challenge with logic-induced congestion is that it is often context-sensitivea cell might be chosen for performance, area, or power reasons and might be fine for congestion in one context, but the same cell might increase congestion in another context. This is why it is critical to consider congestion in conjunction with performance, power, and area. As you can see, the causes of congestion span logic design and physical design. This is what leads to a lot of the misunderstanding over whose fault it is when a chip cannot be implemented on schedule. Fortunately, this can now be avoided by analyzing the cause in physically-aware synthesis tools before handoff to physical design, and taking the appropriate action.
Fixing Congestion
Analysis
Fixing congestion starts with identifying that congestion is the problem and then determining the root cause. For the logic designer, this will require using a synthesis tool that can predict physical issues. More specifically, this requires high-quality production placement in the production floorplancongestion is entirely dependent on the floorplan, placement quality, localized utilization, and power grid effects on the die. For instance, are there enough routing resources around the macros? Are there placement regions that must be obeyed, such as in the case of
www.cadence.com
power domains? Are there placement or routing blockages that must be obeyed? How densely can the logic be placed? How much buffering has to be performed on long wires in order to meet timing? Is there room to place these buffers in the optimal location? Is there space to upsize cells in their current location? It is important to model these possibilities as accurately as possible. At the same time, if the goal is to provide useful feedback to logic designers, then the environment must be usable and understandable to a logic designer. In this case, all analyses must be performed within the existing logic synthesis environment. Once this is performed, quality of silicon (performance, power, and area measured with wires) can be determined and reported within the synthesis tool. At this point, if there are timing violations, the logic designer will begin to analyze the violating paths. In wireload-based synthesis, the wire delays on the violating paths will be proportional to the amount of fanout from the driving gates. In a physically-aware synthesis tool, there may be large wire delays where there is little fanout, or there may be a large amount of buffers on a path with little fanoutthese will be long physical wires. If these long wires appear, they should be examined in a physical placement viewer to see why they exist. It could be a case of routes detoured around congested areas. If congestion is identified as a problem, then all root causes must be understood before proceeding with the appropriate correction.
www.cadence.com
www.cadence.com
Preventing Congestion
Preventing congestion entirely is a difficult proposition due to its localized nature. It would be easy to prevent if you were able to globally reduce utilization or globally avoid complex cells. Since performing these tasks across the entire chip would cause a die size penalty and possibly even induce congestion, the more balanced approach would be to utilize congestion-aware synthesis to automate a lot of the steps described earlier. The first requirement of such a synthesis tool is that it be able to model and measure congestion dynamically, so that it can make good decisions during the optimization process. This model needs to be updated with every change to the logic and placement, since congestion can sometimes be fixed in one place but moved to another. Once this model is present, the tool can examine the various methods described above. Preventing floorplaninduced congestion is most likely out of its scope. But identifying congested areas and structuring logic differently, mapping to or avoiding certain types of cells in congested regions, and spreading the placement or re-setting the target utilization for congested regions, are all optimizations that can be performed inside synthesis. And modern global synthesis algorithms can even use congestion as a cost function when creating the initial logic structures, heading off some problems before they even occur. The tools available to logic designers for addressing congestion have come a long way in a short time. But addressing congestion still has to start with analysis. Fortunately, this analysis can now occur directly within synthesis by starting with timing analysis as usual. Congestion is just another dynamic that must be examined and accounted for as part of this process. Adopting a congestion-aware synthesis methodology is thankfully incremental over existing synthesis methodologies. And the rewards can be greatwhether it means reducing iterations between front-end and back-end teams or simply saving die size or time in the schedule. Ultimately, a physically-aware and congestion-aware synthesis methodology returns control over the success of the project to the logic design team.
Cadence is transforming the global electronics industry through a vision called EDA360. With an application-driven approach to design, our software, hardware, IP, and services help customers realize silicon, SoCs, and complete systems efficiently and profitably. www.cadence.com
2011 Cadence Design Systems, Inc. All rights reserved. Cadence and the Cadence logo are registered trademarks of Cadence Design Systems, Inc., All rights reserved. Cadence and the Cadence logo are registered trademarks of Cadence Design Systems, Inc., All rights reserved. Cadence and the Cadence logo are registered trademarks of Cadence Design Systems, Inc. 21025 12/11 MK/DM/PDF