Hi @Tim Edwards, i was unable to get the extracted drain/source area, perimeter, width/length to be displayed in microns even after using

units microns

in the extract section. Some help would be greatly appreciated, thank you! the numbers make sense tho they just seem to be in lambdas

I think they are in microns. You are using the default spice3 format (not recommended), so you're getting a

.option scale

line that applies a scalefactor to all dimensions (also not recommended). I suggest always doing

ext2spice lvs

before doing

ext2spice

, since

ext2spice lvs

sets a number of options, including "ngspice" format, and turning off the ".option scale" behavior. (It looks like the source/drain area/perimeter are not correctly output with respect to

.option scale

which is likely an error I introduced when revising the way terminal measurements are output; Since I never use the

.option scale

format, I didn't notice it was wrong.)

I tried with

ext2spice lvs

but the numbers are still the exact same 😞

Probably. The layout is always on a "lambda" grid, and conversion to real units is always relative to the GDS output style (cifoutput). For example, in sky130, I have

scalefactor 10  nanometers

Which means that all units in the

cifoutput

style are given in nanometers, and that the default scaling is 1 magic lambda unit = 10 nanometers. I think this is your underlying problem---that you are setting the scale in the

extract

section, which is needed, but magic still needs to know the relationship between layout and physical units, which has to be set up in the

cifoutput

section.

image.png

Ah. You need

lambda <value>

. If you have 1 lambda = 0.5um then you would need

lambda 0.5

if you're also declaring

units microns

.

all good, I was able to get everything to work by applying

lambda 50

which is still a bit odd cuz the units doesn't line up

Yeah, sorry again, I looked at my example from sky130 and made an assumption about the argument value for

lambda

. I should always go back to the documentation (

lambda

is there, by the way; I think it may unhelpfully be at the bottom of the section. One day I will reorganize that document. . . ).

all good, tysm for your help!

From the maint2.html manual:

Extraction Units

Often the units in the extracted circuit for a cell will always be multiples of certain basic units larger than centimicrons for distance, attofarads for capacitance, or milliohms for resistance. To allow larger units to be used in the .ext file for this technology, thereby reducing the file's size, the extract section may specify a scale for any of the three units, as follows:

    cscale c
    lambda l
    rscale r 

In the above, c is the number of attofarads per unit capacitance appearing in the .ext files, l is the number of centimicrons per unit length, and r is the number of milliohms per unit resistance. All three must be integers; r should divide evenly all the resistance-per-square values specified as part of resist lines, and c should divide evenly all the capacitance-per-unit values.

It is completely unclear from this description that "cscale" and "rscale" are completely arbitrary (the values are written out at some scale, and then picked up at the same scale by ext2spice), but "lambda" is an actual conversion factor, and is always in centimicrons per unit length. And I suppose that to be consistent, "unit length" should depend on whether or not "units microns" is specified, but it doesn't; it's always in centimicrons per default-magic-unit (which is lambda---so "lambda = centimicrons per lambda" which means that the concept of "lambda" has been defined two different ways. Inherited from old code). I'm thinking I should bypass "lambda" and introduce a new keyword "lscale" that both (1) is not lambda, and (2) does actually depend on "units microns" being declared. But that's development work for another day. . .