I'm trying to get magic to read a spice netlist and create the cells. It works for transistors, but not for resistors. Magic's error message is "Cell sky130_fd_pr__res_high_po couldn't be read". What devices does Magic support?

@Matt Venn just curious. Do fixed width resistor models work? For example,

sky130_fd_pr__res_high_po_0p35 L=1 multi=1 m=1

How do you manage to get a

res_high_po

without the width suffix? There should only be five resistor types available, in each of the five available widths.

There is a generic schematic symbol for res_high_po.

$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po.sym

in addition to

$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po_0p35.sym
$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po_0p69.sym
$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po_1p41.sym
$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po_2p85.sym
$PDK_ROOT/$PDK/libs.tech/xschem/sky130_fd_pr/res_high_po_5p73.sym

@Mitch Bailey: Thanks. @Matt Venn: I don't support the "generic" resistor type in the device generator for magic. I can probably add it without too much trouble; the five specific types are just limiting cases. Meanwhile, just choose a symbol for one of the five specific types in xschem.

I just selected this one

@Matt Venn the

0p35

in the model name refers to the width which is fixed for the model. The length is variable and specified by the

l

parameter. Looks like you originally selected the generic model, which Tim says does not have a device generator in magic. Not sure why the simulation’s failing. You’ve included the model file, right?

I copied the xschemrc from the pdk tech directory, so I'm assuming it knows where the models are

If you’re trying to simulate from xschem, I think you have to include the libraries in the schematic. @Stefan Schippers?

@Matt Venn @Mitch Bailey you need to have in the .spice netlist a .lib line as shown:

.lib /path/to/pdk/sky130A/libs.tech/combined/sky130.lib.spice tt

and a .spiceinit file in the directory where ngspice is running containing the following lines:

set ngbehavior=hsa
set ng_nomodcheck

I usually place a code.sym element with the following attribute:

thanks Stefan

@Matt Venn when xschem starts it reads the xschemrc file. in this file some checks are done to see if an env var

PDK_ROOT

and

PDK

are defined. If they are not defined some basic search is done to find a pdk in

/usr/share/pdk

/usr/local/share/pdk

or

~/share/pdk

. For sky130 if no

PDK

process variant env var is defined

sky130A

is assumed. If a pdk is found it is used and a tcl variable

PDK_ROOT

(/path/to/share/pdk) and

PDK

(sky130A) is set accordingly (as well as

SKYWATER_MODELS

=

${PDK_ROOT}/${PDK}/libs.tech/combined

). If your PDK installation is not in one of the above standard places just set

PDK_ROOT

and `PDK`:

export PDK_ROOT=/path/to/share/pdk
export PDK=sky130A

before launching xschem. After starting xschem tou can test if

SKYWATER_MODELS

was set correctly:

puts $SKYWATER_MODELS

Also ensure in the

code.sym

the following is set:

format="tcleval( @value )"
value=".lib $::SKYWATER_MODELS/sky130.lib.spice tt"

The first line ensures the second line will be passed to tcl for variable substitution. Of course putting the actual path instead of a variable does not require this tcleval() and you can remove the format= line altogether. fore code.sym normally the

value

attribute will be copied verbatim to the netlist. However ngspice does not underdstand variables, so xschem does the substitution before generating the netlist (the

value

attribute will be passed to tcl and the resulting calculated path will be written in the netlist). This manual page explains the open_pdks integration.

Ah, the tcleval( @value ) is what I was missing