Lots of Hdl21 stuff gets built class-style, with Python identifiers serving as Hdl attribute names. E.g. in our front-page example:
import hdl21 as h
@h.module
class MyModule:
i = h.Input()
o = h.Output(width=8)
s = h.Signal()
a = AnotherModule()
Behind the scenes the identifiers i, o, s, and a are all affixed to those right-hand-side objects, to serve as their "HDL names", e.g. for netlisting.
That fails when the HDL name is a python keyword (e.g. import, from), or an "Hdl21 keyword" - one of the attribute-names of the thing holding it. For example a Module can't have an instance named ports; that identifier ports refers to its ports-dictionary. If you want to make an Hdl object with one of those names - often because you are importing from a non-Hdl21 source, in which that name is not a keyword - then the trick is to use the Module.add & Module.get API, and set the name as a field. E.g.
import hdl21 as h
m = h.Module(name="MyModule")
m.add(h.Input(name="import"))
m.add(AnotherModule(), name="from")
# ...
There's (at least) one place where we can't do this though: parameter names. Param-classes are designed to only take valid python identifiers as names. This could matter for ExternalModules, which have parameters we netlist directly. Note ExternalModuledoes not require its parameters to be a param-class (they can, and often are, dict instead for example). But by convention and priority for the built-in modules (e.g. in PDK packages), we prefer to use param-classes.
164 originally noticed this. To date it's getting by via using a casing-differences from the Python keywords (e.g. As vs as), and the fact that many downstream SPICE programs are case-insensitive. It's not clear that will always work, and not something I'd prefer we rely on.
Couple options:
Add a name or similar field to Param. Prefer it as the parameter name when exporting.
Don't worry about it? If you need an ExternalModule with a disallowed name, use something other than a param-class as its paramtype. E.g. dict[str, Whatever].
Something else?
Note: this is probably worth a review of anywhere else this "identifier names only" problem might come up. I think(?) we have everything else covered.
Lots of Hdl21 stuff gets built class-style, with Python identifiers serving as Hdl attribute names. E.g. in our front-page example:
Behind the scenes the identifiers
i,o,s, andaare all affixed to those right-hand-side objects, to serve as their "HDL names", e.g. for netlisting.That fails when the HDL name is a python keyword (e.g.
import,from), or an "Hdl21 keyword" - one of the attribute-names of the thing holding it. For example aModulecan't have an instance namedports; that identifierportsrefers to its ports-dictionary. If you want to make an Hdl object with one of those names - often because you are importing from a non-Hdl21 source, in which that name is not a keyword - then the trick is to use theModule.add&Module.getAPI, and set the name as a field. E.g.There's (at least) one place where we can't do this though: parameter names. Param-classes are designed to only take valid python identifiers as names. This could matter for
ExternalModules, which have parameters we netlist directly. NoteExternalModuledoes not require its parameters to be a param-class (they can, and often are,dictinstead for example). But by convention and priority for the built-in modules (e.g. in PDK packages), we prefer to use param-classes.164 originally noticed this. To date it's getting by via using a casing-differences from the Python keywords (e.g.
Asvsas), and the fact that many downstream SPICE programs are case-insensitive. It's not clear that will always work, and not something I'd prefer we rely on.Couple options:
nameor similar field toParam. Prefer it as the parameter name when exporting.paramtype. E.g.dict[str, Whatever].Note: this is probably worth a review of anywhere else this "identifier names only" problem might come up. I think(?) we have everything else covered.