WEBVTT 00:00.000 --> 00:13.500 Okay, so welcome to the open hardware dev room in case you're wondering which one you 00:13.500 --> 00:14.700 wandered into. 00:14.700 --> 00:21.280 Our next talk is going to be on the VACASC and the Verilogue A distiller. 00:21.280 --> 00:27.760 So our pod, Berman, is going to talk to us about building a device library for this. 00:27.760 --> 00:40.480 So please welcome our pod. 00:40.480 --> 00:42.480 Thank you. 00:42.480 --> 00:52.280 I'm going to talk about a converter from Spice model format into Verilogue A. 00:52.280 --> 00:57.920 The motivation for this converter was a new circuit simulator, VACASC. 00:57.920 --> 01:05.160 It's an analog circuit simulator and its device library is mostly built with Verilogue 01:05.160 --> 01:06.160 A models. 01:06.160 --> 01:13.440 It uses the OpenVAF Verilogue A compiler and the simulator strictly separates models from 01:13.440 --> 01:17.280 analysis, just like most model simulators do. 01:17.280 --> 01:23.440 This is with the new C++, the code is clean and the simulator is fast. 01:23.440 --> 01:29.280 The roadmap for VACASC includes improvements to harmonic balance analysis, addition of RF 01:29.280 --> 01:36.720 analysis, then support for automated binning, parallel evaluation of elements parallel 01:36.720 --> 01:42.520 linear solver, improvements to these convergence, mixed mode simulation, now this is all 01:42.520 --> 01:45.800 just wishes, of course, at this point. 01:45.800 --> 01:52.600 What I'm going to talk about today, support for legacy Spice devices. 01:52.600 --> 01:58.760 If we compare VACASC to other free open source simulators, it roughly positions itself 01:58.760 --> 02:10.480 between size and NG Spice according to its features and its weak point currently is the device 02:10.480 --> 02:16.760 library, it lacks classic Spice 3 device models. 02:16.760 --> 02:19.040 Now what is a compact device model? 02:19.040 --> 02:24.240 It's a collection of equations that describe the behavior of an individual device, like 02:24.240 --> 02:29.160 for instance a diode, a B-polar transistor or a MOSFET. 02:29.160 --> 02:38.360 In past the defective standard for describing such models was the Spice API and models were written 02:38.360 --> 02:40.000 in C. 02:40.000 --> 02:45.760 Now whenever you wanted to implement such a model in any other simulator that was not 02:45.760 --> 02:49.400 Spice 3, you had to re-implement that model from scratch. 02:49.400 --> 02:54.400 That means you had to write like a few thousand up to a few ten thousand lines of code 02:54.400 --> 02:56.360 per each model. 02:56.360 --> 03:03.000 The current defective standard is very log A for compact models and to use a very log A model 03:03.000 --> 03:07.840 you just need a very log A compiler and your simulator must know how to use these compiled 03:07.840 --> 03:11.440 models and your set to go. 03:11.440 --> 03:19.560 Very log A is a harder description language, it's used for analog circuit description 03:19.560 --> 03:25.240 and it can also be used for describing compact models for that purpose you only need a subset 03:25.240 --> 03:28.240 of very log A. 03:28.240 --> 03:33.040 What is nice about very log A that is that models in very log A are short typically 03:33.040 --> 03:37.360 like five lines of code per each parameter. 03:37.360 --> 03:43.880 And another nice thing about very log A is that you don't have to worry about derivatives. 03:43.880 --> 03:51.080 Very log A compilers generate all the derivatives automatically so you can skip all the error 03:51.080 --> 03:54.040 problem manual coding. 03:54.040 --> 03:58.160 This makes it possible for developers to focus on equations not on the implementation 03:58.160 --> 04:00.240 of the model. 04:00.240 --> 04:06.200 Once you write a model you compile it separately for each simulator and then you can use 04:06.200 --> 04:13.200 that model in each simulator you don't need to re-implement it for every new simulator. 04:13.200 --> 04:16.000 Now what are legacy device models? 04:16.000 --> 04:22.120 These are basically the devices that are built into the Spice 3 circuit simulator. 04:22.120 --> 04:27.480 Like modern ones take for instance B3, B3, B3, B3, B3, B3, B3, B4 or the classical 04:27.480 --> 04:31.800 Gamble Poon, B-Polar, Junction Transistor, Diode etc. 04:31.800 --> 04:38.680 These models have been in development since 1970s all the way to the 2020s. 04:38.680 --> 04:44.080 And certain integrated circuit manufacturing processes are still characterized in terms 04:44.080 --> 04:46.680 of legacy device models. 04:46.680 --> 04:54.200 For instance if you take DSMC 18 or Skywater they use B3 and B3 and B3 in four models. 04:54.200 --> 05:00.440 Also various discrete devices like for instance the well-known 2N2222 transistor are characterized 05:00.440 --> 05:02.920 by the described with their Gamble Poon parameters. 05:02.920 --> 05:09.800 And if you want to use these models you need Gamble Poon, a compact model in your simulator. 05:09.800 --> 05:13.160 These legacy devices also have an educational value. 05:13.160 --> 05:17.400 These are probably the first devices students come in contact with when they learn about 05:17.400 --> 05:22.440 circuit simulation and they also represent engineering heritage. 05:22.440 --> 05:26.440 As I already mentioned they are implemented in C and they are still being maintained in the 05:26.520 --> 05:30.120 end by circuit simulator. 05:30.120 --> 05:35.560 Now the idea came up to automatically convert these legacy models into a more modern form 05:35.560 --> 05:43.400 into very long A. So the project value A distiller was born and the goal was to write a 05:43.400 --> 05:48.920 converter that is reasonably fast. It does not have to be very fast because you do this 05:48.920 --> 05:55.000 only occasionally this conversion. So we decided for Python 3 as the programming language 05:55.080 --> 05:59.960 and the converter uses the PIC parser library for parsing the C code. 06:01.720 --> 06:06.360 The converter includes a library of abstract syntax 3 manipulation functions 06:08.360 --> 06:14.280 that are used for converting the C code into a very long A. 06:15.320 --> 06:22.760 The converter converts models from the NG Spice premaster 45 branch although theoretically it should 06:22.840 --> 06:31.000 also work for other flavors of Spice and one of its main uses is to track development of 06:32.200 --> 06:39.560 NG Spice models. So whenever somebody in NG Spice fixes a bug in a model it can be immediately 06:39.560 --> 06:47.400 made available in very low A just by running the converter. The converted models are validated so 06:47.480 --> 06:54.680 their output is compared with the built in Spice models and the converted models can then be used 06:54.680 --> 07:00.680 in NG Spice and VA task circuit simulators but they should also work in any other simulator 07:00.680 --> 07:10.760 that supports very low A. Now of course the idea came up to maybe write a wrapper for Spice 07:10.840 --> 07:17.320 models. This is what GNU kept us to introduce Spice models into the simulator. 07:18.840 --> 07:25.880 Now this is actually doable but if you want to do any advanced analysis like harmonic balance 07:25.880 --> 07:35.480 and various advanced RF analysis then you need certain components of the model in the pure form. 07:36.360 --> 07:42.120 You will need the resistive and directive residuals and you will need the Jacobians of these two 07:42.120 --> 07:48.680 residuals but unfortunately Spice computes a combination of the two residuals and the combination 07:48.680 --> 07:56.280 of two Jacobians. So they are not separated. This may be good for classical analysis like DCAC, 07:56.280 --> 08:02.280 transient and noise but for advanced analysis like harmonic balance this is not good enough. 08:03.080 --> 08:13.160 Now how is a Spice 3 model built? What does it comprise? A Spice model let's take for 08:13.160 --> 08:19.960 instance a diode model has a header file where the data structures of the model are defined. 08:20.680 --> 08:25.640 Then you have a C file where you have the list of instance in model parameters. 08:26.440 --> 08:35.720 Next four files contain the instance in model parameter set and getter functions and the remainder 08:35.720 --> 08:44.360 of the files are there for model evaluation. The setup file and temperature dependence file contain 08:44.360 --> 08:51.720 functions that are called only once per each simulation and the bulk of the evaluation is in the 08:51.800 --> 09:01.320 load file where the residuals are computed. The noise model of each device can be found in a separate 09:01.320 --> 09:09.080 file for diode this is the diode noise file and all the rest of the model the model comprises 09:09.080 --> 09:18.760 roughly 15 files or so can be thrown away. It's irrelevant it's redundant information which can 09:18.760 --> 09:27.640 be reconstructed from the files you can see in this slide. Now the conversion engine of the converter 09:27.640 --> 09:35.480 is mostly in place it just needs fine tuning. Currently the resistor capacitor and inductor models 09:35.480 --> 09:42.520 have been converted. Now these are not trivial devices they contain many parasitic effects geometric 09:43.160 --> 09:51.560 etc and that's why the converter actually saves a lot of time because you don't have to implement 09:51.560 --> 09:59.080 that manually in C. Then next the diode model has also been converted. Last week the conversion of 09:59.080 --> 10:06.760 the junction fat model was also completed so this point should be black actually we also validated it 10:06.760 --> 10:13.400 and within a month we expect to have the depolar transistor model also converted. What is left 10:13.400 --> 10:22.040 then is to convert the MOSFET models and advanced junction fat and MOSFET models. Now to see how 10:22.040 --> 10:28.760 good this converter works we did some comparisons. First how big are the data structures of the 10:28.840 --> 10:35.080 converted devices. We compared the instance in model data structures of built in spies devices 10:35.800 --> 10:42.040 and the data structures of models generated by the open VAF compiler from the converted 10:42.040 --> 10:49.960 very low game models. As you can see in the last column some models are some data structures 10:49.960 --> 10:54.520 are slightly bigger, some are slightly smaller but on average they are roughly equivalent. 10:55.480 --> 11:08.200 Then if we compare the size of the generated models to C models the reduction in size is very obvious 11:09.560 --> 11:17.160 it goes from a factor of three all the way up to a factor of five. Now if we recalculate the size 11:17.320 --> 11:27.320 of the model per model parameter a typical C model has from 30 all the way up to 60 lines of 11:27.320 --> 11:35.880 code per each parameter. Once you convert this into very low A the size of a model goes from eight 11:35.880 --> 11:43.320 lines of code up to 16 lines of code per parameter. manually coded models in very low A are very 11:43.320 --> 11:49.160 compact they go all the way down to five or four or five lines of code per parameter. 11:52.360 --> 11:59.080 Another issue of course is also the speed of the converted models. For that purpose we 11:59.080 --> 12:05.240 constructed a simple voltage multiplier using four diodes, four capacitors one resistor and one 12:05.240 --> 12:12.120 voltage source and excited it into a 100 kilohertz sinusoidal signal simulated it for 500 periods 12:12.120 --> 12:21.800 and did some timings. To make comparisons fair the open MP and element bypass were disabled 12:21.800 --> 12:31.880 so that both simulators were on leveled ground and we used open VAF to compile the very 12:31.880 --> 12:37.800 log A models generated by the converter. If you compare the total runtime of the simulation 12:37.960 --> 12:47.240 the VACOSC simulator with the converted very log A models is the fastest of the old three test 12:47.240 --> 12:55.480 cases. Now this can in part be explained by the fact that VACOSC uses fewer circuit evaluations 12:55.480 --> 13:02.040 but this difference in circuit evaluations does not completely explain the difference in timings. 13:03.000 --> 13:12.600 If you are a deeper and observe the time spent in the evaluation and load function of the circuit 13:14.040 --> 13:23.400 we can see that very log A model in VACOSC is roughly 25% to 25% slower than a native 13:23.400 --> 13:29.800 spice model in engine spice. What is surprising here is that engine spice using the same 13:29.880 --> 13:39.960 very log A model spends 25% more time for evaluation than VACOSC with the same model. So there 13:39.960 --> 13:49.960 must be some inefficiency in the implementation of the very log A model interface in engine spice 13:49.960 --> 13:57.240 probably which explains this discrepancy. If we go further down and just observe the time that 13:57.320 --> 14:05.080 is spent in the diode model evaluation we need to instrument the code with timing function calls 14:05.880 --> 14:14.520 and when we do that the difference we get is bigger. The diode model in engine spice is roughly 14:14.520 --> 14:24.040 twice faster than the diode model compiled by OpenVAF when it is used in the VACOSC circuit simulator. 14:24.360 --> 14:30.120 But this last timing is somewhat unreliable because once you instrument the code you change 14:30.120 --> 14:38.040 also to things you also add overheads and you change the cache behavior so we need more testing 14:38.040 --> 14:46.040 to accurately determine how fast the converted models are. Now what's in future for the converter? 14:46.920 --> 14:56.200 First of all certain devices in spice are physically inaccurate. They do not conserve charge. 14:56.200 --> 15:02.440 It's a typical problem of the simple MOSFET models in spice and unfortunately you cannot replicate 15:02.440 --> 15:09.480 the same behavior in very log A because very log A enforcers the kind of modeling where it is impossible 15:09.560 --> 15:24.920 to lose charge. So we will have to replace the original spice models with something newer 15:25.880 --> 15:34.040 like for instance the models by Sakala and others but then these models will only approximate 15:34.040 --> 15:40.760 spice 3 behavior the behavior will no longer be identical. There is also an option to write a new 15:40.760 --> 15:48.200 back end for the converter which would output C or C++ code for particular simulators like size 15:49.320 --> 15:55.880 VACOSC or Gnooka. By doing that we could exactly replicate the behavior of the 15:55.960 --> 16:10.680 spice models but this somewhat defies the whole purpose of the converter. Now by adding or changing 16:12.680 --> 16:23.720 the limit construct in open VAF compiler unfortunately this point is quite limited we could 16:23.800 --> 16:31.480 simplify the models generated by the converter and unfortunately this limit construct is not 16:31.480 --> 16:39.640 capable of doing everything that spice models need when it comes to limiting the voltages in the 16:39.640 --> 16:47.000 model. We had to use some hex to replicate the exact spice behavior and they are simply necessary. 16:47.000 --> 16:55.480 We cannot do without them. Next would be to handle BC3 data structures and BC4 data structures 16:56.360 --> 17:03.000 and then we can convert these models and finally maybe you could also add a bank end that would 17:04.040 --> 17:11.400 output VAGDRAMS models from the original spice models. So this concludes my talk thank you for 17:11.400 --> 17:15.640 your attention and I would also like to thank Anna and Ed for funding this project. 17:17.000 --> 17:26.760 So we have well our next speaker is getting set up. We have time for one or two and 17:26.760 --> 17:33.000 sound like there are some spicy questions out there. Sorry I'll be here all day. 17:37.160 --> 17:41.480 Thank you for this presentation. I have a question about PDK you know it's 17:41.480 --> 17:51.800 okay with the right PDK with the spice models. Oh you plan to do with stats. Excuse me I did not 17:51.800 --> 18:00.600 understand you are sorry. Okay we have releasing free PDK so inside we have a spice for the 18:00.600 --> 18:08.440 transistor models for analog designs or you plan to deal with stats actually. Sorry I still don't 18:08.520 --> 18:19.960 understand you. Okay Skyweter is the fundraiser. Yes and the teaspoon reads by GDS and the 18:19.960 --> 18:31.560 spice for the RF-12 stores and so they discuss this model on the very very big spice file with all 18:31.640 --> 18:41.400 the characteristics. Oh you think you can use this PDK with the spice for simulation inside because 18:41.400 --> 18:46.840 me I have developing a library directly in very long after I transform in spice and I 18:46.840 --> 18:55.560 see me in spice directly. So it is an alternative for I don't need to write a spice library with 18:55.560 --> 19:08.600 proper for using is. This converter is for devices not for PDKs so devices are one level lower than 19:08.600 --> 19:19.000 the PDKs itself devices are the equations which PDKs use for describing individual transistors. 19:19.080 --> 19:35.880 You mean Skyweter provides very low a code? As I was saying this converter does not convert 19:35.880 --> 19:45.240 spice netlist. It converts low level device models from C code into very low a code so that they 19:45.240 --> 20:04.520 can be used in any simulator but it does not convert an individual PDK. Actually I was not thinking 20:04.520 --> 20:13.720 about that but since spice netlist quite simple this could be done. Actually the size simulator 20:13.800 --> 20:22.840 has a converter between various netlist formats it converts these netlets into the size format. 20:22.840 --> 20:28.040 So I guess this could be something one could implement it should not be that hard.