https://open-source-silicon.dev
Join Slack
I am facing a bug during global placement where it is stuck ```[STEP 8] [INFO]: Running Global Place...
# openlane
h
I am facing a bug during global placement where it is stuck
Copy code
[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
does it mean the tool is not able to find a solution for another iteration? I’ve seen it remove overflows after 400+ iterations with a different design
m
@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?
@Tim Edwards the log file also had this error when reading the sta library.
Copy code
[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.
Is that something on the openram side or caused during the open_pdk make?
t
It would be in the original OpenRAM SRAM macro repository.
👍 1
m
@Matthew Guthaus d~o you have someone who could check on this message?~
Copy code
[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.
h
@Mitch Bailey these are the macros after floorplanning. I think there is enough space on the borders?
I increased the placement density and it went ahead but is now stuck at step 10: Running Placement Resizer Design Optimizations What is weird and never happened before is the tool just not responding or outputting anything on the log file after being stuck. It's just there running and consuming RAM but showing no output on the log files to debug what's happening
t
@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?
h
@Tim Edwards yeah this is one of the updated lib files with improved characterization and is generated from openram
m
@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?
h
@Mitch Bailey does it create a congestion map during placement? I thought it was created during routing congestion
t
@Hadir Khan: Then I'm going to assume it's an OpenRAM problem (apparently wrote 
e3-03
instead of 
e-03
).
m
@Bugra Onal please check the above float error in the lib file
@Hadir Khan yes, congestion is created during placement and can be viewed in the GUI
b
@Tim Edwards yes, it should be e-03. I had to manually edit that one and made a mistake.
m
@Hadir Khan try this for viewing flylines.
h
@Mitch Bailey this is what I get with viewing flylines
This is equivalent to a congestion? As in, it is showing where it wants to connect nets?
I am not able to see the heatmap. It says: "Heat map "IR Drop" has not been populated with data."
m
@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.
h
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
👍 1
m
@Hadir Khan IR Drop is the power supply, not congestion.
v
h
@Mitch Bailey this is the exact same problem I am facing: https://github.com/The-OpenROAD-Project/OpenLane/issues/1201
I'll try what they suggest, to not provide extra libs however that does not sound like a good solution
m
@Hadir Khan Their overflow is zero
Copy code
[NesterovSolve] Iter: 1 overflow: 0 HPWL: 550190766
isn’t yours like 15%?
h
yes my bad, it is 15%
m
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?
h
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
which could be potentially due to the same reason as above?
m
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.
You should look manually at the pins and ensure they are accessible.
h
@Matthew Guthaus I can see pins below metal5 rails
m
@Hadir Khan those are metal 3 pins, right?
h
@Mitch Bailey yes
m
I’m thinking that the met3 could route without interference from the met5. What does the met3 wiring look like there?
h
@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
m
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?
h
@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?
Because at this stage where the flow is completing without any violations, if I enable either the placement resizer or router resizer it gets stuck at the overflow
For improving hold violations I did this:
Copy code
"PL_RESIZER_ALLOW_SETUP_VIOS": 1,
    "GLB_RESIZER_ALLOW_SETUP_VIOS": 1,
    "PL_RESIZER_HOLD_MAX_BUFFER_PERCENT": 90,
    "GLB_RESIZER_HOLD_MAX_BUFFER_PERCENT": 90,
but it didn't make any improvements to the hold time slack
v
Can you share a reproducible test case?
m
Glad to hear your routing finished. I’m sorry, but I don’t know much about timing analysis. Maybe start a new thread.
7 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by