I'm running into an issue where pdngen doesn't seem to follow the FP-PDN-*-HALO options. I also trie...
m
I'm running into an issue where pdngen doesn't seem to follow the FP-PDN-*-HALO options. I also tried disabling FP-PDN-SKIPTRIM but it doesn't seem to change anything.
It seems that in pdn_cfg.tcl, the halo only gets used by this command:
Copy code
define_pdn_grid \
      -macro \
      -default \
      -name macro \
      -starts_with POWER \
      -halo "$::env(FP_PDN_HORIZONTAL_HALO) $::env(FP_PDN_VERTICAL_HALO)"
It seems to be respecting the macro blockages correctly, but it goes right up to the edge so that it cannot route to pins. Perhaps the halo options aren't the right ones to prevent this, but they sure sound like it. Does anyone know how to push these power routes further away from the macro much like the placement halo?
@Matt Liberty do you know who "owns" the PDN stuff?
@donn Do you know who this is?
It seems there are no unit tests of the halo feature.
It looks like there's a better description of the halo that I found, and it may not relate to routing:
|
-halo
| Specifies the default minimum separation of selected macros from other cells in the design. This is only used if the macro does not define halo values in the LEF description. If 1 value is specified it will be used on all 4 sides, if two values are specified, the first will be applied to left/right sides and the second will be applied to top/bottom sides, if 4 values are specified, then they are applied to left, bottom, right and top sides respectively. (Default: 0)
I'm not sure about the "define halo values in the LEF description". LEF doesn't have such a value (but DEF does)
d
If you filed an issue, @Kareem Farid is looking into it. I’m on leave atm.
šŸ‘ 1
m
Looks like this is a recurring issue in OpenLane: https://github.com/The-OpenROAD-Project/OpenLane/issues/640
Looks like @Dinesh A had this issue too
k
To me, the behavior of PDNgen keeps evolving. This might be recurring but depending on the specific case, it might be something different. Best way to proceed is to open an issue and look at the specific case. If there is a need we can request a feature from openroad.
It might be the case too that -ve halo isn't needed anymore and/or stopped working.
I see that there as an issue already. I will take a look.
m
@Kareem Farid I added a self-contained test case. I also added a PR to get test_sram_macro to replicate it.
@Kareem Farid thanks for looking. it seems like a pretty big issue since it would prevent most macros from working. I don't see a general workaround either.
k
Perhaps if the top and bottom pins aren't on layer met4 the error wont trigger
m
It looks like Peter has fixed this
šŸŽ‰ 1
šŸ‘ 1
m
@Matt Liberty when will it be merged? My class needs the fix :)
m
it is merged in OR
OL will have to update to get the fix