simulation backplane is a viable technique for ... arrival of mixed analogue and digital integrated circuits ... cuit into analogue and digital parts and to simulate.
Anatomy of a simulation backplane M.Zwoli ns ki C.Garagate 2 Mrea rica T.J. Kaimierski A.D. Brown
Indexing terms: Simulation backplane, Mixed signal simulation
Abstract: The paper describes how mixed signal simulation has been performed using a simulation backplane. This work is based on the draft standard for a simulation backplane, published by the CAD Framework Initiative. The simulation backplane allows two or more circuit, logic or behavioural simulators to be coupled. A circuit is partitioned between the simulators, and changes in analogue and digital signals connecting the simulators may be passed through the backplane. Synchronisation of the various simulators is handled by the backplane, and the paper describes a new synchronisation algorithm that avoids backtracking and prevents deadlock. A version of SPICE has been integrated into the backplane, and true mixed signal simulation has been demonstrated. These results show that the simulation backplane is a viable technique for linking multiple simulators, but that the overheads caused by interprocess communications are significant.
1
Introduction
The increasing complexity of electronic circuits and the arrival of mixed analogue and digital integrated circuits commonly requires the use of more than one simulator for the analysis of a single design. Traditional logic simulators cannot model analogue circuitry, and conventional circuit simulators are too slow for all but the simplest circuits. While it is possible to partition a circuit into analogue and digital parts and to simulate these parts independently, the simulation of a mixed signal design can be considered reliable only if the circuit is simulated as a whole. As a result of this, mixed h signal simulators have been developed. The logic parts are described and simulated by a logic simulator, and the analogue parts by an analogue simulator. The simplest and most efficient way to develop a mixed signal simulator is to tightly 0 IEE, 1995 IEE Proceedings online no. 19952128
Paper first received 13th January 1995 and in final revised form 7th June 1995 M.Zwoliriski, C. Garagate, T.J.Kaimierski and A.D.Brown are with the Department of Electronics and Computer Science, University of Southampton, Southampton SO17 lBJ, United Kingdom Z MrCarica is with Elektronski facultet NiS, Katedra za electroniku, Beogradska 14, 1800 NiS, Yugoslavia IEE ProcComput. Digit. Tech, Vol. 142, No. 6, November 1995
couple two simulators The logic and analogue simulators are combined in a single program, with a single circuit description laqguage and a single control loop, usually in the analogue part of the simulator. This unified approach does, however, have its drawbacks. If one wanted to couple a third simulator in a tightly coupled mixed h signal simulator, it would be very difficult. An integrated design environment, that contains several simulators, and allows the integration of new simulators if necessary, and that has other tools needed for electronic circuit simulation, is an attractive solution. Simulators and other tools can be designed for such an integrated environment. However, many manyears are needed to develop a new simulator. It would be desirable to integrate existing simulators, such as SPICE [l] and VHDL simulators [2] into the design environment. This would allow a user to use different simulators to analys,e different parts of the same design, choosing the most appropriate tool for each partition. This integrated environment should allow different logic, analogue and lmixed h signal simulators to be coupled. These tools ,are very complex, and use different simulation algorithms, data representation, and user interfaces. Some support circuit description at a transistor level, others at a gate level or a higher level behavioural description. Different models of simulation time are used, too. A SPICE-like analogue simulator [ 11 calculates the time-step (i.e. the next simulation time), on the basis of the local truncation error (LTE) estimate at a time point for a given numerical integration formula. On the other hand, an event driven simulator [2] calculates a new event and its time as a result of events that aLre happening at the current time, given the delays of gates. An integrated simulator can use a hybrid algorithm, allowing both event driven and SPICE-like simulations to take place [3-51. Some simulators are capable of backtracking, they are able to retum the simulation time to a given breakpoint, but this is not generally possible. Furthermore, in analogue simulators, the circuit variables are floating point numbers: voltages, currents, charges and fluxes or some other nonelectrical variable. In a logic simulator, variables take more abstract values: zero, one, unknown, high impedance etc. (i.e. there is a finite set of values). This paper is not c;oncerned with all the data types and function calls specified in the proposed CFI standard, but some of them are mentioned for the purpose of explaining the synchronisation algorithm. 371
2
The simulation backplane
The model of a simulation backplane has been proposed to allow different tools to be integrated into a common structure. The interface between the backplane and the different simulators is standardised to make the task of integrating a new tool simply that of writing the interface. A first step toward such a standard has been made by the CAD Framework Initiative (CFI) [6].The CFI Application Programming Interface (API) has been used as the basis of the work described here. The general structure of a simulation backplane is shown in Fig. 1. The tools that are integrated into the backplane are the simulators, or solvers and the waveform display tool. For these tools, interfaces must be implemented to connect them to the backplane. Also, the backplane must have a user interface, and a synchroniser, that contains the control loop of the simulation. The design data contains information about the partitioning of the design and about connections between partitions, which is necessary for passing global signals from one partition to another.
I
.I
I
r
I
I
11
Simulation backplane structure
From the point of view of the backplane, the interfaces must be standardised. While a simulation is running, the backplane communicates with all simulators in the same way. An instruction given to a particular simulator uses the same, standardised function call, whatever the capabilities of the simulator. On the other hand, communication between the interface and the simulator itself is at the level appropriate for that simulator. The interface converts data from the form used by the backplane to that used by the particular simulator, and vice versa. Thus the same functions calls from the backplane result in different activities in, for instance, logic and analogue simulators. The interface is responsible for translating the instruction from the backplane into the appropriate
An event which is passed over a global net is represented by a union of the logic (enumerated type), integer and analogue (64-bit floating point type) values. There is also an additional variable to indicate whether it is a logic, integer or analogue quantity. In this way, all types of events can be passed over the backplane in the same manner. The CFI backplane proposal [6] supposes that all integrated simulators and the backplane run as a single process, because communication is achieved by using standard function calls. However, it is not necessary that all integrated simulators must be linked into the backplane. If they are linked in, it is difficult to use more than one instance of a simulator to simulate different partitions. Every instance must read its own partition and build its own data structures describing both the partition and the current state of the simulation. If an existing simulator such as SPICE [l] is integrated, it would have to be modified in order to simulate several partitions. Using integraled simulators that run as separate processes can make multiple instances of one simulator very simple, as every process makes its own copy of the data structures when invoked. Function callback registering is supported in the backplane to implement multiple instances. Since [6] assumes that simulators are linked in, integrating them as separate processes into the backplane is done such that their existence as separate processes is transparent to the backplane. The interface for a simulator integrated as a separate process is divided into a backplane part and a simulator part (Fig. 2). The backplane part communicates with the backplane in the standard manner, using standard data types, and functions. The simulator part of the interface is linked to the simulator object files. Communication betw two parts of the interface is implemented using sockets. Inevitably, it has been found that the interprocess communication adds a significant overhead to the simulation time.
simulator activities.
Fig. 2 Simulation backplane with simulators
Time is represented in the backplane as a 64-bit integer value [6].A special value is used for infinity: all bits are set to 1. When an integer type is used for time, equality of times can be determined by comparison, which is very important for synchronising multiple simulators. If a simulator has a different representation of time (e.g. a floating point type), the interface for that simulator must convert the time from its backplane representation to the simulator representation and vice versa.
Thus, the simulator instances exist as separate programs and run as separate processes. This makes concurrent processing feasible. However, even using multiple processors does not mean that simulation really runs in parallel, because the synchronisation algorithm only allows one simulator to run at a time. A different synchronisation algorithm would be needed to exploit concurrency fully.
378
as
separate processes
IEE Proc -Cornput Drgit Tech,Vol 142, No 6, November 1995
3
Design elaboration
Ideally, the user would simply indicate the simulation accuracy required for each part of the design and the partitioning would be done automatically, choosing the most appropriate simulator for each partition. The partitioning problem has not, however, been tackled here and the design must be partitioned by hand. One difficulty in integrating different simulators into the backplane is that they can have different input languages. Ideally, the design would be passed to the backplane and thence to the simulators by a central database but for simplicity here, each partition is described using the syntax of the respective simulator. Moreover, the partitions are described in separate files. Besides these files, there is a configuration file, read directly by the backplane. The configuration file names the partition files and the simulators, as well as global nets (ports) connecting the partitions. An example of the configuration file is shown in Fig. 3. For instance, the line ‘als PhaseDetector’ in this configuration file means that the ‘als’ logic simulator is used to analyse the partition described in the file ‘PhaseDetector’. If a simulator is used in configuration file more than once, more than one instance of that simulator will be created. PLL
i i i t * * * t * t * *
The method proposed here forbids multiply driven global nets. If the global net in Fig. 4 is owned by any of the partitions A, B or C, than we have the situation shown in Fig. 5. Here, Ihe global net is owned by partition A. Instead of one. we now have two global nets, neither of which is multiply driven. Resolution of the net is done in the partition that owns the net, in this example partition A. ID this approach, global nets are not nets in the general sense, they are only one-to-one connections (i.e. ports). The port between partitions A and C in Fig. 5 is bidirectional, but is always resolved by one simulator. r----------------------
1 global net 1 partition B
I I
global net 2
t
partition
Fig. 5
C
Resolution of two globul nets
*********ti
als PhaseDet global portinout is output global portoutup is up global PortoutDown i s Down spl Fllter global portinxinl is up global portrnxin2 is Down global portoutxoutl is Cont vco vco global DortinVcontrol i s cont global portoutout is Output time 200000
Fig.3 Example simulation backplane configuration file
A partitioned circuit has a number of global nets, connecting two or more partitions. In the general case, one global net can be driven by the outputs of more than one partition, as is depicted in Fig. 4. The global net is driven by the outputs of partitions A and C, and is driving inputs of partitions B and C. For partition C, this global net is bidirectional. partition B
partition A
I
1 partition C
U Fig.4 Resolution of global net
When a global net is driven by more than one output, the value on the net must be resolved before it is propagated to partitions driven by that net. Global nets do not belong to any partition, and are not resolved by any simulator instance. There is an obvious drawback to this approach. The backplane is now not only an interface and synchronisation mechanism, it is a solver itself, with logic and analogue capabilities, This is achievable, but complex, especially if the resolution function is supplied by the user. IEE Proc -Cornput Digit Tech, Vol 142, No 6, November I Y Y 5
In the backplane, whatever method of partitioning is used, it is assumed that a global net has a single type. If a global net connects a logic and an analogue partition, the net can be either analogue or logic. Signal conversion is done within one of the partitions. If the simulator employed for a particular partition is not able to perform signal conversion, then the interface that integrates that simulator to the backplane should do so. Interface models also need to be generated by the partitioning software, although here they are the user’s responsibility. Connections between partitions must be stated in the configuration file. In the configuration file of Fig. 3 , the line ‘global portinout is Output’ indicates that al net with the local name ‘portinout’ is connected to a global net ‘Output’. ‘global’ and ‘is’ are keywords. Each global net name must be stated exactly twice in the configuration file, because only one-to-one connections between partitions are allowed. Besides the configuration data, the time interval for the simulation of the dlesign is given in the configuration file, in nanoseconds for the example in Fig. 3. The time interval is common for all partitions. Other data, needed to simulate some particular instance (LTE tolerance, absolute and relative tolerance for analogue simulation, delay model for logic simulation etc.) are given in the partition files. Names of nets that are to be traced and displayed using the waveform display tool are also given in the partition files. Only one waveform display tool is integrated into the backplane, therefore it is not necessary to specify the waveform display tool in the configuration file. 4
4. I
Simulation algorithm
Synchronisation
There are a number of algorithms for the synchronisation of two or more simulators [3-51. At one extreme, optimistic simulation allows each simulator to progress in time until it runs out of inte activity has ceased). If an event from another simulator 379
is generated before the end of this optimistic time interval, all results generated after that event are discarded. This means that simulators must be able to backtrack. At the other extreme is the lockstep algorithm, in which all the simulators progress with the same time step. This approach ensures that there is no need for backtracking and no results are thrown away. The approach adopted here is a hybrid algorithm, in which the simulators use their own internal timesteps, but the global simulation time is approximately the same for all simulators. Two functions implemented in the simulators, and called by the backplane, are of crucial importance for the implementation of the synchronisation algorithm. The backplane is not aware of the nature of the simulators called, so the function calls have the same parameters for both event driven and circuit (SPICE-like) simulators. Before explaining timing synchronisation, the response of event driven and circuit simulators to these function calls will be described. The first function returns the next activity time of a simulator to the backplane. If the simulator is event driven, its next activity time is simply the time of the first event in the event queue. If there are no scheduled events, a special value of infinity is sent. When the function is executed for a circuit simulator, the value returned to the backplane is the last already solved time point. A circuit simulator is not able to determine its next activity time in advance. After solving at a time point, the simulator predicts its next activity time, but this estimated time point can be rejected. The time step is then cut. Only when circuit has been solved at one time point and the error is within acceptable limits, can this time be defined as the next activity time. The second function invokes a simulator to run until a specified time, the target time, is reached. An event driven simulator will simulate until all events in the event queue scheduled before the given time have been processed. If there are events scheduled exactly for the target time, only one delta cycle will be executed at that time [2]. When this function is executed for a circuit simulator, the simulation will run until the last solved time is greater than or equal to the target time. Fig. 6 illustrates the sequence of simulation times. The last solved target time
i I
accepted time
I
I
I
1
* time
next activity time
Fig.6 Relation of simulation time points
time is shown as the next activity time. The time point before the next activity time is called the accepted time. The next activity time is greater than or equal to the target time and the accepted time is always less than the target time. Both event driven and circuit simulators can stop execution before the given target time if they produce a global event (i.e. an event on a global net), before the target time. This global event will change the next activity time of some other simulator, and the sim380
ulator that is currently running must stop to avoid possible backtracking. The simulator behaves as if the time of the global event is its new target time. For a circuit simulator, the next activity time (the time when the global event occurs) is then equal to the new target time.
4.2 Simulation cycle In the initialisation phase, the configuration file is read and the backplane is invoked. For every partition, the backplane invokes one instance of the appropriate simulator. Also a waveform display tool is invoked. A simulator, when invoked, reads its partition file and performs all the initialisation of the circuit that it is able to do without knowing the values of its global inputs. Initialisation of the circuit as a whole will be explained in the following Section. In this phase, the connection of global and local nets is established. Every local net name described in the configuration file must be found in its partition description, otherwise an error is reported and simulation is not performed. After the initialisation phase, the backplane is told to perform a simulation for a user defined period of time. The backplane performs the simulation using the following algorithm: (i) idle-count is set to zero for all simulators. idle-count shows how long a particular simulator instance was idle (i.e. how many times other simulators were invoked to run while that one was not). (ii) The next activity time is returned for each simulator instance. (iii) The backplane calculates the start time as the minimum of all next activity times from (ii). The simulator with the minimum next activity time is also found. This simulator will be next simulator to run. The minimum next activity time for all simulators other than the next simulator is found. This is the target time for the next simulator. If two or more simulators return the same minimal next activity time, the start time and the target time are the same. One of these simulators has to be chosen as the next simulator. The simulator that has been idle for the longest time (i.e. that has the greatest value of idle-count) is chosen. If the idle-count values are also the same, any of these simulators can be the next simulator (this can happen only if these simulators were inactive from the beginning of the simulation). (iv) The simulator causes the next simulator to run to the target time calculated in (iii). It can stop before target time if it produces a global event, as explained above. While running, the simulator sends all events on traced signals that occur before the target time to the backplane. Events generated after, or at, the target time (i.e. at the next activity time) (Fig. 6 ) are not sent because they can be discarded in the next run of the same simulator instance. When the backplane receives a traced event, it immediately sends it to the waveform display tool. Global events are also sent to the backplane. They are sent if their time is less than or equal to the target time; they are not sent for the next activity time (Fig. 6 ) if it is greater than the target time. The backplane finds the receiver of the global event on the basis of the data in the design configuration representation and sends the global event to the receiver simulator instance. idle-count for the simulator which is running is set to 0, and for other simulators idle-count is increased by 1. IEE Proc.-Comput. Digit. Tech. Vol. 142. No. 6, November 1995
Steps (ii) to (iv) are repeated until all activity is exhausted or until the user defined finish time is reached. A circuit simulator will only receive global events that occur after the accepted time (Fig. 6). Thus the next activity time of an analogue simulator may have to be discarded, because a new global event can occur before the next activity time. However, backtracking is not a problem if it is limited only to the most recent time point (next activity time), because it is simply a matter of reevaluating a time point, with a decreased time step. As the simulators are implemented as separate processes, each call from the backplane to a simulator has a high price in terms of interprocess communication. The efficiency of the backplane can be improved significantly if the next activity times for each simulator are stored within the backplane. As only one simulator runs at a time, all the next activity times other than that for the simulator that runs remain the same. Thus only one call to one simulator instance is needed at each time point to find the next activity time.
4.3 Lock-up problem The problem that must be resolved, however, is the prevention of time lock-up, when two or more simulator instances are exchanging events at one time point, and no progress in time is made. This problem will be discussed first with the simple example of two event driven simulators. Consider the example in Fig. 7 where two event driven simulators have the same value of next activity time. Suppose that first simulator 1 runs from start time = target time to target time. Simulator 1 will execute one delta cycle and exit. After that, simulator 2 will do the same. If they are not sending events at target time to each other, simulators 1 and 2 will run one after the other until all events scheduled for target time are exhausted. The reported next activity time will be increased, so lock-up will not occur. simulator 1
target time
simulator 1 time
I.1 f
simulator 2 time
I
simulator 2
target time
Fig.7 Logic simulator lock-up
Lock-up may occur if simulators are sending global events at the target time to one another (Fig. 7). Neither simulator l nor simulator 2 is able to exhaust all the events scheduled at the target time and the time will never be increased. This can happen only in a circuit which has a zero delay feedback loop, and such a circuit cannot be simulated even as a single design, without partitioning. When the delta count becomes too large, lock-up is detected and the simulation is stopped
PI.
With an analogue simulator the problem is more complex. Suppose that two simulators have the same target time (Fig. 8). Simulator 1 runs but there are no IEE ProcComput. Digit. Tech, Vol. 142, No. 6, November 1995
global events sent to it by simulator 2. So, simulator I increases its time and solves the circuit at a new time point, its next activity time (Fig. 9). Simulator 2 runs next. If it sends global events to simulator 1 at its target time, a new event is scheduled at the accepted time of simulator 1. Thus siimulator 1 should reject not only its next activity time, but its accepted time as well. Thus, simulator 1 should not run when its target time is equal to its next activity time, and there are no new global events at its next' activity time to cause recalculation at this time. But, if both simulators in Fig. 9 are analogue, simulator 2 will not perform any activity if no events are sent from simulator 1. Therefore, neither simulator 1 nor simulator 2 do anything when invoked and a lock-up occurs without good reason. accepted time 1
next activity tJme 1
*
7) simulator 1 time
w
accepted time 2
next activity time 2
simulator 2 time
Fig.8 Analogue sirnulator lock-up accepted time 1
I
accepted time 2
next activity time 1
I
next activity time 2
simulation 2 time
Fig.9 Avoidance of lock-up
The backplane avoids this as follows. When an analogue simulator does not have any activity (i.e. its next activity time is equal to the target time), and no global events are sent to the simulator before running, the simulator reports to the backplane that no activity has occurred. When the backplane finds that more than one simulator is to run to the same target time, and all of the simulators report no activity when invoked, it avoids the unwanted lock-up by increasing the target time sent to all the locked-up simulators by one integer unit of time. This situation is most likely to happen in the initialisation phase. 5 Integrating SPIC:E3e2into the simulation backplane
The synchronisation allgorithms of the simulation backplane were tested with a simple event driven logic simulator and a simple analogue simulator. In addition, an analogue behavioural model of a voltage controlled oscillator was used in one simulation example. While the logic simulator is sufficient for modelling gate level circuits, any realistic simulation of nonlinear analogue circuits requires a relatively complex circuit Simulator. SPICE3e2 [7] has therefore been modified to include an interface to the simulation backplane. SPICE3e2 was chosen because the source code is readily available. The interface contains functions which establish a communication channel between the backplane and SPICE and control the SPICE simulation processes. The inter381
face is divided into three parts: the interface module, the partition data module and the simulation engine module. Fig. 10 shows the interface which connects SPICE to the backplane. simulation backplane
Fig. 13
t
volinport
I Interface module I partition data
1 .
simulation engine
Fig. 14 .logoutport SPICE application programming interface
r
I
SPICE 3e2 circuit simulator
~
l
‘,Ut t
Fig. 10 Simulation backplane interface to SPICE3e2
The first function of the interface module is to establish a communication channel between the SPICE simulation process and the backplane. When the backplane initiates a new simulation process, it passes two parameters, the instance handle and the SPICE netlist file name. The instance handle is an integer which specifies the instance identification number for each process. The SPICE netlist file name is obtained from the backplane configuration file. The interface module initialises the partition data module and then enters a loop which reads the socket, interprets the commands, invokes the simulation engine functions and returns the messages to the backplane. The loop is repeated until the simulation terminates. The partition data module is a parser which extracts global port information, traced signal information and signal conversion parameters from the input files. The global and traced nets are declared in a SPICE circuit description file, while the signal conversion parameters are defined in a separate configuration file. SPICE3e2 does not provide interfaces to external nets. The global net interfaces are included in SPICE in the form of subcircuits. Six different subcircuits have been designed for six distinct global net connections as shown in Figs. 11-16. The subcircuit definitions are described below
1. TCi” Fig. 11 Input/output port model: loginport
Fig. 15 :curoutport
Fig. 16 :voloutport
‘loginport’ declares a logic input port which is modelled by a voltage source, a resistance and a capacitance. The source value is set according to the logical input state [8]. The parameters which specifies the conversion from a logic value to an analogue value and the transition time are described in the SPICE configuration file. ‘curinport’ and ‘volinport’ are subcircuits that model inputs from other circuit simulator instances or behavioural simulators which produce analogue outputs. ‘logoutport, curoutport’ and ‘voloutport’ are output port subcircuits. The ‘logoutport’ is used to comect SPICE to a logic simulator. The threshold values which specify the transistions from logic one to zero and zero to one are given in the configuration file. The ‘curoutport’ and ‘voloutport’ are used to connect to another analogue simulator instance. These six keywords are reserved for global port declarations. It is important that the global ports must be used correctly because they receive and produce different event types. The SPICE backplane interface has a signal conversion capability. The analogue to digital and the digital to analogue conversion parameters are described in the SPICE configuration file as follows: global < xinputl >
I
Fig. 12 382
curinport
1
4
0
loginport Tlh=O Thl=O L=O H = 5 X = 2 5 Z = 3 Type=O global < xoutputl > logoutport tr01=4 trlO=l
For a logic input net (‘loginport’), the parameters ‘Tlh’ and ‘Thl’ specify the transition times used to change IEE Proc -Cornput Digit Tech, Val 142, No 6, November 1995
the logic state from low to high and high to low, respectively. Parameters ‘L’, ‘H’, ‘X’ and ‘Z’ define the voltage or current source value for the low, high, unknown and high impedance states, respectively. The parameter ‘Type’ defines the input source type. ‘Type = 0’ specifies the input is a voltage source, while ‘Type = 1’ indicates that the input is a current source. On the other hand, the parameters for the logic output net: ‘trOl’ and ‘trlO’ specify the threshold levels in which the output state changes from logic zero to one and from logic one to zero respectively. The SPICE circuit is described using the normal SPICE netlist format. A global port is declared by using one of the global net subcircuits. For example, the SPICE netlist file might contain the lines:
< inputmame > x < outputname > x
n l n2 n3 loginport n4 n5 n6 logoutport .plot tran v(n1) v(n2) v(n3) .tran 10ns 20000ns The traced nets are declared with the ‘.plot’ line and the simulation time is specified on the ‘.tran’ line. The simulation engine module controls the SPICE simulation processes. The engine functions as an event driven simulator. It receives global input events from the interface module, performs signal conversions, then inserts the events into SPICE by modifying the data structures for the sources in the input subcircuits. The engine also examines the global output ports at every time step, and send global output events to the backplane. At present, the engine receives only logic input events. A logical input event consists of a signal name, a new logic state and an event time. The logical output events are generated by observing when the node voltages cross the threshold values on the global output nets. Output events can also be a voltage or a current which drives another analogue partition. The voltage and current events are sent to the backplane directly without any conversion. An analogue event is defined as an output which has changed by l o p units. Output changes which are less than lop units are ignored to reduce the communication between the simulator and the backplane. As will be explained below, these output events are not sufficient to interface to another instance of SPICE. SPICE3e2 contains a transient analysis function called DCTran(). DCTran() runs the analysis for a certain number of time steps or to a particular time. This would appear ideal for implementing the synchronisation, although some modifications to include the last time point revaluation capability are needed. The simulation function in the simulation engine module now performs the following operations. First of all, the global input processing function is invoked to convert the global input events and insert them into the SPICE data structures. Then it checks whether the target time is equal to the last simulation time. If they are equal, the repeat flag is set which means the last time point is being repeated. Then, the function checks whether the last time point solution needs to be re-evaluated, and sets the re-evaluation flag. If the last time point is being repeated but does not need re-evaluation, the function will indicate to the backplane that no activity has occured and it exits. On the other hand, if the solution needs to be re-evaluated, the program will invoke the DCTran() routine which will cancel the last IEE Proc -Compyt Digit Tech, Vol 142, No 6, November 1995
solutions, cut the time step and simulate the last time point by taking into alccount the new events. After that, the function goes into the main run through time loop. The loop starts with the global output processing which processes the global output nets. If the simulator generates global events, it will return the number of the created events, then exit. If there are no global events, the function checks whether the simulator time is less than the target time and the function exits if the simulator time is equal to or greater than the target time. Otherwise, the last tirne point is an accepted time and any traced nets are sent to the backplane. Then, DCtran() is invoked 1.0 advance the simulation to the next time step. This loop is repeated until the simulator generates global events or it reaches the target. As will be shown, tlhese modifications to SPICE and its integration into Ithe simulation backplane allow mixed signal simulations to be performed. While it has already been noted that the synchronisation algorithm is not suited to concurrent multiple processor simulations, it is not unreasonable to consider whether it is possible to simulate an analogue circuit using multiple invocations of SPICE:. In principle, the backplane is capable of coupling two analogue simulators together and passing events between them. This has been done with the original, basic circuit simulator. To couple multiple invocations of SPICE, however, the loading effect of one partition on another must be modelled. To do this, it is necessary to derive the equivalent circuit for one partition and to insert this equivalent circuit into another partition. The second phase of this is already implemented: we can use a ‘curinport’ model and update the component values to reflect changes in another partition. The derivation of these component values is not trivial, however. The matrix solution algorithm in SPICE would have to be modified to perform only a partial solution and the matrix values would have to be extracted [9]. It has been decided that the changes needed to SPICE cannot be justified as the functionality added to the backplane is more than offset by the fact that the simulation of a circuit partitioned between two OK more instances of SPICE would be very inefficient because of high cost of interprocess communication. Nevertheless, as we show below, if the loading of one part of an analogue circuit upon another is not significant, it is possible to perform a mixed level behavioural and circuit level analogue simulation using two simulators. 6
Simulation examples
This Section describes two mixed signal simulation examples, which have been used to test the functions of the simulation backplane and the integrated simulators. The first example is a phase locked loop (PLL) design. The second example is a sigma-delta converter circuit.
6.1 Phase locked loop simulation A phase locked loop consists of three parts as shown in Fig. 17: a voltage control oscillator (VCO), a phase detector and a loop filter. The VCO generates an output which has the same frequency as the input signal to the PLL. The phase dletector observes the phase difference between the PLL, input and the output generated by the VCO and generates two control signals which constitute a feedback control signal to the VCO. The PLL circuit is divided into three partitions simulated at three different levels of abstraction. The VCO 383
m
n: output
-1
Input I
-
I
!
I
I phasi detector
I
I I I I I I I I I
Fig. 19. The circuit consists of two switched capacitors, an integrator, a CMOS inverter and a D-latch register. The circuit has an analogue input voltage: ‘vin’ and produces a digital output: ‘q’. The circuit requires two nonoverlapping clocks: and $2 and it also needs two reference voltage sources at 5 and -5V.
. -
I
-
i
I I I I I I I I
Fig.19
I
has a central frequency at 15kHz and a slope of 2kHzI V and is simulated at the behavioural level using a C program which performs the VCO function. The phase detector is simulated at gate level by the logic simulator and the loop filter is simulated at circuit level using SPICE. The simulation results shown in Fig. 18 illustrate the simulation outputs from 0s to lms. The simulation results show that the changes of the phase detector outputs(‘Up’ and ‘Down’) resulted in node voltage changes on the filter circuit (vl and v2). The control voltage (v2) is sent to the VCO which varies the output frequency response (‘output’) to the control signal.
Switched capacitor sigma-delta modulator
The design is divided into two partitions. The switched capacitors, the integrator and the CMOS inverter are simulated at the circuit level using SPICE3e2. The switched capacitors are implemented as NMOS pass transistors and capacitors. The op-amp is modelled as a voltage control voltage source (VCVS). The D-latch is modelled at register level using the logic simulator. The simulated waveforms are shown in Fig. 20. The analogue input, vin is a slow ramp signal rising from 3.5 volts at 0 p to 4.5V at 400p. The nonoverlapping clocks oscillate at 200kHz. Only the Q2 clock is shown. Fig. 20 shows that the spaces between output pulses increases with the rising input.
d
vtn
0
o
1.2 1.8 2.9 3.8 4.4 5.0 5 5 6.1 7.2 8.2 8.8 9.4 time xl00 ps
Fig. 18
09
1 2 16
19 2 3
26
30
33
37
timexlOO v s
Fig.20
Simulation results of sigma-delta modulator
Simulation results of phase locked loop
The total simulation time was 850s. This time is divided as follows: the SPICE simulation took 298s, the logic simulation 1s and the behavioural VCO simulation 76s. The time spent in the backplane was 162s and the system CPU time was 313s. The system CPU time is the time used for interprocess communication. Some of the simulation time is also spent sending and receiving event transactions.
6.2 Analogue to digital converter design A sigma-delta converter circuit diagram is depicted in 384
03 06
The A to D simulation was performed successfully under the simulation backplane. However, because many parts of the circuit were simplified, the digital output was not very accurate. The input range which produced a linear output was limited. The output accuracy and the linear range could be improved by employing more accurate models of the circuit. Again, it is interesting to note the proportion of time spent in each simulator and the backplane. The SPICE simulation took 43s of CPU time, the logic simulation 2s, the backplane 14s and the system calls 27s, giving a total simulation time of 86s. IEE Proc -Cornput Digit Tech, Vol 142, No 6, November 1995
7
Conclusions
The implementation of a simulation backplane has been described. By using the CFI model, a standard programming interface to logic, circuit and behavioural simulators can be developed. A synchronisation algorithm that avoids backtracking and lock-up has been described. The integration of SPICE3e2 into the backplane has been achieved with relatively few changes to the algorithms within SPICE. while it is possible to couple two or more instances of SPICE and to pass signals between these instances, it is not possible to accurately model the loading of one partition modelled in this way upon another without some very radical modifications to SPICE. Two examples of mixed signal simulations have been demonstrated, proving that the simulation backplane can be used to couple simulators, but also that the overheads in this method are significant.
IEE Proc.-Comput. Digit. Tech, Vol. 142, No. 6, November I995
8
References
1 NICHOLS, K.G., KAZMIERSKI, T.J., ZWOLINSKI, M., and BROWN, A.D.: ‘Overview of SPICE-like circuit simulation algorithms’, IEE Proc. Circuits Devices Syst., 1994, 141, pp. 242250 PERRY, D.L.: ‘VHDL’ (McGraw-Hill, 1994, 2nd edn.) BLOOM, M.: ‘Mixed-mode simulators bridge the gap between analog and digital design’, Comput. Des., 1987, 26, pp. 51-65 CORMAN, T. and WIMBROW, M.V.: ‘Coupling a digital logic simulator and an analog circuit simulator’, VLSI Syst. Des., 1988, 9, (2) SAMPSON, G.: ‘An ideal mixed-mode simulation’, VLSZ Syst. Des., 1988, 9, (1 l), pp. 70-78 KEMP, T.: ‘A proposal for a modest prototype simulation backplane interface revision 1.O’ (CAD Framework Initiative Inc,1992) QUARLES, T.L.: ‘The SPICE3 implementation guide’, Electronics Reasearch Laboratory, College of Engineering, University of California Berkeley, CA 94720, USA, 1989 8 ARNOUT, G. and DEIVIAN, H.J.: ‘The use of threshold functions and Boolean-controlled network elements for macromodelling of LSI circuits’, ZEEE J. Solid-State Circuits, 1978, SSC-13, (3), pp. 326-332 9 ZWOLINSKI, M. and NICHOLS, K.G.: ‘The design of an hierarchical circuit simulator’, European conference on electronic design automation, 1984, pp. 9-12 -
385
