DRC Validation cells errata

[RTimothyEdwards]

@KrzysztofHerman , @sergeiandreyev , et al.,
Here's a list of things I came across while working on the tech file for magic for IHP s13g2. It is just a dump of things I found, mostly minor, and I have not looked through the issues list to see if any of them have already been reported.

In the DRC validation GDS library:

1. The "ActivFiller" cell has text "PASS ... PASS" instead of "PASS ... FAIL"
2. The "TopMet2Filler" cell has text "TM1" on all the rule numbers.
3. The Thick Oxide devices in the "thickgateox" cell fail the minimum gate length rule.
4. The same problem with (3) above is also in the "gatpoly" cell for rule Gat.a3 and Gat.a4. The error shows up on the "pass" side, so the validation cells seem to assume that minimum gate length for a thick oxide device is 0.33um, which is in direct contravention to the documentation, which says that a thick gate oxide device minimum length is 0.4um for pFETs and 0.45um for nFETs.
5. Additionally, layouts for rules Gat.a2 and Gat.a4 show transistors formed from poly on P+ diffusion not in nwell; this forms a p-type varactor device, but no model exists in the PDK for such a device.
6. Layouts for rules Gat.c and Gat.d appear to be incorrectly using GatPoly.filler instead of GatPoly. The combination of GatPoly.filler over Activ (non-filler) should not be legal.
7. The "passiv" cell shows passivation over both metal7 and over metal6. The metal6 use case is not documented in the SG13G2_os_layout_rules.pdf file. I do not know if this use case is valid.
8. There is no layout for pSD rules, which is a large set of needed validation examples.

Documentation (SG13G2_os_layout_rules.pdf):

1. The Rsil.d rule illustration is wrong in SG13G2_os_layout_rules.pdf; the rule specifies distance from pSD to GatPoly but the dimension illustrated is pSD to EXTblock.

In the sg13g2_pr.gds library:

1. There is no marker layer for PNP. This makes it impossible for a tool to distinguish it as a device as opposed to just a piece of diffusion surrounded by a double guard ring.
2. The p-diode (dpantenna) has no nwell drawn underneath, which makes it, as drawn, a substrate tap and not a diode.

In the standard cell library:

