Okay, so welcome to the open hardware dev room in case you're wondering which one you
wandered into.
Our next talk is going to be on the VACASC and the Verilogue A distiller.
So our pod, Berman, is going to talk to us about building a device library for this.
So please welcome our pod.
Thank you.
I'm going to talk about a converter from Spice model format into Verilogue A.
The motivation for this converter was a new circuit simulator, VACASC.
It's an analog circuit simulator and its device library is mostly built with Verilogue
A models.
It uses the OpenVAF Verilogue A compiler and the simulator strictly separates models from
analysis, just like most model simulators do.
This is with the new C++, the code is clean and the simulator is fast.
The roadmap for VACASC includes improvements to harmonic balance analysis, addition of RF
analysis, then support for automated binning, parallel evaluation of elements parallel
linear solver, improvements to these convergence, mixed mode simulation, now this is all
just wishes, of course, at this point.
What I'm going to talk about today, support for legacy Spice devices.
If we compare VACASC to other free open source simulators, it roughly positions itself
between size and NG Spice according to its features and its weak point currently is the device
library, it lacks classic Spice 3 device models.
Now what is a compact device model?
It's a collection of equations that describe the behavior of an individual device, like
for instance a diode, a B-polar transistor or a MOSFET.
In past the defective standard for describing such models was the Spice API and models were written
in C.
Now whenever you wanted to implement such a model in any other simulator that was not
Spice 3, you had to re-implement that model from scratch.
That means you had to write like a few thousand up to a few ten thousand lines of code
per each model.
The current defective standard is very log A for compact models and to use a very log A model
you just need a very log A compiler and your simulator must know how to use these compiled
models and your set to go.
Very log A is a harder description language, it's used for analog circuit description
and it can also be used for describing compact models for that purpose you only need a subset
of very log A.
What is nice about very log A that is that models in very log A are short typically
like five lines of code per each parameter.
And another nice thing about very log A is that you don't have to worry about derivatives.
Very log A compilers generate all the derivatives automatically so you can skip all the error
problem manual coding.
This makes it possible for developers to focus on equations not on the implementation
of the model.
Once you write a model you compile it separately for each simulator and then you can use
that model in each simulator you don't need to re-implement it for every new simulator.
Now what are legacy device models?
These are basically the devices that are built into the Spice 3 circuit simulator.
Like modern ones take for instance B3, B3, B3, B3, B3, B3, B3, B4 or the classical
Gamble Poon, B-Polar, Junction Transistor, Diode etc.
These models have been in development since 1970s all the way to the 2020s.
And certain integrated circuit manufacturing processes are still characterized in terms
of legacy device models.
For instance if you take DSMC 18 or Skywater they use B3 and B3 and B3 in four models.
Also various discrete devices like for instance the well-known 2N2222 transistor are characterized
by the described with their Gamble Poon parameters.
And if you want to use these models you need Gamble Poon, a compact model in your simulator.
These legacy devices also have an educational value.
These are probably the first devices students come in contact with when they learn about
circuit simulation and they also represent engineering heritage.
As I already mentioned they are implemented in C and they are still being maintained in the
end by circuit simulator.
Now the idea came up to automatically convert these legacy models into a more modern form
into very long A. So the project value A distiller was born and the goal was to write a
converter that is reasonably fast. It does not have to be very fast because you do this
only occasionally this conversion. So we decided for Python 3 as the programming language
and the converter uses the PIC parser library for parsing the C code.
The converter includes a library of abstract syntax 3 manipulation functions
that are used for converting the C code into a very long A.
The converter converts models from the NG Spice premaster 45 branch although theoretically it should
also work for other flavors of Spice and one of its main uses is to track development of
NG Spice models. So whenever somebody in NG Spice fixes a bug in a model it can be immediately
made available in very low A just by running the converter. The converted models are validated so
their output is compared with the built in Spice models and the converted models can then be used
in NG Spice and VA task circuit simulators but they should also work in any other simulator
that supports very low A. Now of course the idea came up to maybe write a wrapper for Spice
models. This is what GNU kept us to introduce Spice models into the simulator.
Now this is actually doable but if you want to do any advanced analysis like harmonic balance
and various advanced RF analysis then you need certain components of the model in the pure form.
You will need the resistive and directive residuals and you will need the Jacobians of these two
residuals but unfortunately Spice computes a combination of the two residuals and the combination
of two Jacobians. So they are not separated. This may be good for classical analysis like DCAC,
transient and noise but for advanced analysis like harmonic balance this is not good enough.
Now how is a Spice 3 model built? What does it comprise? A Spice model let's take for
instance a diode model has a header file where the data structures of the model are defined.
Then you have a C file where you have the list of instance in model parameters.
Next four files contain the instance in model parameter set and getter functions and the remainder
of the files are there for model evaluation. The setup file and temperature dependence file contain
functions that are called only once per each simulation and the bulk of the evaluation is in the
load file where the residuals are computed. The noise model of each device can be found in a separate
file for diode this is the diode noise file and all the rest of the model the model comprises
roughly 15 files or so can be thrown away. It's irrelevant it's redundant information which can
be reconstructed from the files you can see in this slide. Now the conversion engine of the converter
is mostly in place it just needs fine tuning. Currently the resistor capacitor and inductor models
have been converted. Now these are not trivial devices they contain many parasitic effects geometric
etc and that's why the converter actually saves a lot of time because you don't have to implement
that manually in C. Then next the diode model has also been converted. Last week the conversion of
the junction fat model was also completed so this point should be black actually we also validated it
and within a month we expect to have the depolar transistor model also converted. What is left
then is to convert the MOSFET models and advanced junction fat and MOSFET models. Now to see how
good this converter works we did some comparisons. First how big are the data structures of the
converted devices. We compared the instance in model data structures of built in spies devices
and the data structures of models generated by the open VAF compiler from the converted
very low game models. As you can see in the last column some models are some data structures
are slightly bigger, some are slightly smaller but on average they are roughly equivalent.
Then if we compare the size of the generated models to C models the reduction in size is very obvious
it goes from a factor of three all the way up to a factor of five. Now if we recalculate the size
of the model per model parameter a typical C model has from 30 all the way up to 60 lines of
code per each parameter. Once you convert this into very low A the size of a model goes from eight
lines of code up to 16 lines of code per parameter. manually coded models in very low A are very
compact they go all the way down to five or four or five lines of code per parameter.
Another issue of course is also the speed of the converted models. For that purpose we
constructed a simple voltage multiplier using four diodes, four capacitors one resistor and one
voltage source and excited it into a 100 kilohertz sinusoidal signal simulated it for 500 periods
and did some timings. To make comparisons fair the open MP and element bypass were disabled
so that both simulators were on leveled ground and we used open VAF to compile the very
log A models generated by the converter. If you compare the total runtime of the simulation
the VACOSC simulator with the converted very log A models is the fastest of the old three test
cases. Now this can in part be explained by the fact that VACOSC uses fewer circuit evaluations
but this difference in circuit evaluations does not completely explain the difference in timings.
If you are a deeper and observe the time spent in the evaluation and load function of the circuit
we can see that very log A model in VACOSC is roughly 25% to 25% slower than a native
spice model in engine spice. What is surprising here is that engine spice using the same
very log A model spends 25% more time for evaluation than VACOSC with the same model. So there
must be some inefficiency in the implementation of the very log A model interface in engine spice
probably which explains this discrepancy. If we go further down and just observe the time that
is spent in the diode model evaluation we need to instrument the code with timing function calls
and when we do that the difference we get is bigger. The diode model in engine spice is roughly
twice faster than the diode model compiled by OpenVAF when it is used in the VACOSC circuit simulator.
But this last timing is somewhat unreliable because once you instrument the code you change
also to things you also add overheads and you change the cache behavior so we need more testing
to accurately determine how fast the converted models are. Now what's in future for the converter?
First of all certain devices in spice are physically inaccurate. They do not conserve charge.
It's a typical problem of the simple MOSFET models in spice and unfortunately you cannot replicate
the same behavior in very log A because very log A enforcers the kind of modeling where it is impossible
to lose charge. So we will have to replace the original spice models with something newer
like for instance the models by Sakala and others but then these models will only approximate
spice 3 behavior the behavior will no longer be identical. There is also an option to write a new
back end for the converter which would output C or C++ code for particular simulators like size
VACOSC or Gnooka. By doing that we could exactly replicate the behavior of the
spice models but this somewhat defies the whole purpose of the converter. Now by adding or changing
the limit construct in open VAF compiler unfortunately this point is quite limited we could
simplify the models generated by the converter and unfortunately this limit construct is not
capable of doing everything that spice models need when it comes to limiting the voltages in the
model. We had to use some hex to replicate the exact spice behavior and they are simply necessary.
We cannot do without them. Next would be to handle BC3 data structures and BC4 data structures
and then we can convert these models and finally maybe you could also add a bank end that would
output VAGDRAMS models from the original spice models. So this concludes my talk thank you for
your attention and I would also like to thank Anna and Ed for funding this project.
So we have well our next speaker is getting set up. We have time for one or two and
sound like there are some spicy questions out there. Sorry I'll be here all day.
Thank you for this presentation. I have a question about PDK you know it's
okay with the right PDK with the spice models. Oh you plan to do with stats. Excuse me I did not
understand you are sorry. Okay we have releasing free PDK so inside we have a spice for the
transistor models for analog designs or you plan to deal with stats actually. Sorry I still don't
understand you. Okay Skyweter is the fundraiser. Yes and the teaspoon reads by GDS and the
spice for the RF-12 stores and so they discuss this model on the very very big spice file with all
the characteristics. Oh you think you can use this PDK with the spice for simulation inside because
me I have developing a library directly in very long after I transform in spice and I
see me in spice directly. So it is an alternative for I don't need to write a spice library with
proper for using is. This converter is for devices not for PDKs so devices are one level lower than
the PDKs itself devices are the equations which PDKs use for describing individual transistors.
You mean Skyweter provides very low a code? As I was saying this converter does not convert
spice netlist. It converts low level device models from C code into very low a code so that they
can be used in any simulator but it does not convert an individual PDK. Actually I was not thinking
about that but since spice netlist quite simple this could be done. Actually the size simulator
has a converter between various netlist formats it converts these netlets into the size format.
So I guess this could be something one could implement it should not be that hard.