The-OpenROAD-Project
VDD/VSS pins on macro not visible at top level
Describe the bug
I'm running the hierarchical flow with a proprietary library. I create a macro by setting SYNTH_HIERARCHICAL=1 after specifying the block-level and top-level grid strategies using PDN script files.
The macro (aes_192) is built successfully, but during the top-level (aes_192_mock_tss) run the VDD and VSS pins (i.e. stripes) on the macro aren't present at the end of stage 2_4_floorplan_tapcell, despite the fact that the corresponding rectangles are present in the LEF file for the macro.
The missing VDD/VSS pins cause the following failure:
Running pdn.tcl, stage 2_5_floorplan_pdn [INFO][FLOW] Using corner FuncRCmin [INFO PDN-0001] Inserting grid: top [INFO PDN-0001] Inserting grid: aes_192_Grid - aes_192_inst [WARNING PDN-0232] aes_192_Grid - aes_192_inst does not contain any shapes or vias. [ERROR PDN-0233] Failed to generate full power grid. Error: pdn.tcl, 6 PDN-0233
Expected Behavior
I would like the top-level power grid to overlay the macro entirely. I don't want a power ring around the macro, rather I just want a grid in the macro and I want the top-level power grid to connect to the macro grid using vias where the stripes overlap. In other words, I'd like to see more or less the same result that's in the mock-array example, but it's not working. Could very well be a set up issue rather than a bug.
Environment
Here's my block-level PDN script:
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDD$} -power
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDPE$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDCE$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDP$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDC$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VNW$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSS$} -ground
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSSE$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSSC$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VPW$}
set_voltage_domain -name {CORE} -power {VDD} -ground {VSS}
define_pdn_grid -name {block} -voltage_domains {CORE}
add_pdn_stripe -grid {block} -layer {M1} -width {0.096} -pitch {1.152} -offset {0} -followpins
add_pdn_stripe -grid {block} -layer {M3} -width {0.308} -spacing {0.332} -pitch {20} -offset {4.8}
add_pdn_stripe -grid {block} -layer {M4} -width {0.308} -spacing {0.332} -pitch {20} -offset {4.8}
add_pdn_connect -grid {block} -layers {M1 M3}
add_pdn_connect -grid {block} -layers {M3 M4}
Here's my top-level PDN script:
source $::env(SCRIPTS_DIR)/util.tcl
####################################
# global connections
####################################
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDD$} -power
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDPE$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDCE$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDP$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VDDC$}
add_global_connection -net {VDD} -inst_pattern {.*} -pin_pattern {^VNW$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSS$} -ground
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSSE$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VSSC$}
add_global_connection -net {VSS} -inst_pattern {.*} -pin_pattern {^VPW$}
####################################
# voltage domains
####################################
set_voltage_domain -name {CORE} -power {VDD} -ground {VSS}
####################################
# standard cell grid
####################################
define_pdn_grid -name {top} -voltage_domains {CORE}
add_pdn_stripe -grid {top} -layer {M1} -width {0.096} -pitch {1.152} -offset {0} -followpins
add_pdn_ring -grid {top} -layers {M5 M6} -widths {0.504 0.544} -spacings {0.140} -core_offset {0.504}
add_pdn_stripe -grid {top} -layer {M5} -width {0.308} -spacing {0.332} -pitch {12.8} -offset {4.8} -extend_to_core_ring
add_pdn_stripe -grid {top} -layer {M6} -width {0.308} -spacing {0.140} -pitch {12.8} -offset {6.4} -extend_to_core_ring
add_pdn_connect -grid {top} -layers {M1 M5}
add_pdn_connect -grid {top} -layers {M1 M6}
add_pdn_connect -grid {top} -layers {M5 M6}
####################################
# Element grid
####################################
# The halo around the macro prevents pdn from blocking pin access
set macro_names {}
foreach macro [find_macros] {
set macro_name [[$macro getMaster] getName]
dict set macro_names $macro_name 1
}
set macro_names [dict keys $macro_names]
define_pdn_grid -macro -cells $macro_names \
-halo "$::env(MACRO_ROWS_HALO_X) $::env(MACRO_ROWS_HALO_Y) $::env(MACRO_ROWS_HALO_X) $::env(MACRO_ROWS_HALO_Y)" \
-voltage_domains {CORE} -name aes_192_Grid
add_pdn_connect -grid {aes_192_Grid} -layers {M5 M6}
In aes_192.lef I see the following:
MACRO aes_192
FOREIGN aes_192 0 0 ;
CLASS BLOCK ;
SIZE 351.847 BY 351.847 ;
PIN VDD
USE POWER ;
DIRECTION INOUT ;
PORT
LAYER M4 ;
RECT 7.302 347.59 347.61 347.898 ;
RECT 7.302 327.59 347.61 327.898 ;
...
RECT 7.302 27.59 347.61 27.898 ;
RECT 7.302 7.59 347.61 7.898 ;
LAYER M3 ;
RECT 347.302 2.832 347.61 349.68 ;
RECT 327.302 2.832 327.61 349.68 ;
RECT 307.302 2.832 307.61 349.68 ;
...
To Reproduce
I didn't include a script at this point because the library is proprietary, and I don't know yet if it's simply a setup issue.
Relevant log output
Screenshots
No response
Additional Context
No response
Without a testcase it's hard to be sure, but it doesn't look like the power pins are getting placed on a layer that can be accessed on the subblock by the top level. It's extremely unlikely that there is not routing on layers above M3 and M4
Ahh, I see what you're saying: The tool doesn't want to put M5/M6 stripes over the macro since there are presumably signal nets on those layers within the macro. Cool, I'll try moving the stripes to higher layers to see if I can get it working.
More generally, can you please clarify the usage model of the "define_pdn_grid -macro" command? Specifically, if the LEF for the macro contains the rectangles for the nets within the macro, why do I need to redefine the PDN for the macro at the top level? I can understand why I'd need to give the tool that information in cases where a power ring is being used around the macro, but if the top-level stripes are overlaying the macro then that define_pdn_grid command seems superfluous. What am I missing?
Lastly, I have the following command for the macro grid which says that M5 stripes should connect to M6 stripes:
add_pdn_connect -grid {aes_192_Grid} -layers {M5 M6}
But should I also have something that tells the tool to connect the top-level stripes to the macro stripes? Or do the earlier commands cover it:
add_pdn_connect -grid {top} -layers {M1 M5}
add_pdn_connect -grid {top} -layers {M1 M6}
add_pdn_connect -grid {top} -layers {M5 M6}
Thanks for your help!
@Cronus-38 you don't have to specify a macro grid (this is required if the macro has specific requirements for the powergrid, which is sometimes needed for memories). If you have a connection from M5 and M6 in the top grid and the straps will satisfy the grid requirements, then you should be able to just be able to do that.
@gadfort I was able to successfully cover the macro with the top-level power straps, but I can't get the tool to make the connections between the straps and the power pins on the macro. I looked at the asap7/mock-array design that comes with the ORFS container, and I see the same problem.
In the first of the following two images you can see I've selected the VDD network at the top-level. In the second image I've selected the VDD network within the macro. Notice the two networks are disjoint. How can I get OR to make the connections? The mock-array build shown was run without any modifications, so you should be able to see the same behavior on your end. Thanks!
@Cronus-38 what does check_power_grid report? It looks like you have vias to the macro.
Hi Peter,
Here you go…
check_power_grid -net VDD [ERROR PSM-0025] VDD does not contain any terminals [ERROR GUI-0070] PSM-0025
Thanks! Cronus
It seems your power grid doesn't have any terminals (ports) which is what it's complaining about
Are you referring to terminals on the macro or terminals on the top-level?
I need to correct what I said earlier.
I see now that if I run check_power_grid after analyze_power_grid then I don't see the message about missing terminals:
set_pdnsim_net_voltage -net VDD -voltage 0.7
analyze_power_grid -net VDD
[INFO PSM-0040] All shapes on net VDD are connected.
[INFO PSM-0073] Using bump pattern with x-pitch 140.0000um, y-pitch 140.0000um, and size 70.0000um with an reduction factor of 3x.
########## IR report #################
Net : VDD
Corner : default
Supply voltage : 7.00e-01 V
Worstcase voltage: 6.39e-01 V
Average voltage : 6.95e-01 V
Average IR drop : 5.23e-03 V
Worstcase IR drop: 6.13e-02 V
Percentage drop : 8.76 %
######################################
check_power_grid -net VDD
[INFO PSM-0040] **All shapes on net VDD are connected.**
1
So, going back to the earlier question, why aren't the top-level straps being connected to the macro VDD/VSS pins? (I confirmed that VDD and VSS on the macro are defined as "PINS" in the LEF (and the LEF is what the top-level build uses to represent the macro).
As mentioned, the behavior I described above can be demonstrated in the mock-array design (with the asap7 library) that ships with ORFS.
@maliberty Do Openroad/ORFS support static IR drop analysis on hierarchical designs? Here's a screenshot of the asap7/mock-array example. Notice that the heat map doesn't extend over the macro instances, presumably due to the connectivity issue I highlighted earlier in this thread.
If IR drop analysis is indeed supported for hierarchical designs, can you please tell me what I need to do to get the mock-array design working?
It does if the liberty model has power information, without that the power is 0 for those instances
-
How do I get the tool to add the necessary power information to the .lib model when it generates the macro in the hierarchical flow? If the tool can't generate this as part of the ORFS flow then I don't think it would be accurate to say that the hierarchical flow supports IR drop analysis.
-
Why doesn't highlighting the top-level power network also highlight the macros' power networks? If they're truly connected then shouldn't they be highlighted together? Is the output of check_power_grid sufficient validation that the top-level and macro-level networks are indeed connected? If so, doesn't this indicate there's a bug in the GUI, since the GUI doesn't show them as connected?