https://open-source-silicon.dev
Join Slack
Menu
Home
Archive
hey, i'm running into a `[ERROR PSM-0042] Unable to connect macro/pad Instance manchester_baby to th...
# gf180mcu
k
hey, i'm running into a 
[ERROR PSM-0042] Unable to connect macro/pad Instance manchester_baby to the power grid.
error, which i'm struggling to solve i have 
"SYNTH_USE_PG_PINS_DEFINES": "USE_POWER_PINS"
in my 
manchester-baby/config.json
and in 
lincoln_gfmpw/config.json
(which is basically my version of the user_proj_example) both of the .v source files for those modules are using the ``ifdef USE_POWER_PINS` header, and i can see that they are present in the gate-level versions of the verilog source, but for some reason it just isn't connecting it. interestingly you can see a gap in the openroad gui where it didn't bother. i've attached my issue_reproducible if anyone is able to help, thank you :)
issue_reproducible.zip
m
If you are using hard macros, you probably need to define
Copy code
"FP_PDN_MACRO_HOOKS": [ "instance1 vccd1 vssd1 vccd1 vssd1,",
        "instance2 vccd1 vssd1 vccd1 vssd1" ]
This connects the parent power nets to the macro power ports. Be warned that the pdn router connects the top level metal to one level lower in the macro. If the macro has top level vertical metal4 power rails, the parent metal5 horizontal rails will connect. As in your diagram, I don’t think vertical metal4 will connect to parent vertical metal4. Be aware that using nested macros means that the routing layers will be limited. Top: routes with metal5 • Child macro: top routing layer metal4 ◦ Grandchild macro: top routing layer metal3
k
okay i see what you mean so lets say my hard macro 
manchester_baby
that is instantiated within 
lincoln_gfmpw
would need the 
"RT_MAX_LAYER": "Metal3"
set in 
manchester-baby/config.json
when hardening it? as for your 
FP_PDN_MACRO_HOOKS
example, i'm assuming this would go inside 
lincoln_gfmpw/config.json
?
m
as for your 
FP_PDN_MACRO_HOOKS
example, i’m assuming this would go inside 
lincoln_gfmpw/config.json
?
correct.
k
i tried rehardening the macro with 
"RT_MAX_LAYER": "Metal3"
and it still fails on the PSM-0042 error if i add in 
"FP_PDN_MACRO_HOOKS":  "manchester_baby vdd vss vdd vss,"
it fails with the following:
Copy code
[INFO PDN-0001] Inserting grid: stdcell_grid
[INFO PDN-0001] Inserting grid: macro - manchester_baby
[WARNING PDN-0232] macro - manchester_baby does not contain any shapes or vias.
[ERROR PDN-0233] Failed to generate full power grid.
m
Can you share your config and verilog files? You have a lef file for 
manchester_baby
that has the shapes defined and that’s referenced in your config file, right?
k
yeah, i've got 
manchester_baby.lef
defined in 
EXTRA_LEFS
in 
lincoln_gfmpw/config.json
, and it is present in the 
lef/
folder the project is available here: https://github.com/diy-ic/lincoln-gfmpw/tree/dev (dev branch) also thank you for helping, i appreciate it
m
I get a 404 with that link. Maybe it’s a private repo.
k
my bad, just changed the visiblity
👍 1
m
I’m thinking that syntactically, you might need a 
,
after the 
.vss(vss)
(x2) in 
verilog/rtl/lincoln_gfmpw.v
Copy code
`ifdef USER_POWER_PINS
            .vdd(vdd), .vss(vss)
        `endif
Could that be causing problems?
k
ah possibly, though it didn't fail linting when doing 
make lincoln_gfmpw
i shall fix that and see if it is happy
no luck, still failing on 
WARNING PDN-0232] macro - manchester_baby does not contain any shapes or vias.
m
So 
lincoln_gfmpw
corresponds to 
user_proj_example
and you’re going to have one more hierarchy above that, correct? If so that means that the top routing layer in 
lincoln_gfmpw
will be metal4 and the max metal layer you should use in 
manchester
and 
ram
would be metal3. Currently, the lef has metal4 for 
manchester
and 
ram
power. However, I don’t think that would give the missing 
shapes or vias
message. Can you share you full log?
k
yes, so it should be 
user_project_wrapper -> lincoln_gfmpw -> manchester_baby (+ other designs)
i had set 
"RT_MAX_LAYER": "Metal3"
in 
manchester-baby/config.json
and ran 
make manchester-baby
, so i would've thought that would update the lef file... perhaps i should try deleting and re-running to make sure it creates the correct layers i deleted the files, rehardened the macro and still ran into the same error (i realise i didn't update the submodule on github, so i'll do that right now. might need to switch to the gfmpw branch in the manchester-baby repo to see it.)
7-pdn.log7-pdn.errors7-pdn.warnings
m
I would also expect running openlane on 
manchester-baby
to update the lef file. Can you check the lef files to ensure that they have no metal4 references? The 
manchester-baby
macro looks to be relatively small. Can you check that it will intersect with the power rails at the current position?
k
strange, i'm finding 3 references to Metal4 in the lef file after re-rehardening - does the order in the config.json file matter? i had set 
"DIE_AREA": "0 0 210 210"
in the config.json too, since i saw some warnings about the PDN being resized, so i think it should intersect with the rails on 
lincoln_gfmpw
this is where Metal4 is referenced:
Copy code
PIN vdd
    DIRECTION INOUT ;
    USE POWER ;
    PORT
      LAYER Metal4 ;
        RECT 22.240 15.380 23.840 192.380 ;
    END
    PORT
      LAYER Metal4 ;
        RECT 175.840 15.380 177.440 192.380 ;
    END
  END vdd
  PIN vss
    DIRECTION INOUT ;
    USE GROUND ;
    PORT
      LAYER Metal4 ;
        RECT 99.040 15.380 100.640 192.380 ;
    END
  END vss
this is the current 
manchester-baby/config.json
:
Copy code
{
    "PDK": "gf180mcuD",
	"STD_CELL_LIBRARY": "gf180mcu_fd_sc_mcu7t5v0",
    "DESIGN_NAME": "manchester_baby",
    "VERILOG_FILES": [list of files],
    "CLOCK_PORT": "clock",
    "CLOCK_PERIOD": "24.0",
    "SYNTH_USE_PG_PINS_DEFINES": "USE_POWER_PINS",
    "DESIGN_IS_CORE": 0,
    "FP_SIZING": "absolute",
    "DIE_AREA": "0 0 210 210",

    "RT_MAX_LAYER": "Metal3",
    "VDD_NETS": [
        "vdd"
    ],
    "GND_NETS": [
        "vss"
    ]
}
could the 
VDD/GND_NETS
be causing this?
m
For the all the actual values that openlane uses, look at 
runs/<tag>/config.tcl
. Maybe there’s a power routing layer that default that needs to be overridden.
k
there's a couple references to Metal4 inside 
manchester-baby/runs/<tag>/config.tcl
, i've attached it
config.tcl
there's 
set ::env(CLOCK_WIRE_RC_LAYER) "Metal4"
and 
set ::env(FP_PDN_VERTICAL_LAYER) "Metal4"
which seem weird, especially with 
"RT_MAX_LAYER": "Metal3"
set
m
I agree that it does seem weird, but maybe it’s trying to get one PDN layer and chooses the lowest. Can you try adding
Copy code
"FP_PDN_HORIZONTAL_LAYER": "Metal3",
to your 
config.json
file for 
manchester_baby
? The ram implementation maybe troublesome, though. Are you generating your own ram or using a macro?
k
rehardened with 
"FP_PDN_HORIZONTAL_LAYER": "Metal3",
, ran 
make lincoln_gfmpw
, but still failing on PDN-0232 i realise the ram implementation is a slight gamble, i saw that openRAM doesn't support gf180 yet and the provided macros are only 8-bits wide, but i need 32-bits since that's how the manchester baby was historically made. the implementation is in 
openlane/ram_5x32
and it seems to harden just fine so far
m
Yes, but the ram lef also uses metal4. Does the new 
manchester_baby
lef file have any metal4?
k
yeah that's fine for now, once the manchester baby stops failing on PDN-0232 then the fix can be applied for the ram too and yes, the lef still contains references to Metal4, exactly the same as last time
m
Is the 
runs/<tag>/config.tcl
the same for 
manchester_baby
? Maybe set the 
FP_PDN_VERTICAL_LAYER
to metal2. There is another possible (maybe better) solution and that is to flatten 
lincoln_gfmpw
in 
user_project_wrapper
instead of creating it as a hard macro. There was a webinar the other day about the advantages and disadvantages of each approach.
If you need 32 bits, you could use 4 srams with 8bits each.
k
yeah it seems like config.tcl is the same, still have 
set ::env(FP_PDN_VERTICAL_LAYER) "Metal4"
and 
set ::env(CLOCK_WIRE_RC_LAYER) "Metal4"
on the most recent run going to comment out the 
"FP_PDN_HORIZONTAL_LAYER": "Metal3",
and add in 
"FP_PDN_VERTICAL_LAYER": "Metal2",
seems like it would probably be easier to flatten it/instanciate it in lincoln_gfmpw, may have to try that tomorrow any idea how much space would those srams take up? i've got 2 other designs that i need to squeeze on there
m
Copy code
gf180mcu_fd_ip_sram__sram128x8m8wm1.lef:MACRO gf180mcu_fd_ip_sram__sram128x8m8wm1
gf180mcu_fd_ip_sram__sram128x8m8wm1.lef:  SIZE 431.86 BY 268.88 ;
gf180mcu_fd_ip_sram__sram256x8m8wm1.lef:MACRO gf180mcu_fd_ip_sram__sram256x8m8wm1
gf180mcu_fd_ip_sram__sram256x8m8wm1.lef:  SIZE 431.86 BY 340.88 ;
gf180mcu_fd_ip_sram__sram512x8m8wm1.lef:MACRO gf180mcu_fd_ip_sram__sram512x8m8wm1
gf180mcu_fd_ip_sram__sram512x8m8wm1.lef:  SIZE 431.86 BY 484.88 ;
gf180mcu_fd_ip_sram__sram64x8m8wm1.lef:MACRO gf180mcu_fd_ip_sram__sram64x8m8wm1
gf180mcu_fd_ip_sram__sram64x8m8wm1.lef:  SIZE 431.86 BY 232.88 ;
I wasn’t suggesting flattening 
manchester
, but rather flattening 
lincoln
. The problem with using hard macros in 
user_project_wrapper
is that there is no buffering on the signals to fix timing problems. You need to be aware of the timing requirements for the macros. It’s discussed a little more in the webinar.
k
may be doable, if i understand correctly it'll take up 1727.44 x 232.88 so that should fit on the long edge on the project area. not sure if it would be happy with the timing though also it seems like it's stuck on running detailed routing with the vertical layer set to 2, so i'll try 3 and see what it does ah i see, i'll check out the webinar then and see if i can integrate it - do you know of any tutorial that shows how to flatten it?
oh if i set 
"FP_PDN_VERTICAL_LAYER": "Metal3",
then it fails with:
Copy code
[ERROR]: Last 10 lines:
[INFO]: Setting input delay to: 4.800000000000001
[INFO]: Setting load to: 0.07291
[INFO]: Setting clock uncertainty to: 0.25
[INFO]: Setting clock transition to: 0.15
[INFO]: Setting timing derate to: 5.0 %
[INFO PDN-0001] Inserting grid: stdcell_grid
[WARNING PDN-0178] Remaining channel (6.7200, 15.3800) - (203.2800, 192.3800) on Metal1 for nets: vdd, vss
[ERROR PDN-0179] Unable to repair all channels.
PDN-0179
maybe its time to call it for today :(
m
Sorry, I don’t know of tutorial offhand. Basically, what you do is remove 
lincoln
from the 
VERILOG_BLACK_BOX
list and change most of the other config parameters to match 
user_proj_example
(enable standard cells, etc).
Vertical layers should be even (2, 4) and horizontal layers should be odd (1, 3, 5).
k
ah okay, i'll give that a go tomorrow and see what happens and i had no idea, explains why it failed then. not really sure what's going wrong with this to be honest
i've given up trying to do the macros, kept running into a variety of issues. i'm having much better luck with simply instantiating them inside user_proj_example and then only hardening that before making the user_project_wrapper somewhat unfortunate, and it's probably my fault somewhere in the configuration but i'm actually getting a gds file out now. guess we'll see if it's functional when i try to do gl tests on it
👍 1
122 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