OpenROAD

OpenROAD copied to clipboard

Truthfully, I'm not 100% sure if this is just a config issue but, for some macros, for reasons I cannot discern, pdngen creates vertical straps that covers the macros, ignoring the halo setting.

• Reproducible: pdngen.tar.gz

Curiously, just a different macro with the same config works fine:

working.tar.gz

fyi @mattvenn

we also saw this issue during mpw4 tapeout

https://skywater-pdk.slack.com/archives/C017HPHCMEY/p1638968541275600

I could never reproduce it till now

The straps are on met4 & met5 and the LEF for rgb_mixer has no OBS above met3 so why shouldn't there be a straps there?

The more interesting question is why aren't the power pins connected. I'll look at the config as I get a chance (just digging out from vacation).

the interesting thing for me is that some designs work and others don't. I didn't pickup on the OBS - what adds that in the flow/config?

but this is interesting. A more complex/dense design will use met4, and the met4 obs layer will get generated.

quite hard to see, but there are some 'via like' things on met4

that are on the met5, but they drop down to nothing on the macro.

another interesting thing is that the macro definitely has met4 power stripes

but then the lef doesn't put obs for met4. so maybe it's related to that.

The reported problem of "pdngen creates vertical straps that covers the macros, ignoring the halo setting" is not an issue. I don't think extra OBS are needed.

The real issue is that the macro power pins are dangling.

@VidyaChhabria check_power_grid should be reporting an error on this design but doesn't.

@donn - concerning the original issue you raised: Straps are placed over the stdcell rows. For this testcase the stdcell rows are continuous across the entire design, hence the straps are across the entire design. In order to prevent this, the rows should be cut such that they do not overlap with the macro placements.

@maliberty - the connectivity issue you're seeing needs a little more explanation:

Comments on the testcase data:

• There is no connectivity specified for the vccd1/vssd1 pins on the rgb_mixer in the testcase.
• There are 2 add_global_connect commands. One connects VPWR and VPB pins to vccd1, one connects VGND and VNB pins to vssd1. But since the rgb_mixer block has pins vccd1 and vssd1 for power and ground, these have not been connected.
• Specifying power_pins and ground_pins as part of the macro definition merely serves to identify which pins are power and ground types [pdn now uses signalType information in the db to identify power and ground pins, so this is only necessary if the LEF being used does not have the correct USE definitions].
• The out.def supplied in the testcase creates a physical connection between the met4 pins of the macro and the met5 strap

I expect/assume that in the version of openroad used to create out.def of the testcase, pdn connects macro pins specified by power_pins in the macro definition to the POWER net being added by pdn. From a physical connectivity point of view, I believe this is the desired outcome in this case. However, I would argue that this behaviour is incorrect, since it does not take into account the logical connectivity when making this connection. This results in out.def which has inconsistent logical/physical netlist connections.

The pdn code has been updated since that snapshot

The latest pdn code looks at the database to determine which nets these pins are connected to in order to determine whether a connection needs to be made or not. In this case, the pins are not connected to any net, so no connections are made to the macro. This is consistent in that the physical connectivity matches the logical connectivity

After creating the logical connection between the vccd1 pins on rgb_mixer and the vccd1 net, the physical connection is made by pdn, once again resulting in a consistent DEF file, with matching logical and physical connectivity.

I was able to verify this by adding the logical connection into in.def

SPECIALNETS 2 ;
  - vccd1 ( rgb_mixer vccd1 ) + USE POWER ;
  - vssd1 ( rgb_mixer vssd1 ) + USE GROUND ;
END SPECIALNETS

I could also have used the following TCL commands:

add_global_connection -net vccd1 -inst_pattern rgb_mixer -pin_pattern vccd1
add_global_connection -net vssd1 -inst_pattern rgb_mixer -pin_pattern vssd1

@Colin-Holehouse The working example also has rows across the whole thing. Except the difference is the straps stop just fine there.

@donn The macro rgb_mixer instantiated by pdngen.tar.gz has blockages up to met3, whereas the macro wrapped_rgb_mixer instantiated by working.tar.gz has blockages up to met4. The fact that there are any blockages on met4 causes the macro halo to be used to cut the met4 stdcell grid lines. I can modify the code to also check the layers used by pins to determine which layers to cut - is this a change that you would like to see implemented?

but then the lef doesn't put obs for met4. so maybe it's related to that.

I think the LEF file is created in magic by openlane, using lef write -hide https://github.com/The-OpenROAD-Project/OpenLane/blob/master/scripts/magic/lef.tcl

From magic: Option -hide generates an abstract view that has all interior detail removed, leaving only pins and obstruction layers covering the entire cell with cut-out areas for the pins I think as rgb_mixer only has PINS on met4 it doesn't created the OBS

I can modify the code to also check the layers used by pins to determine which layers to cut - is this a change that you would like to see implemented?

A bit magical for my taste, pun not intended. @mattvenn Thoughts? Could you try to reharden with a met4 obstruction?

I don't see any OR issue to fix here. Is there any reason to keep this open?

@maliberty @Colin-Holehouse Maybe add a warning for if pins are found? Don't auto-avoid, just add a warning.

still hitting this on mpw-6c (edited - used to say mpw-5c)

maybe it will go away with the new pdn in OR, but for now this is still an issue for certain sized macros

changing size 300x300 to 100x250 made the pdn bug go away

@mattvenn if there is a pdn bug we should fix it. Does the problem still occur with the new pdn (with or without resizing)?

How would I know if I was using the new pdn? this is tested on mpw-6c (sorry my comment above was wrong when I said mpw-5c).

How would I know if I was using the new pdn? this is tested on mpw-6c (sorry my comment above was wrong when I said mpw-5c).

It was turned on in commit 0c611a3422f0a9691c10776f951efd32887e85e5. If you see the use of -secondary_power in scripts/openroad/pdn.cfg then you are on the new one.

then the answer is no

@mattvenn any problems with the old pdngen should be retried with the new. If the new one has issues then file a bug report.

Apart from the non reported error, what is the fix?

On Mon, 14 Mar 2022, 18:45 Matt Liberty, @.***> wrote:

@VidyaChhabria https://github.com/VidyaChhabria check_power_grid should be reporting an error on this design but doesn't.

— Reply to this email directly, view it on GitHub https://github.com/The-OpenROAD-Project/OpenROAD/issues/1692#issuecomment-1067111147, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE223FJPYCUWJ6CT2YN3ATU753M5ANCNFSM5QU62NQA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

This issue is quite old. Has anyone tried this with the current OR and the rewritten pdngen?

haven't seen this recently, so probably safe to close.