more vt transistor types with custom names from config file

[chrislafrieda]

Currently, only three vt transistor types, SVT, HVT, and LVT, are supported. Newer technologies have more than three types. Also, some foundries use different naming conventions from the standard SVT, HVT, and LVT. Would be helpful if any number of types could be supported with the name mapping specified in the conf file and hacknet chooses the appropriate name when generating a spice netlist.

[fangism]

Thanks for filing this request!
Pasting some of my earlier notes from chat:

Right now, syntactically, device type looks like this in PRS:

[hvt] x -> y-

The parser has a construct for generic_attribute which corresponds to "hvt", etc.
That construct also supports a quoted string, which was used in the past as a label/name.
Fortunately, the types hvt/svt/lvt are not hard-coded at this point, which means you could write anything there like 'superlvt', and it will parse, but fail later.

Where the names do get looked up are Object/lang/PRS_attribute_registry.cc (for the whole rule) and Object/lang/PRS_literal_attribute_registry.cc (for one PRS literal).
I believe this needs to be resolved when compiling anyways, which means you'll need to extend the compiler's behavior.

At the moment, these implementations live in global registries private to those respective .cc files.
You could add new entries there, or if you want more future-proof flexibility, you'd make access to those registries public, and let loadable modules (plug-ins) add more functionality to them through self-registration.
The haco/haccreate compiler would need some flag to dlopen() plug-ins.

This is just to get support into the .haco files so far.

And then for hacknet, there's another set of (private) registries __rule_attribute_map and __literal_attribute_map you'd need to update to add new functions, again by a hacknet plug-in.

Unfortunately, these implementations reference enum values in net/netgraph.hh (which one cannot just extend with plug-in code).
You would need a space for user-defined/module-defined bit-fields, which is a bit more invasive work.

more notes to follow...

[fangism]

I'm thinking that an alternative to ingesting a config file would be to emit generic transistor attributes that could be post-processed. Let's say we enumerate your transistor types like:

0 = standard
1 = LVT
2 = LVT2
3 = HVT
4 = HVT2
...

These could be defined from your "config" file, and if we emit extra fake device parameters like [VT=N], then we could stream-edit a spice file to alter the transistor types based on these pseudo-parameters.

Pros: the tools never need to know about anything technology specific, you bring your own interpretation.

Work needed for this approach: the data structures involving transistor attributes needs to be generalized a bit to support an arbitrary number of transistor types (8b probably enough). We would also need a little special handling to emit the pseudo parameter in the correct position.