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.
Here are some suggestions:
Icarus Verilog has some support for Verilog-AMS syntax. In the long run, we intend for the vvp run-time to support analog/Mixed Signal simulation, but in the short run we can get some use by having a code generator that turns a Verilog-A/MS into a compiled model for gnucap. Even when we get our own analog runtime, this would be of continuing use to gnucap users.
This task generally remains clear of the Icarus Verilog core, although there may be need to improve support for missing features in the ivl_target API. This task will also require some knowledge of how to compile models for gnucap. The multiple-discipline knowledge needed increases the difficulty. Adding new expression operator types, if desired, will involve Icarus Verilog parser and elaboration knowledge and can increase the overall difficulty. –Stevewilliams 17:01, 5 February 2009 (UTC)
The “language plugins” allow gnucap to read and write different netlist languages.
A separate program that will accept two language plugins, and a translation plugin, will provide a universal stand-alone translator.
We need “language plugins” to import and export file formats used by other programs. In addition to being used by gnucap, they will be used as part of a more general EDA language translation facility. Formats needed: VHDL, gschem, PCB, kicad, Orcad, QUCS, gerber, ….
This is not a complete list. A few of them would make a good summer project.
The most difficult part of this project is studying and understanding the formats being imported.
You can use the existing plugins for Verilog, Spectre, and Spice as examples. The first one will take a while to learn the system, but after that they should be easy.
Gnucap has been using two different build systems, neither of which really works well. One is based on autoconf, which has all of the needed targets, including “install”, but it does not provide features needed for development or multiple simultaneous builds. The old one, which you get by running “configure.old” is better for development, and easier to cope with when it doesn't work, but does not have the installation targets.
With plugins, neither of these is any where near adequate, and there is enough work to do to justify it as a whole summer project. It needs to handle plugins as part of the base install, and plugins added later. It needs to provide an environment to handle user plugins nicely.
There are several file formats in common use that are not netlist oriented, such as IBIS and Touchstone. The IBIS format is nearly complete and too complicated for a SOC project, but the Touchstone format is much simpler, and can be done as a plugin.
As an extension to the “language plugin” concept, gnucap can use “compatibility” plugins, which will provide command style compatibility with other simulators. These plugins need to do things like rearrange commands to mimic the behavior of the other. The top needs are spice-3f5, spice-2g6, Hspice, Eldo, …..
These plugins, combined with “output compatibility” plugins will allow gnucap to be used as a drop-in replacement for commercial simulators in some applications.
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.
Full implementation of Verilog-AMS requires a set of library functions. The ones most in demand seem to be the noise functions: white_noise, flicker_noise, noise_table. Others needed include transition, slew. We also need the “transform” functions laplace_zp, laplace_nd, zi_zp, zi_nd, but these are very difficult. This is not a complete list. A few of them would make a good summer project. More than one student can work on this.
We need plugins to add features. Any feature that exists in any other simulator, or that you wish you had, is a possibility. Some are easy, and would take several to fill a summer. Some are difficult.
Gnucap lacks some types of analysis that are available elsewhere, in other free simulators. This project is to pick one (or more) of them, and port it. To do any of these, you would start with source code from another simulator, such as Spice-3f5, Freeda, or Qucs, and rework it to fit gnucap. The starting code is available and licensed in a way that allows this (mostly BSD, some GPL). The result, mostly new code but clearly a derivative work, would be licensed GPL.
One of these is a good project.
This is fairly simple to do by a “shooting method” as a modification of the transient analysis. This is a good project for someone who wants to stretch a bit. You should have a basic idea of how transient analysis works. I will show you the rest.
We need wrappers, similar to the existing spice_wrapper.cc, to interface to other code, to adapt it for use as a gnucap plugin. Wrappers needed include: System-C, Icarus Verilog, GHDL, XSpice, Qucs, Freeda, …… One of these is a good project.
It would be nice to be able to write extensions (plugins) in an interpreted language, such as Python or Ruby. This project is a wrapper to provide the interface to the other language. One wrapper is a good project.