VAM By kpryct com 2019 12 17 Version

VAM By kp-ryct. com 2019 -12 -17 Version 1. 3

Introduction • VAM is a Verilog-A compiler (from. va to. c). It just focuses on the complex compact model (BSIM-CMG, PSP, Hi. SIM_HV, Hi. SIM 2, etc. ). • Its dumping codes achieve theoretical performance and memory usage.

Advantages / Features: • Comparing with other Verilog-A compilers, VAM has the following advantages / features: • Its dumping codes have the best performance and memory usage, which achieve theoretical values. • By tracing the variables' status, VAM obtains the exact dependencies of variables and statements. Basing on these dependency information, it can dump the codes with best performance and memory usage. • Comparing with the codes dumped by ADMS (2. 3. 6) + Ngspice XML (2. 3. 0) (+ bug fixes and enhancement), the codes dumped by VAM are about 2. 5 X faster. • Comparing with the built-in models of the commercial SPICEs which optimized manually, the codes dumped by VAM almost have no difference in performance and memory usage (like BSIM 4) or EVEN BETTER (like BSIM-CMG, Hi. SIM_HV). • Comparing with the Verilog-A compilers of the commercial SPICEs, the codes dumped by VAM may be about 2. 0 X~5. 0 X faster, and for some cases may up to 10 X. • The Verilog-A source codes don't need any refinement before compiling by VAM, and the dumping codes can be used immediately without any manual intervention. • This makes it possible that doing the compiling on the fly, which enables Verilog-A to be widely used. • Some other compilers may also dump efficiency codes when the Verilog-A source codes follow certain rules (for example: all the bias-independent statements are placed inside @initial_step block, internal nodes are not shorted with external nodes, etc. ). But most of the Verilog-A source codes of complex compact models don’t meet these requirements, and the refinement of Verilog-A source codes may easily introduce bugs. • VAM have no requirements on the Verilog-A source codes, it is smart enough to handle all the cases (See Verilog-A example which showed the difference between VAM and other compilers).

Advantages / Features: • VAM can help the developers to write the high quality Verilog-A codes. • VAM will list the detailed information of all the components (nodes, branches, parameters, variables, statements, etc. ), which provides a convenient and intuitive way for the developers to review the codes. • In addition to the syntax error, other bugs such as useless statements, illegal use of both potential and flow of a probe will also be detected and reported by VAM. • VAM provides a set of smooth and limiting functions, which help the module to get convergence. • VAM will do the QA of the module in next release, and will detect the discontinuity of 0 -order and 1 -order of expressions (like the if-else statement). • The dumping codes are easily to be linked into simulator. • The dumping codes are constructed through a structure (like SPICEdev of Spice 3, but more flexible), and is easy to be linked into the simulator through a lightweight wrapper (similar as the adapter of NXP Simkit). • It could be linked into the simulator statically (as the build-in model) or dynamically (through the shared library). • The dumping codes are clear and readable. This makes it easy to change the codes manually for special requirement. • VAM can dump different codes for different demand. • For example, it can dump codes for SIMD, GPU, Monte Carlo (multi-thread), etc. This allows VAM to be used in more situations.

Documentation • VAM benchmark: • VAM benchmark(1): The benchmark of VAM vs. ADMS (2. 3. 6) + Ngspice XML (2. 3. 0) (+ bug fixes and enhancement). • Please contact us if you want the binary (a modified Spice 3 which includes two BSIM-CMG 107 -- compiled by VAM and ADMS separately) and testing cases. • VAM benchmark(2): The benchmark of VAM vs. Sim A (build-in models and in-house Verilog-A compiler). • Advantage of VAM : How VAM achieves this. • Verilog-A example : A Verilog-A example that designed specially to reveal the difference between VAM and other compilers. • Integration of C codes dumped by VAM : How to integrate into simulators. • VAM FAQ : VAM FAQ.

VAM usage: Model implemtation • As the basic usage, VAM can greatly reduce the work of model implementation. • Currently, most models are released in Verilog-A format (like BSIM-CMG): • Verilog-A compilers are used to translate Verilog-A codes to C / C++ codes. Among this, ADMS (with Ngspice XML or other XML files) are often used. • Using ADMS (2. 3. 6) + Ngspice XML (2. 3. 0) as example, it has following issues (BSIM-CMG 107): • • The dumping C codes can’t be used directly: it needs to do some modification to pass compiling. • The codes have bugs: the state from ddt is overlap; some local variables inside load() are not initialized; analog functions are missed, etc. • The codes are not optimized, and need much efforts to do the optimization (bias-independent calculation, shorting the internal nodes for V <+ 0, useless derivative calculation, etc. ). It may easily introduce bugs when doing the optimization manually. Model developers need some coding skills, the basic understanding of engine, and the knowledge of device physics. But the bug fixes and enhancement on the C / C++ codes translated by ADMS are still an error-prone process. • A statistics shows that, more than 90% bugs of the simulator are caused by model and FE. • VAM can do the compiling (from Verilog-A to C) perfectly. • Its dumping C codes can work immediately, and already do best in performance and memories usage. • The model developers can be liberated from the boring implementation job, and focus on the model itself (the device physics, the extraction flow, etc. )

