paramset support
KenKundert opened this issue · 6 comments
paramsets were added to Verilog-A in version 2.4 for two reasons:
- to provide a Verilog-A/MS native way to specify the information normally provided by the SPICE .model cards (this was considered the last barrier to the enabling of a pure Verilog netlist for circuit simulators, which would allow us to finally leave behind the long painful era of vendor specific netlists).
- to provide optimizing compilers a way of dramatically increasing the efficiency of simulation by flooding the code with constants (the model parameters), that would allow substantial opportunities for expression pre-evaluation and code pruning.
The speed up from paramsets was envisioned to result from combining the code and the paramset before compiling. So rather than one compiled mosfet model in a simulation, there one be one compiled for each .model card in the PDK. This allows for pre-evaluation of many expressions and elimination of many conditionals. It also eliminates the distinction between model and instance parameters, resulting in substantially smaller instance data structures, which improves cache performance.
paramsets represent a significant change to the concept of the SPICE model card that dramatically affects the architecture of the compiler and the simulator, but promises substantial increases in performance. It should be built into the compiler from the start. The commercial model compilers were initially developed before paramsets were defined and missed out on the opportunity provided by paramsets.
Do you have any intention of supporting paramsets?
For the first prototype release of OpenVAF we focused on supporting the parts of the Verilog-A standard used by the CMC compact models. However, we plan to support larger parts of the Verilog-A standard. Currently, we have no short term (next few months) plans to implement paramset support. Instead, we are focusing on finishing more commonly used features.
Language features like paramset or the ability to arbitrarily nest modules are indeed very promising. We also hope that these could finally replace vendor specific netlists. OpenVAF was designed with these features in mind, and adding support in the future should be possible. However, currently we can not prioritize this feature. As established EDA software doesn't support these features there isn't much Verilog-A code out there that makes use of them. Implementing these features is still a larger undertaking and therefore would require a lot of investment from us with little immediate return.
I don't mean to push you, and certainly understand that you must crawl before you can walk, and walk before you can run. I mention paramsets because I think they needs to be designed in from the beginning. I worry that you are painting yourself into a corner. So I guess I am suggesting that as your architect your software you should do so with a laser-like focus on paramsets, as I believe that is where the biggest returns are.
I appreciate you pointing this out to me, I will definitely keep a close eye on supporting paramsets in the future when making design decisions.
However, OpenVAF s architecture is actually very flexible and should be well suited to adding paramsets down the line. The reasons for this is that OpenVAF is internally extremely different from any other Verilog-A compiler. I will try my best with a short summary below so that you don't just have to take my word for it (entirely):
OpenVAF is split into two parts: The frontend and the backend.
The frontend parses a Verilog-A file into a compiler database (like clang) which can be queried for information like:
- all analog statements/modules/variables in a module
- what is the type of a paramter x/expression y
- what does indentifier
foorefer to
Adding new language features to the fronted is comparatively simple as it only seeks to provide all semantic information contained in the sourcecode (so no code transformations). The frontend was even designed to be reused to build a Verilog-A IDE in the future if there is interest for that,
The backend is completely detached from the frontend and has no concept of anything Verilog-A specific. It's an optimizing compiler that operates on a single function. All language specific functionality are represented as function parameters (currents/voltages, parameter, ...) and blackbox callbacks (like ddx). The backend contains a bunch of facilities to transform (add all necessary derivatives with special optimizations, separating the initialization phase from the analysis phase) and optimize these functions. The code representation used for that is called static single assignment form] which is the standard in modern optimizing compilers (clang/llvm, gcc, msvc,.. ). This representation makes it very easily to surgically edit functions. It's possible to replace any value. Even single expressions can be easily replaced. Functions can also be easily merged or split into multiple parts (all of these already happen during compilation). The SSA form in the backend is very similar to LLVM IR and can therefore be quickly and efficiently compiled to machine code with LLVM.
When OpenVAF is called a bunch of gluecode queries the fronted for information about the sourcefile and generates a backend SSA function. That backend SSA function is then transformed with the various modular transformation passes in the backend to realize the various features of OpenVAF. This gluecode is comparatively short and easy to modify. Therefore even adding larger features that may significantly shift the compilation model is possible without modifying the backend itself.
Excellent. That is very reassuring.
Paramset evaluation and pruning is (partly) implemented in modelgen [1]. It speeds up both compilation and execution significantly, as expected.
Unlike OpenVAF, modelgen uses Verilog-AMS semantics internally and is able to dump the pruned Verilog-AMS source if needed. It could hence be used as a kind of preprocessor for other backends lacking the feature. Not sure how/if binning works with OSDI...
[1] https://git.savannah.gnu.org/cgit/gnucap/gnucap-modelgen-verilog.git
That is excellent news!