PDN short circuiting Metal1 in endcap/tbtie cells
Description
We are using OpenROAD (with ORFS) to tape out on a proprietary PDK. The cell library contains endcap, corner and tbtie cells that contain a metal1 ring (that needs to be connected to VSS in our case).
Those cells are placed fine using the tapcell command, but the metal1 PDN stripes generated by add_pdn_stripe -followpins don't take this into account and short onto the metal1.
Is there a way of avoiding skipping the first/last metal1 stripe and trimming the length of the stripes, such that they don't short the metal1 inside this tap cell ring, other than ad hoc patching the PDN generation?
Incidentally, what would be the nicest way to connect a pin in every cell in this ring to VSS, and generate the necessary routing for that?
Suggested Solution
No response
Additional Context
No response
A few pictures would help as I don't understand your description. Normally tapcells/endcaps have power pins in the same location as any other standard cell and follow pins isn't an issue.
Please excuse my "not to scale" sketch to avoid violating any NDAs, hope this still helps.
As well as the standard cell power strips, there is also a "guard ring" that connects a continuous ring of metal1 (pins called DTI in the LEF) around the edge of the core area - this needs to be connected to P-Substate bias e.g. Vss - but at the moment, it's also shorted to the extended Vdd pins.
That's quite odd, if I look at the gf180 endcap I see:
The rails are not going to be shorted due to the gap. Are you saying your endcap cells has a metal strap between the rails?
In the gds for m1:
Nope - the rails inside the cell end well before that Metal1 ring (which is outside the placement boundary of the cell) - it's OpenROAD that's extending the rails such that they short the outer ring.
How did you place cells outside the core area? tapcell will not normally do that.
The core area is defined by the bbox of all the rows in the design. I'm not sure what "placement boundary" is exactly.
@gatecat is there anything he we can resolve or should we just close?
Yes, I think there's still an issue here - as far as cell content ending up outside of the core area, this happens because of negative coordinates in the LEF, even though the placement origin is within the core area. You should be able to see the TBCAPTIE/ENDCAPTIE/CNRCAPTIE cells in the LEF/GDS in our private repo, let me know if you want any other info either here or privately.