Extract different devices with a single extractor

mole99

Hello!
I have a rather interesting situation:

sky130 has different simulation models for the standard nmos depending on the width of the transistor.
For a W >= 0.42 this is sky130_fd_pr__nfet_01v8 and for a W < 0.42 it's sky130_fd_pr__special_nfet_01v8.
Currently LVS is set up to simply extract all standard nmos using DeviceExtractorMOS4Transistor as sky130_fd_pr__nfet_01v8.

This means that LVS fails if a sky130_fd_pr__special_nfet_01v8 is used (such as in digital standard cells).

I see three solutions to this problem:

1. Convert back and forth

After reading in the netlist, simply convert all sky130_fd_pr__special_nfet_01v8 to sky130_fd_pr__nfet_01v8.
Before writing the extracted netlist, convert all sky130_fd_pr__nfet_01v8 with W < 0.42 to sky130_fd_pr__special_nfet_01v8.
(I would like to be able to simulate the extracted netlist, thus the conversion back.)

2. Extract the correct device type depending on W

Basically, reimplement DeviceExtractorMOS4Transistor in Ruby and create a sky130_fd_pr__special_nfet_01v8 device if W < 0.42, else sky130_fd_pr__nfet_01v8.

3. Create two new device extractors

SpecialDeviceExtractorMOS4Transistor -> only creates a sky130_fd_pr__special_nfet_01v8 device if W < 0.42
NonSpecialDeviceExtractorMOS4Transistor -> only creates a sky130_fd_pr__nfet_01v8 device if W >= 0.42

---

Option 1 seems to me to be the less clean solution. But option 2 and 3 require to basically reimplement the "extract_devices" function of the DeviceExtractorMOS4Transistor in Ruby. Perhaps there is a simpler/different way of doing this?

Looking forward to any thoughts on this

Matthias

Hi @mole99,

The open Sky130A PDK I have installed using volare, does not have these two kinds. Are you sure the special variant isn't intended for SRAM for example? In that case, maybe there is a marker layer you could use for detecting the different devices.

It is quite common to have different netlists for LVS and simulation. So maybe one option is to prepare a different netlist for LVS. After all, a LVS netlist is only a topology description and basically does not need to be full SPICE.

I think the key issue is that you are trying to use the generated netlist for simulation. What is the reason you want to do that? The extracted netlist has only little additional value. If you want to use AD/AS for example, I'd not trust these values too much. It is not clear how to derive them from fingered devices for example and this feature is a main cause for a number of hierarchy issues.

If you just want to do LVS, I'd propose to use "same_device_classes" to solve this issue:

# extracted: nfet_01v8
# schematic: sky130_fd_pr__nfet_01v8 or sky130_fd_pr__special_nfet_01v8
same_device_classes("nfet_01v8", "sky130_fd_pr__nfet_01v8")
same_device_classes("nfet_01v8", "sky130_fd_pr__special_nfet_01v8")

This should basically work, but I have not tried it.

I you really want to differentiate the devices in the recognition step, you might try to identify the devices with a below-threshold width using DRC functions and separate the classes.

Matthias

dick_freebird

<=0.42 may be a "dogbone" FET (contact plus
oversize AA =0.42 min?). If so then there is a
definite polygon-level "break" in the relation of
as, ad, ps, pd to W.

Now why the extractor couldn't just fork the
geometry math, instead of invoking a whole
'nother model, I couldn't guess. Well, I could
guess that it was a lack of adult supervision
and perspective. But I have also heard that it was
a third party development and a lot of finger
pointing.

Seems I see more complaints about this foundry's
kit than any other. Maybe just because they are
the only open source PDK game in town. But my
glimpse of the content makes me reluctant to
have anything to do with it. Far too fancy for
130nm "mostly digital". And an analog guy would
never use a W<0.42u device as anything but the
world's crappiest resistor.

If you're doing the extractor I'd look first into
the actual differences between the "model guts".
If trivial or minor, can the difference be "passed in"
rather than "invoked" by device master name?
Likewise, just what differs in what's passed,
to each? There's probably a way to make a
conditional feature based on W, that forks a
param-set to the same model and does the
same job.

Do you see anything in the PCell that looks
like it only attends the "special" one? Or is the
"special", just PCell developer laziness around
the dogbone feature, bifurcating that and then
driving all the other aspects toward elaborateness?

mole99

Sorry for my late reply, it seems I didn't get an email notification.

@Matthias The reason for these two different names for the same device lies in the history of the sky130 PDK. First the discrete models were released where the nfet model also covers W < 0.42. At a later time the continuous models were released which are more accurate than the discrete models, but do not cover the same range (at least for the nfet).
That's why a different name was chosen for the nfet with W < 0.42, so that the discrete model can be used (sky130_fd_pr__special_nfet_01v8) and the continuous model is used for W > 0.42 (sky130_fd_pr__nfet_01v8).

Thanks for the hint with same_device_classes, that's a great solution for LVS!

@dick_freebird Thank you for your ideas, but it really is just the same device, a simple nfet. The reason for the different name is because of the different simulation model.
As far as I know, W < 0.42 is only allowed in digital standard cells and is only used in some of them.
Unfortunately, the only difference really is just the width.

I agree, sky130 is a rather peculiar PDK