it seems that there is some DRC rule with the overlap of the cap contacts with the other cap layer? So the capacitor layers themselves can overlap, but the vias for the capacitors can not overlap the other capacitor type? So the picture in the PDK info is wrong?

I was also having trouble stacking the MiM caps due to DRC errors. I'm currently just using a single layer, but would definitely like to use both layers if possible.

I have a very vexing LVS issue I can not resolve despite a lot of manual checking. is it possible that a submodule that passes LVS itself can cause LVS to fail once included? I know that LVS will not catch things like you flipping the + and - pins of an opamp.

I'm running into an issue with netgen that I've now stared at for several hours. I have a layout and a schematic which match cleanly in terms of nets and devices, but for which netgen yields property errors for one of the devices. In particular, both my layout netlist and schematic netlist have exactly 3 dummy devices with all four terminals tied to VDD (can ctrl-F to verify), two of width 8um and one of width 6um. Netgen complains about a property error for one of these devices. However, when I explicitly change my schematic netlist such that all three devices are of width 8um, netgen yields no property errors and a perfectly clean result, despite the fact that one of the layout dummy devices has width 6um. How is this possible? I've attached both SPICE files and the comp.out file in the comments. Changing M55 in the schematic netlist to have a width of 8um instead of 6um yields no property errors despite the clear netlist difference.

I see three inductors (coil1, coil2 and coil3) provided in sky130_fd_pr cells. However, I am not able to find its spice models or inductance values.

I'm probably missing something obvious, but I installed open_pdks and I don't see any explanation of how to tell the tools about it? Looking to get started with klayout or magic. Trying to source the magicrc give file not found errors, I assume it needs som env variable. In klayout I cna open the lyp and lydrc file, but no clue about lyt. Does klayout have pcells? Else probably easier to start with magic to get familiar with the cells.

@User @User: Stacking MiM cap contacts and passing to Calibre passes all DRC checks, so it is clearly not a violation according to Calibre. I'll review the documentation again, and how the Calibre rule is written, and remove the restriction from the magic techfile.

Relatively minor error, but I am getting LVS property errors for sky130_fd_pr__res_high_po_1p410 because the extracted layout does not have device width as a property (as its encoded in the file name) but the schemematic netlist does

That's an issue for Stefan Schippers. . . the device is 1.41um wide no matter what so W=1.41 should not be passed to the device subcircuit.

@User, @User Thank you, will fix. Guess the same will happen to all 0p35, 0p69, 1p41 variants ...

Fixed. https://github.com/StefanSchippers/xschem_sky130/commit/00a83f068404d4f0067c3263706d04053804b8b9

I'm having some trouble with blackboxing in netgen. My ultimate goal is to get this to pass (it currently fails for me when I clone the repo): https://github.com/efabless/caravel_user_project_analog/blob/main/netgen/run_lvs_wrapper_verilog.sh I think the challenge is that we need to treat the analog subcircuit as a blackbox because its verilog implementation is only a functional model. I can't get the "model mycellname blackbox" command to work as I expect, even on a tiny example. My failing examples, with some notes, are here: https://github.com/standanley/netgen_blackbox_test

What is the exact meaning of "Result: The top level cell failed pin matching." for netgen? I have two netlists with matching components and number of nodes and it is giving that error. I seem to remember a more explicit error if the connectivity in the netlist is different.

I dont know if its related, but I am trying to use the hvl logic cells in xschem. To debug I tried flattening my design before extraction and netgen does not seem to flattening the logic cells in the schematic that it can not match because the extracted netlist is just fets. I am loading the sky130A setup file into netgen, so I really dont know whats going on

except, given that I have traced through the layout several times and the nodes and component numbers for the unflattened version do match, I highly suspect the design matches the netlist and something weird is going on with netgen.

Ah, I see. Unlike the device models I needed to have the logic cell spice libraries explicitly included (they were only included in the top level simulation file). It matches now! It looks like there is something in the sky130 setup file for netgen that ignores decap and other cells that is not implemented for the HVL library, but there are easy enough workarounds

