What layer do I need to make a proper tap for pmos devices in magic? I have imported a design from Cadence Layout XL, but device taps that pass those DRCs have layers are not clean in magic checks. For example, placing pdiff to fix N-tap overlap of N-tap contact < 0.12um (licon.7) results in a "Can't overlap those layers" error. Other commenters have mentioned a "psd" layer, but for some reason I don't have that naming convention, only pdiffusion. A number of other layers have similarly strange names.

@Vladimir Vesely magic uses the concept of planes where on any given plane, you can not overlap shapes. This is why when you draw poly over diffusion (both on the same plane), magic converts the overlap into a fet device. N/P-taps are on different layers than the N/P-diffusion. N/P-taps show as

nsubstratendiff

and

psubstratepdiff

in the layer menu. These may be abbreviated as in many ways in the command window

ppd or ppdiff or psd or psubdiff or psubstratepdiff or ptap
    nnd or nndiff or nsd or nsubdiff or nsubstratendiff or ntap

Try placing

nsd

to fix the N-tap contact overlap.

Thanks, that works for N-taps. For Ptap,

psd

also generates a layer overlap error. I think perhaps a layer here should be removed? However, I can't seem to figure out what layer is already there, even with select area <layer> (tried pdiff and a few others). Any tips for troubleshooting? The N-well error is also rather strange...

@Vladimir Vesely: The names "psd" and "nsd" are a carry-over from the SCMOS technologies that magic was originally written for. The names "ptap" and "ntap" also work, respectively, for these layers, and correspond to Sky130 naming conventions. I should probably re-order the names so that the names "ptap" and "ntap" are the ones reported when queried. Cadence likes to separate contact cuts into their own subcells so that they can be more efficiently arrayed in GDS. That makes it harder for magic to import---a bare contact without any surrounding layers is missing information needed to create the derived layer type that magic uses for the contact. Setting the option

gds flatten true

will help. I think your GDS import is causing the contact and the surrounding diffusion to disagree on whether they both should be a tap layer or not.

Hi Tim, thanks for the explanation. Flattening does not appear to work on the magic side. e.g., exporting heirarchical GDS from cadence then using

gds flatten true

(or

gds flatten 10

, etc) prior to

gds read <cellview>

. However, exporting individual flattened cells from cadence does eliminate a lot of the small drc issues.

psd

and

nsd

must still be added manually to taps. (Pcell flattening seems like it must be done on a cell-by-cell basis)

@Vladimir Vesely before your actual

gds read

statement, you can set multiple

gds flatglob <string>

. This will flatten any cells that match the pattern if all the subcells of that cell are also flattened. For example,

gds flatglob *_CDNS_*

will flatten all cells that contain

_CDNS_

.