It looks like you're new here. If you want to get involved, click one of these buttons!
KLayout's LVS functionality is fantastic, with a wealth of extensibility, and I've done quite a bit of experimentation with it since its inception, and there's no doubt that it's a great piece of work.
I tried to use custom parameter extraction and parameter comparison, and after I extracted the calculated parameters I assigned values to the params inside the DeviceClass _via the _set_parameter _method.
However, this custom parameter has certain limitations, it must be defined in advance in klayout source code, for example in _dbNetlistDeviceClasses.cc
But for some cases, these parameters are also not sufficient.
For example, for a non-quadrilateral bjt, as shown below, the area is not an important parameter when designing the library file, its area is not intuitive to the designer, and such a bjt is usually defined by the length of the emitter.
So the calculation of L is based on the empirical formula:
So if I want to verify this bjt I have to extract its L, and store this parameter internally for comparison.
But it is not supported now, is it possible that such a feature will be supported in future versions?
Comments
If you are using, and others will be using a PCell for this
device, then building in "recognition features" is a way to
get at this easily. And if you make the features a polygon
(or a text) then they can ride along in the GDSII.
For example "back in the day" I worked in a lot of bipolar
technologies and my CAD group put "length" and "width"
(which I believe are in the base Cadence layers set) rectangles
on critical features, built from PCell input args. From $LE we
got a "length" rectangle with length set to LE and width to 1,
placed inside the emitter diffusion; likewise for WE. One for
collector sinker length (other degrees of freedom subsumed
in WE, w/ groundrule-min nestings from there).
So at extract time, getting the area was a simple Boolean from
the recognized device tub (done by getTexted() on the isolation
layer) and the diffusion nesting logic (emitter = N+ AND Pbase
AND Ntub, collector = N+ ANDNOT Pbase AND Ntub,
LEext=length AND emitter, WEext=width AND emitter, ...).
The only weakness lies in other people going "off road" and
making device layouts which omit the tags. Og go and mung
the tags on a "0-x" flattened device layout. Which is on them,
according to me. If you decide that either everything will be done
from PCells, or that everyone who makes custom devices by
hand owns the outcome, it's all good.
I've occasionally pestered Matthias about this approach but
so far I've just stuck with plain layouts and hand checks.
I'm keen to collect examples that work, for recognizing devices
by "planted text AND boolean" and for extracting feature values
likewise. I'm working in a technology that has taken a different
approach and don't like the proliferation of recognition-layer-
per-device (while still needing to measure "stuff", which means
ortho layout style pretty much?) - expecially now that I am fixing
to make device types they never imagined, but have discovered
through reverse engineering, and the kit (as it were) was last
touched a decade ago by somebody long gone). If I'm a-gonna
do significant work, I'll be doing it (or hiring it done) my way.
So plow my road, why don'cha?
Well, I personally also favour the "correct by design" approach that @dick_freebird mentions.
If you need to support special devices you can basically implement an entirely custom extractor. It's a little tedious as you have to provide Spice I/O code etc., but it gives you full freedom.
I have provided some sample code for a talk I gave on the FSiC2022 here: https://gitlab.com/klayoutmatthias/fsic-2022-demo-files/-/tree/main/klayout-talk/lvs/custom_device. It implements an extractor for a MOS capacitor.
If you look at "defs.rb" you will find the device definitions, "spice.rb" provides Spice I/O (all devices need to be added there). "lvs.lylvs" is a sample LVS script and there is some sample layout too.
Maybe that helps.
Matthias