1. Cell "sg13g2_a21o_1" has been incorrectly named "sg13gs_a21o_1" ("gs" instead of "g2") in the GDS. <--- (Edit: This has to be something I did; I don't remember doing anything with this cell but I must have copied it with a typo because it showed up in my cell list. Sorry for the false positive.)

[sergeiandreyev]

Hi @RTimothyEdwards, thank you for detailed analysis and reporting!
I'll start from the end :)
Std cells:

• could you please tell us how you're checking the cell list in GDS? opening the sg13g2_stdcells.gds in KLayout GUI I do not see any naming mismatch
  

Primitive library:

• pnpMPA recognition: we have this implemented in KLayout LVS deck (as I understand), maybe @atorkmabrains or @FaragElsayed2 can give a hint on how they made it working w/o marker layer
• the dpantenna Pycell device was updated some time ago to include NWell
  
  we need to regenerate the sg13g2_pr GDS to make it consistent (thanks for finding!)

Docs:

• yes, it should be fixed - I'll forward the issue to our responsible team member

For the other questions, I'll come back later after internal review

[RTimothyEdwards]

@sergeiandreyev : Sorry about the false positive with the standard cell name; I must have manually copied the cell with a typo although I don't remember doing anything with that cell. Anyway, it is not repeatable and clearly not a problem and I should have done a bit more due diligence before reporting it.

[RTimothyEdwards]

@sergeiandreyev : Looking at the klayout extraction deck, it appears that a PNP is identified as an area inside a p-type guard ring (ptap) that literally isn't everything that is not a bipolar (i.e., "bjt_exclude" = poly + pwell + nSD + salicide block + ext block + diode ID + resistor ID + inductor ID + substrate ID). It seems both over-complicated and non-robust to identify a PNP transistor as "not (everything that is not a PNP transistor)".

(So I suppose I have to rescind my comment that it is "impossible" to differentiate the PNP from other devices. It is possible. It just isn't straightforward.)

[atorkmabrains]

@RTimothyEdwards I respectfully disagree with you about the PNP exclude conclusion here. There is a reason we follow such exclusion it's important for proper functionality and proper identification of devices.

[RTimothyEdwards]

@atorkmabrains : I don't intend to get into a flame war here, but under what circumstance is it not simpler / more efficient / cleaner / more robust simply to draw TRANS over top a PNP device and declare that an NPN device = (TRANS containing low- or high-voltage emitter window) and a PNP device = (TRANS not containing emitter window)? Or equivalently, just define an additional GDS layer called PNPTRANS which identifies a PNP transistor?

[atorkmabrains]

@sergeiandreyev I believe the suggestion above by @RTimothyEdwards is for you not for us. We follow your lead on this. I believe I mentioned something similar at the very beginning of the project about marker layers and truth table.

@sergeiandreyev Do you want to proceed with @RTimothyEdwards suggestion?

[sergeiandreyev]

unfortunately, we have to discuss this internally as always for such questions (the consistency with the proprietary PDK is an important topic)
one thing to note is that we're now reimplementing the pnpMPA device (model updates, etc.), so this is a good timing to discuss possible improvements in the device layout / extraction as well

[sergeiandreyev]

@atorkmabrains : I don't intend to get into a flame war here, but under what circumstance is it not simpler / more efficient / cleaner / more robust simply to draw TRANS over top a PNP device and declare that an NPN device = (TRANS containing low- or high-voltage emitter window) and a PNP device = (TRANS not containing emitter window)? Or equivalently, just define an additional GDS layer called PNPTRANS which identifies a PNP transistor?

yes, this is a question to our internal PDK

[sergeiandreyev]

Hi @RTimothyEdwards, most of the items from the DRC validation list should be fixed with the latest commit, could you please double check on your side?
for the bullet 7. - we don't have metal6 and metal7 in technology and in passiv QA cell as well, do you mean Top metals?

[RTimothyEdwards]

@sergeiandreyev : Yes, I mean the top metals (I've mapped them to names "metal6" and "metal7" in the magic tech file).

[RTimothyEdwards]

@sergeiandreyev : After pulling your updates from this morning, I find that my item number 5

Additionally, layouts for rules Gat.a2 and Gat.a4 show transistors formed from poly on P+ diffusion not in nwell; this forms a p-type varactor device, but no model exists in the PDK for such a device.

is still showing as an issue in the DRC pass/fail layout for GatPoly.

[sergeiandreyev]

on this one - we have SVaricap (essentially a varactor) device that is planned to be added to the OpenPDK, along with the other currently missing devices
unfortunately, cannot provide a timeline for this

[RTimothyEdwards]

@sergeiandreyev : I am currently preparing to have magic extract devices such as SVaricap as a subcircuit of the same name; however, it will remain unsimulatable until a device model exists, and it will not be added to the device generator in magic until rules exist for the device geometry. On the other hand, ESD FET devices in scr1 and nmoscl_2, and nmoscl_4 are currently being extracted as MOSFETs without regard to the difference in modeling caused by the unsalicided source/drain regions. If specific models for these devices are added to the PDK, then it is easy enough to change the name of the device being extracted from magic.

[sergeiandreyev]

added also @prabhatdubey92 to this issue, he's working on SVaricap model support

[sergeiandreyev]

@sergeiandreyev : Yes, I mean the top metals (I've mapped them to names "metal6" and "metal7" in the magic tech file).

I think the TopMetal1 and TopMetal2 use cases are described in Pad Dimensions section, in the Passiv section indeed we have only this:

I'll double check with the document owner

[RTimothyEdwards]

@sergeiandreyev : Specifically, rule Pad.i: dfpad without TopMetal2 not allowed appears to invalidate all of the layouts in the QA "passiv" layout in which the passivation cut is placed over TopMetal1 without the presence of TopMetal2.