So what is it?
Secsea stands for "Synthesis of Electronic Circuits in SPICE with Evolutionary Algorithms".
In other words, this project is an attempt to create a system that automatically designs
circuits to meet given specifications. We hope to use an
evolutionary algorithm to "breed" circuits
in a pseudo-darwinian survival-of-the-fittest environment. Most of the code will be written in
Okay, what is SPICE?
SPICE stands for "Simulation Program with Integrated Circuit Emphasis". It is a very popular
system for simulating the behavior of analog circuits. A circuit
is described in a simple text file format in which each circuit element is described
with by its connections and parameters (e.g., resistance/capacitance). SPICE is
capable of time-domain transient response analysis as well as frequency domain
analysis. Other types of analysis are available depending on which specific SPICE
implementation is used.
The original SPICE was created at Berkely and released under the very-open
which allowed everyone to take the code and do whatever they wanted with it. This was
good in that inspired generations of high-quality circuit simulation packages, such as
The downside is, of course, that most of these packages cost a lot of money.
Fortunately, the original
Berkley SPICE code is still available, and there is an
open source project called ngspice with the goal of
improving/replacing the original SPICE code until it is competitive
with commercial SPICE simulators. Once all of the code has been rewritten, ngspice will
be relicensed under the GNU GPL, which will
prevent people from creating closed-source derivatives. Although Secsea is designed to be as
general as possible when it comes to interfacing with a SPICE package, it is currently running on the development cluster with ngspice.
Alright, so what is an evolutionary algorithm?
An evolutionary algorithm is a way of solving certain kinds of problems by simulating natural selection.
The basic idea is to create a set of totally random solutions to a problem and give them all some kind
of rating based on how well they actually solved the problem. Obviously, since these initial solutions are
totally random, none of them will solve the problem very well. But even though all of them will fail miserably,
some of them will fail oh-so-slightly less miserably than the others. It is these members of the population that
are considered more "fit" in the environment of the problem.
After this initial population has been rated for fitness, the a new generation is created from the top-rated
individuals from before. Thus, fitter solutions tend to reproduce more, which gives the population a tendency
to contain ever-fitter members as this process is repeated.
And this applies to circuits how?
Well, in theory, it's pretty simple. In terms of the above description, the problem is defined by the
desired behavioral characteristics of the circuit, and the solutions are actual circuit layouts. Evaluation
of circuit fitness is accomplished in two main steps:
Circuits that more closely match the desired characteristics are considered to be more fit, and
therefore produce more offspring into the next generation of circuits. This process is repeated many
thousands of times until, it is hoped, sufficiently good circuits appear in the gene pool.
- Simulation: Each circuit is sent to the SPICE package for behavioral simulation. Secsea
generates a netlist file describing each circuit and provides this as an input to spice. In turn, the
simulator package returns a binary file containing vectors of voltage vs. frequency or voltage vs. time data.
This file is read by Secsea and parsed into more readily-used data structures so that the performance
may be evaluated.
- Evaluation of Results: The resulting data are given to a user-supplied function which examines
the data and returns a floating-point number on the interval [0,1) representing how closely this particular
set of behavioral data matches the ideal performance specifications.
Wouldn't that be incredibly slow?
In a word: yes.
Analog circuit simulation is very processor intensive, and complicated circuits take
noticeable time to simulate. Also, most of Secsea's code is written in Python, an interpreted scripting language
that favors readability and maintainability over speed optimizations. All of this means that Secsea burns
CPU cycles. The solution to this problem is simple: get more CPU cycles! And these days, the most efficient
(read: cheapest) way to do that is to use a cluster of x86 PC's running GNU/Linux.
For our development work
at Bradley University, we're using a 20-node cluster of rackmount dual
Pentium III 866 Mhz machines running Redhat Linux. Secsea is designed to take advantage of a parallel computing
cluster to speed up its work. Currently, only clusters running a POSIX OS (e.g., Linux, FreeBSD, Solaris, etc.)
are supported, but it is possible that other architectures (e.g. Windows) could be supported in the future.