https://open-source-silicon.dev logo
Join Slack
Powered by
I have a question about generating the power grid ...
# openlane
a
I have a question about generating the power grid through openlane. I have to bring in analog blackboxes that use mimcaps through m3-m5 so I can't have the PDN grid cover the entire chip. I tried metal obstructions but since the PDN gets generated first, I am trying to keep the grid out of the analog area with halos: 
set ::env(FP_PDN_HORIZONTAL_HALO) 420
set ::env(FP_PDN_VERTICAL_HALO) 420
But I am not quite sure how this works...the horizontal power straps persist. Is there to disable both horizontal and vertical stripes in the halo area?
🌍 1
m
Are you bringing this in as a LEF macro?
a
For the six macros placed above, they were just brought in as hardened digital macros using their lef/gds. I was going to repeat this for analog cells (not imported in this figure, but I was just going to use a blackbox verilog along with lef/gds exported from magic)
m
if they are macros then pdngen should respect their OBS
in the LEF
a
Ah ok I’ll try adding the analog ones first then!
Hi @Matt Liberty, would I need to manually set an OBS within my analog macro's LEF (filter_p_m.lef)? If I import our analog block ("filter_p_m") as a blackbox'd macro (config.tcl), I end up with routing congestion (11-resizer.log)
Copy code
[ERROR GRT-0118] Routing congestion too high. Check the congestion heatmap in the GUI.
Error: resizer_routing_timing.tcl, 53 GRT-0118
Once I pull up lef/def for this step, I see that the PDN is entering the analog macro. The issue there is we have mimcaps using m3/m4/m5 in the analog...and having the PDN overlap these mimcaps shorts our supplies (screenshots). I also tried GRT_OBS to block out the all metals from where the analog blocks would come in, but the horizontal PDN stripes still tend to come in over GRT_OBS. Is there a way for us to keep out PDN stripes from specified sections of our chip?
Hi @Matt Liberty, quick update: I was able to add OBS layers to our analog layout in magic and export these to LEF, which I then ran through through openlane's flow to integrate with the 
caravel_user_project_wrapper
. The OBS is now successful in keeping PDN m4/m5 outside of our analog (mim caps), but now we see congestion errors on step#11 (global routing resizer timing optimizations). I am in the process of setting up the OpenROAD GUI to understand the root cause here, but I suspect it is from having m4/m5 OBS layers overlapping with the m4/m5 in the macro itself (from the caps) -- trying to confirm.
Copy code
[STEP 11]
[INFO]: Running Global Routing Resizer Timing Optimizations (log: ../fossi_cochlea/openlane/user_project_wrapper/runs/22_09_17_18_37/logs/routing/11-resizer.log)...
[ERROR]: during executing openroad script /openlane/scripts/openroad/resizer_routing_timing.tcl
[ERROR]: Log: ../fossi_cochlea/openlane/user_project_wrapper/runs/22_09_17_18_37/logs/routing/11-resizer.log
[ERROR]: Last 10 lines:

[INFO GRT-0101] Running extra iterations to remove overflow.
[INFO GRT-0197] Via related to pin nodes: 182
[INFO GRT-0198] Via related Steiner nodes: 0
[INFO GRT-0199] Via filling finished.
[INFO GRT-0111] Final number of vias: 380
[INFO GRT-0112] Final usage 3D: 15409
[ERROR GRT-0118] Routing congestion too high. Check the congestion heatmap in the GUI.
Error: resizer_routing_timing.tcl, 53 GRT-0118
child process exited abnormally
Any other debug ideas you could think of would be appreciated!
m
Sorry to be slow but I was out of town. Are you pins for external connection on the edges of your block?
a
I will have to interface the analog core’s pins from the pad frame as well as pins on the hardened digital macro.
m
I'm not sure what that means as I know little of your block. I am wondering if you are trying to force the router to reach pins inside an OBS
a
Oh I see — I think that’s right! I'll fix that, and bring the pins outside the OBS!
But my OBS is only on m4/m5…would that cause a problem too? I was assuming that the pins inside the OBS could be routed using lower metals.
m
I would have to see the pins to really understand. However I think it is best to route them out to the edges if possible
👍 1
you can open an issue with a test case if you think this should be routable
a
Thank you @Matt Liberty, I incorporated your suggestion and moved analog ports to the edges. While doing this, I brought the ports to where they could interconnect with the digital macros as needed, but that seems to be giving congestion errors. I have opened an issue here: https://github.com/The-OpenROAD-Project/OpenLane/issues/1375 (I suspect that the congestion issue may also have something to do with my updating to openlane's latest image as of today...with older openlane I suspect I didn't get congestion errors but something would still tank at the LVS stage) For tackling the PDNgen's entering into the analog macro's area, I tried combining all of the analog cells into one giant macro. That somehow took out most of the PDN -- except some lines still surface in multiple parts across this large macro. I have included screenshots of this behavior with the above issue as well. I took out the OBS layers I had painted with magic as I wasn't sure if they would generate conflicts with having M4/M5 already painted on top.
m
I'll take a look tomorrow
33 Views
Open in Slack
PreviousNext
Powered by