Many Unconnected Filler/Tap Cells in Design

[b224hisl]

I've encountered an issue. It's a very simple design that includes two GF180 SRAMs. When I run analyze_power_grid, I encounter many instances that are not properly connected to power. Do you know if this relates to my failure to correctly add the PDN with macros? If so, how can I ensure that all these instances are properly powered?

In the GUI, I see that the instances that are reported not connected to power seem to have already made contact with VDD and VSS through -followpins. Could you explain what might be going on?

This is my environment: (/OpenRoad-flow-scripts/tools/OpenROAD# ./etc/Env.sh)
env.txt

To reproduce:
final_report_2small_gf180_10_tsv_2024-11-16_21-11.tar.gz

Here is the report of the unconnected instance ( check_power_grid -net VDD -error_file error.rpt):
error.txt

Thanks very much!

[maliberty]

Can't reproduce

[ERROR ORD-0007] ./results/gf180/2small/10_tsv/6_1_fill.odb does not exist.
[ERROR GUI-0070] Error: final_report.tcl, 4 ORD-0007

btw, this would be better filed as an issue

[b224hisl]

Can't reproduce

[ERROR ORD-0007] ./results/gf180/2small/10_tsv/6_1_fill.odb does not exist.
[ERROR GUI-0070] Error: final_report.tcl, 4 ORD-0007

btw, this would be better filed as an issue

It should be good this time：
final_report_2small_gf180_test_2024-11-17_15-32.tar.gz

[maliberty]

Btw, it is more natural to use

export ADDITIONAL_LEFS += $(MACRO_FOLDER)/gf180mcu_fd_ip_sram__sram64x8m8wm1.lef
export ADDITIONAL_LIBS += $(MACRO_FOLDER)/gf180mcu_fd_ip_sram__sram64x8m8wm1.lib

than

BLOCKS = gf180mcu_fd_ip_sram__sram64x8m8wm1

As I expect you are not building the sram in OR.

[maliberty]

Maybe you did as the VDD pin looks weirdly fragmented:

[b224hisl]

I have included the SRAM block because I have modified the Makefile:

In the GUI, this SRAM block also appears to be fine. This is the Gf180 SRAM

I think the GF180 SRAM has its own power stripes, which I did not place myself.

[maliberty]

@gadfort could you help here? Its a bit odd. There are power pins on m1, eg

The grid seems connected but everything is being flagged by psm:

Is there some assumption in psm about power coming in from above?

[gadfort]

Looking at the LEF, the VDD port is broken into "weakly" connected statements which PSM interprets are requiring the macro to be externally connected (which it is not)

[maliberty]

@b224hisl please include macro.tcl.

I turned off MACRO_PLACEMENT_TCL/BLOCKS, and added ADDITIONAL_LEFS/ADDITIONAL_LIBS in the config.mk. I was able to run the flow and still see a version of the problem with somewhat different macro placement.

[maliberty]

You can see the inputs LEF at designs/gf180/2small/macro/gf180mcu_fd_ip_sram__sram64x8m8wm1.lef

[b224hisl]

@b224hisl please include macro.tcl.

I turned off MACRO_PLACEMENT_TCL/BLOCKS, and added ADDITIONAL_LEFS/ADDITIONAL_LIBS in the config.mk. I was able to run the flow and still see a version of the problem with somewhat different macro placement.
Here is the macro.tcl

set block [ord::get_db_block]
set units [$block getDefUnits]
set vals [list 2 1 95 20 0 116]
lassign $vals rows cols offsetx offsety pitchx pitchy

for {set row 0} {$row < $rows} {incr row} {
    for {set col 0} {$col < $cols} {incr col} {
        set inst [$block findInst [format "genblk_%d_%d_sram_u" $row $col]]
        puts "row=$row,col=$col"
        set x [expr round( ($offsetx + (($pitchx) * $col)) * $units )]
        set y [expr round( ($offsety + (($pitchy + 232) * $row)) * $units )]
        $inst setOrigin $x $y
        puts "x=$x"
        puts "y=$y"
        $inst setPlacementStatus FIRM
    }
}

[b224hisl]

The grid seems connected but everything is being flagged by psm:

The power grid failed to generate (per the logs).

add_pdn_connect -grid {block} -layers {Metal1 Metal4} -max_columns {5} -ongrid {Metal2 Metal3 Metal4} -split_cuts {Metal3 0.128}

changing this to:

add_pdn_connect -grid {block} -layers {Metal1 Metal4}
add_pdn_connect -grid {block} -layers {Metal3 Metal4}

the grid generates a complete grid,

By the way, I would like to ask how I can determine that the PDN grid is fully/completly generated. As shown in this example, I add power stripes in Metal1 and Metal4, why the add_pdn_connect should be applied in {Metal1 Metal4} and {Metal3 Metal4}? I have reviewed the documentation for add_pdn_connect, but I am still unclear on this point.

[maliberty]

@gadfort would a power-ring make this easier?

[maliberty]

Yes around the RAM. Wouldn't you just need to connect the straps to the ring and not all the power pins? Separately you would need stubs to tie the ram pins to the ring.

[maliberty]

There looks to be an internal power ring in the gds

No idea why these are weak connects

[gadfort]

It's how they are expressed in the LEF file (I cannot see the GDS from within PSM).
If the LEF was modified to make 1 PORT with lots of PINs then PSM would not complain since LEF specifies that as strongly connected internally.

[gadfort]

a ring would not be required, but the LEF being wrong doesn't help.

[maliberty]

I don't know what hope there is for a corrected LEF. The blockages are pretty terrible as well.

[maliberty]

I pulled the gds from https://github.com/google/globalfoundries-pdk-ip-gf180mcu_fd_ip_sram

[b224hisl]

OK thank you very much~