 So, thank you for being here. My name is Guilherme, and I'm representing QCCS, the Quiet Universal Circuit Simulator. As I know, the first name was actually QT, from the QT framework, but they got a message that, well, it's not related to QT, please change the name, so they changed to Quiet Universal Circuit Simulator. So, my talk is about an overview and the status of the development and some remarks, and if time allows, I will show you some short demo of what the tool is about. So, the project started in 2003. It was created in T.U. Berlin by Michael Magraff and Stefan Jan. The first one created the user interface. The second one created the solver or the engine. It was from the beginning, GPIO 2+. To date, it has more than 20 contributors. It's translated into about 20 languages. It's cross-platform, and the user base is varied. It's from education, from researchers, hobbits, and even the industry. You have some stats here for the website that was there from 2005. Number of downloads. This is from Sourceforge, where the code is hosted since the beginning. The binary is in the source, the tar balls. On the graph below, we have the account for Windows binaries that were released 13 days ago. So, we have roughly 400, 300 downloads weekly for this part with the Windows binary. I mentioned that the original creators, they are no longer active on the project. Around 2011, 2012, they dropped the project, so it went orphaned, and the community adopted it. The main features. It's basically a schematic capture, a simulator, and it has data visualization built in. It has an equation system for pre- and post-processing of the signals. It has a component library, which is also parameterized with common components. It has also design and synthesis tools. For modeling, if you want to write models, it has some features to import. It's quite limited on the constructs that it can handle. It has a built-in component that's called Equation Define Device, which is quite powerful because you can really rewrite the equations for, say, a transistor model in this kind of even graphical fashion, which is quite handy for development. It also has a very low-gay model builder or loader, and it has some post-processing capability that you can export data in NuCap or Python or Octave. The dependencies that we have, it's C++, Qt4. We're still struggling to remove Qt3 from the source, but we are working on that. It builds with AutoTools and CMake and GIPR for the simulator, and the parsers are also written in FlexBison. We depend on ADMS for the VeryLogA part, and the documentation, most of it is written in LaTeX. There is some experimental work, or I would say external work that's not in the mainline, which is this fork. It's called QXS, which is by Vadim Kuznetsov and Mike Brinson, the first one from Russia, the second one from the UK, which is a pretty full-featured spice front-end based on the QX schematic capture. It can work with NG Spice, Zeiss and Spiceopus. They made up VeryLogA generators that work with these Equation Define devices that you can make your device graphically and then generate a VeryLogA code. They also made recently some extensions for X Spice, so they can also, in a similar fashion, make C code that can be linked into NG Spice, for instance, and Spiceopus, I guess. The previous speaker, Felix, mentioned Gnuk Satter, which is one effort that he started to make a replacement engine based on Gnukap for QX Satter. There is also an effort that we saw this year. This user, he has a tool that translates into G-Schem, and he managed to import the schematics from QX into a G-Schem, so that's interesting. For support for the project, we have the main website. At the moment, we have account six active maintainers or developers. It's me. It's Claudio. That's Nitaly. Vadim in Russia. Felix, that's here. That's located in UK now, but from Germany. Andres, that's in Spain. And Mike Brinson, that's in UK. I think it's a quite good documentation, especially the tutorials and the technical manual. You can find on the website. They are very well written and cover quite a lot of ground. We have, yeah, a tradition. We have most things on SourceForge, for example, the binaries. We have the Git repository, but we are gradually phasing it out in favor of GitHub. We still have the issue tracker enabled there. And the form is sometimes active, and the mailing list is also hosted there. On GitHub, most of the work is happening there now, and most of the issues are also there. We ported the wiki from SourceForge when it was disabled into GitHub, and from there, we also enable continuous integration with Travis and Upvail for Linux, OS X, and Windows. So if you look into the package, what kind of tools do you have there? As graphical interface, you have Qt, which is the schematic capture, and then you have design tools or helpers that is for active filter attenuators, passive attenuators. It has a beauty editor that we are phasing out as well. It has a tool for developing passive filters. There is a small help tool that's being also phased out in favor of read the docs documentation online. There is a matching tool. There is the library, and there is a small resistor to color conversion codes that's useful for students. And there is also transmission line calculator. In Tota, we have, now it's less, but it was 170 components. We removed some non-GPL components recently, but we are adding new components for RF, so the count is about the same. From the common line, you can access Qt, which is the interface, the schematics. You can use the Qxator, which is a simulator, and Qxconf, that converts between formats, also imports the spice netlist into the Qxator native netlist. And we also interface to third-party tools, like ASCO, which is an optimizer, ADMS XML, which does the Verlach A to code, or C++ conversion that we need to run the models. We can run from the schematic, Verilog, free HDL that we are working to replace by GHDL, hopefully for the next release. And there are some conversion tools from PSPies to Spice, and then you can also run, there is a dock where you can run Octave directly from the user interface, and Python is mostly script for parsing the data. I will show quickly these screenshots, but I also brought them in the end. So this is the main interface you have on the left. You can have many projects, as many projects as one. This reflects your working directory, you sync with the file system. You can have different contents for each project. And then on the right, you can have either circuits or in-line visualization, or you can have also separate tabs only for visualization. So you can make quite nice looking documents to document your simulations or models. So we have a component tab where you can drop down most of the building components. And you have libraries which are either Spice-based or parameterized, parameterization of the building components. And yeah, as I said, you can have a nice separate documentation or visualization tab for documenting, if you like, or simply to look good. A few of the tools, this is merged on the latest release. It's for developing or designing active filters. So you input the parameters and then it visualizes for you the schematic. And then on the press of calculate and copy to kilter part, you can just paste it into your schematic and have it running on the simulator. Similarly, you have these passive attenuators that there is a whole range of simulators that you can input there and get the schematic ready for simulation. We had that, which is the help, very simple, like introductory help that's now migrated to that website. This is going to be removed. Then we have also these matching ports that then you have the library where you have, you can drag and drop the components from this dialogue or from the doc that you have on the user interface. And this is the calculation from colors to value or value to colors. It was okay. Then you have transmission line calculation. There are new components that are coming on for the next release, but it has a dozen of components that can be already now used for transmission lines calculations. Then you have also the passive filters. And as I said, what can you do? You have what can you use from the common line? So the user interface can be used for generating the net list for a schematic. It can also print the schematic. And there are some comments to dump the components that we have. So this could help if you are looking to extracting the component descriptions. You can hack into that to do it. The simulator supports DC transient AC S parameter. And harmonic balance is just for resistors, capacitors and inductors at the moment. I highlighted here S parameter because this is, to my knowledge, one of the only tools that does that on the open source directly. You can do with AC simulations, but this is a built-in feature of the tool that's it's where it started also. The first comments of the simulator and the user interface were to accommodate S parameter. And the Quaxconf is a tool that converts between a few formats that I used to visualize or to convert net lists and library components. And yeah, this is a bit of the problem that we might talk later on the panel that we have custom file formats for the schematic, which is the same for the library. And also the net list and the data files. There are plain text files that are also custom. So we might work on that to collaboration. It's a bit difficult. It makes more difficult because of that. Okay, on the front of Verilag A, we had quite a lot of models. We still have quite a lot of models. However, due to licensing issues, we had to remove three of the industry standard models. They were a bit like BSD, three clause licenses which are incompatible. And we stripped them out from the repository. We are now moving them to a non-free repository. You got a bit of a backlash from the model developers, but there is nothing you can do. It's incompatible. We removed. Same thing with ADMS. There were headers that were proprietary to Accelera, which is the organization that handles the standard. So me and Felix, we stripped those headers and we rewrote new headers. And we re-licensed ADMS to as a GPL 3 plus. Considering Verilag A and QX, there is a limitation that this construct is not yet supported. But for most things, you can compile BCM6 and some other very complicated models. Okay, they run slowly because our engine is kind of slow, but it runs. And it's mostly accurate compared to commercial simulators. We might have to compare against a new cap now. And, okay, I have a demo, but I will just close this slide so I will go as time allows to the demos. These are the same demos from last year, but just for the ones that are here to get a feeling of how the tool behaves. So I have this circuit with a parameter sweep, a macro model, optimization. That's a kind of thing that would be interesting to see as an output to a layout tool because these micro strips are basically traces on a PCB or another substrate. So this is something that we could work with a layout tool to get it exported. That's quite interesting. So how you can do some Verilag and VHL simulations. And, okay, to wrap up the slides, .19 was released. Mostly bug fixing, cleanups, ongoing parting from Q3 to Q4. There is this new tool that's the main new thing that we have. We did integration, a bit of regression testing. We removed the non-GPL. We adopted a new git branching model because before that we were merging everything into master and it was kind of untidy. Now we have master only for releases and we have develop for development. And on this release cycle we closed roughly 160 issues, regressions and things like that. For the next release we coordinated a bit better the efforts and we are prioritizing some RF components and microwave components that were developed by Andres. And there is also a tuner feature that you can slide values and rerun the simulation. As I mentioned, removal of Quax editor and Qx help. We hope for a quick release, but there is also other things that are on the pipeline like Felix is implementing a way of loading similar to NuCap things into the user interface which might help us on the future. And this is the status for the development. And okay, I just put it here for the PDF. You have all the links you might want here. This is also interesting. We are now getting more and more translations on this translation platform which is nice as then helps us on localization of the tool. And the final remarks, the project as a whole aims to be very user friendly. We have advanced components and modeling features. We are open to collaboration. We hope to use more of the tools that we have available and enter into the flow of the working flow of more people. And your help is most welcome. I do have a few examples I would just show. So as I mentioned, we have this tab here with the projects. Then I have five minutes, right? Just show one example. So ideally you pick up your components from here. We have a library of components. But this is already configured. So we have on the contents this schematic. I will close this now. So yeah, this is a simple example where you can enable and disable parameters like that. So in this moment the value of this resistor is being picked up from this equation. These equations can be quite complicated. They are pre-processed and then sent to the simulator. And then you can run this NAC simulation. You get a short transcript of this over. And then just like that you can toggle that parameter into a parameter sweep and then rerun it. Then you get this visualization online here. I will show you maybe another project. This is how we skip. This is the one I mentioned about micro strips. So this is perhaps not the best frequency. This is for 10 gigahertz. But you can also do micro strips at lower frequencies that can be easily manufactured on PCBs if you want. And this is something I would like to see pushed forward on the layout side. And it's quite quick to run. So this is the SP parameters of this bandpass filter. The window. Then we have, yeah, the intention. This is a very log. It can also, so in this case we have this very log file here. And here you have the description of the very log. Then it wraps it into a test bench and it ships it to Icarus. And then you can run it. Yeah, it has some warnings because the wrapper is not properly done. But then you have the counter here. It's visualized here. I have to fix this. Never tried a small screen. And a simple example of very log A. Here we have the equations defining a resonating tank because we don't have the V assignment. We do a trick here to transform the inductor as a gerator. But that's beyond the point. And then you can basically build this model. So it's going to kick in ADMS in the background, generate C code, C++, then run the compiler. And then you can, you predefined the symbol for this text. Then you can load it. Then you can assign an icon to it. And then you can now open this schematic. Let me full screen this. So here we have the equivalent into primitives. And here you have the equivalent from the very log A. And then you can just run it. Then it runs some warnings. And yeah, it is just the error from the two curves. But this is the idea is to have a very streamlined workflow to load components into the user interface as well into the simulator. But that could be streamlined further because these manual steps, they're not necessary. As Felix showed before, we can have comments on your net list that make this machinery all into the simulator itself. So we are working to either replace that or to streamline this process. So as a closing note, QXIS is about schematic and simulation. We don't have any PCB. We don't have the concepts of footprints. So to do that, we have to interact with other projects. And if you want to see that happening, please help us. So if you have questions. So the question is, to what degree our custom net list is compatible to Spice? It's not. It's a different format altogether. Worse than that, our components are primitives of our simulator. Our components or the models are only available at the moment. Some of them are only available into QX. So if you want to run that into a Spice-like, you have to first move it, the components to a Spice engine. So it's a dual problem. It's not only the net list description but also the availability of the underlying models that are not there. So yeah. Can you work with vendor models? So the question is if you can use vendor models. That depends. If you can import Spice descriptions, sometimes you can translate into the built-in components of QX, then it works. But as long as you have more complicated Spice descriptions like those poly functions there, we don't have the conversion built-in so that will not work. So for simple models, yes. Do you have a release schedule for removing the QT? The question is if we have a schedule for removing the Q3 support. No, because we work on our free time. So the release is ready when it's ready. Not for the next release. The next release is a short one. It's mostly for merging these RF features that Andres needs for his work. So maybe for the next release, I have an experimental branch where most of these Q3 things are removed but they need work. They need work. They need fine tuning. So maybe one year. Can you repeat the question? Do you discuss those RF and microwave tools that you plan to add in the next release? So the question is what are the tools for RF and microwave that are going to be introduced on the next release? I don't know them all but I know that there is a tapered waveguide. There is a circular transmission line, a cylindrical transmission line. There are mostly new components. There are no new tools so to say but there are new components that are going to be integrated. So the question is about the micro strips. What would take it to make a transient signal integrity simulation like? Most of the RF components are only defined in frequency domain. So you would have to have some way of converting that back to time domain. So that's not there. So the question is if you extract parameters from the board. If you do as parameter extraction, you could do signal integrity analysis, for instance. If you want to evaluate the signal integrity at the pins of your chip and you do the extraction of that, you get as parameter or yeah, then you can do signal integrity on that. I saw people from history doing that. We had a request to increase the number of ports on the SP files that we could handle just to run this kind of simulation on these multi-pin chips that they're out there. Students, my main question is why would I invest time in learning kukes instead of spending time on just standard spice? What does kukes offer me that spice will not? So the question is why invest time in kukes instead of using a spice? Note that spice is the engine, right? So we have, there is a divide between the schematic entry and the engine, right? So yeah, if you want to really, that's also a problem for me. I don't want to be in this black hole where you dump your schematics, your knowledge, your IP and you cannot get out anywhere. So at the moment we are working together to be able to port one schematic to one project or another as it should be, right? But what can I say? If you need the tools that we have, maybe other tools don't have it. Like the modeling capabilities that we have, for research it's interesting. So as a hobbyist that you need to get the models from the internet, maybe it's not the best use case. We run out of time but I think this will be a subject of discussion in the discussion session after the next talk. So thank you again.