I am getting LVS errors that I believe have to do with the way I am connecting vssd1 and vccd1 to my SRAM macros. The net mismatch count is always 2x the number of SRAM instances in my design, and a design with 12 SRAMs shows no matching net for

sram.sram_blocks[n].sram1/vssd1

and

sram.sram_blocks[n].sram1/vccd1

for each SRAM. I've routed

vssd1

and

vccd1

to the instances in my verilog source using ``ifdef USE_POWER_PINS` guards and added

_"FP_PDN_MACRO_HOOKS"_: ["sram.sram_blocks.* vccd1 vssd1 vccd1 vssd1"],

to my config.json. Can anyone see what I'm doing wrong with the power nets?

Number of nets: 68707 **Mismatch**         |Number of nets: 68683 **Mismatch**         
Net: sram.sram_blocks\[0\].sram1/vssd1     |(no matching net)                          
Net: sram.sram_blocks\[5\].sram1/vssd1     |(no matching net)                          
Net: sram.sram_blocks\[1\].sram1/vccd1     |(no matching net)                          
Net: soc_6530/HI                           |(no matching net)                          
Net: soc_6528/HI                           |(no matching net)                          
Net: sram.sram_blocks\[11\].sram1/vccd1    |(no matching net)                          
Net: sram.sram_blocks\[11\].sram1/vssd1    |(no matching net)                          
Net: soc_6550/LO                           |(no matching net)                          
Net: sram.sram_blocks\[5\].sram1/vccd1     |(no matching net)                          
Net: soc_6532/HI                           |(no matching net)                          
Net: sram.sram_blocks\[9\].sram1/vssd1     |(no matching net)                          
Net: soc_6525/HI                           |(no matching net)                          
Net: soc_6551/LO                           |(no matching net)                          
Net: sram.sram_blocks\[7\].sram1/vccd1     |(no matching net)                          
Net: sram.sram_blocks\[7\].sram1/vssd1     |(no matching net)                          
Net: sram.sram_blocks\[3\].sram1/vccd1     |(no matching net)                          
Net: sram.sram_blocks\[3\].sram1/vssd1     |(no matching net)                          
Net: soc_6561/LO                           |(no matching net)                          
Net: sram.sram_blocks\[10\].sram1/vccd1    |(no matching net)                          
Net: sram.sram_blocks\[10\].sram1/vssd1    |(no matching net)                          
Net: sram.sram_blocks\[6\].sram1/vccd1     |(no matching net)                          
Net: sram.sram_blocks\[6\].sram1/vssd1     |(no matching net)                          
Net: sram.sram_blocks\[2\].sram1/vccd1     |(no matching net)                          
Net: sram.sram_blocks\[2\].sram1/vssd1     |(no matching net)                          
(no matching net)                          |Net: vccd1                                 
(no matching net)                          |Net: vssd1

@Peter Herrmann The default pdn connection script connects met4 and met5, I believe. What is the top metal on your sram macros? If it’s less than met4, you might need to modify the pdn generator script. For example, if the top macro metal is met3, something like this might work.

[copy] the

$OPENLANE_ROOT/scripts/openroad/common/pdn_cfg.tcl

script [to your] working directory, [add] the line

Copy code

add_pdn_connect -grid macro -layers "met3 met4"

[at the end of the script] to specify that metal 3 was horizontal and metal 4 was vertical, and [point] to that script [in] the

config.json

by

Copy code

"FP_PDN_CFG":"dir::pdn_cfg.tcl"

@Mitch Bailey I believe the top layer is met4:

PIN vccd1
      DIRECTION INOUT ;
      USE POWER ; 
      SHAPE ABUTMENT ; 
      PORT
         LAYER met4 ;
         RECT  4.76 4.76 6.5 411.78 ;
         LAYER met4 ;
         RECT  676.6 4.76 678.34 411.78 ;
         LAYER met3 ;
         RECT  4.76 410.04 678.34 411.78 ;
         LAYER met3 ;
         RECT  4.76 4.76 678.34 6.5 ;
      END
   END vccd1
   PIN vssd1
      DIRECTION INOUT ;
      USE GROUND ; 
      SHAPE ABUTMENT ; 
      PORT
         LAYER met4 ;
         RECT  680.0 1.36 681.74 415.18 ;
         LAYER met4 ;
         RECT  1.36 1.36 3.1 415.18 ;
         LAYER met3 ;
         RECT  1.36 1.36 681.74 3.1 ;
         LAYER met3 ;
         RECT  1.36 413.44 681.74 415.18 ;
      END
   END vssd1

Can you visually verify that the modules are not connected in the layout? Sometimes the extractor doesn’t recognize connections that pass through a virtual hierarchy.

@Mitch Bailey It looks to me like it is genuinely disconnected, but I'm very new to these tools. The contacts for vccd1 and vssd1 for each of the macros don't appear to have anything routed to them (contacts in picture are in the corner of a frame around the macro, none of them appear to be connected)

Can you share your

config.json

file?

Sorry, I thought I had provided all that originally but I hadn't. The config.json is here, and a copy of the whole repo at a state where this issue is reproducible is attached. In the version attached, the SRAMs are instantiated inside a generator block and

config.json

uses a regex wildcard. I thought this might be an issue so I also did a run with the SRAMs instantiated individually with explicit names and listed them all out in `config.json`(as seen below), but the results were identical.

"FP_PDN_MACRO_HOOKS": "sram.sram0 vccd1 vssd1 vccd1 vssd1, sram.sram1 vccd1 vssd1 vccd1 vssd1, sram.sram2 vccd1 vssd1 vccd1 vssd1, sram.sram3 vccd1 vssd1 vccd1 vssd1, sram.sram4 vccd1 vssd1 vccd1 vssd1, sram.sram5 vccd1 vssd1 vccd1 vssd1, sram.sram6 vccd1 vssd1 vccd1 vssd1, sram.sram7 vccd1 vssd1 vccd1 vssd1, sram.sram8 vccd1 vssd1 vccd1 vssd1, sram.sram9 vccd1 vssd1 vccd1 vssd1, sram.sram10 vccd1 vssd1 vccd1 vssd1, sram.sram11 vccd1 vssd1 vccd1 vssd1",

How about setting this in the

config.json

file.

"SYNTH_USE_PG_PINS_DEFINES": "USE_POWER_PINS",

Hey @Mitch Bailey, good call; I tried that and no change

@Peter Herrmann Can I take a look at your

verilog/gl/soc.v

file? Also, there might be a clue in the pdn logs (

find openlane/soc -name '*pdn*'

).

Definitely, thank you for the assistance on this! Looking at the pdn logs, I get many instances of errors like this:

[WARNING PSM-0030] VSRC location at (139.780um, 90.000um) and size 10.000um, is not located on an existing power stripe node. Moving to closest node at (175.440um, 89.760um).

Looking at the layout, the strips seem to stop at the edge of the macro and do not route in:

That looks normal for the vertical met4 power - it normally does not cross the macro. Met5 should be crossing the entire macro horizontally though. That’s where the via4s should drop to the macro met4.

That sounds reasonable to me! I hadn't touched the max routing layer, that was definitely just set to the defaults from the user_proj_example macro. Starting a run with max routing set to met5 (and

SYNTH_BUFFERING

at

1

), will update when that finishes. Thanks!

Now the problem comes when you want to integrate

soc

into

user_project_wrapper

. You’ve already used

met5

. You may want to eliminate the

soc

level by renaming it to

user_project_wrapper

and making sure all the pins are matched to

user_project_wrapper

.

This ended up working, thanks!