Hi there. Thanks for the introduction to Seth. Thanks for accepting the talk and thanks for
organizing this whole thing. I'll talk about Gnukab. We've got this project on very
log AMS which is running for a couple of months, two years now maybe funded by an
internet. David's couldn't calm his flight was cancelled but anyway his input is in this
talk as well and give a quick overview of what Gnukab actually is. It's a circuit simulator
back from back in the days when circuit simulation tools were kind of soaring and then
kind of diffused into companies and were no longer being talked about much. It was put under
GPL license basically to evade license issues. In 2000 when it was also around when it was also
renamed to Gnukab and there was some refactoring and progress later on. It importantly the
move to plugins which allows everyone to use it for their own applications. It was originally running
on Game Boy style CPUs which existed back then and it outpaced the common alternatives which
needed quite big machines. The devices algorithms language is on our plugin so if you have other
devices then we have you just add them, if you have other algorithms just add them and the whole thing
is a small library and basically everything is a plugin so yeah and simulation wise we are past
spice, we do mix techniques for fast analog that means we don't use co-simulation techniques
that we have heard about today and we have a single engine mix signal simulator as known from
some commercial product and model gen is the model compiler that fits this bill and that it has
seen a revamp to the model gen area of things within this project. So on Gnukab the project we
are working on has this Gnukab on one side and the model gen model compiler on the other side and
then obviously need to interact and fit each other some ways and lots of work in the digital
domain and mixed domain has had to be revamped and algorithm had to be adjusted to make it happen
and the stuff that drifted apart what drifted apart we have seen very log 95 which is in
why use for digital simulation and there's analog simulation around as well mainly spice but
some others and there's some middle ground that's not covered very well and the standards that
we are using kind of explains how to implement that how to map how to standardize this stuff
we've defined a schematic interchange format which means we can store schematic in a way
that other tools can use and reuse it. I give examples later the work in progress is on
similar formats for layout and PCB design which means we want to store the relevant stuff in a
file attached to the circuit so we can actually do more advanced stuff in the end.
The the whole spice is part of very log AMS the standard says spice remains accessible very
log A defines ways to to use spice in in in in these very log stuff very log models and
can you have also has the option to use the native sea implementations from from the early days
until spice 50 45 probably so we just use the use the code and wrap it and run it and see
what does it do differently between version so we don't need to reimplement that.
Yeah we need a sauce language because any tools use different languages for doing very basic stuff
and especially the in between here and standards defined the best practice for for the exchange
and why why these standards because so many people are behind it and because it's working in
industry as everyone can see so we are not doing system very long yet but we have areas where
whether it would really be helpful because there are new ideas in system very long that make it
easier so I've just put some characteristics on this slide the way I understand stuff and on the
GNUCAP column here you mainly see plugins everywhere that means if it doesn't work the way we do
and you can do better you plug it in or plug in something else and it might work better and then you show us
so we don't have this problem of maintaining 15 different ideas for for doing one thing
and yeah I mean these tables have kind of it's more of a I don't know that's the way people
present stuff and I can say the latest stuff we did this year sorry last year was
making the solvers pluggable so we don't need to have this built in solver which had problems
I have a much faster solver I don't want it to be standard I want to experiment with it it's
it's there for you you can load it if you want you don't need to load it if you don't want and
it's just doing a UD composition and everything else is also plugins so the model compiler similar
situations the other part of the other side of the coin so we generate C++ code we compile it we
do it this has been ongoing since very before very log has even been defined and my collaborator
is on these very log standard documents named as an author so his experiments with model gen
actually influenced how the standard looks like and now we've most of very log a covered which
means yeah there are some gaps obviously and I'm working on it and the new stuff since last
months or so is we have look up tables to do completely discrete modeling like tables with
question marks and zeros and ones the ones you know from very log 95 and we will extend this and
go go further of course but we need to start somewhere and the connect module generation is pending
and we use a hardware at one and algorithms won't change a lot but we need to generate code for
them as well in the end and model gen doesn't generate code for other simulators there was no
not much interest there are other other model compilers in use and it's better if you use the
genug cap interface in your simulator if it doesn't have a device interface yet here's again this
nice table the nose you see here I mean it's a bit unfair because nobody says they work on
very log A or they work on very log AMS at all so this is this is basically a status report on on our
progress and importantly we do param set we do param set both in the simulator and in the
and in the model compiler which is important for identifying which device goes into which spot
in the schematic when simulating or when doing other stuff and in in the model compiler it's
it's also used to prune stuff flood for constants before even compiling so you can combine
parameter values which become constants before you compile a model and stuff like that so
the advanced stuff well discrete models yeah we have the lookup tables we will have more as we go
and everyone asked me is that generate yeah we are working with a generate is the mechanism in
very log allows to script to script automatic expansion of of device topologies and stuff and
that's intended but it's it's harder obviously the always block is what corresponds to the analog
block and it will be there as soon as it's there so crux is is a is a graphical user interface
genug have doesn't have a graphical user interface yet and it was never intended to have one
but it turned out that we managed to revive the crux project after a long pause and we
resolve the stalemate only last year in December because David wanted to help us and I thought
him just do this and we have a format that stores schematics in a way that you can read and that you
can use another tool so you can get your data out of quarks now getting it back in yeah we're working on
and the lot less round trip and then just moving on to the next format will be done
that's that's the work in progress and translating other other tools schematics into something that
that we can read is also on schedule the device library format will basically
exploit the parameters mechanism so you can actually have your schematics your device model separate
from each other and then do the stuff that Christopher has explained but also from big signal
circuits like he is the device library he has my schematic do something with it and the
the device library format will then also be available in quarks so we have a playground now
we have portable devices we have self documenting devices it's a bit fiddly to use still
but it's just the user interface you can just export and go full pinook app if you want
and there's some devices available particularly we have logic aid primitives from from the
standard we have the spice primitives mostly covered these are mentioned in NXE that's the
stuff that will replace spice net listing or spice device models and some devices I implemented
in native very log A as a demo for you to modify and and do your own stuff with it and they are just
playing portable very log devices that were hardwired in in in the quarks simulator back in the days
and they will become a kind of user library that you can then embed into his schematic or
ship separately or whatnot this is a demo and so we have a full mixed signal simulation
which means the simulator decides what role which node plays here this is very stupid and I just
started using this schematic editor a week ago and everything else we have all the complex
circuits are handwritten and they just use they are to use those tests there's something
interesting about demo circuits the the worst is the circuit is the better example it is
because you want your simulator to find problems in your circuit you don't want to know the results
and then see if the simulator agrees so this one you could easily do by hand and write a net
list which is now very log I save you the I save you the attributes for for markup like this
device is here that device is there there's a wire here you can see that in the repo we have
test cases that dump the schematic and the schematic dump is tracked in the version control system
and that's the 5 format we we think makes sense you can still read it even with the attributes
and in this case the the library here there's an ant gate and an organ which is just a
subcircuit that wraps logic primitive defined in the very lot 95 standard R and C of course
not that's just yeah so it's a big project I'm one person we have David now we have L on the team who
invented all this we could need some help really and having this graphical user interface
might make a difference I don't know if you like text it is more as I do send us your text
and implement other stuff we need more data exchange in different applications so we have
only quacks and the data project covered now and a very locked up in keycat would be nice
in the end and in other tools as well questions thanks for listening
thank you for this beautiful presentation me I have a micro library with the space and I work with
very log and black box which uses I can generate space but I need to maintain a space
library me it's a lot of pain yes it's very locked I am as I can make a bridge between
very log 95 and very log A and for example using the space directly the very log A of the
EHP PDK so yes it's a pain to to work with a space netless and how are we going to solve this
does that paraphrase your question and yes my idea is to turn very locked up circuits
into very long sorry spice sub circuit blocks into very locked modules which is something I want
the model compiler to do as an alternative input format it's planned and it's it's an official task
and I'm trying to work on it if you can help and that would be amazing yes thank you
another question you mentioned dumping the output in keycat what do you need for that
as a starting point dump the schematic into a netless into no into a schematic into a
the schematic file format is a very log you can think of it as a netless but a net is a is a
first level object so it's a component and attributes give the markup information so which pin is
where and where are the ports and what are the symbols that's all markup and if you drop
everything except the the very log without the attributes you get a netless that is standard
very log and reflects the circuit you were you were wanting to talk about
there's yet another question thank you it's very interesting what the very log is I never
thought before sorry it's very interesting about very log is schematic yes I never
ever before so it's the creep like a black box for having a graphic modules on the schematic
but oh you keep the information about the plus and wrote by very log S works by adding
meta data to a circuit like positions and symbols used and they will have to be specified in
the way an application once the once to use them for example in gdr you would add an attribute
gdr symbol is that file and in quacks you would say the quacks model sorry the quacks device
name is resistor you would put that into an attribute which you can safely ignore further down the
road but when interchanging stuff interchanging schematics between tools these attributes are meant to
be preserved so you you open it with a different editor which supports the format you save it you can
save it back in in another tool and the attributes are still there so you can still color this
resistor red this wire green and this symbol still looks like an operation amplifier in the other
tool you can standardize further but that's maybe not needed I don't know so we we just a stick
to application ways of dealing with markup thank you thank you thank you very much thank you
thank you