okay to butt MOSCAP against NFET?

[quantized]

My foundry's LVS deck will not recognize an NFET if it shares a source with a MOSCAP. The MOSCAP is recognized by a special layer, and it "kills" recognition of any FET touching any diffusion that intersects that special layer. It doesn't look like this was done deliberately -- butting a MOSCAP against a FET is a somewhat unusual case -- but I can't really be sure.

Is there a reason not to do this?

It's in a really tight part of the layout and not having to put trench isolation in there would sure help.

The DRC deck does not prohibit this. I figured out how to adjust the LVS deck to allow it.

Thanks,

 

[dick_freebird]

You could of course make your own MOSCAP, using a
MOSFET of appropriate doping, and represent it in the
schematic as such. But if your MOSCAP uses a doping
that is unsupported as a plain MOS device (which I have
seen, depletion MOS being unsupported in order to prevent
people from using them as active devices) then you are
going to have to hack rules or eat area.

 

[quantized]

You could of course make your own MOSCAP, using a
MOSFET of appropriate doping, and represent it in the
schematic as such.

That's what I'm doing… but I want the LVS deck to recognize it as a capacitor (SPICE "C") rather than MOSFET (SPICE "M") since HSIM tries to get clever with MOS gate capacitances and in this case I just want a plain old capacitor. Also representing it as a "C" element will let it be absorbed into RC network reduction for quick sanity-checking simulations; I run a few hundred of these every day so it matters. I only do the high-accuracy simulations once a week or so.

But if your MOSCAP uses a doping that is unsupported as a plain MOS device (which I have
seen, depletion MOS being unsupported in order to prevent people from using them as active devices)
then you are going to have to hack rules or eat area.

I don't think the foundry MOSCAPs are doped differently from ordinary transistors. There definitely is no mask corresponding to the capacitor-marker layer (I have the mask list) and the foundry-provided I/O pads involve MOSCAPs with the same doping layers as the transistors.

Note that this is for a stripped-down process option set with only one oxide thickness.

 

[Kevin Aylward]

That's what I'm doing… but I want the LVS deck to recognize it as a capacitor (SPICE "C") rather than MOSFET (SPICE "M") since HSIM tries to get clever with MOS gate capacitances and in this case I just want a plain old capacitor. Also representing it as a "C" element will let it be absorbed into RC network reduction for quick sanity-checking simulations; I run a few hundred of these every day so it matters. I only do the high-accuracy simulations once a week or so.

What CAD kit are you using? In Cadence you can have two views, one with a spice cap, the other containing the moscap, and just do a view switch to the “behavioural” one when simulation speed is required. I don’t see that having LVS faked to report something that isn’t, is an optimum idea.

 

[quantized]

I don’t see that having LVS faked to report something that isn’t, is an optimum idea.

That's exactly why I want to use the "C" model.

The foundry's own SPICE deck for their own I/O pads use "C" elements for MOSCAPs. The capacitor model is more accurate model of a MOSCAP. The foundry runs lots of test wafers with MOSCAPs and measures their capacitance per unit area, so it's very well known and measured, a simple function of the width and length.

On the other hand the implied gate capacitance of a MOSCAP represented as an "M" element is computed from the transistor model parameters which are optimized for accurate modeling of short channel MOSFET behavior under varying source+drain voltages. It's highly unlikely that those models are ideal for a MOSCAP whose source+drain voltage are tied to a power rail and whose length is at least 10 times the minimum gate length. The foundry puts a lot more effort into modeling short-channel devices, so I trust the models a lot less under these unusual conditions. Fortunately I'm just using it as a capacitor, not a transistor, so I don't need a sophisticated model -- just a capacitance value.