SUSANA: a MOS-Mixed-Circuit Simulator Using Logic/ELogic ...

Download PDF
3 downloads 47184 Views 126KB Size Report
Comment
In this work it was applied to large digital ISCAS85 benchmark circuits. Several ... Using Logic/ELogic Algorithms implemented in. Python. Tiago Carrisosa.
SUSANA: a MOS-Mixed-Circuit Simulator Using Logic/ELogic Algorithms implemented in Python Tiago Carrisosa Tiago F´elix Miguel Jer´onimo INESC-ID/DEEC, Instituto Superior T´ecnico R. Alves Redol, 9, 1000-029 Lisboa, Portugal

Jos´e Soares Augusto INESC-ID/Physics Dept., Fac. Ciˆencias da Univ. de Lisboa R. Alves Redol, 9, 1000-029 Lisboa, Portugal email: [email protected]

Abstract— In this paper we describe the simulator SUSANA (Portuguese acronym for ”Alternative Numerical Algorithmsbased Simulator”), based on the ELogic simulation approach and implemented in Python/wxPython. ELogic, traditionally used in digital MOS circuits simulation, is also suitable for analogue and mixed circuits simulation. In this work it was applied to large digital ISCAS85 benchmark circuits. Several improvements have been added to standard ELogic, such as the implementation of a logic simulator to obtain initial conditions in ELogic simulation of digital circuits. The use of a very high level programming language (Python) permitted the rapid development, test and debugging of a quite complex circuit simulator and of the associated visual input and data analysis components. Examples, results and a description of the simulation environment are presented here.

I. I NTRODUCTION Several techniques have been developed to speed-up circuit simulation. In particular, the simulation of digital circuits has been researched and implemented in many different ways. The application of efficient algorithms, developed mainly to the simulation of digital circuits, to mixed and analogue circuits is reviewed in detail in [1]. These algorithms are usually much faster than the direct solution of the circuit differential equations [2], [3] used in Spice-like simulators. One of the most well succeeded simulation concepts is that of event-driven simulation. This concept is used in SUSANA by means of the ELogic algorithm [4]. Present day wide choice of programming languages and paradigms offers excellent opportunities for the rapid development, debug and test of complex programming projects. The choice for writing SUSANA has been the Python language [5] due to its clear syntax, to its support of high level programming concepts (garbage collection, dynamic data structures, functional programming and list-oriented processing, threading,...) and to the existence of a rich and robust library: in particular, the WxPython/WxWindows library [6], [7] of visual components was used to implement the user-simulator interface.

II. E VENT-D RIVEN S IMULATION AND THE EL OGIC A LGORITHM In this section we review the general concept of event-driven simulation and its particular implementation in electrical-logic (ELogic) simulators. A. Event-driven simulation Event-driven simulation is a simulation paradigm that exploits the latency found in the operation of most electronic circuits, mainly in digital circuits, and implements a ’selectivetrace’ type of simulation. In fact, it has been observed that at a given time only 10% to 20%, on average, of the gates/nodes in a digital circuit is changing values [4], which demonstrates that in many circuits latency is prevalent. ’Selective-trace’ means that only the circuit elements whose inputs are subject to changes are simulated: the elements whose inputs remain steady are not simulated and, as a consequence, circuit simulation runs faster. In standard time-domain simulators, such as Spice, many calculations are done without need because, although most of the nodes are static at a given instant, the numerical algorithm calculates all the node voltages (and the currents in some elements). If only a few nodes are under strong activity – an example is the clock line in a sequential circuit –, then the time step used to integrate the circuit’s differential equations by Spice’s algorithm is restricted to a fraction of the clock period. All the node voltages (which can be many thousands in practical circuits), and some currents, are calculated at a rhythm imposed by the time step. Each time step a linear system with as many equations as circuit variables (can be thousands) must be solved, and this is a computationally intensive task. In event-driven simulation, at a given time only the node voltages/circuit elements which are undergoing change are simulated. To track the changes, it is used the concept of fanin and fanout nodes: the fanout nodes of a given node (say node p) is the set of nodes which must be processed after a state change in p. Correspondingly, node p is a fanin node of all its fanout nodes. For instance, in a MOS transistor the drain and