VAM usage: Do the compiling on the fly • The build-in models' codes are fixed when the simulator released. This will cause inconvenience in many cases. • One popular case is: Some model libraries may define subckts or macro models, inside which some model parameters' values are the functions of instance parameters. Following is an example: subckt newbsim 4 (d g s b) parameters l=1 u w=1 u model nmos 1 bsim 4 type=n vth 0=0. 5+l*1 e-4+w*2 e-5 m 1 (d g s b) nmos l=l w=w ends newbsim 4 • In this example, model data (here is nmos 1) can't be shared by different instances of subckt newbsim 4 if they have different l or w. So one instance needs one corresponding model data when the simulator setups the link, which will cause the memories exhausted for large scale integration circuits, and may also increase the cache-miss rate (so hurt the performance). • For example, in a good implementation of bsim 4, its instance data structure size might < 80 double, while its model data structure size might > 1000 double. So the memories used in this kind of subckts may be 12 X larger than normal.

VAM usage: Do the compiling on the fly • Generating the model on the fly is a good solution. • The suggested flow is: • The simulator is released together with the models' Verilog-A source codes; • After parsing the netlist to get related information, FE calls Verilog-A compiler to generate corresponding C model codes and compile to shared library; • Then the simulator can import the new model by loading the shared library as if it is a build-in model. • Now the new model can meet the requirement; • In the above example, the new model will treat vth 0 as instance parameter and move it from model data structure to instance data structure, so the new model data structure can still be shared between instances. • Why not using this flow before? • The Verilog-A compiler of SPICEs can't generate efficient C model codes from Verilog-A source codes (see here). • Other reasons? • VAM makes the solution attractive, since the codes dumped by VAM have no degradation in performance and memory usage comparing with the built-in model (see here).

VAM usage: Foundries • Foundries may have the requirement of 1, developing a new model (or possibly makeing some changes on the basic model); 2. hiding the process parameters. • Using making changes as example, foundries may have following solutions: • Foundries notify the basic model's developers, and may get the changes in the basic model’s next version. After that, simulators and extraction tools will merge the changes into their next release, so foundries and design houses could use it. • For example, WPE (Well Proximity Effect) works on this way. • Foundries use subckts or macro models, which use expressions for the changes. • In some cases, foundries may just need the changes from simulators. • For example, some foundries may need the ACM to be one of the bsim 4 diode model. In this case, the support from simulators are enough. • TMSC used TMI. • Can TMI really hide the parameters? • The above solutions may have one or more of these inconvenience: the developing cycle is long; the flow is complex; simulators need much efforts to support; the equations and parameters are exposed; just bias-independent changes can be made; and so on.

VAM usage: Foundries • Using Verilog-A should be a better choice: • A possible flow might be: • Foundries develop a new Verilog-A module, or make some changes basing on a known Verilog-A module; • The Verilog-A codes are loaded into extraction tools to do the parameter extraction; • Finally, foundries release the Verilog-A codes together with the corresponding model libraries. • Comparing with other methods, Verilog-A solution has many advantages, such as: all the steps are under control by foundries; it has no the trouble of inconsistency (between extraction tools and different simulators); • In this process, if foundries want to hide the context of the Verilog-A codes (such as the equations, the meanings of parameters, etc), it could first convert the Verilog-A codes to C codes and compile it to a shared library, then the extraction tools and simulators could import the Verilog-A module by loading in the shared library as if it is a build-in model. • By using this method, the extraction tools and simulators didn't need to own a Verilog-A compiler, but just need to open their model interface instead (like the CMI of spectre). • Since the equations and the meaning of parameters are hidden, the corresponding parameters' values are meaningless to the competitor. • If foundries only want to hide the process parameters, there may be a quick solution. • For example, in bsim 4, we have vth=vth 0 +. . . , we may change it to vth=(2. 0*kk - 0. 1) +. . . ; then in the model library, kk replaces vth 0, and nobody knows what it means.

VAM usage: Foundries • Why not using Verilog-A before? • The Verilog-A compilers at that time may be not good enough: it can’t handle the complex compact Verilog-A module, or the performance of dumping codes is poor. • Some features may be no easy to support, like binning or corner model. • Other reasons? • VAM can solve the above issues: • The performance and memory usage of VAM’s dumping codes are even better than the simulators’ build-in models (See benchmark 2). • In addition, VAM brings many other benefits. Please see ”VAM can help the developers to write the high quality Verilog-A codes”. • Other possible obstacles: • Some fast SPICEs may have their special requirements on the models. • For example, vth and vsat of the MOSFET might be needed by kernel for partition. • Others?