MOSFET Primitive `Enums` and `MosParams`

[kcaisley]

I have a couple of questions/proposed changes regarding the Enums and Params for primitive transistors. Relevant snippet from primitives.py:

class MosType(Enum):
    """# MOS Type (NMOS/ PMOS) Enumeration"""
    NMOS = "NMOS"
    PMOS = "PMOS"

class MosVth(Enum):
    """# MOS Threshold Enumeration"""
    STD = "STD"
    LOW = "LOW"
    HIGH = "HIGH"
    ULTRA_LOW = "ULTRA_LOW"
    ZERO = "ZERO"
    NATIVE = "NATIVE"

class MosFamily(Enum):
    """# MOS Family Enumeration"""
    NONE = "NONE"
    CORE = "CORE"
    IO = "IO"
    LP = "LP"
    HP = "HP"

@paramclass
class MosParams:
    """# MOS Transistor Parameters"""
    w = Param(dtype=Optional[Scalar], desc="Width in resolution units", default=None)
    l = Param(dtype=Optional[Scalar], desc="Length in resolution units", default=None)
    npar = Param(dtype=Scalar, desc="Number of parallel fingers", default=1)  # FIXME: rename
    mult = Param(dtype=Scalar, desc="Multiplier", default=1)
    tp = Param(dtype=MosType, desc="MosType (Nmos/ Pmos)", default=MosType.NMOS)
    vth = Param(dtype=MosVth, desc="Threshold voltage specifier", default=MosVth.STD)
    family = Param(dtype=MosFamily, desc="Device family", default=MosFamily.NONE)
    model = Param(dtype=Optional[str], desc="Model (Name)", default=None)

I understand (from Dicussion #103) that the MosParams.model field is designed as an "escape hatch" to allow specifying less-common device flavors that don't warrant covering in the MosFamily, MosVth, and MosType enums.

1. With that in mind, two of the PDKs I use have separate RF devices, which share the same core BSIM model as the normal baseband devices but include more accurate parasitic + LDE modeling. (The associated layout pcell includes a guard ring and bulk/well contacts, etc.) I am currently using the model escape hatch to tell <mypdk>.compile() to convert primitives to ExternalModules for the RF devices. But I'm curious if you feel the RF transistor type is appropriate and common enough to warrant adding a RF="RF" member to the MosFamily enum?

2. Can I propose adding a ULTRA_HIGH = "ULTRA_HIGH" member to the MosVth enum?

3. Can I propose addressing the # FIXME: rename for MosParams.npar below, by renaming it to MosParams.nf?

Will open a pull request if these changes are useful. (Will be sure to go through the examples to update the references to npar.)

[dan-fritchman]

Thanks for digging in here!

1. Adding a MosFamily.RF variant makes sense to me
2. Is ULTRA_HIGH a real one you've encountered, or just, like, for symmetry with ULTRA_LOW?
3. Go for it! There are FIXMEs all over to move the primitives.MosParams field names to nf and mult. They just haven't happened since they require updating the downstream PDK packages, including the non-built-in ones. We can roll those in as they come up.

[kcaisley]

Okay, great. I've made the changes for the enums, and renamed all instances of npar -> nf and all instances of m, mf, and vm -> mult. I've grouped them together with my outstanding PR #164 as all the changes are related to device MosParams.

Regarding ULTRA_HIGH Vth class devices: Yes, I know some PDKs that have them. One publicly documented is a TSMC 28nm PDK, which has ULVT, LVT, SVT, HVT, UHVT (and even an 'extremely high' EHVT variety, to boot). From the linked page:

Closing now (as this is implemented in #164 )