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.
We are inviting attempts to initiate grant funded projects. Joint projects are welcome. We also offer help with your own proposals. For relevant code contributions we can offer paid internships with support from NLnet. Get in touch if you are interested.
Here are some suggestions:
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, roughly easiest to hardest:
One of these is a full summer-of-code project.
For more info, see:
There is already some work done on some of these. It is up to you to decide whether to use it or not.
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 schematic and pcb translator projects have been more difficult than expected. There have been several starts that were never completed. If you want to tackle one of these, dig in ahead of time so you (and we) know what you are getting into. Before applying you should be familiar with gnucap language plugins, the Verilog based intermediate format and also the format you are writing the translator for.
If you are already active in the community of the tool being translated (kicad, geda, or qucs), that will be considered favorably when comparing competing applications.
Gnucap device models are plugins with a well defined interface. Foreign (non-gnucap) models can be used by wrapping with code to map the interface. We have such code for mapping models written for Spice-3 variants. The concept can be applied to others.
One of these is a full summer-of-code project.
There is already some work done on some of these. It is up to you to decide whether to use it or not.
To qualify for one of these projects, you should first be familiar with gnucap's model interface and the other model interface. If you want to tackle one of these, dig in ahead of time so you (and we) know what you are getting into.
If you are already active in the community of the tool being translated (qucs, icarus, verilator, ghdl, system-c), that will be considered favorably when comparing competing applications.
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.
Here are three categories of commands needed:
1. 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.
2. Compatibility with other simulators: We have a lot of the commands already, but maybe not in a compatible form. The idea here is to make a set of commands, many are just variants on what we have, to mimic the scripting capability of another simulator, such as NGspice, Hspice, Spectre, or Qucs. If you want to do this, your application should include an analysis showing that you understand what we have, what they have, and what it will take to get there.
3. Interface to languages and tools. Sometimes it is desirable to write scripts in some known language (Python, Ruby, Perl) or some numeric tool (octave, R). If you want to do this, your application should include an analysis showing that you understand what we have, what they have, and what it will take to get there.
To qualify for one of these projects, you should be a relatively advanced simulator user, already familiar with such scripting. Your proposal will need to list the commands you plan to implement and a reference showing syntax and usage.
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.
Formats needed:
One of these is a full summer-of-code project.
There is already some work done on some of these. It is up to you to decide whether to use it or not.
The gnucap output code is in a state of flux, which will add to the difficulty of these projects.
To qualify for one of these projects, you should first be familiar the target format, at least one application that uses it, and gnucap output code.