I am facing a bug during global placement where it is stuck

[STEP 8]
[INFO]: Running Global Placement (log: ../home/mkhan33/openram_testchip2/openlane/user_project_wrapper/runs/23_09_07_14_35/logs/placement/8-global.log)...

The tool is not even writing to the log file anymore. It is stuck on Iter:350 and not moving forward

@Hadir Khan Just guesses here, but looks like there might be over 15% overflow, possibly meaning that the die area is too small or macros are too close to the border. Are you able to increase the die area and place macros with more space between the macros and more space to the border?

It would be in the original OpenRAM SRAM macro repository.

@Matthew Guthaus d~o you have someone who could check on this message?~

[WARNING STA-0139] /home/mkhan33/openram_testchip2/openlane/user_project_wrapper/../../lib/sky130_sram_2kbyte_1rw_32x512_8_TT_1p8V_25C.lib line 364, 2.39900e3-03 is not a float.

@Mitch Bailey these are the macros after floorplanning. I think there is enough space on the borders?

@Mitch Bailey @Hadir Khan: In reference to the warning message about

sky130_sram_2kbyte_1rw_32x512_8_TT_1p8V_25C.lib

--- There is no such value in the file that comes from the PDK. So this is some local file, and since this is an OpenRAM test chip, then I'm assuming that OpenRAM generated it locally. Meaning that this macro is not the one in the PDK? Is this a repaired or upgraded version of the macro?

@Tim Edwards yeah this is one of the updated lib files with improved characterization and is generated from openram

@Hadir Khan There might be a problem at the bottom if there are a lot of logic analyzer pins. Can you see the congestion map in the openroad gui?

@Mitch Bailey does it create a congestion map during placement? I thought it was created during routing congestion

@Hadir Khan: Then I'm going to assume it's an OpenRAM problem (apparently wrote

e3-03

instead of

e-03

).

@Bugra Onal please check the above float error in the lib file

@Tim Edwards yes, it should be e-03. I had to manually edit that one and made a mistake.

@Hadir Khan try this for viewing flylines.

@Mitch Bailey this is what I get with viewing flylines

@Hadir Khan that’s what I was referring to although it may not be a true congestion map. You can see that there are a large number of nets that are connecting to what I assume are the logic analyzer pins at the bottom. It might work better if there were more room at the bottom and the wider macros were at the top, but that’s just a guess.

Thanks @Mitch Bailey for the valuable feedback! I'll see what I can do. This definitely seems like an hit-and-trial process by changing the positions of macros and seeing what happens

@Hadir Khan IR Drop is the power supply, not congestion.

https://open-source-silicon.slack.com/archives/C0161A4A59V/p1694153125489029?thread_ts=1694133050.043529&cid=C0161A4A59V for flylines to view during placement stage

@Mitch Bailey this is the exact same problem I am facing: https://github.com/The-OpenROAD-Project/OpenLane/issues/1201

@Hadir Khan Their overflow is zero

[NesterovSolve] Iter: 1 overflow: 0 HPWL: 550190766

isn’t yours like 15%?

yes my bad, it is 15%

Even with putting the wide macros at the top and adding more space at the bottom, you’re overflow is still 15%? Does it change if you remove some macros?

I didn't try changing the macro positioning. What I did was to change the "PL_TARGET_DENSITY": 0.25 -> to 0.29. Then it passes through the global placement but gets stuck on the placement resizer optimizations

Are there any pins that are inaccessible on the SRAM macros due to power strap placement? If the power strap is placed over a pin, it may not be able to be routed to.

@Matthew Guthaus I can see pins below metal5 rails

@Hadir Khan those are metal 3 pins, right?

@Mitch Bailey yes

I’m thinking that the met3 could route without interference from the met5. What does the met3 wiring look like there?

@Mitch Bailey even after removing one macro and placing bottom two macros in the middle, the flow is still stuck on global placement and the logs show 10 iter with 16% overflow

Thanks for the feedback @Hadir Khan. Can you try doubling the space between the macros and pins on the left, bottom, top and right and see if that makes any difference?

@Mitch Bailey I tried changing macro placement and removing one and now the flow passes through even after detailed routing. The problem now is I am getting hold violations with the max being around 4.17ns. For each SRAM macro we have a lib file which is read into the flow by setting "STA_MULTICORNER_READ_LIBS": 1. Though this variable is to do sta on different corners but this is the only way of reading multiple lib files of your own macros (told by @Kareem Farid). However, our macros are characterized only at nom process corner. Could this be somehow causing problems with the resizer being stuck?

Can you share a reproducible test case?

Glad to hear your routing finished. I’m sorry, but I don’t know much about timing analysis. Maybe start a new thread.