Abstract

Conventionally, timing and area are main focus in logic synthesis stage. DC-Topographical is broadly used in advanced design. It shares placement technology with IC Compiler and it potentially improves timing correlation between synthesis and PNR tool. However, we may still get large QoR degradation due to routing congestion. Traditionally, routing congestion is taken into account in placement stage or routing stage. If the design has heavy congestion, we may need to refine the floorplan. To get a better QoR correlation, we still need to re-synthesize. The schedule may be delayed due to iteration.

The latest DC-Graphical feature extends the DC-Topographical technology to predict, analyze and minimize routing congestion in logic synthesis stage. We introduce DC-Graphical technology into our flow. This paper aims to show what we can get by using DC-Graphical.

1. Introduction

In ultra deep sub-micron designs, interconnect parasitics have major effect on path delay. Accurate estimation of resistance and capacitance can get accurate path delay calculation. DC-Topographical technology employs virtual placement in synthesis stage. It can predict post-layout timing, area, and power during RTL synthesis without the need of wireload model-based timing estimation. It uses Synopsys’ placement and optimization technologies to drive accurate timing prediction within synthesis. It provides better correlation to final physical design.

However, the Back-End engineer may find the design is hard to route. There are too many nets which need to be connected in some special regions. It causes routing congestions. These regions are called congestion hot-spots. To route these congested nets, the placer have to move the cell out of the congested region or detour the nets. It may cause large QoR degration. We may need to refine the floorplan to reduce routing congestion. After refining floorplan, we need to synthesis again to get better QoR correlation. These iterations may delay the schedule. If routing congestion can be predicted in earlier stage, the flow will be much smooth and the schedule will be speed up.

In DesignCompiler A-2007.12-SP2 release, the DC-Graphical technology is introduced. DC-Graphical extends DC-Topographical with virtual global routing technology. It can predict, analyze and minimize routing congestion during synthesis.

We introduce DC-Graphical technology into our design. We will show our experience by using DC-Graphical.

2. What’s routing congestion

In logic synthesis stage, routing congestion is estimated based on global routing result. Global routing partitions design into virtual array of global routing cells. The routing congestion in a design occurs when the number of wires traversing a global route cell is greater than the capacity of the region. If the ratio of usage-to-capacity is greater than 1, the region is considered to have congestion problems. Figure 1 shows what the routing congestion is.

Figure 1: What is routing Congestion

Congestion can be associated with RTL or floorplan. Figure 2 shows the floorplan and RTL related congestion

Figure 2: Different kind of Congestion

Floorplan-related congestion is caused by location of Macro cells and IOs, for example, narrow channel between macro cells. If there are too many cells in the channel, it will reduce the routing resource and cause congestion. The common solution is to put a placement blockage around the channel. It ensures no cells are placed inside the channel. The routing connection is far from macros. It can reduce routing congestion. Sometimes we may need to change the placement of the macro cells or port location. It can not be reduced by changing the RTL.

Normally, RTL-related congestion occurs in the center of stardand cell region since there are too many interconnections between cells in these regions. The routing resources are exhausted. So it causes the routing congestion. A typical case is multiplexor trees. If there are many nets connecting high fanin mux cells, there are many pins in this small region. The pin desity is high. This will induce routing congestion. One solution is to change the RTL or re-strcutre the multiplexor tree. It is possible for the synthesis tool to re-structure the logic to reduce congestion. An example is to replace the 8 to 1 muxes with 2 to 1 muxes since 2 to 1 mux have lower pin density.

3. Experience of DC-Graphical Usage

3.1 Layout Window in DesignCompiler Graphical

The Design Vision layout window is available as part of Design Compiler Graphical. This tool provides a graphical user interface (GUI) for viewing and analyzing the physical aspects of a design that you have optimized by using the Design Compiler topographical technology. With layout view, it is easy to distinguish the floorplan congestion or RTL-related congestion.

The layout window is a useful tool for debugging physical problems related to synthesis in Design Compiler Topographical mode. It provides general guidelines for using the layout window to efficiently debug physical design problems and achieve better results with Design Compiler Topographical mode.

