### gEDA GSoC Project Ideas

This page contains various ideas for projects. You can use these as fodder for creating your application to Google. Also, if you have your own idea, feel free to share it with the gEDA developers – they might like it more than any project on this list!

Note that some of these projects are too small by themselves to be stand-alone projects. The Summer of Code program is a 3 month program, and you’re supposed to treat your project as a full-time job. Applicants should keep that in mind and possibly combine ideas from different projects if one suggested project is too small. To help you, I have graded each project on a scale of 1 to 5, where 1 = too small for a full summer, 3 = roughly enough for a full summer, and 5 = way too large for a full summer. Of course, what takes one programmer one week might take another six months, so any judgement is subjective. However, you can use these ratings to help you figure out which project is the right one for you.

The vast majority of gEDA Suite programs are written in either C or C++. However, a whole range of scripting languages are used including scheme (guile), perl, python, bourne shell, tcl/tk, and others. GUI toolkit use is also fairly broad including GTK+ (this is the primary toolkit of most of the programs), Lesstif, WxWidgets, and others. We are pretty much open to using most languages or GUI toolkits for new programs, however some of the projects listed below will require knowledge of a specific language and/or GUI toolkit (as they are well established programs).

Please visit the gEDA Project’s main GSoC page for more info (including contact information).

### Project manager

gEDA needs a new, top-level project manager. Using this tool, A user would type “geda” at the command line (or push a button on his desktop manager), and this program would start a GUI which would provide easy, user-friendly access to all design tools. The project manager would implement (at least) the following functionalities:

