I would assume there is no connection to bulk. Is ...
# magic
a
I would assume there is no connection to bulk. Is there any bulk connections? They have to have a TAP layer with psdm/nsdm for pwell/nwell. Second I would make sure that PFETs are connected to VDD and NFETs to VSS.
t
@User: In magic, that would be layer
psd
for the substrate with
psc
for the contact (or
ptap
and
ptapc
, if you prefer).
d
Thanks! (yes, that 'diode' in the upper right was supposed to be a tap. 😆) I believe I can use the cell
sky130_fd_sc_hd__tapvpwrvgnd
as a tap example. None of the std cells I looked at had taps (which makes sense if taps are needed infrequently.)
Looks like that did the trick. But one other weird thing: the spice netlist extraction tries to make cells as sub-circuits, and when it does so, the cells without a tap still show the transistor bodies as disconnected. (The screenshot below shows the extracted netlist on the left, and a portion of the circuit to the right.)
image.png
This can be worked-around by adding the line
ext2spice hierarchy off
to the extraction script. so all cells are flattened. After I do this, GND is correctly connected to all transistor bodies. Is this the expected behavior? Should I always need to flatten everything for LVS?
t
No, you're not supposed to need to flatten everything for LVS. I have been trying for some time to correct behavior around substrate nodes, and it's difficult to support all the possible cases, especially to deal with the convoluted hierarchy of the SkyWater I/O cells. Possibly, removing some code for handling implicit substrate connections was a bad idea. That seems to be what happened here. There is no tap within the cells n-leg_ctrl_fet_X, so the fet bulk connection gets the default substrate name (VSUBS), which then should be a pin of the subcircuit. I have a good idea of what I did to the code that caused it to get left off of the pin list, and can probably fix it in about ten minutes. Can you please tarball and post the layouts so I have a known failing example to stare at?
d
(n-leg.mag is the top level one)
(and that tcl script generates the netlist)
t
Got it, thanks.
a
Aso one more suggestion: try using newer versions of magic, old versions had this bug and I encountered it too: the nwell connection was not parsed across hierarchy
t
@User: This does appear to be a tool version issue. I just ran your example and the resulting SPICE netlist looks correct.
@User: FYI, the Tcl script in the tarball is corrupted. I generated the netlist with the simple commands
extract do local;  extract all;  ext2spice lvs;  ext2spice
.
d
Yep! I updated to version 8.3.261 and the issue is fixed! Thanks everyone!