The layout view allows debug the physical design problems that cause QoR degradation, especially timing degradation. The layout view provides visual feedback about the physical placement of timing path objects. This visual feedback helps you to find answers for such questions as critical path, high transition, and so on. By querying and highlighting design objects in the layout view, we can find answers to these questions that help you understand topographical mode placement and the issues that cause timing degradation.

Here is one example how to debug the timing issue with layout window in our design. Figure 3 shows layout window in DesignCompiler.

Figure 3: Debug the Timing Path in Layout Window (pre-fix)

The highlight path in figure 3 is the worst timing path. Its slack is -0.42ns. With the layout window, we can find the long net is the key reason. There are some cells in the narrow channel. So some long nets occur between cells in the narrow channel and cells in the center. The long nets cause hurge delay.

To limit the long nets occurrence and improve the timing, we put the placement blockage on the narrow channel. The circle in the figure 4 is the placement blockage which we added. The highlight path in figure 4 is the worst timing path. The slack of the timing path is -0.15ns. We can find the timing is improved.

Figure 4: Debug the Timing Path in Layout Window (post-fix)

3.2 Power Mesh Information

The pre-route nets (such as power mesh inserted at floorplan stage) affect the routing resource. DC-G global route uses the pre-routes while computing congestion map. It can improve DCG/ICC consistency in congestion map calculation.

In DC A-2007.12, we can use set_congestion_options commands to estimate future route resource consumption.

set_congestion_options -layer METAL6 -availability 0.9

set_congestion_options -layer METAL5 -availability 0.9

But we find the estimation is far from real power mesh. So we have to model the power mesh structure by using wiring keepouts. The following is some of what we use in DesignCompiler. It needs many efforts to model power mesh from IC Compiler floorplan.

Starting with version B-2008.09, it is much easier to model power mesh. DC Graphical supports pre-route extraction from DEF by converting the power structure into the create_net_shape TCL commands.

When export the DEF in IC Compiler, the specialnets option must be added to write_def command.

write_def -rows_tracks_gcells -vias -regions_groups -macro -pins -blockages -specialnets –output MY_DESIGN.def

When extract the DEF in DesignCompiler, the pre_route option must be added like the following:

extract_physical_constraints –pre_route MY_DESIGN.def –output MY_DESIGN_phy_con.tcl

The create_net_shape command can be found in MY_DESIGN_phy_con.tcl. It means power mesh is identified in DesignCompiler. With the new feature, it can reduce the pain to model power mesh.

3.3 Congestion Report

The following is an example of report_congestion command.

The report describes congestion violations in the design. The congestion is divided in to 2 sections: horizontal and vertical, just as the metal layers on the chip area. Also, for each GRC (Global Routing Cell) we consider both horizontal and vertical edges to get the “Both Dirs” number.

The Overflow value is the total number of wires in the design GRCs that do not have a corresponding track available. Just like the Total Negative Slack (TNS) of the timing report – it gives the summary of the design.

The Max corresponds to the highest number of over-utilized wires in a single GRC. So if the Max is 14, it means there are GRC edges where we need 14 more wires than there are available. The number in parentheses (1 GRCs) indicates that 1 cell has this maximum value. Just like the Worst Negative Slack (WNS) of the timing report. It tells you how bad the worst part of the design is and how widespread the worst part is.

The GRCs number is the total number of over-congested GRCs in the designs. We can think of this as the number of violating paths. The percentage in parentheses is the percentage of GRCs with violations.

Even we explain congestion report like this, the congestion report is still hard to understand. In most cases, we use DC-G congestion map to check it is congested or not. Figure 4 shows our DC-Graphical congestion map in layout window. It uses different color with different congestion overflow region. It gives us congestion report which is easy to understand. The left two red hot-spots mean they are congested regions. It also gives the congestion overflow histogram like the right section. From the overflow histogram, we can know congestion distribution in our design.

Figure 5: Congestion Map in Layout Window

3.4 Predicting and minimizing routing congestion

