Folks, A problem with schematic entry netlisting has come to our attention from a designer doing work on a VCO. The problem description is related to schematic entry, the netlisting, modelling of the fingered fet structure SGDGS vs 2x SGD. Does anybody in the community have a handy example of how these are entered in schematic, (How they are indicating which terminal is inside and which outside) How they netlist and how the results come out in capacitance for the D and S terminal versus the layouts?xx Thanks in advance, Andy

I have additional questions for anybody who might know the answer or be able to point me in the right direction: (1) In BSIM models, what is the relationship between the S/D area/perimeter parameters (AD, AS, PD, PS) and the fingered device stress parameters (SA, SB, SD)? From what I can tell, the stress parameters don't affect source/drain capacitance, and (AD, AS, PD, PS) don't affect stress, but they measure similar dimensions and it is easy to make them mutually incompatible. I rarely see (SA, SB, SD) used. How much effect do they have on simulation? (2) What does (AD, AS, PD, PS) mean for a fingered device; is this the total area and perimeter or the area and perimeter per finger? (3) Are (AD, AS, PD, PS) used for anything else besides capactitance calculation? If stress parameters are not used, how much difference is there between a simulation a a fingered device of NF fingers and an equivelent set of M non-fingered devices, if the S/D areas and perimeters are all specified such that they arrive at the same totals in both cases?

As far as I know, there LVS can not tell the difference between the two configurations. For simulation, there might be a difference. For a total W/L of

1u/0.5u

, in xschem, you’d enter the SGDGS as

nf=2 mult=1 W=1 L=0.5

. The 2x SGD would be

nf=1 mult=2 W=0.5 L=0.5

. The xcshem model has the following calculations.

ad="'int((nf+1)/2) * W/nf * 0.29'" 
pd="'2*int((nf+1)/2) * (W/nf + 0.29)'"
as="'int((nf+2)/2) * W/nf * 0.29'" 
ps="'2*int((nf+2)/2) * (W/nf + 0.29)'"
nrd="'0.29 / W'" nrs="'0.29 / W'"

For SGDGS,

ad=int(3/2)*1/2*0.29=1*0.5*0.29=0.145
pd=2*int(3/2)*(1/2+0.29)=2*1*0.79=1.58
as=int(4/2)*1/2*0.29=2*0.5*0.29=0.29
ps=2*int(4/2)*(1/2+0.29)=2*2*0.79=3.16
nrd=0.29/1=0.29
nrs=0.29/1=0.29

For 2x SGD, the values for 1 transistor are

ad=int(2/2)*0.5/1*0.29=1*0.5*0.29=0.145
pd=2*int(2/2)*(0.5/1+0.29)=2*1*0.79=1.58
as=int(3/2)*0.5/1*0.29=1*0.5*0.29=0.145
ps=2*int(3/2)*(0.5/1+0.29)=2*1*0.79=1.58
nrd=0.29/1=0.29
nrs=0.29/1=0.29

Since mult=2, these values are effectively doubled.

ad=0.29 double SGDGS
pd=3.16 double SGDGS
as=0.29 same as SGDGS
ps=3.16 same as SGDGS

which is what is expected, I think.

These issues, plus others, mean that for RF, dedicated device layout templates and models are often created. As a circuit designer, you can only work with these templates (usually means fixed W, L, and NF per transistor block). The modeling can then be very precise. However, these templates often have significant area overhead (plus they are like they are, no possibility to tweak), so in some RF cases people tend to go back to the non-RF models.

@Tim Edwards currently AD/AS/PD/PS in xschem are estimated as total drain / source areas / perimeters. The calculation is done considering the number of fingers (nf) and the finger width (=total W / nf). The assumption for even (nf=2, 4, ...) number of fingers is that source terminal takes the outer diffusions. For example in a 2 finger MOS the configuration is S-G-D-G-S. Source contacts take 2 diffusions, drain contact takes the center diffusion. This explains the

int( (nf + 1) / 2)

and

int( (nf + 2) / 2)

expressions in the xschem calculations for drain and source parameters respectively. Needless to say these calculations are bare estimations considering minimum design rules. Custom layouts may have completely different difusion shapes and areas/perimeters. You can always override xschem expressions by giving actual numbers for AD/AS/PD/PS instance attributes.

@Stefan Schippers: That's actually pretty sophisticated. I had not noticed the

int()

corrections in the expressions.

Thanks everybody for the quick responses. That was super helpful.