gEDA FAQ

The gEDA project has produced and continues working on a full GPL'd suite and toolkit of Electronic Design Automation tools. These tools are used for electrical circuit design, schematic capture, simulation, prototyping, and production. Currently, the gEDA project offers a mature suite of free software applications for electronics design, including schematic capture, attribute management, bill of materials (BOM) generation, netlisting into over 20 netlist formats, analog and digital simulation, and printed circuit board (PCB) layout.

The gEDA project was launched by Ales Hvezda in Spring 1998 in order to advance the state of free hardware and open source hardware. Over the past ten years, the gEDA software and the community have grown considerably. A few people are contributing to the original tools, while others are doing their own development on their own tools. “gEDA” does not refer solely to the original tools anymore (those tools now stand on their own), but instead to all the projects which are free and are somehow associated with this webpage or the gEDA mailing lists. By associating with gEDA, free software authors do not give up any control over their tools, but they gain a community which cares about quality and free (as in freedom) EDA tools.

gEDA can be pronounced “gee-daahhh” (rhymes with cheetah) or “g-dahhh (short g).

gaf stands for “gschem and friends”. It is a subset of the entire tool suite grouped together under the gEDA name. gEDA/gaf is a collection of tools which currently includes:

• gschem: A schematic capture program
• gnetlist: A netlist generation program
• gsymcheck: A syntax checker for schematic symbols
• gattrib: A spreadsheet programm that manipulates the properties of symbols of a schematic
• libgeda: Libraries for gschem gnetlist and gsymcheck
• gsch2pcb: A tool to forward annotation from your schematic to layout using PCB
• some minor utilities

The gEDA/gaf tools share a common file format (.sch) and also share a common link library (libgeda.so). The gEDA/gaf source distribution can be found on this website (http://www.geda-project.org).

Even though gaf is very much a part of gEDA, the gEDA name does not necessarily only apply to gaf – tools gathered under the “gEDA” moniker include many other programs. Indeed, gEDA refers to any GPL'd EDA tool which decides to associate itself with the gEDA website/mailing list. Important examples of gEDA tools include the layout program PCB, the Verilog compiler Icarus Verilog, the analog circuit simulator gnucap, and the open-source SPICE simulator ngspice. Many other gEDA programs also exist.

For historical reasons, on freshmeat gaf is known as the package “gEDA”.

The gEDA suite is the collection of all the various tools that are part of, associated with, or just plain work with the gEDA project’s software. Currently the gEDA suite includes:

• Tools for schematic capture and netlisting:
  • gEDA/gaf
• Tools for digital and analog simulation:
  • spice – netlister for SPICE simulation
  • ngspice – SPICE simulation
  • gnucap – modern “post-spice” (and SPICE) analog and mixed signal circuit simulator
  • Icarus Verilog – Verilog simulator
  • covered – Verilog Code Coverage Analyzer
  • gspiceui – GUI front end for ngspice/gnucap
  • Programs for data plotting and viewing
• Tools for pcb layout and manufacturing:
  • pcb – PCB layout
  • gerbv – Gerber viewer
  • wcalc – Transmission line and electromagnetic structure analysis
  • mcalc – Microstrip Analysis/Synthesis Calculator
• Libraries of symbols and footprints for all the above:
  • http://www.gedasymbols.org/

Tools in the gEDA suite and associated tools have the following characteristics:

• Free in the monetary sense (no cost).
• All the file formats and source code are available via the GPL license. This license grants specific rights to the authors and users of GPL'd software.
• Independence from any one vendor. All gEDA tools come with full source. You may freely redistribute, change, improve and port the tools. You may also distribute your changes, if you follow the terms of the GPL.
• No mechanism is used to restrict the use of the tools (like making use of hard disk serial numbers or ethernet addresses to force the software to only run on one machine).
• No arbitrary, marketeering-driven limitations. Free versions of commercial tools usually include capricious limitations (i.e. limited design size, inability to print, inability to export netlists, etc.) which cripple the program, and force the serious user to buy the real tool. In contrast, the gEDA tools are fully-featured, and do not arbitrarily impose limits on design as a way of extracting money from you.
• Legacy design protection. Since the software will always be available, and can always be updated to work with updated operating systems or libraries, gEDA tool design files will always be viewable and editable.
• Open design flow. This means that the tools talk to each other via known and documented means (files / APIs). It is easy to replace a tool or augment the tools with something else if you so desire. The gEDA suite is an EDA toolkit. The individual pieces are loosely coupled and allow for end users to customize or replaces parts of the design flow.
• Stability - Bugs which cause crashes are investigated immediately and fixed as soon as possible.
• Minimize bloat and unnecessary features.
• Run on as many platforms as possible. For gEDA/gaf: GNU/Linux, various other Unix systems.
• Developed in an open (no secrets) fashion.
• Strive to be documented.

gEDA may not have all the latest cutting edge features found in other packages and may be viewed sometimes as being on the trailing edge of EDA technology, but the tools are becoming useful to a lot of people for the above mentioned reasons.

The gEDA suite is indeed a confederacy of somewhat independent programs. This happened for reasons of history: Ales Hvezda started the gEDA project more or less on his own. The original vision was to produce an end-to-end software suite for creating PC boards so that robotics hobbiests could design their own boards. However, as the gEDA project progressed the large magnitude of this task became clear – and coding many of the proposed apps had not even begun!

Meanwhile, other software developers – with their own independently written applications – found the gEDA project vision compelling. The authors of those applications joined Ales and contributed their programs to the gEDA project. Amongst the contributed projects was “pcb”, a ten year old (at that time) PCB layout program. With the contribution of “pcb”, gEDA’s originally planned layout tool “gpcb” was scuttled. At the same time, other developers contributed analog and digital simulators, waveform viewers, and so on.

In this way the gEDA suite came together. It is not shared code, or a common user interface which distinguishes the gEDA suite. Rather, the shared vision of an open-source EDA environment is the thread which holds the project together. Today, the gEDA Suite is a collection of many different programs contributed by many different authors. The apps strive to work together, and usually succeed. But the separate beginnings of each program in the suite are still observable. Nonetheless, with a little work the various components of the suite are interoperable, and many people have completed quite complex board designs using the gEDA suite.

In the end, the best way to think about the gEDA suite is as an EDA toolkit. This toolkit approach gives the end user considerable control. End users can modify or completely replaces parts of the design flow to suit their own requirements.

This is ultimately a matter of religion. I’ll summarize some of the pros and cons (as I see them) of each approach here.

• You can use “best of breed” applications for each part of the design flow. That is, you can use the standard gEDA flow gschem → gsch2pcb → pcb to create a PC Board. However, if you think that the open-source application “pcb” stinks, you can use the flow gschem → gnetlist → Protel (for example). Recall that gnetlist can output more than twenty different netlist formats! Moreover, if you don’t like one component of the flow, you can write another tool to replace it. Now at this time it is true that only a single application generally exists to perform a particular task. However, this situation will likely change with time – witness the forking of the “pcb” project, the contributed netlister gnetman, as well as the HEC project. As a general rule, the suite approach offers the greatest freedom to the user.
• The design flow has a lot of natural breakpoints. These occur where one design tool completes its job and writes out a file (i.e. gschem writes out a .sch file, or gnetlist writes out a SPICE netlist). At this point, you can easily break into the flow and write scripts which process and/or munge the design data. For big, advanced designs, this is a real advantage to the “design suite” approach. This advantage may appeal only to the “power user”, but note its importance: professional-grade EDA suites (Synopsys, Xilinx) also work the same way.
• Usage of an applications suite can be automated using a Makefile, or even a Perl script. ASIC designers do this all the time with their design and synthesis tools. Some gEDA users have stated on the e-mail list that they do this too, and point to it as an important feature of the gEDA suite.

• More confusing to new users, since they don’t know the flow right off the bat. That is, they actually need to RTFM to know what tool to run next. Good documentation helps (that’s why you’re reading this), but documentation is always second choice behind developing an intuitive application interface.
• Different programs have different UI conventions. That is, menu organization, keyboard and mouse bindings are inconsistent. This can be uncomfortable even to those who are familiar with the programs.
• Since no assumptions are made about the design flow, schematic symbols are necessarily light. This forces the user to spend more time attaching e.g. footprint attributes to his design. Moreover, the user must spend more time actually researching which footprints to use.
• Some developers are more energetic than others, or have more free time. Therefore, some programs in a suite will be more developed (and less buggy) than others. Unfortunately, a single buggy program in a suite can unfairly taint a new user’s perception of the entire suite.

• A single, unified design environment is easier for new users to grasp.
• It is easier to harmonize UI conventions.
• Schematic capture symbols can be heavy, so less work is required in attaching attributes to each symbol in a schematic.

• Not infinitely scalable. One developer can’t do everything, no matter how smart. Therefore, a monolithic app will never approach the size or power of a suite developed by a confederacy of programmers.
• Lack of choice. If the developer doesn’t like your way of doing things, you have no choice. Even if you submit patches to enable your way of performing a task, there is a chance the main developer will ignore or reject your patches. This is probably not an issue for newbies, but for “power users” it represents a problem.
• Risk. If the developer quits, the code becomes abandoned, and the users suffer. This effectively happened to the program XTrkCAD, a CAD program for designing model railroads. The author of this program quit developing it, but thankfully placed his stuff on Sourceforge so that the program wouldn’t simply disappear. Unfortunately, without the original developer’s involvement, the code languished. Patches contributed to the project went to /dev/null. Eventually, a coalition of concerned user/developers created a fork of the code to enable further development. However, work on the forked code has been piecemeal and sporadic. (Hopefully, this will change someday.) Meanwhile, for the ordinary user, the fact that the original developer quit represents a catastrophe.

Newbies sometimes show up on the gEDA mailing lists and flame the project for missing features, perceived bugs, and supppoesd UI quirks. The gEDA developers are very interested in receiving constructive feedback and criticism, so we do welcome feature requests and bug reports. But please keep in mind that the developers are full-time professional EEs or software engineers, and work on gEDA as an unpaid, fun hobby. Unconstructive or ill-informed flames are not the way to get new features implemented.

If you need a new feature implemented in one of the gEDA tools, here are your options:

• Write it yourself. The code is open and available for everybody to see, understand, and modify. If you have implemented a new feature, please submit your patches to the project; chances are good that they will be incorporated into the main development branch.

• Ask politely on the gEDA e-mail lists. If your feature request is simple, or of interest to one of the developers, it's possible that somebody will implement your feature. If it's more complicated, it's likely that the feature is already under discussion amongst the developers, but nobody has enough spare time to implement it. (You can also submit feature requests via the Launchpad bug tracker.) Please don't rant or flame on the e-mail lists, since you will likely be flamed right back and you won't get your feature either. Why waste your time?

• If the above possibilities don't work for you, hire an open-source developer to write the feature for you! It's amazing how often this possibility is ignored. People willing to pay $25,000 – $100,000 for commercial EDA tools will balk at paying a teen-age programming whiz $10/hr to re-create the same features in the gEDA Suite. Why? If you're an educator, consider hiring some students for a UROP project to work on gEDA. If you run a business, hire a teenager or somebody fresh out of school! And if you want seasoned help, you can (soon) turn to some of the main gEDA developers who do consulting.

All of the tools and associated files in gEDA will be released under the GNU General Public License version 2 (GPL), from the Free Software Foundation.

From the license:

“When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.”

This cannot be stressed enough: gEDA is GPLed software. Therefore nothing proprietary can be distributed with gEDA like part libraries from proprietary EDA products. Conversion programs for proprietary libraries will be available, but any converted files which are part of a proprietary product must never find their way into gEDA. Contributed files must be GPLable (or be placed under another free license). Please keep this in mind if you wish to contribute something.

Even though the focus of gEDA is GPLed software, other software licenses are more than welcome to be mixed with the existing software, as long as they are compatible with the GPL.

For more information about the license used by gEDA, please read the licensing page.

The official website is gEDA Project.

There are several mailing lists. Please look at the mailing lists page for how to subscribe and post.

You can download all the software from the download page.

You can find the latest set of documentation on the top-level documentation page.

The most important thing to do is to read and understand one or both of the tutorials available online:

• Bill Wilson’s excellent gschem -> gsch2pcb -> PCB tutorial.
• DJ Delorie’s tutorial on pcb also covers basic usage of gschem.

Also be sure to check out the other gEDA documentation. An installation guide is contained in this Wiki, as is some general information about how to use the tools. Spend some time browsing, download the gEDA Suite, and try it out for yourself!