Events-list at time t N

Node Y

Node X

Present time

Vdd

tN

Vin

M2

tN+1 Voltage N-1

Voltage N-1

Voltage N

Voltage N

M1 t=0

Time

fanout list of node Y (evaluated nodes)

fanout list of node X (evaluated nodes)

Vo

Vo

C

5 4 3 2 1 0

t1

t2

t3

t4

t5

t

Fig. 2. CMOS inverter responding to a input L-to-H transition, at t = 0, using ELogic simulation with 6 states. The continuous curve represents approximately what would be seen in a Spice simulation.

Scheduling of future events

Fig. 1.

Data structure of the event-driven simulation engine in SUSANA.

source are fanout nodes of the gate, and the gate is a fanin node of D and S nodes, in case a unidirectional model is used for the MOSFET, as is common. In figure 1 a simplified view of the data structure used in the event-driven simulation engine of SUSANA is shown. The column at the right is the time-axis: at a given ’time instant’ (tN in the example) there is a linked list with the nodes to be processed (i.e. to change state) at that instant. In the example these are the nodes X and Y . Each node has information about its change of state and, after consulting the database with the fanout nodes, it is verified if these fanout nodes change state in response to the modification in the state of X (or of Y ). In case this happens, the instant when that state change occurs is calculated (see the description of the ELogic mechanism below) and the corresponding events are scheduled in the events-list, or time queue, at a future time. Event-driven/selective-trace simulation is used heavily in logic simulation [8] when the gate delay (say τg ) is taken into account: only the gates where, at least, one of the inputs changes are simulated. After a change at one input, the output is scheduled to change at tnow + τg , where tnow is the current simulation time. In (multivalued) logic simulation, there is clearly defined a change of state because the states belong to a discrete set (e.g. {0,1}, {H,L,X,Z}, etc). However, voltages and currents in analogue and mixed circuits are continuous and must be discretized in order to be possible to have ’a change of state’. This is what happens in ELogic simulation. B. ELogic simulation There have been several implementations of the ELogic algorithm, differing mainly in the complexity of the simulation engines. In this work the simplest one (named ELogic-1 in [1], [4]) has been implemented, because ELogic-2 and ELogic-3 are slower, and our implementation already suffered from the drawback of using the interpreted language Pyhton which is much slower than compiled languages. However, it is

