@User: FYI, it is basically a non-issue as far as the integrity of the Caravel layout, but it does indicate that a change in the magic techfile has unfortunate unexpected side effects with extraction, and needs to be fixed.

Thanks for the update. I'll look for the tech file update.

At the moment, I'm not sure if the tech file needs fixing, or magic's extraction code.

That was quick! I changed the extracted spice connections and models to what I hoped would match the library. Running into 2 more problems. 1. size missmatch. spice library pfet w=1

.subckt sky130_fd_sc_hvl__decap_4 VGND VNB VPB VPWR                  
X0 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u         
X1 VPWR VGND VPWR VPB sky130_fd_pr__pfet_g5v0d10v5 w=1e+06u l=1e+06u
.ends

extracted layout pfet w=1.75

.subckt sky130_fd_sc_hvl__decap_4 VNB VGND VPWR VPB
X0 VPWR VGND VPWR VPB sky130_fd_pr__pfet_g5v0d10v5 w=1.75e+06u l=1e+06u
X1 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u
.ends

skywater pdk problem, I think. 2. The second problem concerns the power/ground nodes. In the extracted netlist, vssa*, vdda* are not connected to anything. In the verilog, it looks like they want to have cells with different nets connected to VNB and VPB. Some cells have vssd connected to VNB and some have vssa1 or vssa2. Is this a 3-well process and are they using deep nwell in the mgmt_protect_hv layout?

@Mitch Bailey: To avoid the problems, edit the sky130A.tech file extract section and remove the entries for the 20V devices. As long as magic believes that it is looking at a 20V device, everything about it will be wrong, including the connections and the gate size. As long as you don't have 20V devices in the layout, then removing them from the tech file will have no effect other than to fix the extraction.

Removing the 20V devices from the tech file results in matching decap. The unconnected vssa* vdda* remain. Here's the extracted level shifter.

.subckt sky130_fd_sc_hvl__lsbufhv2lv_1 X A VPWR_uq0 VGND VNB LVPWR VPB
X0 VGND_uq0 a_30_1337# a_30_207# VNB sky130_fd_pr__nfet_g5v0d10v5 w=420000u l=500000u
X1 a_30_207# a_30_1337# VPWR_uq0 VPB sky130_fd_pr__pfet_g5v0d10v5 w=420000u l=500000u
X2 VGND_uq0 a_389_141# X VNB sky130_fd_pr__nfet_01v8 w=740000u l=150000u
X3 VGND a_30_1337# a_389_1337# VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X4 VGND a_30_1337# a_389_1337# VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X5 LVPWR a_389_141# X LVPWR sky130_fd_pr__pfet_01v8_hvt w=1.12e+06u l=150000u
X6 LVPWR a_389_1337# a_389_141# LVPWR sky130_fd_pr__pfet_01v8_hvt w=1.12e+06u l=150000u
X7 a_389_141# a_30_207# VGND_uq0 VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X8 VGND_uq0 a_30_207# a_389_141# VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X9 VGND_uq0 a_30_207# a_389_141# VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X10 a_30_1337# A VPWR VPB sky130_fd_pr__pfet_g5v0d10v5 w=420000u l=500000u
X11 VGND A a_30_1337# VNB sky130_fd_pr__nfet_g5v0d10v5 w=420000u l=500000u
X12 a_389_1337# a_389_141# LVPWR LVPWR sky130_fd_pr__pfet_01v8_hvt w=1.12e+06u l=150000u
X13 VGND_uq0 a_30_207# a_389_141# VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X14 a_389_1337# a_30_1337# VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
X15 a_389_1337# a_30_1337# VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
.ends

It appears that the

extract unique

option has created VPWR_uq0 and VGND_uq0. VPWR_uq0 and VGND are ports with external connections while VPWR and VGND_uq0 are not.

"extract unique" does not work well with standard cells that have a fixed number of ports with names; e.g., the level shifter is a double-height standard cell, and there are two power and ground rails. They are not connected but both are named "VPWR" and "VGND" and do not have separate ports, which is technically incorrect. To get around problems like those, I added the option "extract unique noports". This will allow the ports to keep the original names, implying a connection between the duplicate rails that isn't really there, but will allow it to pass LVS.

Who is responsible for the

mgmt_protect_hv

verilog and layout? Currently, the extracted layout has no connections to vssa*, vdda* and the level down shifter internal LVPWR is unconnected.

Xmprj_logic_high_lv mprj_vdd_logic1 mprj_logic_high_lv/A vccd vssd vssd mprj_logic_high_lv/LVPWR
+ vccd sky130_fd_sc_hvl__lsbufhv2lv_1

@Mitch Bailey: Once I verify it, which I started in earnest yesterday and am continuing today. The SkyWater netlists have a few errors, but there are more issues arising from netgen and magic, as happens for any library that is substantially different from others we have handled before. I think I am close to being able to verify the GPIO pad, which is the most complicated one. I have already been able to verify it in simulation, and I can assume that the layout is correct because these pads have been used in the Cypress pSOC product line. But getting LVS to work with the open source tools is still challenging.

@Tim Edwards Thanks for the update. Let me know if there's anything I can do.