SKY130 Open PDK Integration

[ThomasPluck]

Hi, I'm currently hacking on expanding the SKY130-HDL21 module to include everything seen here and I wanted to ask questions about/plan out loud the design:

Expanding Mos Variants

I'm guessing from the ioxtors here that the general pattern should be to group by this particular heirarchy:

• MosType - Pmos or Nmos
• model - Transistor type, operating voltage, is it native, is it used for ESD?
• MosVth - What is the threshold voltage?

Is this robust enough that if I encounter a zero-threshold - I should actually expand MosVth to include a ZTH parameter?

Introducing Resistors

Resistors in the SKY130 PDK are split into two camps, generic resistors (which accept W and L parameters) and precision resistors (fixed width with L parameter left up to user) - so my understanding of how HeirarchyWalker should work in this instance is that I should have seperate cases handling:

• Generic Two Terminal Resistors
• Generic Three Terminal Resistors
• Precision Three Terminal Resistors

My understanding is that this should be done using the following recipe:

1. Create two new paramclasses Sky130PrecResParams and Sky130GenResParams that respectively contain W,L and just L.
2. _res_module builder function then takes a modname, number of terminals and desired paramclass, as well as model string to easily distinguish between different kinds of resistors.
3. res_module_call inside HeirarchyWalker should be able to distinguish between PhysicalResistor and ThreeTerminalResistor primitives and use res_module to determine what resistor is being used from the returned module's model parameter.

Capacitors

Capacitors are complicated from the device details, there are two objects that I think might actually require new primitives:

1. Varactors
2. Shielded Capacitors (4 terminals, 2 for top/bottom shielding)

Each species of capacitor should get its own paramclass (particularly MiM/Varactors) - but the rest seem to correspond to pre-defined capacitor cells in the PDK - so I'm tempted to create a Sky130DeviceParams paramclass which is just an alias for HasNoParams and to just used model as a key.

BJT/Diodes

All BJTs and Diodes simply seem to need being distinguished via model name and BipolarType in the case of BJTs. I don't believe that there are yet parametric models for BJTs or Diodes available, so these will have to bundled similarly with the Sky130DeviceParams nothing paramclass and model key.

House-keeping Notes

To try and keep the code presentable and not overly cluttered, I'm thinking of implementing using the following guidelines:

1. Top of pdk.py should be for the Installation class, imports and Corners
2. In another file pdkparams.py all paramclass objects should be defined
3. In yet another file pdkmodules.py all ExternalModule creating functions should be defined
4. The next section pdk,py will be long lists calling pdkmodule functions to build out module dictionaries
5. Cache and heirarchy walker should be at the bottom of pdk.py which include the usual _module_call methods within

Let me know what you think of this idea or any suggestions for how this can be improved.

[ThomasPluck]

Seeing the Nmos and Pmos wrapper functions in primitives.py gave me the following idea: why not include helper functions as standard - seeing as the number of models available grows to be quite daunting with semantics like:

h.Nmos("20.0V", MosVth.ULTRA_LOW)

Instead we have:

s.Nmos20V(MosVth.ULTRA_LOW)

This allow the user to quickly find their device of choice with s.N... autocompletion with docstrings to explain the components, rather than having to memorize/lookup devices from documentation. As well as being an idiomatic way to store the default sizing parameters of the SKY130 components without having to hand that off to a complicated HeirarchyWalker call. Although a consequence of this is that using direct HDL21 native primitive compilation will require the user to manually look up sizing for each component.

[dan-fritchman]

Awesome work on this!

A few general things -

• Sky130 has a buncha... kinda weird stuff. There's no great objective or factual basis that statement, other than having seen plenty of other, particularly newer, techs.
• So, I wouldn't really want to use sky130 as the primary basis for defining generic primitives. Some stuff translates pretty generically, other stuff doesn't.
• A fixed-length, variable-width resistor is a great example of something not terribly common or generic!

More tactically:

• The recently-merged PRs from dev add a MosFamily enum and a so-valued family field to the generic primitives.MosParams. The intent is for this to differentiate things like "core vs IO" and the like. It's not "rolled out" to any PDK packages yet, but could be of value here.
• The string-valued model field is there in MosParams, and (whether by intent or not) serves as an "escape hatch" for dictating device-types that don't fall among all those enum's. But we shouldn't expect every instance of primitives.MosParams to have one. Again it's an escape hatch. A big part of having generic-primitives is the ability to do things like:

@h.module 
class HasMos:
  m1 = h.Mos(...)(...) # instantiate a generic primitive `Mos`

# Now "compile" this into different technologies
pdk1.compile(HasMos)
pdk2.compile(HasMos)

Requiring setting a model string, and having it be in the namespace of the target technology, disables that. (Unless the models are the same between technologies, which in general they're not.)

There's an easy alternative if you want a particular technology's particular, bespoke element: just instantiate its PDK-package's ExternalModules. (Or instantiate a generic with a model field - but just don't make every generic primitive do it too!)

I added some (even) more tactical line-by-line commentary on the PR. Thanks again here this is great!

[dan-fritchman]

Related thought which came up on the GF180 PR:

In each of these technologies, there should, in general, be some notion of "the regular transistors". I.e. the ones the standard logic library uses. Often called the "core" transistors, etc.

The idea of having different thresholds vth also generally transfers between techs. That's a pattern that translates, and helps to define and use the enumerated MosVths. The notion of a few different "families" is probably next-most common. For most modern techs, the two typical families are often called "core" (i.e. the regular ones) and "IO" (i.e. the higher-voltage ones). We could add a few things to that MosFamily enum - but certainly should stop short of every possible voltage rating.

We should reserve the model field as an escape hatch for "weirder", more tech-specific things - e.g. the difference between having 6V and 20V devices, when the "main" ones are 1.8V. Then designers who want these devices can set the model field (while omitting it gets "the regular transistors" instead), or just directly instantiate the PDK's ExternalModules.