LUP.WARN.1 DRC violation TSMC 3nm

[Daniel Mog]

I have a placed and routed design in Innovus, from which I extracted an .OAS file - I ran Calibre for DRC and the following violation popped up for std cells as well as filler/dcap cells in my design. At first I though this has something to do with the tap cells, but the description doesn't indicate any issue with them - but rather that there's an issue with the text(?). I would appreciate an explanation for this violation (as well as what the CB, CB2_ALL and UBM_ALL are, what the meaning of the HiR resistor is and how I can deal with these violations):
LUP.WARN.1 { @ Voltage high text or voltage marker layer must exist in CB, CB2_ALL and UBM_ALL in chip level. Connection is broken by HiR resistor.
Exception: 1. SEALRING_ALL 2. Connections with "DUMMY_PAD_TEXT" on the same net, when "DEFINE_PAD_BY_TEXT" is turned on. 3. Connections with "D2D_INT_CDM05V_PAD_TEXT" on the same net, when "DEFINE_PAD_BY_TEXT" is turned on. 4. Connections with "D2D_INT_CDM10V_PAD_TEXT" on the same net, when "DEFINE_PAD_BY_TEXT" is turned on. 5. Connections with "D2D_INT_CDM50V_PAD_TEXT" on the same net, when "DEFINE_PAD_BY_TEXT" is turned on. When turn on option "DEFINE_PAD_BY_TEXT" DRC checks voltage text on power/ground/signal virtual pad in cell level When turn off option "DEFINE_PAD_BY_TEXT" DRC checks all of CB, CB2_ALL and UBM_ALL in chip level
LUP_NW_VOL_WARN NOT NW_PAD_DBT_WAIVE
LUP_RW_VOL_WARN NOT RW_PAD_DBT_WAIVE
LUP_PSD_VOL_WARN NOT PSD_PAD_DBT_WAIVE
LUP_NSD_VOL_WARN NOT NSD_PAD_DBT_WAIVE
LUP_PSTP_VOL_WARN NOT PSTP_PAD_DBT_WAIVE
LUP_NSTP_VOL_WARN NOT NSTP_PAD_DBT_WAIVE
}

 

[dick_freebird]

Looks like "HV" (maybe I/O) transistor used w/o it's proper marker polygon-surround. But you'd think Pcell would be self-DRC-
passing.

One way to get this is to use a LV basic device and put thick ox over it. Then the HV marker has not been put down and the FrankenFET has "nobody pulling for it to succeed".

 

[Daniel Mog]

Looks like "HV" (maybe I/O) transistor used w/o it's proper marker polygon-surround. But you'd think Pcell would be self-DRC-
passing.

One way to get this is to use a LV basic device and put thick ox over it. Then the HV marker has not been put down and the FrankenFET has "nobody pulling for it to succeed".

I'm using TSMC std lib cells (I believe their layers are standardized and shouldn't elicit such DRV, isn't is so?). Is there a way to solve this problem? Do I need to add a marker layer somehow to indicate high voltage to pass this DRC?
What is an HiR resistor in the context of the violation?

 

[dick_freebird]

Aren't markers thrown, that you can display to
find the offenders and interrogate them?

I believe it's possible to "do things" to or above
placed stdcell instances, which will "fool" DRC
into identifying them as high voltage (vanilla logic
always gets the basic layout, with later extensions
getting "marked").

Look at (if you can) the specific rule logic - its
input terms should inform you the layers at play
and look for the one that has no business in a
low voltage logic gate. Process of elimination
may get you there. Or at least narrow the field
for you to go hunting polygons.

Like, somebody could have thrown a "HVmark"
rectangle over the whole chip (like you probably
place "bulk") when it should have been "surgical"
around some pads or something. Be sure to look
down from top level from funky layers, they may
(should) not be in with the logic itself. But maybe
your logic is part of a block with HV content and
got "over-marked" by a layout person who knew
"it's a HV block" and nothing more.

I don't know what a HiR resistor's construction is.
If it's a very shallow very light implant sitting in a
HV well, maybe it's the well than needs marked
and not the resistor body. Or something. There
should be a PDK groundrule document that says
how it should be made; again, turn off every legit
layer for that device and see what's left. Or, when
you went to turn off a layer that should have been
there and no difference, see if that is part of rule
logic (incl precursors).

I don't work with TSMC so specifics, you'll have to
get elsewhere. Stepped in stuff before, though, yeah.

 

[ThisIsNotSam]

Make sure you are doing block level DRC instead of chip level DRC. The violations you mention seem to be related to a seal ring that only exists at chip level.