pcell generator for Deep Nwell appears to be incorrectly changing any

psubstratediff

and

psubstratecontact

into

nsubstratediff

and

nsubstratecontact

, respectively, if I draw Deep Nwell over it using the pcell generator. I don't think it should be doing that. If you look at the two pictures, one before and one after drawing DNW (yellow dots), the

psubstratediff

(orange/with yellow dots) got changed to

nsubstratediff

(green) and causing DRC errors and likely breaking the circuit. The difference in

psubstratecontact

and

nsubstatecontact

isn't visible as the color scheme for both are same/similar, but I can see the layers changed in Magic. The original

psubstratediff

was added for two inverter cells to form the bulk connection. Also want to mention that it doesn't matter whether I draw

pwell

around

psubstratediff

first before drawing DNW with the pcell generator, as

pwell

gets wiped out by the DNW pcell generator. If I just draw

dnwell

by hand over

psubstratediff

,

psubstratediff

remains and doesn't change. Additionally,

nwell

appears to be getting wiped out as well (visible in picture) at the top of the pmos transistors of the inverter cells. UPDATE: It could be user error on my part. The way to not have the DNW pcell change the existing layout (

psubstratediff

psubstratecontact

pwell

nwell

) is to first draw DNW in an empty area, then transfer the DNW (with its associated nwell guard ring) to the desired location.

@Robin Tsang Glad you found a solution. It may also be possible to use the dnwell pcell generator to create a region in the parent cell and instantiate your cell(s) over that.

@Robin Tsang: Good catch. That's caused by the way that I created the nwell, which was to draw nwell over the whole area and then erase it from the center. It is actually pretty easy to change the routine to draw the nwell in four separate rectangles.

Thanks Tim and Mitch, appreciate it.

@Robin Tsang: This limit is (in theory) enforcing the latchup rule of maximum diffusion to tap spacing of 20um. So the maximum guard ring width and height cannot exceed 40um. The length of 8 at 6 fingers is exceeding 40um in the X direction, so you can't have more ranks in the Y direction than can fit in 40um height. Only something isn't right with the calculation, because you should be able to make M about twice that amount before hitting the limit.

Thanks Tim, makes sense.

What's wrong with the calculation is that I put an arbitrary clearance of 3um to account for the height of the cell, and that's limiting the total number of ranks of devices to something well below what should be the maximum. Ultimately, any violation will be caught by design rules, and although I can reduce the estimated clearance value to something more reasonable like 1um, I think maybe the max limit should produce a warning message instead of trying to force a limit.

Thanks Tim, good idea, I think it’s better to give the user the flexibility as well using a warning instead.

@Tim Edwards, what does it take to update the PDK (native installation from your github repositories)?

@Christoph Maier: I install the PDK by cloning open_pdks myself and building locally. If I use the defaults, then all the repositories get cloned into open_pdks/sources/. If I then do

make update

in open_pdks, it will do a git pull on all those sources, after which I can run another

make; sudo make install

.