- Menu items or buttons to run various gEDA programs like gschem, gattrib, gsch2pcb, PCB, gerbv, ngspice, Gnucap, etc.
- Manage resource files (i.e. the project manager allows you to edit and write gafrc, gsch2pcb project file, spinit, etc.
- Enable creation of project archives – i.e. using garchive, but using an intelligent method to gather & archive the symbols & footprints used in the project.
- Perhaps implement some type of lockfiles, or at least some enforcement of the design flow (good for newbies).

Since the project manager is the first program seen by many new users, this program needs a high degree of polish, and should enforce good design practice without getting in the user’s way too much.

Difficulty = 4

### Improve handling of non-copper layers in pcb

PCB’s support for non-copper layers needs improvement. In this project, you would add support for more easily-editable non-copper layers. These non-copper layers would be used for things like keepout regions, assembly drawing, and an actual board outline layer that is not just a copper layer. For more thoughts on the issue of layers in PCB, please see database.txt and keepouts.txt

Difficulty = 2

### Gerber to PCB converter

In this project, the student would create a program which reads a Gerber file, and creates an output file which is a metal layer or footprint editable by PCB. This might be a Perl or Python script. Such a program is very desirable since it gives users the ability to edit legacy designs – i.e. those for which they only have Gerbers.

Difficulty = 3

### Usability improvements for ngspice/Gnucap

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:

- Specify what kinds of simulations should be run
- Specify which voltages and currents should be plotted
- Start the simulation

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.

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

### Parts manager

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

### Gnetlist/gnetman support for hierarchy

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

### Libgeda API formalization

In this project, you would expand libgeda (if needed) to provide a complete enough guile interface to be able to do more complex database manipulations. One use would be to have a back annotation tool that used libgeda instead of relying on perl. The problem with perl is that you’ve involved Yet Another Gschem Parser. This actually may be combined with the previous project about rewriting the gnetlist internals.

Difficulty = 3

### Recently loaded file list for gschem and/or pcb

Presently gschem and pcb do not present a list of recently loaded files in the file menu. It would be nice if gschem and/or pcb kept track of the last few files a user loaded. This is a common feature found in other programs.

Difficulty = 1

### Remember dialog size and positions

gschem and pcb dialogs should remember their size and position. Currently they do not remember anything about their position and size and several users have complained since they have to reposition and/or resize the dialog boxes every time they are opened..

Difficulty = 1

### Show hidden attributes for selected components

In gschem, please add a why to show hidden text for just one symbol only. Currently [en] will show all the hidden text for all symbols and that makes a real visual mess. Implement this by just showing the hidden text for the currently selected symbols.

Difficulty = 1

### Constant sized handles/grips

In gschem, the size of the handles for lines, nets, and objects scale with increasing zoom. Thus for small lines the handles overlap, and if I zoom in closely, it becomes very hard to pick the right object to manipulate. Please let the size of the handles be constant, regardless of the zoom factor. This is virtually how all vector graphics applications work.

Difficulty = 1

### Automatically fill in global attributes in gschem

In gschem, implement a mechanism that would (when turned enabled) automatically fill in proper global attributes for the design. These attributes could be the date of the last modification, name of the project, author, number of sheets, etc…

Difficulty = 1 to 2

### Visual feedback when pressing keyboard accelerators

In gschem, please give some feedback when a user presses one of the keyboard accelerator keys. Currently gschem allows for multiple key presses to represent a single command. Sometimes it is hard to remember which one you have pressed. Maybe a little area in the status bar can output this information.

Difficulty = 1

### Improve error messages in gschem

Improve error messages in gschem when a rc file doesn’t load correctly. Currently the error messages are cryptic and not useful at all. There are several other places in gschem where the error messages could be vastly improved.

Difficulty = 1

### Global search and replace

Add a dialog box that lets you do a global search and replace. Currently you can do a find for a specific attribute, but several users have asked if gschem could also provide a way of doing a replace operation as well.

Difficulty = 1 to 2

### Visual feedback for attached attributes

In gschem, add some sort of visual feedback to tell the user which attribute is attached to which component. This would be useful since sometimes you move attributes/components around and things get a little bit separated distance wise.

Difficulty = 1 to 2

### Schematic and symbol modes

Add schematic and symbol modes to gschem. Right now users can do invalid things like add a net or bus inside a symbol and gschem allows this quite happily. If there was a symbol mode that disallowed certain actions, then users will not be able to hurt themselves so easily when creating symbols. Like wise a schematic mode wouldn’t allow certain operations (such as adding a pin).

Difficulty = 2 to 3

### Movable symbol origin

Add the ability to move the origin of a symbol in gschem. Right now the origin is always at 0,0 and users have to translate the symbol to the origin. It would be nice if the origin was movable so that you wouldn’t have to translate the symbol manually anymore. This would also allow the user to pick the insert point of the symbol when adding components to a schematic.

Difficulty = 2 to 3

### Modify instantiated symbols in a schematic

Add the ability to move pins/attributes/whatever on instantiated components in a schematic. This one is quite tricky, but it would allow for various things that people have been requesting (this might be a good foundation for a greatly improved back annotation mechanism from PCB).

Difficulty = 3 to 4

### Finer grid when moving attributes

In gschem, add a finer grid when moving attributes or text around.

Difficulty = 2

### Frequently used symbols sidebar

Add a frequently used symbols sidebar to gschem that is dynamically loaded and/or can be preloaded from an rc file. Several people have asked for this since using the component selection dialog box can be time consuming for recently used/needed components. This is a GUI heavy project idea.

Difficulty = 3

### Add more toolbar buttons

Adding some more useful buttons to the gschem toolbar. Typical functionalities that gschem does not have on the toolbar:

- Up/down schematic/symbol
- Add various graphical objects (maybe make these only appear in symbol editing mode)
- Edit component attributes
- Copy/paste/delete
- Page forward/back
- Component mirror/rotate
- Zoom in/out

It would be really nice if the toolbar buttons were configurable either on the fly or through an rc file.

Difficulty = 2 to 3

### Filled polygon object

Adding a filled polygon graphical object type to the gschem symbol file format and, of course, gschem would be a nice project. This would be useful for filled arrows (transistors) and a filled triangle for diodes.

Difficulty = 2 to 3

### Fix gEDA/gaf bugs and/or implement feature requests

There are several bugs listed at the gEDA/gaf bug tracker and feature request at the gEDA/gaf feature request tracker that could potentially make good student projects. Some of the bugs/feature requests are quite feasible to finish in one summer, while others are way beyond what is possible to finish in one summer. However some of the bugs/feature requests are trivial to implement, so several might need to be combined together to fill up the entire summer.

There are other bug/feature request trackers for the other gEDA affiliated programs (such as PCB or Icarus Verilog) that contain possible project ideas as well. Selecting bugs or features requests to work on from any of the trackers needs to be approved and agreed upon by the appropriate mentor(s) to make sure it is appropriate, feasible, or even fixable.

Difficulty = various

### Make gsch2pcb use same search paths as PCB

Gsch2pcb is a key program in the gEDA Suite. It made it relatively easy to take a schematic drawn using gschem and prepare it for layout using PCB. It has played an important role in popularizing gEDA for PCB design amongst students and hobbyists. However, it has a flaw: It uses footprint search paths which can be different from those in PCB. Users are sometimes perplexed that they can see footprints in PCB, but gsch2pcb claims it can’t find them. Or gsch2pcb gives them footprints different from the ones they expect to see based upon a footprint search using PCB. In addition, gsch2pcb needs to be able to parse the PCB .pcb files directly. This means many file format changes trigger a required update to gsch2pcb.

It would be more preferable for gsch2pcb to be able to query PCB through a well defined and stable API to find out the information it needs. In addition, rather than trying to duplicate PCB’s mechanism for creating a new board and locating footprints, gsch2pcb should simply instruct PCB to peform these operations. The goal is to provide a stable interface between the tools and impose appropriate abstraction barriers in between.

Difficulty = 2

### Verilog/VHDL code generator[s] for Icarus Verilog

A Verilog code generator targets to emit simplified Verilog code. This has use as a Verilog “reducer” (or obfuscator) to translate verilog to more simplified forms. It can also be used to support other Verilog run time engines.

A variant of this is to generate VHDL, and thus get a VHDL translation from the Verilog input.

This task remains pretty clear of the core Icarus Verilog compiler and just works with loadable code generators. SDF Parser/Annotator for Icarus Verilog

SDF parser to parse SDF files generated by typical SDF sources such as Xilinx ISE. It should be possible to invoke this from an $sdf_annotate system task and match paths with the specify paths actually available (via vpi) in the design.

The specify paths are now available in the vvp run time, some work is needed to offer up the VPI objects that an SDF annotator needs.

This task can mostly be done in C and loaded as a VPI module. There is some work needed in the vvp run time engine to make the paths available to VPI modules, though. Macros with Arguments

The Icarus Verilog preprocessor currently does not support macros with arguments. A good task would be to add support for arguments. This task would work entirely within the ivlpp program that does the preprocessing for the ivl core. It is written in C and bison and would be a good task for someone not an expert in Verilog or EE in general. Upgrading/resurrecting the analog waveform viewer “gwave”

In this project, you would work on improving and modernizing the analog waveform viewer “gwave”. Several improvements are desirable, including (but not limited to):

- Remove requirement for guile-gtk (which is basically dead I as far as I can tell).
- Adding support for hdf5 (as a way to help move towards a better than ascii format that is non proprietary).
- Add a waveform calculator that lets you do things like add waveforms, do fft’s, etc.
- Provide a way for the tool to be easily extensible by the user. Some examples are custom grid lines (smith, nichols, polar, etc), custom cursor functions (smith, nichols, etc), and complex measurement and waveform processing functions.
- Support for digital as well as analog signals. For example you may have a digital bus present in a mixed signal circuit and would like to plot the value on the bus as simply a digital transition diagram with annotated bus values, or you may wish to plot the bus value as a quantized value.

Note that the gEDA Project needs a gwave mentor.

Difficulty = 3

### Create comprehensive test suite for entire gEDA Suite

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

### Revive TCLSpice, add return code to analysis

TCLSpice is a version of ngspice (the classic analog simulation program) in which the SPICE commands and cards have been exported to TCL. The idea is that you can then write a scripted SPICE analysis using TCL, a feature which is extremely valuable for performing circuit optimizations, repeated circuit simulations for Monte Carlo or corner-case evaluation, and so on.

A problem with TCLSpice is that the internal data structures do not provide return codes when called, so it is impossible to see if an analysis has run successfully or now. In this project, the student would fix tclspice so that every analysis would provide a return code reporting success or failure.

Difficulty = 4

### PCB DRC interface improvements

Improve the DRC interface for PCB. Perhaps have a DRC layer that gets generated when you run DRC. Then you could have an interface that lets you step through them and see on that layer, exactly what failed. Maybe this could be combined with making the DRC checks more unit testable.

Difficulty = 2

### Add enhancements to gerbv.

Gerbv is gEDA’s Gerber viewer. It is a good tool for inspecting Gerbers. Adding a different pop-up box displaying the properties of objects you click on (i.e. round pad diameters, track widths, etc.) would be invaluable.

Difficulty = ?

### PCB Autorouter

PCB currently incorporates a simple autorouter. However, a topological autorouter would represent a significant improvement over the existing autorouter. In this ambitious project, the student would create a topological autorouter for PCB.

Difficulty = 5

### Improved and formalized mechanism for forward/backward annotation

Add hooks into gschem needed to fully support things like backannotation of simulation results and click-to-plot results. Specifically, this would enable you to draw a schematic in gschem, then simulate it in ngspice without leaving gschem. The simulation plots would then appear in a graphical pop-up window.

Difficulty = 3

### IPC Footprint Calculator

Build a footprint calculator that can take the IPC rules and produce a pcb footprint. Preferably write this in a way where the core program is independent of a gui so that you can script it for generating entire large families of footprints or hook it up to a GUI of choice (lesstif, gtk, maybe even cgi). Would require the purchase of IPC-7351 (approximately U.S.A. $100)and verifying that one is allowed to produce such a calculator.

Difficulty = 2