All right, Felix, you ready?
All right.
Good morning.
Our first talk of the day is from Felix.
Felix is a researcher and free software supporter currently working on the Vera
Log AMS in GNUCAP with funding from NL nets.
Thanks, Felix.
Thank you.
Thanks, Chris, for the introduction.
Thanks for organizing this event.
Thanks, everyone, for coming at this early hour.
I would like to talk about GNUCAP again,
and what happened since last first and basically,
giving a quick summary.
And thanks to NL nets,
most, because this wouldn't happen without NL nets.
There was lots of tinkering before
and it came entering the scene.
And I think that's an important aspect of this whole thing.
So an extra thanks goes to Amsterdam.
And so what is this about?
The GNU circuit analysis package is a small package.
We do circuit analysis.
We extend the library with plugins,
which I will explain in a bit.
And it was originally meant as a different spice,
like simulator to simulate stuff,
but on smaller machines, smaller hardware demands,
and stuff.
And it brought a model compiler,
which allowed you to describe models
and run them with your simulation.
And the bit of the extra here is,
we do post-spice simulation.
We use new algorithms, new concepts,
and towards mixed simulations,
and doing things faster than other simulators do.
And it started in 1990 with ACS.
That's else circuit simulator Alice.
As here, he couldn't join us last year,
but if you have questions to him,
you can ask him maybe not after the session.
He released his software in 2001 under GPL license
to avoid patent issues.
And that's maybe part of the deal.
We have stuff that others don't,
and others would like to have,
but don't.
And L decided to move to plugins 10 years after
in order to make it more kind of community friendly.
Without funding, that wasn't possible,
and funding started three years ago.
And so why circuits?
We simulate circuits,
it's part of the design process of chips,
and everything that depends on chips, PCBs,
or circuits in general.
And we want more of them,
and commercial tools do this all the time,
and free software is a bit lagging behind.
And part of the problem is missing standardization.
There's been some standardization work
in programming languages in the past decades,
which kind of missed out on circuit simulation
and hardware description.
And everyone, it invents their own hardware description language.
And some companies set together and decided to write up a standard
to simulate, or to verify first,
the circuit relevant models
and came up with very log 95,
and everyone probably knows from small logic simulations.
And later variants have come up,
and people have kind of collectively created models
or could exchange data and simulate them,
and do similar things with similar results.
And a very log AMS is the analog mixed signal extension
for very log 95,
which adds what spies had to the very log 95,
and adds some interconnect layers,
and modeling for stuff in between the analog and digital domain.
And we just do it that way,
because we have no time to reinvent the wheel.
Plugins, everyone knows plugins from Linux, from Python.
We do it basically the same way.
We have an interface that loads plugins.
We allow everyone to build their own plugins.
We don't care what they do really.
And if you have plugins, you can share them with others
and let others run your stuff.
You don't need to bother with upstream development,
or you don't need to bother with completing them.
You have a proof of concept.
You can talk about it.
You can present it.
And we have some existing examples,
some of which are built into the main repository.
And we have some satellite repositories or branches with other stuff.
And the new stuff that has happened since last,
for us them is we have now we have no ordering plugins,
because no ordering is a hard problem.
Everyone who can do better will come and do better.
Show us your plugin.
We have a KLU plugin, KLU is one of these general purpose matrix solvers,
which turned out to be nice for small analog circuits.
And we are waiting a new version of KLU.
We already have the interface for it.
And whatever you want to do.
So we have these goals here at the standardization,
the very log model gen.
The support for very log AMS splits into the simulator support
and the model compiler support.
And we want to kind of make other people standardize their workflows
to make tools more transparent and stuff.
And that's why the first topic today is five formats again.
And the second and third topic is about advancements in the simulator
and model compiler.
And I've got some working progress on stuff,
particularly other people jumping on board and doing great stuff.
And I want to get into that a bit.
So why do we need a file format for data interchange?
It has been puzzling many for many years,
but to build a chip or anything more complex,
you need multiple tools and you want to get your data across.
And when you watch circuit designers,
there's one group that uses commercial tools.
The commercial tools are driven by armies of developers who write converters
and nobody in the open source or free software world
can be really bothered with,
I don't know, with catching up really.
So everyone catches up but in different directions.
So there's no common denominator and it's a bit of a mess.
And people are validating data exports more than they do real work.
And the other problem is the one way conversions.
You do a conversion one way, you send some schematic to some simulator
and you never get it back into the schematic.
And then you start inventing workarounds for that.
And that's just the example I want to get into in more detail now.
And a schematic is nothing but the circuit,
but it does have coordinates attached to it.
So why not just use circuits instead of drawings.
And drawings is something that you can forget.
If you miss out on a drawing, it's still the circuit that you want to design.
And the syntax we chose for this proposed format is based on very log
because it has a history in this area, very log 95.
I mean, that's a year, that's like 30 years ago and more.
And if you do it that way, you could use the same circuit and just go with it.
And a very log S is the kind of standard extension name that we dub it very log S
because it's very log and it has some extras.
The S is schematic and there has been early work as early as 2012.
There was a summer of code student who started to try and import Gida plugins
which prompted L to think about it more and he gave a talk here 10 years ago.
And we put it on our proposal in 23 to extend on that work and build up this standard document,
which is now a means partly complete,
but it works the way you would need it for what we want to do.
And we have support in the simulator and model compiler for so-called same party vices,
which I will go and explain in a bit.
And it's also very log S support in a satellite project that David did from what was that.
He's also NGI funded and he wanted to use Quacks for schematic editing stuff
and used Nukep and we kind of collaborated on some patches to Quacks.
And then there's very log S support there now which is usable but not complete.
And I hacked on this Nukep Gida project which came out of this group of summer of code project in 2012
and we do have non-circuit item support so you can have proper schematics with everything attached to them
and go back and forth between different presentations.
And what else is there that needs doing.
Lapton is what was GDA, GDA and or Gida and we were talking about adding very log S support to that too
and they're political problems with that.
It would be nice if somebody took over Quacks and finished that work
and other schematic editor programs should also move forward.
So the same party vices that we have added support to.
Yeah, what are nets? In spice nets don't exist.
In schematics nets are like drawings and lines and in very log 95 or surprise,
they have been standardized and they have a proper meaning and they are supported.
And implemented since forever in tools that do discrete digital stuff.
And it hasn't been propagated to the analog folks unfortunately,
which means we can't really, we can't do much with schematics without nets.
In Quacks there are kind of traces in the code that indicate that it might have been intended.
We have hacked that and it's not working.
And very log has this nice description for a same port device which just means we have name ports
and we have internal nodes in the module.
And we can connect them anyway we want which also gives it which already gives us a net.
And every schematic has these everywhere.
And now we can represent them so our schematic becomes circuit.
I mean the drawing.
So the simulator has worked weight.
This was the file format and data exchange.
So this is the next topic and advancements in the simulator.
Most of it was algorithmic and low level stuff that we have added.
And some is actually visible to users.
We have this circuit topology stuff supported in full.
So you can now read in the schematics last year at first them.
I said oh there's this work around and we can simulate quacks stuff and stuff.
And now we can actually read in the files that quacks saves and simulate them.
We have integration methods selection which I will explain.
We have data shared across identical devices which is important for scaling.
Some minor stuff that yeah the node orderings are plug-able.
That was a kind of a bigger lift but it's not as user visible.
It's something that researchers might be interested in.
And the matrix interface and stuff.
And you can now pass big spicy net lists which kind of choke the system.
Because why would we want to do that anyway.
But now it's possible.
There are still working towards the advent driven stuff.
And all the other very log AMS features related to that.
The messages it will come.
It's on my list.
It's on my desk.
It's more than half finished.
It's much more finished than last year.
And yeah we are on track.
It's not easy because if it was easy it would be called football.
I don't know.
So let's go to the algorithms here.
The nets.
In practice these nets have different models.
So we want them to be first class devices in a model for different reasons.
One is we want them to be a drawing and mischematic.
It doesn't really, we don't really know what users will do with them.
The application is going to decide and whether a net is a transmission line or a short
really depends on what analysis you're going to do.
So we need them explicit regardless and we have this module net.
We can use, we can do the schematic drawings.
And this union find algorithm is now in place in the in the library.
And it curves out the actual technology of the circuit that is needed.
And we have added these spice style things.
I mean we do have this spice subsystem in GNUKAP because the very log stand at one step.
It's not because spice is fun.
But we want to support spice.
And if you have a spice net list, we basically want to run it or understand it.
It's unmodified.
So you don't need to change your data.
You can just keep using it the way it is.
The integration method selection is a deeper problem from signal processing.
In analog simulation, you have this problem with time steps and integration method.
Integration methods, if you have like capacitors or coils in your circuit,
and something has inertia and stuff you need to integrate stuff.
And there are different methods that represent the rule.
I mean it's like if you integrate and you measure the area under your curve,
you can use this trapezoidal method.
And it's very nice if your signals are clean and smooth.
And fast allows for big time steps.
And if there is a king, it is continuity.
Some discrete signal saying, oh no, this signal is suddenly something else.
It starts ringing because of high frequency components and stuff.
And people from the spice world have come up with some other methods that damps out discontinuities.
They call it gear.
And they switch to gear whenever it rings.
And they do it globally.
So the whole circuit now runs with gear.
And then dissipates energy.
So the results are suddenly questionable.
So we need to make choices here.
And in GNUKAP, this choice was made like 30 years ago that we need this option per device on the user level.
And not for someone who can write a C model for each case or for each stuff it does.
So we can now select the integration method at a fine granularity at the user level.
And for this, we need the very log input language because the very log input language has support for system parameters.
And system parameters can have extensions.
So we can add an extension that does that.
And for large simulations, this would be necessary.
And so we are moving ahead with stuff we need for large mix simulations.
And that concludes my simulator stuff that is new.
And I'm going to explain a bit more about the model compiler.
Model compiler kind of extends the whole system by the behaviors.
The subset support for very log AMS.
Behavioral modeling support is the bit in very log AMS that allows you to describe your devices using differential equations and assignments and delays and operators and stuff.
And in order to run them, you need to turn them into byte code.
We turn them into C++ code.
We compile them with GCC and we load them into Gnucab as plugins.
And model gen very log is the part that turns behavioral descriptions into C++ code.
And that can be loaded.
And the work we are doing here is based on the model gen, which is the original model compiler,
which coincidentally has influenced the way very log AMS looks now, but nobody has finished it.
So it's kind of a good set up, but the model gen was analog only and there was no AMS features back in the day.
Model gen very log now covers most of their log A.
And whatever that means really very log A is the kind of weird animal,
because when some say very log A they mean spice.
We mean very log A as in NXE of the LRM, which means analog stuff plus events.
And the growing a very log AMS support.
Yeah, it goes towards the features that that digital design has known from Icarus like delayed assignments and stuff.
This is on the way and working on it.
So the connectivity overhaul is already explained already.
I already explained also touches the model compiler and the code generation for same pod devices and stuff.
I mean same pod devices just one example.
It just means you can connect whatever to whatever in a hierarchical way and get the simulation out of it.
That it would that you would want to simulate.
And we have been prompted to add random number generation.
Oh, there's a typo. You can keep it.
Random number generation is important when you do micro electronics like semiconductor devices,
mismatch simulation stuff, which is something someone else wants to do.
So I added random number generation first.
I had to drop something else, but this is this is ready and kicking now.
And the data type framework has been streamlined and extended.
So we have the three very log basic data types.
Real string and integer now supported.
And I think they should work in all places now.
You will prove me wrong if you can.
And I can fix it, but that's basically there now.
Strings are great if you want to describe stuff or if you want to print out messages from devices that just monitor something.
And then you can say all this device has a problem or it's overheating and stuff or you can.
You can use strings to select devices.
If you have identifiers in devices that enable or disable features and then have a selection process.
Interges are pretty clear.
I mean, we need integers to do the very log 95 feature set.
And the hierarchical references.
That's a bit of an interesting one.
And very log has a concept of peeking into other devices during expansion and elaboration to do things like global variables or process parameters and stuff.
And that mechanism is dubbed hierarchical reference.
And it is exactly what you would think.
To something else and something else and you want to grab it and that's your oxide thickness.
Whatever.
And for the designer to actually specify this in a convenient place and not use some script that turns your circuit upside down in order to make all oxide thicknesses random.
And we can do it in any way using the standard procedures with hierarchical references.
And there's some other feature now the storage type in appearance, which is only performance related.
It doesn't really add anything, but it will make larger simulations feasible.
And I will get into that in a bit.
The storage type.
Very log AMS has variables in each device variables can be used for different things.
The user doesn't need to specify so the compiler needs to make guesses.
And variables can be device states.
I mean, they can be in between device states like nodes and stuff, but these are explicit.
The device states themselves are implicit.
And the other thing is if you have two identical devices, they can share memory.
If there are some constants in them that are model related.
And the ones that are neither of those two types are temporary and you don't need to store them.
So that also saves memory.
And it all depends on the assigned use pattern of variables.
If you read a variable before you actually set it, the simulator assumes that you mean the status of that variable from the previous time step.
Or from the time stuff.
And that assigned use pattern needs analysis.
And we do this now.
And there's a heuristic implemented in the model gen.
And it's a heuristic because exact computation.
Well, do we want that?
It might be possible, but it will have a horrendous runtime.
And in most cases, wild constructions are not used.
We can't move me wrong.
We can gradually extend this if needed.
But just to get started and make everything else work.
I think that's pretty pretty good already.
And we need less storage in the components because of the shared storage.
We don't store temperatures anymore.
And we don't store all states as not.
We don't store all variable values as states in each instance of every device, which obviously reduces overhead.
And that's another thing we need for scaling up.
And what else do I have?
Yeah, the topic for is the related work.
And it's really fun because people are suddenly coming and want to do stuff with new cap.
And we have set up continuous integration, which I will go into in the next slide.
We have this model's repo, which is kind of an old repository.
It has it shows models from other projects that run with GNU cap and it shows how to how to link them together, how to load them, how it provides unit tests for them.
So we actually have regression tests on models from other projects.
And we do numerical cross validation.
That means someone did it and that was quite fun because most of the time everything just matched what others have computed.
And the one case was a bug.
So we fixed one bug.
And that is going to lead into another, and it's such a like project about generic test benches.
So we have test benches formulated in a way that would run in different simulator environments under different conditions and with different models and whatever you want.
So the generic is the idea and there's an OSDI wrapper in production, which I cannot present yet.
And the IHP, the Institute for what is it high performance processing in Frankfurt, they have a chip factory, they have a PDK, they open PDK.
The IHP open PDK is some low voltage stuff.
They want to support GNU cap and support their PDK for using GNU cap.
Which is the other point where I give some details and a bit.
So the continuous integration is thanks to Eric at common caretakers.
He dropped by gave this idea, he had some scripts together and this is running.
So in order to grow we need a contribution process.
Everyone can contribute by writing their own plugins, but if you want to submit the bug, you would expect CI or something.
And there's some structural hassle.
I mean we have these repositories all over the place.
And we need to find the common denominator and make it work nicely.
And we need you as contributors in the end.
I mean you can even contribute some free resource structure ideas that would be fun to discuss this with people from other domains or just getting some insight.
I mean I do this as a sideline Eric does this as a helping hand.
There's lots of work to do to make this work cleanly.
We are now set to do this on codebook because codebook is the only same platform these days.
And we don't need code, code pilot, nonsense and stuff.
And the models and validation, the models repo.
We do have the old Spice 3.5 C code that runs with GNU cap and it shows how to do that.
We have wrappers for this.
We have all these NG Spice releases lined up in different branches.
I mean the main branch only has NG Spice 17 as a golden reference and the current.
And the Berkeley university has, oh that's supposed to be a capital B in Berkeley, sorry.
They have released their C code for Spice models back in the days and this also runs with GNU cap.
GNU cap is the only simulator that runs the code and modified by the way.
And so we can run the Berkeley models and show what the results are.
There's this compact modeling coalition that has raised some attention and they collect very low A models for different devices.
Like PSP and there are some some other some some resistor and lots of transistor devices that make good test cases for us.
And there's lots of work in progress adding them to the repository.
We are currently doing trying to generalize the process and make it streamlined.
In the end we want you to be able to clone the repository type make and see all the nice binaries for these.
For these coalition compact model coalition plugins as well as the old Spice devices that you can all combine together in your simulation if you like that.
And the regression testing has shown up to be useful.
And this is everyone needs regression tests.
And when we change the solvers to new stuff we also want to know that it still works with the Spice 3F5 models.
So we need that to validate every single step we take.
And we already found a bug in NG Spice to a model gen using this process.
I mean bugs that are more than trivial.
Like that's not a semicolon bug but.
And if we added other devices from other from other projects we might find some others.
So the cross validation is thanks to Lucas.
He has got some internet funding to make nice pictures with comparison plots and numerical tolerance checks for various devices.
He looked particularly into the very log A stuff because that would catch the problems we have in origin.
And here you see some plots he showed me some noise analysis.
And this noise is just the numerical error exponent which means low error.
And here this oscillator trajectory at transient outputs.
They just basically match exactly with something another simulator would give you.
And I want to extend this.
We want in the end we want to use very log S for these test cases because very log S allows you to visualize the circuits and allow you to not modify them for simulation.
So you actually see what you get and not some weird mix of things and you don't need extra tools so you can.
You can even map very log S to spice.
I mean if you know how to very log has attributes you can use attributes to to attach spice meta data.
And you can turn it into a spice netless to feed into NG spice.
So very log S is the format that should be used for schematics.
And the separate project is on the way it's not fully agreed yet.
But this is something Lucas is doing.
Lucas is also working on the OSDI wrapper.
That's a file format or interface format from the OpenGAF project which has stopped when the author has been hired by a company.
That needs it and they have really fast compilation for analog models.
They were the target was the these compact models and millions of lines of code.
No, thousands of lines of code of behavioural stuff.
And I have a method that is much faster than what we have in terms of compilation but they only do spice.
So why not also do this?
And we have wrappers.
We know how spice works.
Lucas is getting into the meta right now and he's working on this wrapper.
And that would allow you to just add another animal to the zoo.
And the IHP PDK that's the stuff in Frankfurt.
Christoph has picked up some stuff.
Peppin has uploaded and we are collaborating to mix cell libraries and he's finding bugs.
I'm adding features.
It's a nice collaboration.
And that will lead to official support for canoe cap in that PDK eventually.
And that's basically all I have.
I mean this is really testing new features and allows me to spot gaps.
And he says I want this point at page in the LRM and the language reference manual and says I want this feature.
And I'm on the thanks slide already.
So if you want to join us or if you want to try you can get started on the weekly on the mailing list chat.
And if you want to do stuff, there's funding from an internet.
It might be more funding than I can use myself.
And yeah, thanks for listening and thanks for coming.
And do you have any questions?
We really don't have time for questions.
So you can.
Yes.
No question time is up.
Yeah.
So we're moving on to the next.
I'm around just just feeling to meet you outside.
Thank you.
Thanks Felix.