Is it possible that in the future, the custom comparison parameters can be added in lvs

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

Sign In or Register to comment.