OpenROAD icon indicating copy to clipboard operation
OpenROAD copied to clipboard

PDN short circuiting Metal1 in endcap/tbtie cells

Open gatecat opened this issue 1 year ago • 9 comments

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

gatecat avatar Mar 26 '24 15:03 gatecat

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.

maliberty avatar Mar 26 '24 15:03 maliberty

Please excuse my "not to scale" sketch to avoid violating any NDAs, hope this still helps.

image

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.

gatecat avatar Mar 26 '24 16:03 gatecat

That's quite odd, if I look at the gf180 endcap I see:

image

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?

maliberty avatar Mar 26 '24 20:03 maliberty

In the gds for m1: image

maliberty avatar Mar 26 '24 20:03 maliberty

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.

gatecat avatar Mar 27 '24 06:03 gatecat

How did you place cells outside the core area? tapcell will not normally do that.

maliberty avatar Mar 27 '24 15:03 maliberty

The core area is defined by the bbox of all the rows in the design. I'm not sure what "placement boundary" is exactly.

maliberty avatar Mar 27 '24 15:03 maliberty

@gatecat is there anything he we can resolve or should we just close?

maliberty avatar May 21 '24 22:05 maliberty

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.

gatecat avatar May 22 '24 08:05 gatecat