DC-Graphical uses the Synopsys virtual global routing technology to predict wire-routing congestion. In this technology, congestion is estimated by dividing the design into a virtual grid of global routing cells, followed by a global route to count the number of wires crossing each grid edge. The capacity and size of each global routing cell is calculated by using the technology physical library information. A particular global routing cell is considered over-congested if the actual number of wires passing through it is greater than the number of available tracks.

DC-Graphical predicts the congestion number by subtracting the maximum wires allowed for a particular edge direction from the total number of wires crossing per edge. Any number over zero is a congestion violation. This calculation is represented by the following relationship:

Congestion = (number of wires) – (maximum wires allowed)

With layout windows section 3.1 mentioned, we can find the congestion hot-spot. If the hot-spot is close to macro, it means floorplan-related congestion. We can tune the floorplan to reduce it. If the hot-spot is in the center of the random standard cell logic, it is RTL-related congestion. We can let DC-Graphical optimize the congestion. However, if we still see the RTL-related congestion after optimizing, we need to change the RTL. It gives us the congestion prediction in the early stage. It can also optimize routing congestion in synthesis stage. In figure 5, we can find the congestion hot-spot in synthesis stage. This will reduce iteration between frond-end and back-end.

In our design, we use two-pass synthesis flow. The first one uses the traditional synthesis strategy. We only add the congestion report. To get it much clear, the congestion map is checked with DesignVision layout window. Like the figure 5 shows, we can find our design is congested in some region.

……

compile_ultra –scan …

report_congestion

……

The second step is to use DC-Graphical to minimize the congestion before place and routing. Below is the script which we use.

3.5 Congestion Correlation

To get a better comparison, we list congetion maps with different flow. One is using traditional DC-T flow (no congestion optimization). The other introduces congestion optimization with DC-G flow. The two synthesis netlists are placed with ICC place_opt by using same floorplan.

The Figure6~7 show the congestion map of synthesis and post-place with DCT/DCG netlist.

Figure 6: DC Congestion map (left, without congestion optimization. Right, with congestion optimization)

Figure 7: ICC place_opt Congestion map (left, DCT netlist. Right, DCG netlist)

From the figure 5, we can find DC-G can minimize the congestion in DCT. DesignCompile can’t estimate the post-place congestion which is in narrow channel. It causes the worse congestion correlation in synthesis and post-place.

4. Discussion

We would like to see that DC-G could be improved in some areas in the future release. Here are some suggestions of improvement.

4.1 Routing on macro

In the DC-G congestion map, we can find some congestion area on the macro, such as the blue macro at right corner in Figure 5 (the dashed rectangle). Actually, the macros use the all metals (from bottom metal to top metal). It doesn’t enable routing on them. But DC-Graphical sees the congestion. It gives us the wrong unstandstand on the macro. So it needs to impove in future release.

4.2 Congestion Correlation between DC and ICC place_opt

In ICC place_opt congestion map (figure 6), we can find the congestion hot-spot in narrow channel in the right corner. It is floorplan-related floorplan. But DC-Graphical can’t see it (figure 5). It gives the different congestion result in the narrow channel between DC and ICC place_opt. The correlation is not good. So it needs to improve in future release.

4.3 GUI improvement

The feautre of DC-G layout window is only a little part of ICC GUI. If DC-G includes most of the ICC GUI feature, it is much easier to use.

5. Conclusions and Recommendations

We introduce the DC-Graphical technology into our flow. The DC-Graphical layout window provides a crossing physical and logical constraints debugging capability. With it, it is easy to debug the QoR, floorplan, congestion issues. It can speed up the debug time.

With DC-Graphical, we can predict routing congestion in logic synthesis stage. When DC-G estimates congestion, we can minimize the routing congestion with DC-G technology. In our design, it can reduce most of congested hot spot. As a new technology, it still has some limitation. But it gives us visibility into routing issues before PNR. We believe DC-G can do better in future release.

6. Acknowledgements

We would like to thanks LI Ang, our SNUG technical reviewer, for his valuable inputs.

7. References

[1] Design Compiler Graphical Application Note, A-2007.12-SP2, Synopsys.

[2] Design Compiler User Guide, B-2008.09, Synopsys.