Local congestion with 6.1*?

Hi Eng Han,

Here's how I'd recommend troubleshooting problems like these...

I think it's important to differentiate between local placement density and local routing congestion. Usually, we're alerted to these kinds of problems via the routing congestions markers trialRoute creates in the display. When I see areas of high routing congestion, I like to assess what the placement density is in that region using the "Query Placement Utilization" widget at the top of the Encounter GUI that allows you to draw a box and it reports back the placement density in the box. If that number is high (like greater than 90%) I'd agree that a you have a situation where high local placement density is causing local routing congestion.

From there- how to solve it? There's a lot of different things that can cause this to occur. I'd recommend determining at which stage in the flow the problem first presents itself. If it's truly only at the CTS stage and no earlier, a couple of things to look for would be:

1) In the area of local routing congestion, select all of the clock buffers ("selectInstByCellName *CKBUF*" is an easy way) and determine if there's a lot of clock buffers in the area. If there are, then it would be useful to reserve space in this region for clock buffers. You can do this with cell padding, perhaps on all the flops in the design ("specifyCellPad"), placement density screens, or by asking the placer not to exceed a maximum density (setPlaceMode -maxDensity").

2) The problem could have to do with the routing rules you're using for your clock nets. If the width, spacing, or shielding of the clock nets is too aggressive it may just be too darn hard to route the clock nets the way you're requesting. BTW, it's recommended to do routing concurrent with CTS in Encounter (RouteClkNet YES) in your clock tree spec file. Further, you might want to relax the width of the routing only at the leaf level ("LeafRouteType" in your clock tree spec file).

Finally, I'd be curious to find out whether the problem occurs prior to optDesign -postCTS -or- after. If after, then I'd be especially curious whether hold fixing is causing the density problem or setup fixing. If hold fixing, the cell padding approach would be applicable, and it would also be worth checking out your hold uncertainty to make sure it's not unrealistically aggressive.

Please report back your findings and whether you've been able to resolve your congestion issues. I'm sure others would be interested in your findings.

Hope this helps,
Bob

Hi Eng Han,

Here's how I'd recommend troubleshooting problems like these...

I think it's important to differentiate between local placement density and local routing congestion. Usually, we're alerted to these kinds of problems via the routing congestions markers trialRoute creates in the display. When I see areas of high routing congestion, I like to assess what the placement density is in that region using the "Query Placement Utilization" widget at the top of the Encounter GUI that allows you to draw a box and it reports back the placement density in the box. If that number is high (like greater than 90%) I'd agree that a you have a situation where high local placement density is causing local routing congestion.

From there- how to solve it? There's a lot of different things that can cause this to occur. I'd recommend determining at which stage in the flow the problem first presents itself. If it's truly only at the CTS stage and no earlier, a couple of things to look for would be:

1) In the area of local routing congestion, select all of the clock buffers ("selectInstByCellName *CKBUF*" is an easy way) and determine if there's a lot of clock buffers in the area. If there are, then it would be useful to reserve space in this region for clock buffers. You can do this with cell padding, perhaps on all the flops in the design ("specifyCellPad"), placement density screens, or by asking the placer not to exceed a maximum density (setPlaceMode -maxDensity").

2) The problem could have to do with the routing rules you're using for your clock nets. If the width, spacing, or shielding of the clock nets is too aggressive it may just be too darn hard to route the clock nets the way you're requesting. BTW, it's recommended to do routing concurrent with CTS in Encounter (RouteClkNet YES) in your clock tree spec file. Further, you might want to relax the width of the routing only at the leaf level ("LeafRouteType" in your clock tree spec file).

Finally, I'd be curious to find out whether the problem occurs prior to optDesign -postCTS -or- after. If after, then I'd be especially curious whether hold fixing is causing the density problem or setup fixing. If hold fixing, the cell padding approach would be applicable, and it would also be worth checking out your hold uncertainty to make sure it's not unrealistically aggressive.

Please report back your findings and whether you've been able to resolve your congestion issues. I'm sure others would be interested in your findings.

Hope this helps,
Bob