@User, i have committed a beta for p and n MOS transistors accepting 'finger width' instead of 'total width'. These are the new symbols:

sky130_fd_pr/nfet_01v8_lvt_nf.sym
sky130_fd_pr/nfet_01v8_nf.sym
sky130_fd_pr/nfet_03v3_nvt_nf.sym
sky130_fd_pr/nfet_05v0_nvt_nf.sym
sky130_fd_pr/nfet_g5v0d10v5_nf.sym
sky130_fd_pr/nfet_g5v0d16v0_nf.sym
sky130_fd_pr/pfet_01v8_hvt_nf.sym
sky130_fd_pr/pfet_01v8_lvt_nf.sym
sky130_fd_pr/pfet_01v8_nf.sym
sky130_fd_pr/pfet_g5v0d10v5_nf.sym
sky130_fd_pr/pfet_g5v0d16v0_nf.sym

the

_nf

suffix reminds you these are fingered devices and the

W

attribute refers to one finger width, the number of fingers being

nf

. I have added some small graphical 'artwork' to clearly show these are different from the original transistors. Existing designs using the original symbols are unaffected. I am doing some tests to verify everything is working as expected. If you find inconsistencies please report. Do not use for production yet :-)

Great! thank you, @User. I will of course let you know if I find any issues. Cheers

How does this effect LVS? In this netlist, you will have one device that represents several (parallel?) devices in the layout. netgen can reduce parallel devices, but does so by adding individual widths. Currently,

nf

parameters are not compared and possibly unextractable from the layout. @User do you have any thoughts?

I'm assuming that the netlist will look the same and that the new symbols effectively just calculate the W from the schematic's nf and per-finger width values. That correct @User?

Yes, correct. The transistor netlist will have a constant expression for W like:

XM8 net9 G1v8 S B sky130_fd_pr__nfet_01v8_lvt L=0.15 W='0.5 * 2 ' ....

in above example 0.5 is the value assigned to W attribute and 2 is the nf attribute value. Similarly all other calculations for area/perimeter for source/drain terminals are adjusted. Ngspice as well as most other simulators will evaluate these constant expressions at parsing time so there is no simulation speed issue.

@User when cau I expect these to be picked up by open PDKs? For now I've just manually copied them over and they seem to be working well btw!

@User: open_pdks just pulls the git repo for xschem's sky130 setup and libraries. open_pdks now has a

make update

recipe that pulls any new changes from the repositories that it clones automatically.

Ah. Good to know. Thanks Tim

@User: The

make update

assumes that you have run

make

once; part of

make all

is

make prerequisites

which clones the various repositories. If you have not run

make

at all, then all these repositories will clone the most recent version, so there's nothing that

make update

would do. All that

make update

does is that it visits each of those repositories and does a

git pull

. But be aware that it will only do so for repositories that were automatically cloned; that is, repositories which you didn't clone yourself and then reference in the configure script command line (e.g., if you cloned skywater-pdk yourself and did

configure --with-sky130-pdk=/my/own/path

, then you would be responsible for running

git pull

on it yourself whenever you want to update). All these automatically-created repositories are dropped into the

sources

subdirectory in open_pdks. I guess I did not document

make update

if you couldn't find it, so I guess I'll put that on my to-do list.

@User I tired a

make update

having done a

make

as per your instructions, and it appeared to be successful (it certainly took a while). But upon looking in

sources/xschem_sky130

I couldn't find the

_nf

symbols which are present when I manually pull the

xschem_sky130

repo. and looking at the git log in

sources/xschem_sky130

shows:

commit 048c6d64820180073d23110f85641044a0bd9290 (grafted, HEAD -> main, origin/main, origin/HEAD)
Author: Stefan Frederik <stefan.schippers@gmail.com>
Date:   Wed May 26 23:55:01 2021 +0200

    All example test cases changed to use open_pdks installed spice models

Which explains why the symbols are missing. Also, when i ran

./configure

I did it like this:

./configure --enable-sky130-pdk

so I expect it to be doing a pull since I didn't specify an external repo.