DEMO: Inverter schematic-driven-layout using gplugins + possible SPICE simulations

[daquintero]

Just thought to make this issue to break down the tasks and get my head around the latest updates:

We have the skywater PDK currently, and want to integrate a more standard schematic-to-layout flow using gdsfactory

Would the goal be to export a SPICE netlist from a given schematic-capture tool eg. and then performing the layout accordingly using the gdsfactory layout generator?

Caveats to consider:

• SPICE formats are tool specific, they are not necessarily compatible, so in any case we want to make this explicit what tool and SPICE language we're converting from
• How to deal with abstract components such as sources, etc? We would need an identifier of physical and nonphysical netlist composition.

Requirements:

• Schematic capture icons for sky130nm component ports etc. Use either defaults or explore maybe an existing icon set?

So we would need to generate the first set of spice desciptions, convert to yaml, and then integrate the layout flow. I assume the idea of using "jupyter notebooks, QUCs and XSchem" would be to automate this generation.

The tasks then become:

• [X] Update dependencies https://github.com/gdsfactory/skywater130/pull/92
• [ ] Create a hdl21 equivalent PDK for our current version https://github.com/gdsfactory/skywater130/issues/93
• [ ] Convert from hdl21 to xschem. Initial ideas:
  • [X] Generate a schematic file accordingly with the selected tool with the corresponding SPICE, and extract the netlist SPICE. I guess the idea is more towards XSCHEM in some sort of sky130nm integration that is compatible with ours possibly https://github.com/StefanSchippers/xschem_sky130
  • [ ] TODO verify compatibility between xschem generated netlist to our Pcell declaration (have they been updated? possibly not)
• [ ] From whatever this format is to YAML to convert to gdsfactory formats https://github.com/gdsfactory/gplugins/issues/306
• [ ] Automatic layout already implemented like here https://github.com/gdsfactory/gplugins/blob/main/notebooks/20_schematic_driven_layout.ipynb

So the place to start would be explore the current schematic representation or design flow as currently implemented? Make sure the names match, or a interface interconnection is explicit, in order to then make sure that the sky130nm PCells can be related to the schematic description. Test the SPICE conversion accordingly, make sure the layout can be fundamentally generated using this PDK and go from there.

Existing resources in this direction:

• Existing sky130nm xschem library https://github.com/StefanSchippers/xschem_sky130.
• open_pdks are what people are currently using to install the demo PDKs apparently http://opencircuitdesign.com/open_pdks/index.html https://github.com/RTimothyEdwards/open_pdks
• Mabrains already has demonstrated xschem SPICE extraction using the gdsfactory default PDK https://github.com/mabrains/gdsfactory-generic-pdk/tree/main/xschem
• They also already have a bunch of macros to setup https://github.com/mabrains/skywater130/tree/main/sky130/cells/klayout/pymacros/cells
• We already have a yaml representation that can be used to demonstrate layout https://github.com/gdsfactory/skywater130/blob/main/sky130/circuits/sample.pic.yml albeit TODO verify if after 2 years has the netlist structure changed?
• Dependency on volare currently

Thoughts:

• Demo on the open_pdks integration with gdsfactory flow makes sense, since it extends existing tools people already use.

[daquintero]

I believe the ideal interim solution in relation to https://github.com/efabless/sky130_klayout_pdk would be to have the fixed as a submodule and gdsfactory recursing though them to get the cell declarations. Ultimately, this is an application repository that builds onto the existing pdks. As such, and given that most users are using volare etc to install the PDKs, I'm not sure this is the most straightforward strategy on including the gdscells onto the package. WHat we can do, rather than pip installing possibly, would be to include the source PDK repositories and simply add the gdswrapper functionality on top of that. However, this comes at a packaging complexity problem.

[daquintero]

Hey @joamatab just to keep you posted: I've managed to fix things to get schematic-driven-layout from the sky130nm PDK using the gplugins schematic editor. However, there's a serious dependency hell I had to sort out, and when I've got it reproducible enough in the sky130nm repo, I'll migrate the examples there which I'm currently working on between multiple repos atm.

Think I have a plan to automate going from hdl21 models to the yaml too. The next few weeks I'll be broadly working on the stuff for the conference fyi. The next step after that is going from an xschem SPICE declaration into some python construct using vlsir, but it's a bit more involved. I'm trying to avoid writing a spice parser as there are so many variations to reconstruct the parameters.

Still some polishing work required on vis: