These projects make the others work together as a system.
This project involves creating a system which can create an annotated fab drawing from the drill file output by PCB, along with other inputs. In one possible implementation, you could use LaTeX/metapost driven from an external script. The script would read in some type of template holding boilerplate fab notes, insert a .eps version of the drill file, also read in some type of file holding stack-up information and other info for the PCB fab house, run LaTeX on it all, and then output an annotated .ps or .pdf fab drawing.
Difficulty: 2
This project encompasses the functionality of the entire gEDA PCB design flow. You would develop a test framework for as much of these tools as possible. This likely means creating a large regression test suite. Some examples are sets of layouts (using PCB) that just barely pass and just barely fail each of the different DRC checks, generate BOM's, x-y files, generate gerbers and maybe use gerbv to do a graphical xor against a “golden” file. For gnetlist, reference netlists that have been placed into some canonical form should be generated from gschem schematics (.sch files).
This project should be fun for a hardware hacker, since it would involve creating all kinds of strange circuit designs, and you would learn the detailed ins-and-outs of all tools in the gEDA Suite!
Difficulty = 3
Ngspice and Gnucap are the gEDA Project's analog circuit simulators. They are both command-line tools, meaning that you type commands into a shell-like program at a prompt. However, some popular commercial simulators support easy simulation and analysis directly from within a schematic capture GUI. This method of working is particularly well suited to newbies.
A new user would like to do the following things inside gschem:
The simulation runs and the postprocessing may be in an extra program that is triggered by IPC. More thoughts about the project have been entered by Werner Hoch on the gEDA Wiki (Circuit simulation improvements, Plotting improvements).
This project involves tightening the link between gschem and the back-end simulation programs. This might be done using some type of IPC, such as DBUS. Indeed, a preliminary DBUS implementation for gschem ↔ PCB already exists; the student might leverage the DBUS work for this project.
Difficulty = 3
In this project, you would create a parts manager that takes a graphical symbol and a physical footprint, and marries the two to produce a heavy part. In addition, this tool should be able to support multiple backend flows. By this I mean that the parts manager should be able to also indicate how the symbol should be netlisted for spice, gnucap, or other backends. If possible it would be nice to integrate this into gschem in a way that allowed symbols to be placed and the footprint attribute to come up with a list of choices.
Another possible direction for improved parts management is to create a program like gattrib (or perhaps just re-use gattrib) which reads a bunch of .sch files, and also interfaces to an SQL database holding all info about parts (including spice models, footprints, .pdf datasheets, etc) . The program would then allow users to perform database searches for footprints and other attributes stored as columns in the database.
Difficulty = 4
The goal of this project is to create a scalable, professional-grade netlister. The project might involve re-writing gnetlist to enable hierarchical designs, or might involve upgrading “gnetman” to incorporate scripted back-ends. The upgrade would be done with an eye towards scalability. Ideally, highly capable and efficient internal data structures and methods for accessing the netlist database should be used. Then a scheme/guile API provided for an external script engine. (It may be beneficial to use swig to allow easy interfacing to multiple scripting languages.) The idea is to produce a netlister capable of handling large, hierarchical designs while still allowing users to write their own netlisters for their favorite netlist format (as gnetlist does now).
Gnetman is probably the logical starting point since the database was designed by someone with a lot of experience in EDA, and it uses datadraw which is a proven high power CASE tool. However, the student may take whatever approach he wishes, but should provide a strong argument that his approach makes sense before starting coding. In any event, It will be important to provide a compatibility API for the existing backends while providing a more high power and flexible API for new backends and improvements of the old ones.
Difficulty = 3
The goal of this project is to write a driver file format translation, particularly for import and export of foreign formats. A start already exists with gnucap language plugins. It would be sort of like the existing “gnetlist” but be universal and able to translate in both directions.
This alone is too easy for the whole summer, but combined with support for one or two formats makes it good for the summer.
Difficulty = 1
After we have the “translator main program”, above, we need plugins for the formats to import and export. Gnucap already has support for Spice, Spectre, and Verilog, as plugins. These plugins can be used with the system, and as examples of how others can be written. The plugin needs to translate in both directions.
Obvious formats needed by the gEDA system are gschem, PCB, and Gerber.
Foreign formats needed, to provide a migration path between gEDA and other flows, include kicad, oregano, orcad, QUCS, LTspice, ….
This approach is a good way to implement translations asked for as other SOC suggestions. (Gerber to PCB, PCB to IPC-356)
This is not a complete list. One or two of them would make a good summer project. More than one student can work on this.
The most difficult part of this project is studying and understanding the formats being imported and exported.
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.
Difficulty = 1 to 5 depending on the format(s).