known that ELogic-1 has the drawback of showing diminished accuracy in some cases [4]. In the ELogic approach a set of discrete voltages is defined, where each value corresponds to a possible ’state’ in the node. The maximum and minimum voltages in the circuit, as well as the voltage interval between states, ∆V , are used to define the states. For instance, if Vmax = 5 V, Vmin = 0 V and ∆V = 1 V, then there will be 6 states in the set {S0 , S1 , ..., S5 }. Figure 2 demonstrates a typical ELogic simulation of a CMOS inverter subject to a L-to-H transition in its input. In ’ELogic’ terms this means that the state of node Vin changes abruptly from S0 to S5 . (We assume Vdd = 5 in the simulation.) The state transitions at the output node, V o, are shown also in the figure: at time t1 the state of the output changes from S5 to S4 ; at time t2 it changes again from S4 to S3 ; and so on and so forth, until at time t5 it changes from state S1 to state S0 and, as there is no more activity in the circuit (the events-list is empty), the simulation stops. The transitions are scheduled in the events-list or time-queue and processed. In the CMOS inverter all nodes, but V in and V o, are fixed. V in is an independent voltage source and is thus always defined. The events-list, in this particular example, only has events in V o after the initial event in V in (L-to-H transition) which starts the simulation. In ELogic-1 the equivalent circuit of the inverter is shown in figure 3. The transistor M2 is cut-off and thus it doesn’t contribute to the charge/discharge of C. It is assumed that all the nodes which are not at a fixed potential (which aren’t voltage source nodes) have a grounded capacitor. This capacitor models all the interconnection capacitances and all the MOS parasitic capacitors attached to the node. In figure 3, the electrical characteristic curve of M1 is replaced by a linearized model, calculated at the actual operating point P , consisting of the current source I1 and of the conductance G1. G1 is the slope of the tangent line at P . Note that I1 and G1 in general depend on the MOS voltages (i.e., on the specific location of P in the Id(V gs, V ds) curve.) For the sake of illustration, suppose that we start the analysis at t = 0 s. Node V in has just risen to 5 V. This event is put in the events-list and starts the simulation. As V o is a fanout node of V in it is evaluated (in ELogic, whenever one node

Vin=5 V

M1

Vgs=5 V C

I1(Vin,Vo)

Id1

Vo

Id1

I1

P

G1(Vin,Vo) Vo

Fig. 3. Equivalent circuit of the CMOS inverter in ELogic simulation as seen by node V o.

changes state all of its fanout nodes are evaluated: each node is a fanout node of itself, that is, whenever it changes state, it also ’calculates’ its next change.) The state of V o is S5 (it is initially charged with 5 V). When a node is in state Sk it will move to one of the states Sk+1 or Sk−1 depending on the Norton equivalent it sees. In fig. 3, C is discharging which means next state will be S4 , corresponding to 4 V in node V o. The time ∆t it takes to go from S5 to S4 is, under a forward-Euler approximation: ∆t =

C ∆V I1 + G1 V o(S5 )

(1)

where ∆V = V o(S5 ) − V o(S4 ) is the voltage separating the adjacent states (1 Volt in the example). In general, when several adjacent elements are contributing to the current in the capacitor CK located in the node under evaluation, NK , the overall contribution can be represented by a Norton equivalent consisting of a current source IK (pointing ’into’ CK ) and a of conductance GK , which leads to the general equation ∆t =

CK ∆V IK − GK VK

(2)

After calculating ∆t the transition is scheduled at tnow +∆t and the next event in the list is removed from the eventsqueue and processed. The simulation continues until the end of simulation or until there are no more events in the queue. A much more detailed explanation of ELogic is given in [1], [4]. III. I MPLEMENTATION I SSUES IN SUSANA A. Algorithmic issues The ’states’ of the nodes are defined by the user, through the maximum and minimum voltages and the ∆V parameter. Capacitors at each node are also user-defined, or can be extracted from MOS electrical models (used in Spice simulators). 1) Initial conditions in long-path circuits: An important issue in time-domain simulation is that of initial conditions (ICs). Standard simulators (e. g. Spice) perform a DC simulation at t=0 to find the ICs, unless the user provides them in the simulation file. In SUSANA this problem is particularly important when simulating MOS digital circuits with long paths. An extreme example is that of a chain of inverters with ’0’ at the input: if all the nodes are initialized at ’0’, half of the inverters have the

