Does a tool exist that automatically draws a transistor level schematic from a SPICE netlist, like, of

sky130_fd_sc_hvl__lsbuflv2hv_symmetric

?

"Automatic schematic generation" (ASG). I have looked into the problem before, and it is equivalent in complexity to writing an auto-router tool from scratch.

In that case, has someone bothered to draw transistor level schematics of the level shifter cells in the

sky130_fd_sc_hvl

cell library? Those aren't relatively straightforward digital gates.

I will shower praises upon anyone who does this, although that doesn't keep it from being a massive and tedious task.

A few days ago I was about to draw the schematic of the

lsbuflv2hv_1

from the .spice file but there's an error in the netlist. The node

a_1606_563#

is left floating.

@Lucas Daudt Franck: The google repository is not the one used by open_pdks. Use my fork at Efabless, which has been heavily patched and repaired: http://github.com/efabless/skwater-pdk-libs-sky130_fd_sc_hvl.

ahem This one, maybe? https://github.com/efabless/skywater-pdk-libs-sky130_fd_sc_hvl

Thanks @Tim Edwards and @Christoph Maier I wasn't aware of this. I'll take a look. Maybe adding a warning message in the PDK Docs pointing to these patched repos would be helpful to avoid any future confusion.

@Tim Edwards, how do you deal with non-contiguous layout ports (like

VGND

in double width level shifter cells) that will get connected higher up in the hierarchy, anyhow? [EDIT: I still don't know how you dealt with non-contiguous ground rails, but apparently, you dealt with them somehow … LvS passes.] … and where is the method to make the pin orders in schematic and layout to be extracted documented? How to define pin order in

xschem

schematics (not symbols) seems to be drowned in the SNDR of discussion forums and version hell of almost correct documentation pages … [EDIT: Turns out that LvS doesn't care about pin order, as long as the number and names of pins match]

@Lucas Daudt Franck: The reason I forked the repo was the complete lack of response from Google when trying to get them to merge pull requests or handle issues. So I'm doubtful that I can get them to post a message redirecting to the repo fork. This may resolve itself eventually, as Google is trying to move responsibility of the repositories to another 3rd party.

For what it's worth, I did draw a xschem schematic of the

sky130_fd_sc_hvl__lsbuflv2hv_symmetric_1.mag

level shifter cell, and after some corrections to the netlist from https://diychip.org/sky130/sky130_fd_sc_hvl/cells/lsbuflv2hv_symmetric/, LvS passes, see https://github.com/tatzelbrumm/sky130_cm_ip__biasgen/blob/LvS__lsbuflv2hv_symmetric_1/xschem/sky130_fd_sc_hvl__lsbuflv2hv_symm.sch How much characterization has been done for this cell, and who designed it in the first place? In a layout comprising rows of digital standard cells, the cell makes sense as is, but in a mixed signal environment with several level shifters, pasting in cells with large nwell separations might not make that much sense. … which also opens the can of worms whether there should be some layout conventions for the various and sundry analog cells in chipalooza, in case someone want to creatively combine them.