FYI those who are using bipolar devices in the design (@User and several others): I just pushed an update to open_pdks that makes changes to the PNP devices that are saved in the sky130_fd_pr library. I changed the name of the layout to add

_rf_

to the name of the layout view; e.g.,

sky130_fd_pr__rf_pnp_W3p40L3p40.gds

. This became necessary because when I updated the

.mag

view to allow it to write the correct name of the subcircuit wrapper for the PNP model, which is named

sky130_fd_pr__pnp_W3p40L3p40

, I realized that the layout has to have a different name than the subcircuit wrapper or else the two subcircuit names will be the same and you'll end up with an output in which the subcircuit is apparently instantiating itself (oddly enough, the NPNs were all correctly done already). If you have something hacked together that works now, then probably you don't want to mess with it, but if you want to do the update I can explain how to do it with minimal disruption.

Looking at the caravan test harness I see multiple independent ground connections. Can someone explain to me how this works?

Are these only tied together off-chip?

If I have some noisy circuitry (power circuitry) I assume I want it on a seprate ground domain?

I'm running into more property errors with netgen which I can't explain and which appear to be as simple as swapping transistors. I'm also confused though because the comp.out file refers to the exact same two devices twice (M27 in the schematic and M40 in the layout) but extracts different lengths in the two error lines. I've double-checked both the layout and schematic files and it should be able to match the two dummy devices: one of the dummy devices has length 1um and the other has length 4um. I've attached the comp.out file and the two netlist files in the comments.

The analog library comes without the original parametric cell code. I know that there is some TCL code for Magic. Are there any additional resources that may help to recreate pcell code?

I was going to put my whole power stage in a deep nwell for noise isolation. I remember someone talking about extraction for devices in a nwell being partly broken or something. Am I going to be able to produce a LVS clean design after extraction? Is there any precautions I need to take?

Tim Edwards I am getting a build failure with the latest version of openpdks

IndexError: list index out of range
# Install OSU T18 ls digital standard cells.
set -f ; ../common/foundry_install.py -std_format -source  -target /home/wbraun/projects/asic/open_pdks/sky130/sky130A \
	-techlef sky130_osu_sc_18T.tlef rename=sky130_osc_sc_18t_ls.tlef \
	-spice 18T_ls/cdl/*.spice compile-only exclude=*.*.spice \
	-lef 18T_ls/lef/*.lef \
	-lib 18T_ls/lib/*.lib \
	-gds 18T_ls/gds/*.gds compile-only \
		options=custom/scripts/gds_import_setup.tcl \
	-library digital sky130_osu_sc_18t_ls 2>&1 | tee -a sky130A_make.log
Traceback (most recent call last):
  File "../common/foundry_install.py", line 430, in <module>
    sourcedir = option[1]
IndexError: list index out of range

Edit: Ahh, I see. This seems to be just an issue generating the OSU stuff and is not a fatal error. Everything else seems to have built correctly.

Layout question: Magic will ~ maximally densely tile contacts anywhere I have a contact area. If I have a very large M1 and M2 layer I have connected together (say a guard ring with a metal layer that is both M1 and M2) will there be any downside in having the whole area be a contact area too? Or will too many vias significantly increase the resistance of the M2 layer / reduce current handling or something?

This message was deleted.

Hi <!here> M vs NF. We are creating a design and we are working now on finishing some of the layout and when I looked closely to the netlist from xscheme I saw something like this:

XM6 Vout net2 VDD VDD sky130_fd_pr__pfet_g5v0d10v5 L=0.5 W=20 nf=1 ad='int((nf+1)/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29'
+ pd='2*int((nf+1)/2) * (W/nf + 0.29)' ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd='0.29 / W' nrs='0.29 / W'
+ sa=0 sb=0 sd=0 mult=20 m=20

nf = 1, mult=20 and m = 20. I'm a little bit confused because I'm not sure if the model will take source/drain sharing correctly in that case? Nor does it takes the LOD effects.

If you look at the BSIM 4.8 documentation:

Page 127 and page 15. It relies heavily on NF not m.