Within the canonical gEDA Suite apps there are two analog circuit simulators: ngspice and gnucap. In (slightly) more detail:

• Ngspice is a port/clean-up of classical SPICE 3f5 to the GNU/Linux platform. It is fully functional, includes the XSpice extensions (such as SPICE 2 POLY constructs), and the CIDER framework.
• Gnucap is a new circuit simulator written from the ground up. It offers the ability to perform event-driven – as well as continuous time – simulations. It is the work of Al Davis. If you wish to download it, make sure you grab the latest version, available through the “development releases” link on the gnucap website.

Both are CLI (command line interface) programs, meaning that you interact with the simulator by typing commands at a command line. It also means that you need to learn the simulator-specific command set.

If you prefer a graphical interface, the new gEDA app GSpiceUI provides a nice GUI front-end to drive the simulation programs. However, GSpiceUI is not a complete schematic-to-simulation-output simulator like LTSpice or PSpice. Rather, it just provides a GUI menu which helps you navigate the commands you need to perform your ngspice/gnucap simulation.

Tclspice was a fork off the ngspice development path. It was begun in the 2002 timeframe. In principle, tclspice would export the SPICE command set to a TCL API, allowing you to embed SPICE analyses into a TCL program. This vision is certainly very attractive since TCL is a powerful scripting language – much more powerful than the scripting constructs available from within SPICE itself. Using TCL, one could imagine writing complex circuit optimizers, adding behavioral elements to a simulation, and finally gaining control over SPICE's graphical output.

As it turns out, this goal was partially met – with tclspice you can indeed do something like this:

#! tclsh 
package require spice 
spice::codemodel /usr/local/src/tclspice-0.2.12/src/xspice/icm/spice2poly.cm 

spice::source netlistname.cir
spice::tran 0.1ns 40ns
spice::run
spice::plot Vout
puts "All done now!"

Unfortunately, tclspice lacks certain important features, like providing you a return code which tells you whether your simulation actually worked or errored out instead. Also, the graphics functionality never seemed to work (at least for me … and the developers admit that the graphics stink). Converting TCL variables to and from SPICE vectors never seemed to work – again at least for me. Finally, ngspice (at least) has a lot of memory leaks, making long simulation runs difficult. Therefore, tclspice doesn't meet the promise it originally held out: a convenient, scriptable way to drive SPICE simulations.

Development on tclspice effectively stopped in 2004. Perhaps some day somebody will pick it up again. In the meantime, the main ngspice development branch has picked up the tclspice features if you want them (they require separate configuration options), and the code is fresher.

There are only very few open source models made available by enthusiasts. This is why there is no extensive library of models included in the gnucap or ngspice package. If you rolled your own and feel like contributing to the project, this would be an excellent opportunity (hint, hint…).

Although many manufacturers provide SPICE models free of charge, they keep the license proprietary. This means, that the models can't be distributed with the gEDA suite. In addition, different implementations of SPICE have slightly different ideas about the correct syntax. As a consequence, some models as supplied by the manufacturer need to be tweaked to work with specific implementation.

Spicelib provides a way to receive models tweaked for gnucap and ngspice. It is a set of scripts that will fetch vendors' models directly from the source, solving the redistribution problem. Then it will patch them for compatibility with gnucap and ngspice. You can download spicelib from http://www.h-renrew.de/h/spicelib/doc/index.html.

No. The best you can do is use GSpiceUI.

The usual design path is “gschem” → “gnetlist -g spice-sdb” → [“ngspice” | “gnucap”]. You need to attach attributes to the components in your schematic to provide attributes needed by SPICE/Gnucap. You can also attach attributes using gattrib.

The Circuit Simulation using gEDA and SPICE - HOWTO describes all this in great detail.

Some SPICE resources will help you understand how to use spice-sdb.

Use spice-sdb. It is by far the most advanced and feature rich. The others are there only for reasons of history. Note that spice-sdb is an extension of one of the other SPICE backends, so you aren't missing anything by using spice-sdb.

Yes. Also, you can draw your schematic using gnucap directives available in the “spice” symbol directory.

It is better to just draw the circuit, without directives, and run the simulator interactively.

Newbies commonly want to create a single schematic for both design simulation/validation as well as layout. This vision seems very attractive at first, since your layout will have been tested & validated before committing it to FR-4. However, the devil is in the details; using a single schematic for simulation and layout usually doesn't work for the following reasons:

• Components required for simulation and layout are normally very different. For example, simulation often requires a schematic holding a bunch of SPICE-related devices such as voltage sources, dependent sources, SPICE directives, and so on. On the other hand, layout requires non-SPICEable components such as connectors, logic devices, and even things like voltage regulators which might have no SPICE models available, but will pollute your SPICE netlist, possibly making the netlister and the simulator unhappy.
• Some real electronic components don't have built-in SPICE models. There are plenty of components which don't have native SPICE models like potentiometers, transformers, thermistors, EMI filters, logic gates, crystals, vacuum tubes, and on and on. Therefore, if your design uses any of these components, you must mock up the device using an equivalent circuit for simulation. This makes it very difficult to reuse the simulation schematic for layout.
• Usually, you only really need to simulate a subset of your design. For example, you might want to simulate the behavior of a filter or oscillator circuit, but don't care about (or can't simulate) your power supply, glue logic, or other part of your design. If you insist upon creating a SPICE model for these circuit subsections, you might need to jump through a lot of hoops – and do a lot of unnecessary hard work – in order to find or create SPICE models for parts of your design which aren't important.

Therefore, I (SDB) normally recommend that you shouldn't try too hard to use the same schematic for simulation and for layout. If you can do it, great! But usually you can't.

Personally, I tend to create SPICE models of only the critical analog sections of my design. A larger project might therefore have a couple of simulation schematics validating a couple of analog subcircuits. Besides the simulation schematics, I'll have a main schematic which is used for layout.