I just tried to add something to my wrapper, but for some reason when I extract it rather than a subcircuit the actual transistors are showing up in the spice netlist which obviously causes a structural mismatch in the prechecks. @User do you know what could cause this?

@User Are you seeing the transistors in the LVS report or the actual netlist?

ACTUAL NETLIST

What was the name of the cell you added?

analog_switch

Ok, so you're extracting from the

mag

files and not the gds, right?

yes I'm just running

extract

then

ext2spice

in magic

Unfortunately, I'm not familiar with that flow. Have you used it before? Do you get the same results with this?

extract
ext2spice lvs
ext2spice

Not sure. I could try that option though. Thanks for the suggestion

@User: The precheck process doesn't run LVS, so I'm not sure in what way this would cause issues with precheck. Regardless, netgen will run a transistor-level netlist against a higher-level netlist and should only emit warnings about cells being empty and therefore treated as black boxes. So I need more information about what the actual problem is.

Sorry I should have clarified: it's the consistency check that fails, with the reason given as LAYOUT. They don't run LVS but they do a structural comparison of the top level netlist and the GDS.

Ah. The point of the consistency check is to make sure that a project is reproducible. For digital projects, this is pretty easy: If you have the verilog source and the openlane configuration, then it's (in theory) exactly reproducible. There is no equivalent reproducibility for analog projects, and we had some submissions to the first MPW run where the submission was missing any schematics or netlists or any way to know what the project was doing other than reverse-engineering it from the GDS. So the consistency check is to make sure that there is at least a netlist in the project that corresponds to the layout. Now I don't have a lot of insight into what was put into the script that runs the consistency check, so it will be helpful to determine if the consistency check is working as intended or not. If it is failing to find a structural match down to the transistor level but the cell views without those transistors are from public libraries, then in my opinion it should not fail the design for that reason.

that's a useful insight about the check, thanks. Where Magic comes in is that when I extract, rather than getting

Xanalog_switch_0 [ports] analog_switch

, the resulting spice netlist has

X0 ports sky130_nfet ...

etc and I'm not sure why

"ext2spice lvs" is just a shorthand for a number of "ext2spice" option settings. Probably "ext2spice format" and "ext2spice hierarchy" are the main issues here. My usual practice is to do "ext2spice lvs" first to apply "sane" settings, and then re-apply individual settings as I need them, such as "ext2spice cthresh 0" to get parasitic capacitances, etc.

right