Gnucap is inviting anyone to take on projects. Most of them involve creating plugins. All of them create something that is identifiably yours, that will be noticed. Most of them will stretch your skills a bit. If you want to learn about simulation, beyond what you can get at school, this is the place.
For “summer-of-code” we expect a full time commitment with regular checkins and discussion on the gnucap-devel list. It is a good idea to introduce yourself and discuss the projects well in advance, before formally applying. We will favor those that do join in before, who become part of our development community, team players, people who will stick around to maintain it and do more after the summer is over.
Here are some suggestions:
We need a better way to display output waveforms. All we have now is “gwave” which is not part of gnucap and hasn't been maintained.
Two paths make sense:
1. Creation of a new program to replace (or update) gwave. It needs to be able to grow to meet future needs. It also needs to interface to gnucap so it can be used interactively. For a Summer of Code project, a well designed expandable program that does what gwave does would be great. It could be written in C++ and use GTK for its graphics. Or it could be written in a modern interpreted languauge like Python or Ruby. For a great project, you would have expansion plans well beyond what you actually do this summer.
2. Interfacing to “octave”. The program “octave” has much of the needed capability, but it is like a programming language, so it doesn't meet the user's need for a simple way to see simulation outputs. The raw capability is there, so how about an interface to use octave under the hood and provide the needed interactive simple interface.
Some other simulators have a scripting language with lots of commands. One example is the “nutmeg” part of Spice. Gnucap has the mechanism, but only a few commands are implemented.
A possible summer of code project would be to implement a set of these commands. One or two commands would be a very easy project, too easy for a whole summer. A bunch of these commands, would be a great project.
Here are some possible command sets:
1. Decision functions: We need the ability to do loops and decisions in a script. It could be “spice compatible”, “Hspice compatible”, C-like, Verilog-like, or some other form. If you have one it is easy to make the others.
2. Wave processing: We need the ability to do math on waveforms. This would include addition, multiplication, convolution, time-shifting, and others. The “WAVE” class has a lot of what you need built-in, and can be extended, so part of this is already done.
These plugins, combined with “output compatibility” plugins will allow gnucap to be used as a drop-in replacement for commercial simulators in some applications.
Other simulators often provide interactive help. A help command for gnucap would display a help text that is contained with the respective plugins. One part of the project is implementing this command and a suitable interface for plugins to provide help and documentation. Another part is collecting and filling in the information that cannot be generated automatically. It will then be possible to generate a section of a manual for a set of plugins.
Beyond that, plugins should carry examples that are browsable interactively. (Some of) these examples may also be used as test cases for the simulator. This will positively affect the test coverage and the motivation to write test cases for user contributed plugins.
The only output format supported by gnucap has been a generic ASCII format that is compatible with most spreadsheets and general purpose programs like octave and gnuplot. We need more specific formats, to support some more special purpose post-processor tools. The most obvious here is a Spice “rawfile” format. There are both binary and ASCII formats, many of them. Some are similar enough that if you have one, a trivial change gives you another. The most requested seems to be the “HSpice” format, and the Tiburon format, which are often used as references. These are similar, and the Spice3f5 format is close enough to be a trivial edit away.
These plugins, combined with “command compatibility” plugins will allow gnucap to be used as a drop-in replacement for commercial simulators in some applications.
The “language plugins” allow gnucap to read and write different netlist languages. They can also provide the capability to directly read and write the formats of schematic and layout programs such as gEDA and Kicad.
The formats in need of support, grouped by priority:
Formats that are
crossed out are already works in progress.
These plugins, when used with gnucap, will provide an interface for smooth interoperation. When used with gnucap's translation utility (a subset of gnucap), they will provide the ability to translate from any supported format to any other, and also to a Verilog based intermediate language that can be used as a neutral, nonproprietary exchange format.
In the past, the interface projects have been more difficult than expected. If you want to tackle one of these, dig in ahead of time so you (and we) know what you are getting into.