Local congestion with 6.1*? 

Hi,

Anyone has seen bad local congestion with Encounter 6.1* after CTS? In my previous project, I had issue with this. In my current project which use a much larger process technology I am face with this issue again. I don't have this issue before with 5.*.

With the local congestion, optDesign is not able to size some of the cells, result in plenty of large negative slack.

Regards,
Eng Han

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 Bob,

First to clarify my issue. I should say "high local placement utilization" and not "local congestion". There is no congestion even when with the high local utilizaiton. The local utilization is very high. By eyeball, it is almost (or it is) 100% for more than 10 rows and 30-50 std cell width (I cannot remember exactly, this is my impression).

There is no issue before CTS (so physical synthesis part is okay). Also, I have not perform fix hold, so the problem occur only during CTS.

I study the issue breifly. I think it is due to the tool size-up all the clock gates (CG)r. The design uses RC to insert cg even only when one FF is gated. So the design has 7000+ CG. Before CTS, most of the CG are 2x. After CTS, most of the CG are 12x and 16x. I believe this is causing local congestion.

Now, before you think I have issue with my CTS specification file, I have tried many things. I have used mainly default setting, relaxed setting, and many in-between. I end up disable the high drive CG. It helps some, but not completely.

Now again (:>) before you double my technology, I am using TSMC 0.18um lef, captable (with co-relation with QX), etc etc. This library cannot be that bad, correct?

Back to my observation and feeling. I don't have this issue when I use 4.* and 5.* but for 2 consecutive projects I have this issue. I tend to think there is something in 6.* that make this happen. Of course I can be wrong; I hope to hear from the users of 6.* if they also face the same issue. Also, spread out the cells to ease local congestion is a basic function of the placer. Although all the cells have been placed, and CTS suppose to make minimum movement of the cells, I think something can be done here in an automated way.

By the way, in a previous project I try to use cell/instance padding but it does not seem to be supported anymore by the new moduleplan placer. I am not 100% sure here...

Regards,
Eng Han

I think i had seen the same problem in my design. I think the problem is with the new placement engine in 6.2 (default modulePlan). It tends to cluster cells much closer(for timing) than the old placement engine. You might want to try the same design/script but turn off the modulePlan placement engine (-noModulePlan?).

li siang

I am answering my own question I posted in this thread.

I confirm that cell padding is supported by 6.1USR3 with moduleplan. I am using it now.

Regards,
Eng Han