Projects

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 Code Generator

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)

File format translator system

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.

Update the build system for plugins

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.

Model file import

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.

Command compatibility plugins

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.

Output compatibility 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.

Behavioral modeling functions

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.

Simulator features

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.

Porting of missing analysis, (noise, pz, disto, hb, etc.) from other free simulators

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.

Periodic steady state analysis

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.

Wrappers for non-native models

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.

Wrappers for other programming languages

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.

 
gnucap/projects.txt · Last modified: 2009/07/04 00:42 by aldavis
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Debian Driven by DokuWiki