https://open-source-silicon.dev logo
Join Slack
Powered by
I’ve done a layout of a circuit, mostly manually, ...
# sky130
v
I’ve done a layout of a circuit, mostly manually, using Magic. When I extracted the circuit and did an ext2spice command, I got a bunch of subckts representing the gates, of course. I believe I can find where those subcircuits are defined. However, I haven’t been able to find the transistor models. Could you please tell me where to find them? Thanks.
t
It depends on where you installed the PDK; but expressing the PDK install location as 
$PDK_ROOT
, then you want to have this in your testbench netlist: 
.lib $PDK_ROOT/sky130A/libs.tech/combined/sky130.lib.spice tt
(newer versions of ngspice will accept the environment variable in the expression; otherwise, substitute the actual path).
v
Thank you so much!! I’m actually reinstalling the whole pdk, as the previous install didn’t complete. I thought a clean install might be a good idea, but we’ll see.
Well, my reinstallation didn’t work. The “make” command finished with some errors, perhaps not fatal, but the “make install” really seemed to not have worked. Here’s the tail end of the output of “make” and the rest of the terminal session: Writing ‘sky130_ef_io__vssd_lvc_clamped_pad’ Writing ‘(UNNAMED)’ Must specify name for cell (UNNAMED). Done. Error message output from magic script: Couldn’t find label VCCD_PAD Can’t write file named ‘(UNNAMED)’ Annotating files in /Users/vkantabu/git_open_pdks/sky130/sky130A/libs.ref/sky130_fd_io/maglef No CDL file contains sky130_fd_io device sky130_fd_io__top_xres4v2 No CDL file contains sky130_fd_io device sky130_ef_io__bare_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_analog_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_gpiovrefv2 No CDL file contains sky130_fd_io device sky130_fd_io__hvclampv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_ground_hvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_power_lvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_esd_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_hvclamp No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vccd_hvc No CDL file contains sky130_fd_io device sky130_fd_io__top_power_hvc_wpadv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_amuxsplitv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssd_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssd_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vccd_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_pwrdetv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vdda_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_ground_lvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_noesd_pad No CDL file contains sky130_fd_io device sky130_fd_io__overlay_gpiov2 No CDL file contains sky130_fd_io device sky130_fd_io__top_gpio_ovtv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssa_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssa_hvc No CDL file contains sky130_fd_io device sky130_fd_io__signal_5_sym_hv_local_5term No CDL file contains sky130_fd_io device sky130_fd_io__top_lvc_b2b No CDL file contains sky130_fd_io device sky130_fd_io__top_sio_macro No CDL file contains sky130_fd_io device sky130_fd_io__top_power_hvc_wpad No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vdda_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vddio_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssio_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_vrefcapv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_gpiov2 No CDL file contains sky130_fd_io device sky130_fd_io__top_lvclamp No CDL file contains sky130_fd_io device sky130_fd_io__corner_bus_overlay No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssio_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vddio_hvc # Add a maskhint set for the GPIO pad .mag view to prevent problems writing # when writing HVI to GDS during hierarchical adjustments. ../common/insert_property.py -std_format /Users/vkantabu/git_open_pdks/sky130/sky130B sky130_fd_io sky130_fd_io__top_gpiov2 \ “MASKHINTS_HVI 1346 17198 5828 19224 13700 1890 15920 2360 24 17522 1778 20612" -mag insert_property.py: source = /Users/vkantabu/git_open_pdks/sky130/sky130B library = sky130_fd_io cell = sky130_fd_io__top_gpiov2 property = MASKHINTS_HVI 1346 17198 5828 19224 13700 1890 15920 2360 24 17522 1778 20612 echo “Ended sky130B PDK staging on “`date` >> sky130B_make.log No CDL file contains sky130_fd_io device sky130_fd_io__top_xres4v2 No CDL file contains sky130_fd_io device sky130_ef_io__bare_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_analog_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_gpiovrefv2 No CDL file contains sky130_fd_io device sky130_fd_io__hvclampv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_ground_hvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_power_lvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_esd_pad No CDL file contains sky130_fd_io device sky130_fd_io__top_hvclamp No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vccd_hvc No CDL file contains sky130_fd_io device sky130_fd_io__top_power_hvc_wpadv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_amuxsplitv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssd_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssd_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vccd_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_pwrdetv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vdda_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_ground_lvc_wpad No CDL file contains sky130_fd_io device sky130_ef_io__analog_noesd_pad No CDL file contains sky130_fd_io device sky130_fd_io__overlay_gpiov2 No CDL file contains sky130_fd_io device sky130_fd_io__top_gpio_ovtv2 No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssa_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssa_hvc No CDL file contains sky130_fd_io device sky130_fd_io__signal_5_sym_hv_local_5term No CDL file contains sky130_fd_io device sky130_fd_io__top_lvc_b2b No CDL file contains sky130_fd_io device sky130_fd_io__top_sio_macro No CDL file contains sky130_fd_io device sky130_fd_io__top_power_hvc_wpad No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vdda_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vddio_lvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssio_lvc No CDL file contains sky130_fd_io device sky130_fd_io__top_vrefcapv2 No CDL file contains sky130_fd_io device sky130_fd_io__top_gpiov2 No CDL file contains sky130_fd_io device sky130_fd_io__top_lvclamp No CDL file contains sky130_fd_io device sky130_fd_io__corner_bus_overlay No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vssio_hvc No CDL file contains sky130_fd_io device sky130_fd_io__overlay_vddio_hvc # Add a maskhint set for the GPIO pad .mag view to prevent problems writing # when writing HVI to GDS during hierarchical adjustments. ../common/insert_property.py -std_format /Users/vkantabu/git_open_pdks/sky130/sky130A sky130_fd_io sky130_fd_io__top_gpiov2 \ “MASKHINTS_HVI 1346 17198 5828 19224 13700 1890 15920 2360 24 17522 1778 20612” -mag insert_property.py: source = /Users/vkantabu/git_open_pdks/sky130/sky130A library = sky130_fd_io cell = sky130_fd_io__top_gpiov2 property = MASKHINTS_HVI 1346 17198 5828 19224 13700 1890 15920 2360 24 17522 1778 20612 echo “Ended sky130A PDK staging on “`date` >> sky130A_make.log Done. vkantabu@Vitits-MacBook-Pro git_open_pdks % sudo make install Password: (cd sky130 && /Library/Developer/CommandLineTools/usr/bin/make install) echo “Starting SKY130 PDK migration on “`date` > sky130A_install.log ../common/staging_install.py -std_format \ -source /Users/vkantabu/git_open_pdks/sky130/sky130A \ -finalpath /home/vkantabu/share/pdk/sky130A \ -variable PDKPATH \ -link_from none 2>&1 | tee -a sky130A_install.log Installing in target directory /home/vkantabu/share/pdk/sky130A Traceback (most recent call last): File “/Users/vkantabu/git_open_pdks/sky130/../common/staging_install.py”, line 439, in <module> os.makedirs(writedir, exist_ok=True) File “<frozen os>“, line 215, in makedirs File “<frozen os>“, line 215, in makedirs File “<frozen os>“, line 215, in makedirs File “<frozen os>“, line 225, in makedirs OSError: [Errno 45] Operation not supported: ‘/home/vkantabu’ make[1]: * [install-A] Error 1 make: * [install-sky130] Error 2
t
I have no idea what that problem is. Sometimes it is difficult to get everything working under Mac OS. I develop on Linux and I don't have a Mac so I depend on other people telling me how to make it work. Maybe you should just try installing with volare? (https://github.com/efabless/volare)
v
Thanks, I’ll try volare. Also, maybe I should just switch to a Linux machine or install Linux on the Mac.
Actually I’m just looking for .model spice cards. Not sure what to do without them. I guess I haven’t learned how to use the pdk.
t
If you're just looking for the SPICE models, then you don't need to install; if you did the build, then the PDK is in the source under 
open_pdks/sky130/sky130A
and you will find the models in 
open_pdks/sky130/sky130A/libs.tech/combined/sky130.lib.spice
, although that's the top level file that includes all sorts of other files; most of the MOSFET models are in 
open_pdks/sky130/sky130A/libs.tech/combined/continuous/models_fet.spice
. But you will find that SkyWater's device models are (unnecessarily) spread over a lot of files and directories.
v
Great, thanks! Then Maybe when I want to do better interconnect simulation, I’ll try again to do the installation. I just had the IT support people reset my Linux/machine machine passwords so I can log on and start using it.
I’m looking for, for example, sky130_fd_pr__nfet_01v8_lvt. The closest match in the file with the models is .model sky130_fd_pr__nfet_20v0_base.0 nmos ………. Is that it? What do the codes fd, pr, 01v8, lvt, 20v0, base.0, mean? Thanks!!
i’m guessing 01v8 means 1.8Volts VDD, but what I found is for 20V! Maybe inappropriate.
By the way, I contacted SKyWater, wanting their datasheet. Their legal department wanted me/my university to sign a non-disclosure agreement. I didn’t think that was a good idea since I might not be able to publish my results freely. So, no datasheet, apparently!
t
The "fd" means "foundry", "pr" means "primitive devices". "01v8" is the nominal maximum gate voltage (1.8V), as is "20v0" (20.0V). "lvt" is "low threshold voltage". "base" just refers to the base model (to differentiate it from the subcircuit model). The ".0" at the end is a bin; transistor characteristics are hard to model over all device sizes, so the parameters are collected into "bins", each of which is valid for a specific range of transistor width and length.
The device 
sky130_fd_pr__nfet_01v8_lvt
is in the file 
models_fet.spice
that I mentioned above, at line 3423.
If you contact SkyWater directly, they will only give you access to their proprietary PDK version (s130). The device information in the open source PDK can be found here: https://skywater-pdk.readthedocs.io/en/main/rules/device-details.html
v
Thank you!!!
The reason I didn’t find the model was because that line says “Msky130….” instead of “.model sky130…“. Is my file corrupted, or is the former shorthand for the latter?
t
Maybe you should review SPICE syntax. "M" is the instantiation of the MOSFET device. This calls the model by name, 
nlowvt_model
. About ten lines below that is the model itself, 
.model nlowvt_model.1 nmos
.
v
I’m well aware of basic spice syntax, but I wasn’t thinking I should be looking for instantiations of a mosfet device, and then the model itself is named differently from the name used in my own layout’s subcircuit file. I mean, why didn’t magic generate mosfets with the model name nlowvt-model?
in general, I don’t understand the organiztion of that file. It would make sense to have a file of all model statements and nothing else.
t
A SPICE circuit netlist should never call the model. It should only call the subcircuit. That is how the PDK is intended to work.
v
i see. I’ll have to think about that one. I guess I’ve used a pdk before, and so I don’t yet understand how one works.
So what’s my workflow now? First a manual layout, then extract, followed by ext2spice, and then I include a file that has the subcircuits representing the standard cells, and then another file with the fet models?
t
The only thing I'd add to that is that you should make your circuit self-contained with a schematic, symbol, and layout with ports. Then have a testbench schematic that instantiates the circuit as a symbol with a "primitive" property. The testbench will contain the statements to include the standard cells and models, and a statement to include the testbench of the circuit. Models should be included from the top using, e.g., 
.lib /path/to/sky130A.lib.spice tt
, with the full path to 
sky130A.lib.spice
in the PDK as the second argument, and the name of the simulation corner as the last argument. To simulate the extracted layout or the schematic-captured circuit, just change the include statement to point to the correct netlist.
v
Thanks!
Tried to answer to your earlier reply, but couldn’t figure out how to do it. What does that tt at the end of the .lib statement mean?
t
tt
is a process corner designation. It means 
typical-typical
. The corner names are defined in 
sky130.lib.spice
. They follow the usual nomenclature for the usual process corners (
tt
, 
ss
, 
ff
).
22 Views
Open in Slack
PreviousNext
Powered by