@Mitch Bailey@Tim Edwards I was seeing some klayout FEOL drc errors on high voltage FET tip implant (hvntm) layer, generated around high voltage NFETs (nfet_g5v0d10v5), as shown in image below as yellow layers. It's a spacing error

hvntm.1, hvntm.2 - min. hvntm spacing : 0.7um

due to what looks like misaligned hvntm rectangles.. Any tips on how to debug this, since this layer does not show up in magic (corresponding magic layout attached), and so manually trying to draw does not seem to be an option? In the layout below, I have an array of 5v nfets (nfet_g5v0d10v5), each with its own substrate diffusion. The hvntm layer is absent where the p-substrate diffusion is, which makes sense as it's not n-type diffusion. The transistor layout itself is flat and I did not instantiate a pcell. #analog-design

Unless I'm mistaken, that appears to be an error in the klayout DRC deck.

@Tim Edwards The rule looks ok to me. https://skywater-pdk.readthedocs.io/en/main/rules/periphery.html#hvntm The HVNTM layer is generated on cifout.

templayer hvntm_block *mvpsd
        grow 185

 layer HVNTM
        bloat-all mvnfet,mvnfetesd,mvnnfet,nnfet,*mvndiode,mvrdn,*nndiode *mvndiff
        bloat-all mvvaractor *mvnsd
        and-not hvntm_block
        grow 185
        grow    345
        shrink  345
        and-not hvntm_block
        mask-hints HVNTM
        calma 125 20

You can see that HVNTM is not generated symmetrically across the actual gate. It looks to me as if

psdm

and

nsdm

overlap at the lower tap/diffusion boundary. Could that be causing problems?

From the magic layout, the substrate and diffusion are non overlapping, but I do see nsdm/psdm overlap in klayout..

@Tim Edwards Any idea why magic would generate overlapping nsdm/psdm?

@Mitch Bailey: My comment was just based on the fact that the position of the error in klayout appeared to be along the edges of a notch, where the material in yellow is supposedly (?) HVNTM. It's possible that the width of that notch is less than 0.7um, and although if that were true there would be additional corner-to-corner spacing errors, but they might exist and not have been highlighted in the screenshot. If there is an NSDM/PSDM overlap (and it does look like it), then that would also be an error, but not related to HVNTM. @Soumil Jain: Can you please post the layout (.mag file) of that subcell, or at least provide the essential width and spacing measurements so that I can reproduce it? The issue may also be (all or in part) related to hierarchy, and it's possible that flattening some of the hierarchy would resolve the errors. In a pinch, there are ways to manually add to and subtract from implant layers, even though you normally don't see them in the layout.

@Tim Edwards The layout files are attached. The screenshot I posted is of 1T1R_16x16.mag, which instantiates 1T1R_2x2, which further instances 1T1R. In a 1T1R cell, the nfet W/L is 1um/0.5um, n-diffusion dimensions are 1um/0.4um, and the substrate dimension is 1um/0.7um.

No problem, just busy with other things and needed the nudge. So here's the issue, and here's what you can do about it: It's a very magic-specific issue. Magic generates GDS for each cell, and then generates GDS for parent cells. If you get messages about "Parent and child disagree on CIF", you should be concerned enough to check what the issue is. In this case, it's a fatal one. Your array has alternating rows of diffusion and tap, but your base cell has just diffusion on one side and tap on the other. So according to the GDS generation rules, the diffusion and the tap need NSDM and PSDM, respectively, on the sides that are on the edges of the cell. But in the array, those sides aren't empty space; there's more tap and diffusion there. So the generated NSDM and PSDM in the child cell overlap in the array (and the HVNTM layer gets messed up for similar reasons). Solving the issue "the magic way" isn't too hard, but it does require adding some complexity to the array. For starters, the diffusion in the base cell should be done like the screenshot below (upper metal layers not drawn, for clarity). This truncates the tap and places it on both sides, so that in the child cell, the additional PSDM on both sides is still inside the tap when it's in the array. Now, this does add an additional tap on the left side of your array that isn't there in your design. That can be taken care of by creating a special endcap version of the cell, or else you can go with the extra tap on the left (which is probably better for matching, anyway) (also note that the truncated tap generates a minimum tap width DRC error, so you still need an endcap, even if it's just a small piece of tap in each row to satisfy the tap width DRC rule). The main thing is that with the modification, when I do

gds write 1T1R_16x16

, I don't get any of those "parent and child disagree on CIF" error messages, which means that the GDS should be DRC error-free.

Thank you so much! I’ll give these a shot