wrong state and the circuit will naturally try to evolve to the correct solution when the simulation starts. However, until the correct solution ’propagates’ from the first gate along the path, there will be a lot of ’uselless’ activity in all the inverters (in a consecutive pair of inverters, in the middle of the path, how do they ’know’ which one will be at ’0’ and which one will be at ’1’?) and there is a long delay until the correct solution develops. It was measured that the simulation of a pulse propagating in a 1000-inverters chain, correctly initialized at t = 0, spent only 40% of the simulation time compared to the uninitialized simulation. As this burdens hardly ELogic, a logic/switch-level simulation algorithm [9] was included in SUSANA. This widelyused algorithm simulates correctly MOS logic circuits with feedback lines and with transmission gates. B. Programming/Implementation Issues The simulator was implemented in Python [5]. The Graphical User Interface (GUI) was implemented in wxPython [6] a Python library which wraps the wxWindows (now WxWidgets) [7] set of graphical libraries. Among other tools, the GUI includes a project browser which allows the user to define input signals, choose libraries, set initial conditions, select signals to observe in the output window, etc. The choice of Python, instead of C, C++ or other compiled language, was mainly due to the high programming efficiency it allows for: in fact, several empirical observations made by many programming teams pointed out that the efficiency, compared to C/C++, is between 2 and 10 times, depending on the specific task being analised. SUSANA comprises about 15000 lines of Python code; complete reports on the algorithms and user manuals, the development of the Logic and ELogic simulation engines and of the WxPython GUI were achieved by a team of three programmers (the first 3 authors) which had never before programmed in Python/WxPython in only a total equivalent time of 1.5 man/year! 1) Accelerating Python: The work was developed in a Windows platform, using some Windows-specific libraries, what didn’t allow to speed-up the simulator through the development of some of its modules in C. It was nevertheless used Psyco, an optimizing bytecode compiler for Python, which resulted in a modest 10% improvement, on average. Under Unix/Linux the Python code could have been easily mixed with C code using extension tools such as SWIG or Pyrex. In [5] is available many information on this topic of Python ’acceleration’, including several alternative ways of doing it. C. Data input and analysis: the wxPython GUI The main GUI window (project window) is shown in figure 4. The simulator accepts either a gate-level description or a MOS Spice-like description: the gate level description is mapped to a MOS electric-level description with the help of circuit libraries. The signal inputs can be pure 0/1 digital and

Fig. 4. Main window of SUSANA: the definition of a simulation project is made in this window using several menus (titles shown in Portuguese). In the left sub-window one can select and edit the stimulii file, the component libraries, and the circuit file.

Fig. 6.

Graphics from the simulation of a ring oscillator.

Fig. 7.

Fig. 5.

Example of piecewise-linear input.

digital clock (for logic simulation only), PWL (see figure 5 for an example) and periodic digital signals with time information. SUSANA includes a full-featured graphics visualization tool which supports zooming, selection of signals, color definition for each signal and compares evenly (or better!) with commercial simulators’ graphics windows (such as Probe in Pspice). In figure 6 are shown the signals resulting from the simulation of a ring oscilator with five stages and an enabling signal (one of the inverters is a NAND gate). All the graphics in SUSANA are colored: those in this paper’s figures have been converted to gray levels. IV. E XAMPLES SUSANA was applied to several circuits, such as: amplifiers, ring oscillators, flip flops, and ISCAS86s benchmark’ circuits. Some of the results are reported here. A. Comparison with Spice To compare SUSANA and Spice, a chain of 1000 CMOS inverters (fig. 7) with a train of pulses, or with a single pulse, applied at the input was simulated. These two kinds of inputs result in quite different simulation activity levels (i.e., number of events processed per unit of simulation time) in SUSANA. Figure 8 shows the run times as a function of the number of

Chain of CMOS inverters.

ELogic states (this is only relevant for ELogic, not for Spice). The top horizontal line (at about 235 s) corresponds to a Spice simulation with the train of pulses; the lower horizontal line (at about 205 s) corresponds to Spice with one single pulse at the input. The two sloping lines, starting at the origin, correspond to SUSANA simulations when the train of pulses (upper, steeper line) and the single pulse (lower line) are applied. When a single pulse is applied, the activity in the circuit is quite low (only the gates where the pulse is propagating at a given instant are active and thus are being simulated – a comparable image is that of a pulse propagating through a transmission line) an this is when ELogic compares more favourably with the Spice standard integration algorithm. The simulation time in ELogic is almost directly proportional (the lines are virtually straight) to the number of states defined for the simulation. In case a large number of states is chosen, ELogic simulation becomes slower than Spice simulation. Run times, in a longer simulation run than that of fig. 8, are summarized in table I. With a state separation of ∆V = 1 V, SUSANA is 83 times more efficient than Spice; with a separation of one tenth of that value (0.1 V), the simulation results are more precise but it takes approximately 12 times more time to run than the previous one (efficiency is 7). The C3540 ISCAS85 benchmark circuit is an ALU. It was used to compare simulation results of SUSANA and Spice in a ’real’ circuit. This circuit comprises 1669 gates, 7640 transistors and 3872 nodes, including 50 primary inputs and 22 primary outputs. Spice and SUSANA simulation graphics, of the same ALU signals, are shown in figures 9 and 10. They are similar except at the beginning of the simulation, in the width of the initial glitches: this is due to the fact that the

