WEBVTT 00:00.000 --> 00:10.240 Hi there. Thanks for the introduction to Seth. Thanks for accepting the talk and thanks for 00:10.240 --> 00:17.280 organizing this whole thing. I'll talk about Gnukab. We've got this project on very 00:17.280 --> 00:24.120 log AMS which is running for a couple of months, two years now maybe funded by an 00:24.120 --> 00:30.680 internet. David's couldn't calm his flight was cancelled but anyway his input is in this 00:30.680 --> 00:38.200 talk as well and give a quick overview of what Gnukab actually is. It's a circuit simulator 00:38.200 --> 00:43.960 back from back in the days when circuit simulation tools were kind of soaring and then 00:43.960 --> 00:51.640 kind of diffused into companies and were no longer being talked about much. It was put under 00:51.640 --> 00:59.720 GPL license basically to evade license issues. In 2000 when it was also around when it was also 01:00.280 --> 01:06.840 renamed to Gnukab and there was some refactoring and progress later on. It importantly the 01:06.840 --> 01:13.800 move to plugins which allows everyone to use it for their own applications. It was originally running 01:13.880 --> 01:25.560 on Game Boy style CPUs which existed back then and it outpaced the common alternatives which 01:25.560 --> 01:32.520 needed quite big machines. The devices algorithms language is on our plugin so if you have other 01:32.520 --> 01:38.600 devices then we have you just add them, if you have other algorithms just add them and the whole thing 01:38.600 --> 01:47.320 is a small library and basically everything is a plugin so yeah and simulation wise we are past 01:47.320 --> 01:53.480 spice, we do mix techniques for fast analog that means we don't use co-simulation techniques 01:53.480 --> 02:00.200 that we have heard about today and we have a single engine mix signal simulator as known from 02:00.200 --> 02:08.200 some commercial product and model gen is the model compiler that fits this bill and that it has 02:08.280 --> 02:18.680 seen a revamp to the model gen area of things within this project. So on Gnukab the project we 02:18.680 --> 02:24.120 are working on has this Gnukab on one side and the model gen model compiler on the other side and 02:24.120 --> 02:31.880 then obviously need to interact and fit each other some ways and lots of work in the digital 02:31.880 --> 02:38.120 domain and mixed domain has had to be revamped and algorithm had to be adjusted to make it happen 02:39.080 --> 02:46.120 and the stuff that drifted apart what drifted apart we have seen very log 95 which is in 02:46.120 --> 02:53.320 why use for digital simulation and there's analog simulation around as well mainly spice but 02:53.320 --> 03:01.400 some others and there's some middle ground that's not covered very well and the standards that 03:02.040 --> 03:11.640 we are using kind of explains how to implement that how to map how to standardize this stuff 03:11.640 --> 03:16.840 we've defined a schematic interchange format which means we can store schematic in a way 03:16.840 --> 03:25.080 that other tools can use and reuse it. I give examples later the work in progress is on 03:25.080 --> 03:32.040 similar formats for layout and PCB design which means we want to store the relevant stuff in a 03:32.040 --> 03:39.080 file attached to the circuit so we can actually do more advanced stuff in the end. 03:40.280 --> 03:48.040 The the whole spice is part of very log AMS the standard says spice remains accessible very 03:48.120 --> 03:58.040 log A defines ways to to use spice in in in in these very log stuff very log models and 03:58.840 --> 04:06.680 can you have also has the option to use the native sea implementations from from the early days 04:06.680 --> 04:16.760 until spice 50 45 probably so we just use the use the code and wrap it and run it and see 04:16.760 --> 04:21.560 what does it do differently between version so we don't need to reimplement that. 04:24.920 --> 04:30.840 Yeah we need a sauce language because any tools use different languages for doing very basic stuff 04:31.640 --> 04:41.720 and especially the in between here and standards defined the best practice for for the exchange 04:41.720 --> 04:47.880 and why why these standards because so many people are behind it and because it's working in 04:47.880 --> 04:54.840 industry as everyone can see so we are not doing system very long yet but we have areas where 04:54.840 --> 04:59.400 whether it would really be helpful because there are new ideas in system very long that make it 04:59.480 --> 05:08.360 easier so I've just put some characteristics on this slide the way I understand stuff and on the 05:08.360 --> 05:15.880 GNUCAP column here you mainly see plugins everywhere that means if it doesn't work the way we do 05:15.880 --> 05:22.520 and you can do better you plug it in or plug in something else and it might work better and then you show us 05:23.240 --> 05:29.960 so we don't have this problem of maintaining 15 different ideas for for doing one thing 05:31.160 --> 05:43.880 and yeah I mean these tables have kind of it's more of a I don't know that's the way people 05:43.960 --> 05:51.160 present stuff and I can say the latest stuff we did this year sorry last year was 05:51.160 --> 05:56.280 making the solvers pluggable so we don't need to have this built in solver which had problems 05:56.280 --> 06:02.440 I have a much faster solver I don't want it to be standard I want to experiment with it it's 06:02.440 --> 06:07.160 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 06:07.880 --> 06:15.480 it's just doing a UD composition and everything else is also plugins so the model compiler similar 06:16.440 --> 06:24.760 situations the other part of the other side of the coin so we generate C++ code we compile it we 06:25.320 --> 06:34.040 do it this has been ongoing since very before very log has even been defined and my collaborator 06:34.040 --> 06:40.440 is on these very log standard documents named as an author so his experiments with model gen 06:40.440 --> 06:45.640 actually influenced how the standard looks like and now we've most of very log a covered which 06:45.640 --> 06:54.920 means yeah there are some gaps obviously and I'm working on it and the new stuff since last 06:54.920 --> 07:00.920 months or so is we have look up tables to do completely discrete modeling like tables with 07:01.000 --> 07:06.520 question marks and zeros and ones the ones you know from very log 95 and we will extend this and 07:07.880 --> 07:14.280 go go further of course but we need to start somewhere and the connect module generation is pending 07:14.280 --> 07:24.040 and we use a hardware at one and algorithms won't change a lot but we need to generate code for 07:24.040 --> 07:31.320 them as well in the end and model gen doesn't generate code for other simulators there was no 07:31.320 --> 07:38.200 not much interest there are other other model compilers in use and it's better if you use the 07:38.200 --> 07:45.400 genug cap interface in your simulator if it doesn't have a device interface yet here's again this 07:45.400 --> 07:52.040 nice table the nose you see here I mean it's a bit unfair because nobody says they work on 07:52.040 --> 08:01.160 very log A or they work on very log AMS at all so this is this is basically a status report on on our 08:01.160 --> 08:09.000 progress and importantly we do param set we do param set both in the simulator and in the 08:10.440 --> 08:17.560 and in the model compiler which is important for identifying which device goes into which spot 08:17.560 --> 08:25.800 in the schematic when simulating or when doing other stuff and in in the model compiler it's 08:25.800 --> 08:31.640 it's also used to prune stuff flood for constants before even compiling so you can combine 08:33.080 --> 08:37.960 parameter values which become constants before you compile a model and stuff like that so 08:39.400 --> 08:46.360 the advanced stuff well discrete models yeah we have the lookup tables we will have more as we go 08:46.440 --> 08:53.800 and everyone asked me is that generate yeah we are working with a generate is the mechanism in 08:53.800 --> 09:05.480 very log allows to script to script automatic expansion of of device topologies and stuff and 09:06.280 --> 09:14.200 that's intended but it's it's harder obviously the always block is what corresponds to the analog 09:14.200 --> 09:22.040 block and it will be there as soon as it's there so crux is is a is a graphical user interface 09:22.040 --> 09:27.880 genug have doesn't have a graphical user interface yet and it was never intended to have one 09:27.880 --> 09:34.600 but it turned out that we managed to revive the crux project after a long pause and we 09:34.680 --> 09:42.760 resolve the stalemate only last year in December because David wanted to help us and I thought 09:42.760 --> 09:52.600 him just do this and we have a format that stores schematics in a way that you can read and that you 09:52.600 --> 09:59.560 can use another tool so you can get your data out of quarks now getting it back in yeah we're working on 10:00.520 --> 10:06.360 and the lot less round trip and then just moving on to the next format will be done 10:09.240 --> 10:15.320 that's that's the work in progress and translating other other tools schematics into something that 10:16.520 --> 10:21.480 that we can read is also on schedule the device library format will basically 10:22.440 --> 10:28.920 exploit the parameters mechanism so you can actually have your schematics your device model separate 10:29.000 --> 10:35.240 from each other and then do the stuff that Christopher has explained but also from big signal 10:35.240 --> 10:42.200 circuits like he is the device library he has my schematic do something with it and the 10:43.720 --> 10:48.840 the device library format will then also be available in quarks so we have a playground now 10:49.800 --> 10:56.520 we have portable devices we have self documenting devices it's a bit fiddly to use still 10:57.160 --> 11:03.000 but it's just the user interface you can just export and go full pinook app if you want 11:03.880 --> 11:11.560 and there's some devices available particularly we have logic aid primitives from from the 11:11.560 --> 11:21.480 standard we have the spice primitives mostly covered these are mentioned in NXE that's the 11:21.480 --> 11:31.240 stuff that will replace spice net listing or spice device models and some devices I implemented 11:31.240 --> 11:39.560 in native very log A as a demo for you to modify and and do your own stuff with it and they are just 11:39.560 --> 11:47.560 playing portable very log devices that were hardwired in in in the quarks simulator back in the days 11:47.560 --> 11:53.640 and they will become a kind of user library that you can then embed into his schematic or 11:54.440 --> 12:00.920 ship separately or whatnot this is a demo and so we have a full mixed signal simulation 12:01.880 --> 12:10.680 which means the simulator decides what role which node plays here this is very stupid and I just 12:10.680 --> 12:18.200 started using this schematic editor a week ago and everything else we have all the complex 12:19.480 --> 12:26.360 circuits are handwritten and they just use they are to use those tests there's something 12:26.360 --> 12:35.080 interesting about demo circuits the the worst is the circuit is the better example it is 12:35.080 --> 12:40.200 because you want your simulator to find problems in your circuit you don't want to know the results 12:40.280 --> 12:48.440 and then see if the simulator agrees so this one you could easily do by hand and write a net 12:48.440 --> 12:56.680 list which is now very log I save you the I save you the attributes for for markup like this 12:56.680 --> 13:02.040 device is here that device is there there's a wire here you can see that in the repo we have 13:02.040 --> 13:10.440 test cases that dump the schematic and the schematic dump is tracked in the version control system 13:11.160 --> 13:19.000 and that's the 5 format we we think makes sense you can still read it even with the attributes 13:19.960 --> 13:27.400 and in this case the the library here there's an ant gate and an organ which is just a 13:27.480 --> 13:35.640 subcircuit that wraps logic primitive defined in the very lot 95 standard R and C of course 13:35.640 --> 13:45.480 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 13:45.480 --> 13:54.280 invented all this we could need some help really and having this graphical user interface 13:55.240 --> 14:03.720 might make a difference I don't know if you like text it is more as I do send us your text 14:05.640 --> 14:14.440 and implement other stuff we need more data exchange in different applications so we have 14:15.080 --> 14:20.840 only quacks and the data project covered now and a very locked up in keycat would be nice 14:22.120 --> 14:29.800 in the end and in other tools as well questions thanks for listening 14:29.960 --> 14:48.440 thank you for this beautiful presentation me I have a micro library with the space and I work with 14:48.440 --> 14:55.240 very log and black box which uses I can generate space but I need to maintain a space 14:55.240 --> 15:02.760 library me it's a lot of pain yes it's very locked I am as I can make a bridge between 15:02.760 --> 15:11.080 very log 95 and very log A and for example using the space directly the very log A of the 15:11.080 --> 15:20.520 EHP PDK so yes it's a pain to to work with a space netless and how are we going to solve this 15:20.520 --> 15:29.000 does that paraphrase your question and yes my idea is to turn very locked up circuits 15:29.720 --> 15:36.520 into very long sorry spice sub circuit blocks into very locked modules which is something I want 15:36.520 --> 15:45.480 the model compiler to do as an alternative input format it's planned and it's it's an official task 15:45.560 --> 15:57.000 and I'm trying to work on it if you can help and that would be amazing yes thank you 15:57.000 --> 16:06.680 another question you mentioned dumping the output in keycat what do you need for that 16:06.680 --> 16:13.960 as a starting point dump the schematic into a netless into no into a schematic into a 16:13.960 --> 16:20.040 the schematic file format is a very log you can think of it as a netless but a net is a is a 16:20.040 --> 16:26.920 first level object so it's a component and attributes give the markup information so which pin is 16:26.920 --> 16:34.040 where and where are the ports and what are the symbols that's all markup and if you drop 16:34.040 --> 16:41.560 everything except the the very log without the attributes you get a netless that is standard 16:41.560 --> 16:47.080 very log and reflects the circuit you were you were wanting to talk about 16:51.640 --> 17:00.920 there's yet another question thank you it's very interesting what the very log is I never 17:00.920 --> 17:08.600 thought before sorry it's very interesting about very log is schematic yes I never 17:08.600 --> 17:18.920 ever before so it's the creep like a black box for having a graphic modules on the schematic 17:18.920 --> 17:24.520 but oh you keep the information about the plus and wrote by very log S works by adding 17:24.520 --> 17:33.000 meta data to a circuit like positions and symbols used and they will have to be specified in 17:33.000 --> 17:39.800 the way an application once the once to use them for example in gdr you would add an attribute 17:39.800 --> 17:48.920 gdr symbol is that file and in quacks you would say the quacks model sorry the quacks device 17:48.920 --> 17:55.400 name is resistor you would put that into an attribute which you can safely ignore further down the 17:55.400 --> 18:03.240 road but when interchanging stuff interchanging schematics between tools these attributes are meant to 18:03.240 --> 18:09.000 be preserved so you you open it with a different editor which supports the format you save it you can 18:09.000 --> 18:14.360 save it back in in another tool and the attributes are still there so you can still color this 18:14.440 --> 18:21.640 resistor red this wire green and this symbol still looks like an operation amplifier in the other 18:21.640 --> 18:27.880 tool you can standardize further but that's maybe not needed I don't know so we we just a stick 18:27.880 --> 18:41.960 to application ways of dealing with markup thank you thank you thank you very much thank you 18:44.360 --> 18:47.560 thank you