This question follows from one in the sky130 channel about proximity effects being modelled in SKY130. Basically investigating how well LOD is modelled. Does anyone know if MAGIC can extract the sa/sb parameters used to model LOD? If not then it would seem this effect will not be present in post layout sims. @Tim Edwards: Have you worked with these parameters in MAGIC in the past? Thanks

I have not, although I understand the basic issues. Magic was formerly unable to distinguish where sources or drains were shared between devices and so inherently unable to extract these parameters. I solved the underlying issue of being able to identify shared diffusion areas, but it is still the case that Magic only extracts individual devices and does not automatically detect fingered devices, which it only does in a rather ad hoc way during

ext2spice

where it no longer has direct information about the geometry of the layout. So there are still some problems to solve before I can get magic to extract SA/SB.

@Diarmuid Collins Such advanced analog modeling is not available at all in Open source tools. It’s not that it hard to support it. But no body cared to have that level of support in Open source tools. I have to admit you are the first one to ask such questions.

I see. Good to know the limitations we are working with here as it enables me to account for them. E.g. in this case, not modelling LOD wont be a major issue provided I keep ~ 5um from the diffusion edge. I thought SKY130 was just ported across from S130 so whatever was modeled in S130 would be included in SKY130. I guess this is a rather naive way of thinking of things since the toolset is different ... S130 is set up for commercial tools while SKY130 is set up for open source tools. Good to clear that up. Txs

Magic will automatically output it as 10 individual devices (by default). Depending on the option used, it can output it as one device with M=10. Netgen will pass this in LVS based on its rules for matching. Netgen always combines devices in parallel, so to netgen, topologically, the

m=1/nf=10

and

m=10/nf=1

are both a single device and only differ by property. With the current netgen setup for sky130,

nf

is ignored as a parameter, but

W

for BSIM devices is the total width for all fingers, so effectively this is, for, say, W=1, a property difference of

m=1/w=10

and

m=10/w=1

. The netgen setup for sky130 will consider this a property error on the first pass, but it is allowed to combine widths for devices in parallel, so in the end it will report it as an LVS match.

Klayout could detect fingered devices but will sum them up.

Thanks @Tim Edwards. So it is important I understand exactly what you are saying so have illustrated my interpretation, attached. E.g. m = 2 => Magic will output this as 2 individual devices as per Fig.1. It is still possible to abut them as per Fig.2 right? Depending on the option used, Magic can also output as a single device, as per Fig.3? Then with netgen - it ignores nf and looks at W instead. So a device of m=1/nf=2 has W = 2um while one with m=2/nf=1 has W = 2*1um which netgen then combines in paralell to give W = 2um. End result being no LVS error between a device in schematic with m=1/nf=2 and its layout representation as m=2/nf=1. If this is a correct interpretation it is not an issue as I see the same thing in commercial EDA tools. E.g. My layouter gives me back a layout where the n/m's are different from what I had in the schematic but which is passing LVS.

(1) Yes, this will be two individual devices in the netlist from magic (either two separate entries, or one entry with M=2 if the devices are really in parallel and the "ext2spice merge conservative" option is used). (2) Yes, you may abut those devices and the only thing that will change in the magic output is that the drain area and perimeter will be divided by 2 and half assigned to each device. (3) The S|D|S configuration will always be two devices in magic output (two entries or one entry with M=2; see (1) above). (4) Likewise, figure 3 is output as two devices if there is a physical separation between the two sources and between the two drains. (5) FYI, there is another option "ext2spice merge aggressive" which will add up the widths of devices in parallel and output them as a single device of M=1. I do not recommend using that, since altering the device width alters the simulation behavior much more significantly than changing the number of fingers vs. the number of devices. (6) Yes, netgen (at least with the provided setup for sky130 and its associated rules for device series and parallel merging) will match devices according to total width and does not concern itself with whether the devices are fingered or have independent drains and sources.

Thanks @Tim Edwards. That clears everything up for me. Cheers.

@Diarmuid Collins and @Tim Edwards

@Andrew Wright: Certainly would be good to have these edge effects modeled. From @Tim Edwards response it seems it is a limitation with Magic so I guess only one tool would need enhancement (possible Netgen also). Tim is the expert here so could answer in better detail.