The name gSpiceUI is an abbreviation of the project title GNU SPICE GUI, which is itself an acronym standing for Gnu is Not Unix, Simulation Program with Integrated Circuit Emphasis, Graphical User Interface.
gSpiceUI is intended to provide a GUI for freely available electronic circuit simulation engines ie. NG-Spice and GNU-Cap. The utility gnetlist is used to convert schematic files to netlist files, Gwave or Gaw to display simulation results and gschem is the preferred schematic capture tool. gSpiceUI is useless without the software tools it depends on, credit should go to the authors of these tools. Links to these various projects are provided in the Links menu to the left.
The gSpiceUI GUI is designed to be as consistant as possible between analysis types and simulation engines. The intention is to abstract the technical particulars from the user so that the focus may be on the simulation rather than the simulation engine or even analysis type.
It is worth noting that whereas NG-Spice is derived from the SPICE code base, GNU-Cap is not. GNU-Cap is an independent implementation of the principals used to analyses electronic circuits. Consequently, analysis results can be generated using two independant mechanisms and can then be compared. This is one of the reasons for supporting more than one simulation engine; if the same or similar results can be achieved using two different simulation engines then it's likely that the simulation results will bear some resemblence to what actually happens in reality.
It is important to realise that a simulation engine models the behaviour of a system and therefore can never be 100% accurate. In addition the simulation engine itself is an implementation in software of a mathematical model and so is also subject to bugs. As the underlying mathematical model and software implementation improve the simulation performance improves. One of the reasons for the choice of simulation engines to support was that they are both in constant development. (Not to mention the inherent goodness and righteousness of open source software, so I won't mention it.)
The skills and judgement of the user have a profound impact on the usefulness of electronic simulation. It can be a technically demanding process requiring considerable thought, practice and persistence. The alternative is to go straight to building prototypes; in any case, ultimately prototypes must be created to finalize a design. However simulation is generally a rewarding step in the development process, even if it only provides a better understanding of the internal workings of a design.
As a personal note, this project began because I wanted to use a free circuit simulation engine but didn't want to have to remember all those pesky command line instructions. After searching around on the Web for a bit and not finding anything to my liking I decided do something about this obvious omission. I vividly recall posing that apparently innocent rhetorical question : "How hard can it be?". Well, after 10 years I can now confidently provide an answer - VERY HARD.
The main features of gSpiceUI are :
- Unix style modular design philosophy (ie. each module is an independant utility).
- Choice of two simulation engines.
- Consistant user interface for the different simulation engines.
- Choice of two waveform viewing utilities.
- Contents of netlist files displayed and can be edited.
- The schematic capture application can be launch from within application.
- Can be compiled on multiple platforms eg. Linux, FreeBSD, MacOSX & Windoze.
- Written in C++ using the wxWidgets library (no other build dependencies).
- Console display eases fault finding of the tool chain.
Here are two screen shots of gSpiceUI in action; the first with GNU-Cap selected as the simulation engine, the second with NG-Spice selected as the simulation engine.
The name of the binary is gspiceui. The non-camel hump format (ie. all lower case characters) is used since it's easier to type. The following gives an example of how to display the usage message :
$ gspiceui -h Analyse a electronic circuit using a GUI to a numerical simulation engine USAGE : gspiceui [-OPTION [ARG]] [FILE/S] OPTIONS : -h : Print usage (this message) -v : Print version information -d : Enable debug mode (generates console spew on standard error) -r RCFILE : Specify a configuration file RCFILE = ~/.gspiceui.conf (default) -c : Rebuild/clean the configuration file -s SIMENG : Specify the simulation engine to be used SIMENG = gnucap (default) or ngspice -a ANA : Specify the analysis page to be displayed ANA = op, dc (default), ac, tr, fo, di, no, pz, se or tf -g [PROC] : Guile procedure for importing a schematic file with gNetList PROC = spice-sdb (default), pcb, protelii, verilog, etc. -w VIEWER : Specify the waveform viewer to be used VIEWER = gwave (default), gaw or gwave2 ARGS : FILE/S : Import schematic file/s or load a circuit description file NOTES : Option -s should come before -a if both are specified
The simplest example :
This command will import the gschem schematic file test.sch in the current directory :
$ gspiceui test.sch
Whilst running gSpiceUI various temporary files may be generated in the directory occupied by the schematic or netlist file/s. To illustrate consider the situation where the gschem file test-amp1.sch is imported and every possible a nalysis type is run using both NG-Spice and GNU-Cap. The following is a list of files which would be created :
<path>/sch/test-amp1.sch → The schematic file to be analysed <path>/sch/test-amp1.ckt → Netlist file with simulation commands <path>/sch/gspiceui.log → Temporary file for raw process output <path>/sch/test-amp1.gnucap.op → Results file - operating point analysis <path>/sch/test-amp1.gnucap.dc → Results file - DC analysis <path>/sch/test-amp1.gnucap.ac → Results file - AC analysis <path>/sch/test-amp1.gnucap.tr → Results file - transient response analysis <path>/sch/test-amp1.gnucap.fo → Results file - fourier analysis <path>/sch/test-amp1.ngspice.dc → Results file - DC analysis <path>/sch/test-amp1.ngspice.ac → Results file - AC analysis <path>/sch/test-amp1.ngspice.tr → Results file - transient response analysis
All file names begin with the prefix test-amp1 (taken from the schematic file name). File name extensions then depend on the file type. Files containing simulation results include the name of the simulation engine used to generate the data and an abbreviation indicating the analysis type.
- gSpiceUI can manage (ie. keep, prompt or delete) temporary files, refer to Settings Menu.
There are various sources of documentation for gSpiceUI :
- This web site (obviously).
- It comes with user documentation built-in which can be accessed via the Help Menu or here .
- There's a man page (for non-Windoze users).
- Text files in the root directory of the program sources, in particular ReadMe and Install.
- The software itself is heavily commented and has been designed and written so that it may be maintained or reused.
The application sources can be downloaded from here at sourceforge.net. You'll also need to have the wxWidgets library installed to compile the sources. Currently wxWidgets version 2.8.12 gives the best results. The code should compile without errors or warnings.
The application sources are maintained in an SVN repository here at sourceforge.net. This can be viewed or else checked out by anyone using the following command :
svn checkout svn://svn.code.sf.net/p/gspiceui/code/trunk gspiceui-code
Many distributions now have a package for gSpiceUI which can be installed using the package management system, dependencies should also be automatically installed. This is generally the easiest installation method.
See the release notes which contain a list of the notible changes since the last release. The Changelog file in the root directory of the sources contains a complete list of all notible changes since the first release.
The gSpiceUI software is licensed under the terms of the GNU General
Public License as published by the
Free Software Foundation. There is copy of the license in the root directory of the sources.
This section provides information related to the design of gSpiceUI. In reality, this application was designed in my head as it went along. A fair amount of it has been re-written as I found better ways of doing things. The design methodology would be best described as prototyping.
The object models shown below where developed to help provide a better picture of how things worked as the project got to the point where I couldn't remember how it all worked. The object models also depict how wxWidgets binds into gSpiceUI. Click on any of the images to enlarge it to it's full size :
The GNU GSPICE GUI Application Object Model depicts the top level application architecture. The App_gSpiceUI class inherits from the wxWidgets library wxApp class which is the entry point to the application ie. it contains main( ).
The Main Frame Class Object Model depicts the top level of the GUI architecture. The FrmMain class inherits from the wxWidgets library wxFrame class which contains all display objects within this class hierarchy.
The Analysis Class Object Model depicts the class structure of the objects which fill the analysis notebook (the notebook with the analysis tabs). It inherits from the wxWidgets library wxNotebook class.
The Process Class Object Model depicts the class structure of the objects which maybe executed as tasks by the application. It inherits from the wxWidgets library wxProcess class.
The PnlValue Class Object Model depicts the class structure of the display control used to contain numeric values. It combines wxWidgets library text, spin and choice controls so that numeric values (either integer or floating point with units) can be set with the mouse or keyboard.
- The GNU SPICE GUI project is comprised of many C++ classes, more than are depicted in the object models shown here. However, all the major classes have been depicted giving a good idea of the overall application architecture.
- The object models depicted here largely show the actual application architecture. However, the software is under development and is often in a state of flux, it will not always exactly match the information shown in the object models.
The source code is heavily commented and has been designed and written so that it may be maintained (or reused) by myself or anyone else for that matter. The project has well and truely got to the stage where it can no longer be maintained simply from memory.