Daily Archives: May 27, 2008

Often there might be cases when we dont know whats the cause of congestion. You can never point at one source and this contributes to congestion. This has to be tracked from very early in the flow (logic synthesis).

I will try to highlight some of the things to check based on my experience. Also,by no means this is complete reference .

1. Does your cell count looks suspicious? even though area is comparable, but if cell count is pretty high, P&R tools might have a  problem in placing and routing so many cells and leads to congestion.

2. Is synthesis tool using lot of complex gates or are there any big muxes infered from RTL itself, then you might need to recode the RTL making routing job easier.

3. If RTL is OK, and synthesis is inferring complex gates, it might help yet times to decompose those logic.

4. Some times logic restructering with cone depth greater than default set in the tool will help..

5. check if you are over contraining/are giving very agressive slack targets to logic synthesis tools..

6. See if you can flatten some smaller modules where constraints are not set..this helps all optimization commands

7. Some times dont touch/force keep attributes prevents synthesis tools from remapping

8.  Check the library to see if any functionally equivalent cells with smaller area footprint should have been used…for example, if you have hidden a DFFS flop and only DFFRS (set-reset flop) is available, you are adding one more pin and higher cell area to be used..check for these..

9. Often incorrect constraints , it can be synthesis or timing or floorplanning or placement constraints also leads to the problem. If the problem is here, dont expect the tool to override these as its a user issue and the tool tries to honour the constraints

10) If you see too many level of logic, you might want to collapse them .  One more point that pops up in this context is hierarchy maintainence. Check if you can do selective hierarchy maintainence and  if its correctly setup.

11) Check for HFN

12) Check secondary cost function objectives

13) If DFT is already done, check the number of Testpoints (TP) inserted . you might be inserting too  many TP for very small cov gain. You need to consult with your DFT team to quantify how much you can really sacrifice. It varies for every design

14) Check if a particular block/module can be optimized for area while the timing critical part of the ckt can be  optimized for delay.

15)  Majority of the congestion issues can be traced to floorplan.

Things to check at floorplan stage in no specific order:

a) Is the congestion around channels between macros? You might need to resize the channels sothat all macro pins can be accessed by the router.

b)See if you are wasting too much space for channel/island widths etc..you might not need channels all the times..an example could be for CAM’s where a pair macros have to be aligned and you can abut the macro pair on side where there no pins. This will save some space.

c) Check the pin density forthe overall block.

d) Check if there are routes around the macro corners

e) check the average & peak track overflows on each metal layer. This will give you hints what can be the reason.

f) Use blockages cautiously

g) did you set the highest routing layer incorrectly

h) is too much wire causing the issue ?

i) are the endpoints which are connected placed far apart. Need to check why ?

j) is it because of scan chain wirelength? Did the scan optimization happened correctly. Yet times, incorrect scan order constraints prevent the scan chain wirelength optimization.

k) check the scan repartitions (often tools like LV will print what are compatiable grps and so what can  be reordered and optimized)

l) Check if the tool is buffering a lot to fix the timing issues..

m)check to see if the pre-placement of analog blocks etc are in optimal location ?

n)check to see if the floorplan grid is defined and set correctly..If incorrect, you are wasting some routing resources. Setting right and efficient routing constraints are essential to get best routing results .

o) check to see if the MBIST controllers are placed at optimal locations to the memories they control.  Optimal sharing of memories and mode of MBIST sharing  (whether serial/parallel) also pays siginifcant role

p) If the macro placement floorplan provided for MBIST insertion is different  from the actual floorplan you are trying to comeup with, then expect congestion issues as the memories shared are not correct in the revised floorplan. Floorplan changes should be only incremental . This is bit subjective and has to reviewed on case by case basis

q) check the cell density. Are there any decent empty spaces in the floorplan while there are some spaces that are heavily congested. This happens if the tool is trying to squeeze the logic inorder to meeting timing.

r) Check for the overlaps. Is there enough space for all the  macros/std cells to legalize .

s) check your power planning ( power mesh/rail creation)

If you checked all the above and you still cannot resolve, may be you are trying to stuff too much logic and you might need to expand/grow your floorplan. This often involves top level floorplanning changes.

If anyone has any other suggestions/tips for congestion anlaysis , or if you have any ideas or methods on predicting the  congestion itself, I would welcome that feedback as well…