In the early days of radio, before the term ``electronics'' came into use, experimenters and scientists (engineers designed bridges then) built circuits on whatever could be found that was appropriate. One popular substrate was the wooden breadboard as found in most kitchens. The breadboard could be used to secure the tube sockets and other appendages through use of screws. Thus, the term ``breadboard'' as a substrate for the building of electronic circuits was born.
Breadboards, in one form or another, were used for the construction of all electronic prototype circuits until the integrated circuit was invented in 1957. Even well afterward, the integrated circuit was only another component on the breadboard. A new circuit could be easily (well, in principle) debugged, modified, enhanced, or otherwise engineered toward perfection, as all points of the circuit were accessible for testing and measurement.
After it became possible to put more than a small number of devices on an integrated circuit chip, design of such chips became quite challenging. Obviously there was no opportunity to solder in new components, or even probe the internal connections. The circuit had to be perfect as designed, or it wouldn't work properly. This is almost never the case for any but the simplest design for any but those engineers with godlike intelligence (or luck). Clearly new tools and methods were needed.
The rescue came in the early 1970's with the distribution of a computer program called SPICE (Simulation Program for Integrated Circuit Engineering), developed at the University of California, Berkeley. SPICE was a big (for its day) Fortran computer program, requiring the power of a mainframe computer. A circuit was described in a certain syntax, which was punched into IBM computer cards. The terminology this inspired persists to this day, as a line of SPICE input is often referred to as a ``card'', and a complete circuit description as a ``deck''. In the bad old days, the engineer would laboriously punch the cards, deliver them to the Computer Center, and receive the line printer output a few hours later. It would generally take several iterations before the first page of output would not say ``Run Aborted...''. Old-time engineers abhorred this activity, which seemed suitable for office wimps and students only. After a few years, and the advent of Tektronix direct view storage terminals, SPICE became the preeminent means of designing not just integrated circuits, but the old-fashioned kind as well.
SPICE is the progenitor of most circuit simulators currently in use. As the source code was available for next to nothing, major organizations customized it for their own needs, and smoothed over some of the rougher edges. It remains a numerically intensive program which can tax even the largest of today's computers.
Looking back, one can identify several important milestones in the accessibility of computer power to the technically inclined masses. The first example was the ability to run the BASIC programming language on a desktop computer, introduced in the late 1970's with the Tektronix 4051. This 8-bit machine with a built-in direct view storage tube for the first time allowed engineers and scientists to have directly applicable computer power at their desk or laboratory bench. Also at about this time, the UNIX operating system running on a VAX minicomputer became popular, largely supplanting the ahead-of-their-time desktop computers. The VAX, although it was a mainframe, was very cost effective as compared to the competition, and UNIX was a much more desirable operating system for scientific and engineering purposes than others available. As with the 4051, it allowed computer accessibility at the point of need, through use of a terminal. Although one could compile and run SPICE on a VAX, it would tend to radically hog the VAX's resources, bringing the system to an annoying unresponsive state. As a consequence, many system managers forbade the use of SPICE on their machines, thus SPICE users were still faced with interfacing to the company CDC or IBM or Cray, and the attendant CPU time charges and batch mode operation. This situation persisted until the advent of the UNIX workstation in the early 1980's.
The original workstations were able to run SPICE, however the execution speed was quite slow by modern standards. Still, they were often faster than a heavily loaded central mainframe, and although expensive, were cost effective over time as compared to CPU charges for a mainframe. Many more engineers were able to take advantage of the convenience of running their simulations on local workstations, but due to the expense of the early workstations, the vast majority still had to slug it out with the mainframe.
In the early 1980's, the IBM personal computer came on the scene, and the real computer revolution was at hand. However, these micros had severe limitations which prevented them from even loading a program as large as SPICE, thus they offered no solution to engineers and scientists needing major number crunching ability. They did, however, provide the ability to run BASIC (thanks to Bill Gates), thus the personal computer began to displace the VAX in many instances, which had in turn displaced the earliest desktop BASIC machines. As the number of machines grew, and thanks to the ingenuity and manufacturing skills resident in the Far East, the cost of these desktop computers dropped rapidly. Intel, designer and purveyor of the microprocessor which was at the heart of the IBM compatible PC, made tons of money, which it wisely reinvested in newer and more capable models. However, the original operating system, DOS, which ran universally on PC's, was designed for and significantly incorporated the limitations of the earliest microprocessors used in PC's. These limitations have echos even today in certain Microsoft products.
Thus, it was not with a bang but with a whimper that the first inexpensive desktop computers which were capable of running SPICE and similar applications appeared. The Intel 386 microprocessor made this possible. Unlike its predecessors, the 386 was a true 32 bit architecture, more powerful than a room full of VAX hardware. It could easily sit on a desk, and cost, even in the early days, less than ten thousand dollars for a fully equipped system. Alas, however, the 386 PC was like a Ferrari which was deliberately equipped to emulate a Volkswagen. In order for the 386 to be compatible with its relatively brain-dead predecessors, Intel included an emulation mode in the instruction set. In this mode, called ``real mode'' by Intel, the 386 would behave as a somewhat faster version of earlier microprocessors, and thus be compatible with DOS, and all of the software written for DOS. So thorough was the emulation that even though the 386 could access 4 gigabits of memory directly, it was prevented from doing so under DOS, so that games and other archaic programs which could possibly make use of the memory address wrap around at 1 megabyte would perform as on earlier chips. To this day under DOS, the 386 and its descendants operate in this emulation mode, leaving the high-power native mode unused.
Intel assumed that a software vendor, meaning Microsoft, would soon produce a successor to DOS that would unleash the full power of its new chips. Alas, Microsoft responded by ignoring this potential in its own products, and appeared unsupportive of the exploitation of this power by other software vendors. The size of the DOS market evidently influenced this business decision. However, thankfully, a few small companies saw the potential. The first was Phar Lap, which by working directly with Intel delivered a product known as a DOS extender. Intel and Phar Lap, and others, created a specification under which extended DOS applications could coexist with regular DOS programs to a large extent. The DOS extender allowed programs of arbitrary size to be compiled and executed in the 32-bit native mode, which Intel termed ``protected mode''. The term derives from the memory mapping which allows all applications to have their own address space, and not clobber one another as they can under DOS. At last, with this product and the right compiler, it was possible to run SPICE on a desktop PC, without worrying about the memory limitations of DOS.
Microsoft eventually began to exploit some aspects of protected mode in the Windows product, however, Windows was completely incompatible with extended DOS software at the time. Microsoft's objective was to influence developers of large applications to port to Windows, for which they made available a $500.00 software development kit. Unfortunately Windows at that time had a memory management system which most judged inadequate for applications such as SPICE, plus the support for earlier versions of the Intel microprocessors in Windows added rather severe performance penalties. Thus, in spite of the lack of Windows compatibility, the DOS extender market greatly expanded, and several large commercial applications made use of this technology. DOS extenders were eventually being included with many advanced compilers for ``free''.
The DOS extenders extended the life span of DOS, however many limitations remained. One such limitation was the lack of multi-tasking. Although some products such as Quarterdeck's DesqView provided some crude multitasking, clearly the time had arrived that a completely new operating system was in order. These new operating systems began arriving in 1992. Vendors of advanced workstations, such as Sun and Next, released versions of their UNIX-derived operating systems for Intel machines. IBM introduced OS2 2.0, which was a 32-bit version of the OS2 operating system. Microsoft has released the NT operating system, the first version of Windows that ``really'' used protected mode.
The contender that will probably most interest engineers and scientists is UNIX. This operating system has a multi-decade history of use and improvement, with features and performance other operating systems are striving to emulate. Proprietary operating systems based on UNIX are available from several vendors, unfortunately, the cost, still quite high due to the licensing fee extracted by the copyright holder, is a deterrent. However, UNIX clones, which operate the same but use non-copyrighted software, are now widely available. The most popular of these are Linux and FreeBSD, both of which are available on the Internet, and on CD for a small fee. Both provide the advanced user with a state-of-the-art operating system, capable of running the plethora of applications available on the Internet. Linux has become quite popular with the general technically-inclined public, while FreeBSD has found a large niche as an Internet server, due to its reliability and speed. The running of massive applications on a desktop computer (or even a laptop) is now a reality. A properly equipped Intel-compatible computer running FreeBSD can be considered in every respect a `'Unix workstation''.
The original Fortran version of SPICE became widespread in the industry, and the creators of SPICE dispersed and went on to new projects. As SPICE became more widely used on modern hardware, its age began to show. Thus, the Berkeley groups set about to rewrite SPICE in a modern programming language (C), and added new features and functionality. The result was SPICE3. Unlike the previous versions of SPICE, SPICE3 was designed for interactive use. Furthermore, there were built-in features for plotting output on-screen, as well as enhanced control over the run in progress. SPICE3 has to date not received the widespread acceptance of its predecessor, mainly because is lacks the long history of use. Early releases did have bugs, and certain features were lacking. The new code, being written in a structured form, is relatively easy to modify, thus SPICE3 should become a standard in time, however it is also competing with commercial versions of SPICE with many of the same features. The original SPICE is still being shipped ``as is'', and although it is robust and stable, there are parts of the code that seemingly nobody understands.
In the early 1980's, IBM had a large project to introduce a computer based on Josephson junction logic. IBM used internal software to model these circuits, as SPICE was not designed to support Josephson junctions. To provide a generally available software simulation tool for the analysis of Josephson circuits, the Cryoelectronics group at Berkeley modified SPICE to include Josephson junctions. This version of SPICE, JSPICE, was distributed by the Cryoelectronics group to the handful of interested researchers. It quickly became the dominant tool for the simulation of these circuits (outside of IBM).
However, being based in SPICE, there were many aspects of the program which could stand improvement. Making these improvements would entail a complete rewriting of the SPICE code, a rather formidable task with the Fortran source. Nevertheless, this was done in large measure for internal use at Hypres, a small company engaged in superconductive electronics. The Hyspice program contained a numerical core written in C, which was supported by much of the original SPICE Fortran. The algorithms were modified to increase execution speed, while providing full support (rather than a tacked on appendage) for Josephson junctions. The execution speed for Josephson circuits increased by about a factor of 3-5 over the older JSPICE. Hyspice, however, was basically a batch mode program similar to JSPICE, although it was designed to work with a graphics post-processor, which was a separate application.
While entering a consulting and contract design practice, the author of Hyspice required a simulation tool in order to pursue design activities. Hyspice was proprietary to a former employer, and was obsolete anyway. JSPICE was even more obsolete. Thus, the author decided to modify SPICE3 to incorporate a Josephson model. Further modifications were anticipated so as to provide uncompromising capability and flexibility in the simulation of circuits using Josephson devices (without affecting the ability to simulate conventional circuits). The resulting program, named JSPICE3, also had to be compatible with the author's 386 computer, yet be portable to other computers and operating systems should the need arise. JSPICE3 evolved for several years. Along the way, new features were added, including a schematic capture front-end. The program, still available from Whiteley Research Inc., currently runs on most UNIX platforms, and is still being used in several industrial and educational facilities.
The author, once again getting restless, founded Whiteley Research Inc., in Sunnyvale, CA in 1996. The company was to develop a new successor to JSPICE3, and other tools for schematic capture and mask layout editing. After about one solid year of development, the XicTools toolset was announced. The electrical circuit simulator, part of the core of the XicTools and known as WRspice, is a descendent of the JSPICE3 program, and maintains full compatibility. The new program was migrated to the C++ programming language, for improved maintainability. Compatibility with the older SPICE program was improved, as support for certain capabilities in SPICE, such as the POLY directive, that were missing from SPICE3 were incorporated in WRspice. WRspice is more network-aware than its predecessors, and in fact can control the dispatching of jobs to remote machines, so that repetitive operations, such as Monte Carlo analysis, can exploit all of the machines in the user's workgroup in parallel. Incidently, Monte Carlo analysis is a new feature, too. Most of WRspice can be controlled graphically using point-and-click, yet is prompt-line compatible with its predecessors.
Probably the most popular industrial-strength SPICE simulator is
HSPICE
from Synopsys, Inc. Although ``next generation''
simulators from several vendors offer greater simulation speed and
support larger circuits, the variety and completeness of HSPICE device
models, algorithm flexibility, and usage history have made HSPICE a
target simulator for most if not all process design kits provided by
foundry services. WRspice has evolved to incorporate some of the
features of HSPICE, such as support for parameters and single-quoted
expressions, and device model extensions, to enable compatibility with
these design kits. Further, when there is a conflict between HSPICE
and Berkeley SPICE defaults, such as in the assumed temperature,
WRspice has adopted the HSPICE conventions. This is to conform to
industry standards and current user expectations. Though derived from
Berkeley Spice3, WRspice seeks to emulate HSPICE behavior as much
as possible.
However, there are some rather fundamental differences, for example: