Correct PDN config?

[dnltz]

The just recently added I2C GPIO Expander (SG13G2) lacks IOPadIOVdd/Vss cells. Apparently, OpenRAOD didn't complain about the unconnected iovdd/iovss nets and continued. I found my mistake while writing the pin-out documentation.

I added the following two lins to the pdn script

add_global_connection -net {IOVDD} -pin_pattern {^iovdd$} -power
add_global_connection -net {IOVSS} -pin_pattern {^iovss$} -ground

OpenROAD now shows nets for both rails in the IO ring but it still doesn't fail. My questions would be

• Is that a case the tool should not catch because it's just "too stupid" to not add the correct IO cells?
• Am I missing commands in my pdn script to fully connect this rails to pads?

This is the pdn script: https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/designs/ihp-sg13g2/i2c-gpio-expander/pdn.tcl

[rovinski]

add_global_connection is the command that creates the logical connection between the IO terminal and the net. Without it, OpenROAD would have no idea that it's supposed to be connected to that net, logically or physically.

Other tools have connectivity checkers that can sometimes flag suspicious situations like these, but I don't think that functionality exists in OpenROAD.

[dnltz]

okay, this command is part o f the script and runs successfully. It's a pretty stupid mistake. Guess we have to be careful for now.

[maliberty]

Does check_power_grid flag the issue?

[dnltz]

N, it reports no errors but that makes sense because technically the IO nets are connected through the ring. It's missing the information about the source of that net.

[INFO PSM-0040] All shapes on net VSS are connected.
[INFO PSM-0040] All shapes on net IOVSS are connected.

[rovinski]

@maliberty there could be a check like

foreach power/ground net:
  if pad cells exist && power grid exists && no connection between pad cell and power grid:
    warn about no connection

Not sure if it currently has this check, but it sounds like it doesn't. I'm not sure about doing an error over warning because I can imagine some false positives.

[rovinski]

@dnltz I think I've misspoken. I was thinking it was a supply cell to power grid connection issue. It actually appears to be an IO supply net connection issue, which I'm assuming is connected completely by abutment. Technically, the only harm I can imagine in this would be that the CDL netlist generated by OpenROAD for LVS wouldn't be correct (missing those connections)

I think the only mistake here is that you didn't use connect_by_abutment (@gadfort this will create the nets, correct?)

[gadfort]

@rovinski connect_by_abutment will generate a set of nets if not specified by the design. The global connect statements are needed before padring generation for that to work correctly. Since this net doesn't actually generate a grid but is contained fully in the padring, there isn't anything beyond connect_by_abutment that would be needed.

[maliberty]

@gadfort interested to hear your opinion as I believe you rewrote the check as part of your psm work.

[maliberty]

From the nightly CI https://jenkins.openroad.tools/job/OpenROAD-flow-scripts-Nightly-Public/5038/artifact/flow/final_report_i2c-gpio-expander_ihp-sg13g2_base_2025-01-22_20-03.tar.gz

[maliberty]

check_power_grid -net VSS
[INFO PSM-0040] All shapes on net VSS are connected.

but

[gadfort]

@dnltz you are correct in that you are missing IO cells to provide IO power and ground (from what I can tell).
The way PSM works it is looking for breaks in the power grids, so since there is no break there is nothing for it to trigger on. If you had a BPin for the net which wasn't connected to the net it would report an error.
If you have a suggestion as to how to detect this without also triggering on all the ring nets, I'm open to suggestions.

[dnltz]

@gadfort I was hoping there is already a command implemented to check for that issue :)

Would it be possible to check if a power/ground net has a supply somewhere? I don't know how much data we can get into the LEF, etc. files but ideally the IOPadIOVdd has an additional property that tells PSM it's a "power supply" for the iovdd net. If that supply is missing on that net, it's obviously an non-supplied net.

Since quite a lot of IO cells can connect to the internal power ring, I think the same thing could have to the IOPadVdd (core voltage) cell.

[gadfort]

I think it would be relatively easy to add a flag to enforce the presence of a bterm for the net.

[maliberty]

@dnltz do you plan to make a PR for your two line fix?

[dnltz]

Yes, I will change two IO cells and fix the pdn script.