Fig. 9.

Simulation of ISCAS85 C3540 ALU with Spice.

Fig. 8. Comparison of SUSANA and Spice run times (chain of 1000 CMOS inverters.) SIMULATOR Spice SUSANA (∆V =1 V) SUSANA (∆V =0.1 V)

TIME (s) 1180 14.3 168

REL. SPEED 1 83 7

TABLE I S IMULATION RUN TIMES OF A CHAIN OF INVERTERS IN S PICE AND IN SUSANA.

Fig. 10.

capacitors in the Spice MOS models were not extracted to SUSANA (they were smaller in SUSANA, what explains the thinner glitches). The run times of these simulations are shown in table II. SUSANA was 12 times more efficient. SIMULATOR Spice SUSANA (∆V =0.25 V)

TIME (s) 4557 380

REL. SPEED 1 12

TABLE II ALU SIMULATION RUN TIMES IN S PICE AND IN SUSANA

We finish by recalling that the simulator is entirely implemented in Python, an interpreted language (it uses internal bytecode compilation, but it is comparable to interpreted languages like Perl or Tcl/Tk) what implies that simulations (i.e., numerical processing) in SUSANA are slower by at least two orders of magnitude when compared to compiled code (C, C++, Pascal, Fortran, etc.). See [10], where the relative efficiency (including run times) of the most common programming languages is compared.

Simulation of ALU C3540 with SUSANA (∆V = 0.25 V).

Current work in the simulator is focused mainly in speed improvement through the revision of its internals (especially the algorithms), and in porting it to Unix/Linux architectures what will allow an easy rewrite of the numeric processing modules in C. Another option under study is the use of Jython (a version of Python written in Java) and of Java to improve the portability of the simulator. Implementation of ELogic-2 and ELogic-3 simulation cores is also under consideration. R EFERENCES [1] R. Saleh, S.-J. Jou and A. R. Newton, Mixed-Mode Simulation and Analog Multilevel Simulation, Boston, Massachusetts: Kluwer Academic Publishers, 1994. [2] L. O. Chua and P. M. Lin, Computer-Aided Analysis of Electronic Circuits, New Jersey: Prentice-Hall, 1975. [3] J. Vlach and K. Singhal, Computer Methods for Circuit Analysis and Design, 2nd Ed., Van Nostrand Reinhold, 1994. [4] Y. H. Kim, S. H. Hwang and A. R. Newton, Electrical-Logic Simulation and its Applications, IEEE Tr. CAD, Vol. 8, No. 1, Jan. 1989. [5] http://www.python.org.

V. C ONCLUSION AND F URTHER W ORK We described the SUSANA circuit simulator that uses ELogic simulation. Despite being programmed in interpreted Python, what burdens its numerical processing efficiency by at least two orders of magnitude when compared to compiled languages, it was often more efficient than Spice in circuits with a substantial amount of latency. On the other hand, the use of Python allowed for the rapid development of a complex simulator and of a complete visual simulation environment.

[6] http://www.wxpython.org. [7] http:/www./wxwindows.org http://wxwidgets.org).

(now

wxWidgets

at

site

[8] M. Abramovici, M. Breuer, A. Friedman, Digital Systems Testing and Testable Design, Piscataway, New Jersey: IEEE Press, 1990. [9] R. E. Bryant, A Switch-Level Model and Simulator for MOS Digital Systems, IEEE Tr. Computers, Vol. 33, No. 2, Feb. 1984. [10] http://www.bagley.org/˜doug/shootout/, http://dada.perl.it/shootout/.