After having edited or created a circuit description file, you can execute the logic simulator by typing
on the system you are using. In response to this, the logic simulator will output the following:logicsim
At this point, type in the file name of the file describing the circuit you wish to test. For example, typeIOWA Logic Simulator, Ver. 9 Source file name:
dlatchto simulate the example circuit, assuming the example circuit description is in file
dlatch. After the file name is given, the system will compile your circuit description file. If there are syntax errors, the system will print out the error messages and terminate. When this happens, correct the errors and try again.
Note that the circuit description is compiled into an internal representation quite different from the textual representation of the specification language. Users of the simulator need not understand this representation, but the following description may be useful in understanding how the simulator works. The internal representation is not machine code or assembly code; instead, each gate is represented by a record with information about the state of that gate and a pointer to a linked list of wires connected to the output of that gate. Each wire record in this list holds a pointer to some other gates and a marker indicating which input of that gate it drives. This data structure is designed to support very fast simulation.
In the internal representation of a circuit, subcircuits and arrays have been replaced by data structures that are the same as the data structures that would have been used had the same circuit been described without subcircuits or arrays. Although the output of the compiler is not textual, the process by which subcircuits are processed resembles macro expansion. As a result, the decision to use or not use subcircuits or arrays should not be influenced by any consideration of simulation efficiency.
If there are no errors in the circuit, the logic simulator will print out the simulation header. For the example test file, this would be as follows:
This header tells you the initial status of the simulator. The components of the header are explained in the following paragraphs:========================================================== circuit name = dlatch input interval = 1.0us If you need help, type h. output interval= 500ns ---------------------------------------------------------- TIME:OUTPUT :INPUT ----:------ :----- 500 :q :qbar : d NS : | : | :do :co : |c : | : | : | : | : : || ========================================================== 0:| :| :| :| :INPUT:
INPUT:prompts in the following simulation. The default input interval value is 1 microsecond. That is, when the next
INPUT:prompt comes out, 1s of simulated time will have elapsed since the previous prompt. (See the advanced features section if you wish to override this default.)
OUTPUTcolumn, and a
INPUTcolumn. These serve as the labels on the three columns of simulation output.
Following the header, the simulator prints the initial values of each output
and the initial
The format for these is explained in the next section.
Outputs are initially low (0 or false) when the simulated power is turned
on, and all inputs are low prior to your entering the first input value.
This initial state is unstable, since it means that some gates may
start out with outputs that are not right for their inputs. As a result,
even if you don't change the input values, some of the outputs will
immediately change from 0 to 1. If your circuit has any feedback loops
in it, for example, if it contains flipflops, it may oscillate between
0 and 1 for some time as a result of these initial changes; this oscillation
may consume considerable computing time and it may delay the
INPUT: prompt appears, the system is in simulation mode.
Each time this prompt appears,
you can give new input values for each input of the circuit.
The legal input values are:
||-||a low (false) logic level.|
||-||a high (true) logic level.|
||-||repeats the previous logic level.|
|empty line||-||all input values remain unchanged.|
INPUT:prompt every microsecond of simulated time. Note that simulated time has nothing to do with real time. Making the input interval smaller will not necessarily make the simulator do any more or less work. This is because the simulator uses what is called a discrete event simulation model; in this model, it takes a (roughly) constant amount of computer time to simulate each change in the input of a gate from high to low or from low to high, completely independent of the input or output intervals. Every transition which takes place within a circuit is simulated, whether or not that transition has any observable effect on the outputs of the circuit. Note that this implies that the accuracy of the simulation is not influenced by the input or output interval! A long output interval only limits the accuracy with which simulation results are reported, not the accuracy with which they are computed. Some other methods of simulation involve an internal clock; such systems tend to give more accurate results if the clock is run at higher speeds.
11 in response to the
INPUT: prompt for the
example circuit indicates that both inputs
assigned the value 1 (high), since a
1 appears in each column.
After being given values, the system simulates all logic
transitions which occur as a result of input changes.
It also samples all the output values at the instant
when one output interval expires and displays the sampled data.
After the input
11, the following will be on the display screen:
There are two new lines of output because the input interval is twice the output interval. The input interval should usually be an integer multiple of the output interval.OK, logicsim IOWA Logic Simulator, Ver. 9 source file name: dlatch ======================================================== circuit name = dlatch input interval = 1.0us If you need help, type h. output interval= 500ns -------------------------------------------------------- TIME:OUTPUT :INPUT ----:------ :----- 500:q :qbar : d ns : | : | :do :co : |c : | : | : | : | : : || ======================================================== 0:| :| :| :| :INPUT: 11 1:|= :|= :|_ :|_ : : 11 2: |:| : |: |:INPUT:
p as an input value causes the simulator to switch the
indicated input from its previous value to the inverse of that value
for roughly half of an input inverval, and then switch it back to the
original value. Thus, a positive pulse will result if the previous
value was low, and a negative pulse will result if the previous value
was high. The pulse created by
p will be roughly centered in
the interval between successive
The input/output formats of the logic simulator are similar to those of a tool called a logic analyzer. Logic analyzers are used in testing and debugging digital hardware; they have a graphical display which will show the outputs of a digital system plotted as a function of time, and they are able to inject prepared sequences of test data into the inputs of the circuit. Because common computer display screens can scroll vertically, but not horizontally, the output of the simulator is turned 90 degrees from its conventional orientation. Because of character set limitations, transitions resulting from input changes will be displayed at the end of the next output interval and not immediately after the change. The latter leads to an apparent delay of one output interval in all outputs from the circuit. (If the ASCII character set had an overbar as well as an underline, this problem would be eliminated.)
The values of circuit outputs are displayed by the logic simulator as follows:
||- a low (false, 0) logic level.|
||- a transition from low to high.|
||- a high (true, 1) logic level.|
||- a transition from high to low.|
||- a short spike or pulse (2 transitions).|
||- a longer pulse (1 transition per line).|
||- multiple spikes (4 or more transitions).|
||- a dirty transition (3 or more transitions).|
Note that, when a spike, multiple spikes, or a dirty transition is shown, repeating the experiment with a smaller output interval will show more detail, allowing each transition to be shown on a different line. This corresponds to stretching the time axis of the display.
When a the simulation of a circuit begins, flipflops will usually
produce multiple spikes for a considerable time; this is a simulation
of the behavior of real flipflops when the power is turned on.
Flipflop outputs will usually settle into a stable state after a few
microseconds, but they can be explicitly set or reset immediately, as
was done with the example input for testing the
It may take a considerable amount of computer time to simulate the
power-on behavior of circuits with many flipflops, but this can
usually be avoided by using the initial low value of some input
to explicitly clear all flipflops in the circuit. Of course, if you
do this, the circuit won't work at all until you enter a high value
for this input.
The globally predefined
low inputs provided by the
simulator can be used to make an automatic power-on-reset circuit.
The key to this is that the simulator provides a low-to-high transition
high immediately after simulating the power-on-transient at each gate.
If an appropriate delay element is connected to the
a signal can be produced which will remain low for a period after the
simulation begins, and then go high for the remainder of the simulation.
There are a number of special commands which the simulator will accept at
INPUT: prompt. With the exception of the
these commands will be executed and then the output from the simulator
will be re-displayed and a new
INPUT: prompt will be
given as if no simulated time had elapsed. The legal commands may all
be abbreviated to one letter; thus,
quit may be abbreviated
input nn uu, where
nnis a positive number and
uuis one of
ns. Large input intervals will allow many output lines to be displayed between
INPUT:prompts. The input interval should usually be an integer multiple of the output interval.
output nn uu, where
nnis a positive number and
uuis one of
ns. Small output intervals allow detals of multiple transitions to be observed with each transition on a line by itself. Note that the input interval should not be smaller than output interval.
read ff, where
ffis the name of the new input file. This command is useful because it allows predefined test sequences to be used over and over, for example, while debugging a circuit, without the need to retype the data each time the circuit is tested. For example, consider the following test sequence stored in a file called
The output from a session in which this command is used is shown below:o 100ns i 0.2us 11 10 -- a comment 01 11 q
Note that each line of the file contains only one command or one set of input values. Note also that comments on an input line are allowed as long as there is at least one space separating the comment from the last column associated with an input pin. If you want a paper copy of the output produced by a session with the simulator, redirect the output before you start the simulator.OK, logicsim IOWA Logic Simulator, Ver. 9 source file name: dlatch ============================================================= circuit name = dlatch input interval = 1.0us If you need help, type h. output interval= 500ns ------------------------------------------------------------- TIME:OUTPUT :INPUT ----:------ :----- 500:q :qbar : d NS : | : | :do :co : |c : | : | : | : | : : || ============================================================= 0:| :| :| :| :INPUT: r example 1:| :| :| :| :INPUT: o 100ns 1:| :| :| :| :INPUT: i 0.2us 1:| :| :| :| :INPUT: 11 2:|= :|= :|_ :|_ : : 11 3: |:| : |: |:INPUT: 10 -- a comment 4: |:| : |: _|: : 10 5: |:| : |:| :INPUT: 01 6: _|:|_ : _|:|_ : : 01 7:| : |:| : |:INPUT: 11 8:|_ : _|:|_ : |: : 11 9: |:| : |: |:INPUT: q Simulation ends. OK,
titlecommand reprints the simulation header. This would have been useful in the above example after the input and output intervals had been reset. This is also useful if the header scrolls off the screen and you forget which inputs are which.
hand see what help the logic simulator can give you.
All error messages produced by the Iowa Logic Simulator during the compilation of a circuit description have the following format:
ERROR on line 999 of file XXX ---> MMM
The first line indicates the line number of the file on which the error was detected, and the second line indicates the nature of the error. The compiler operates in two passes, and if the first pass detects any errors, the second pass will be aborted. Within a pass, the compiler will usually report all errors it detects, tempered by an attempt to avoid reporting the same error more than once; for some errors, however, compilation will be aborted with the following message:
Compilation aborted; fatal error.
Pascal run-time execution errors:
string pool overflow:
packed text overflow:
symbol table overflow:
"circuit" or "inputs" expected:
use) or a keyword indicating start of of the body of that circuit (
circuitwas not followed by an identifier giving the circuit name.
too many use levels; limit = 4:
usedirective was too large. The logic simulator can have no more than 4 open input files at a time. The solution is to move
usedirectives to the global level, so that instead of having the main file include another, which in turn includes yet another, all included files are directly referenced by the main file. Alternately, simply replace some of the more deeply nested
usedirectives by the text of the included files.
usedirective had something in it other than declarations of constants and subcircuits. Keep in mind that nothing but blank space may follow the (optional) period at the end of a file.
")" expected in parameter list:
x found; y expected:
xwas found in a context where it is not legal;
yis one of the tokens (or the name of a token class) that would be appropriate in this context.
x: illegal redefinition:
xin a context where that identifier already had a local definition.
too many (actual)parms:
too few (actual)parms:
x: invalid gate/circuit name:
xwas found after the colon in a part declaration and
xwas not the name of a subcircuit or a predefined gate type.
x: invalid pin name:
xwas found after the dot in a pin name in a wire list and
xwas not the name of an input or output of that subcircuit or predefined gate.
x: invalid part name:
xwas found before the dot (if there was one) in a pin name in a wire list and
xwas not the name of a declared part.
x: unmodifiable name:
xwas found before a dot in a pin name, but was not modifiable by the suffix provided, for example, because
xwas the name of an input or output to the current circuit or subcircuit.
x.y: is illegally reused:
x.yused as the destination of a wire already had another wire connected to it.
no destination given:
towas expected but missing.
is not a source:
is not a destination:
x.y: has an open source connection:
x.y. After parsing the wire list of a circuit or subcircuit, a check is made to see that all outputs of that circuit or subcircuit were connected to some source of data, and a check is made that all inputs of all subcircuits of that circuit or subcircuit are connected to a source of data. As a result, this error message always lists the line number of the keyword
endmarking the end of the subcircuit where the wire is missing.
xwas used in an expression but had no declared meaning.
x: value is of wrong type:
xwas used in an expression and was declared as the name of an instance of a gate or subcircuit, or the name of an input or output pin. Or, in the declaration of the constant
x, the type of the expression giving the value did not match the keyword used in the declaration. In the latter case, an extra line is added to the error message giving the value of the expression that was found.
operands of " " incompatible:
ifstatement in a parts list or wire list was not Boolean. In both cases, an additional line gives the actual value of the expression or operand that was found.
oddwas applied to a non integer, an operand of the
modoperator was not an integer, an attempt was made to exponentiate a non-integer, a range constructor was used with non-integer bounds, or a non-integer array subscript was used. In all cases, an additional line gives the actual value of the expression or operand that was found.
positive integer expected:
modinvolving negative numbers was attempted, division by zero was attempted, or an attempt was made to instantiate a pre-defined gate type with a negative or zero number of inputs. In all cases, an additional line gives the actual value of the expression or operand that was found.
nonzero real expected:
positive time expected:
lastoperator was applied to a value that was not a range, or in the declaration of a part or an input or output pin of a circuit, the syntax of an array specification was used with a value that was not a range, or the expression governing the iteration in a
forstatement was not a range. In all cases, an additional line gives the actual value of the expression or operand that was found.
index out of bounds:
x: not an array name:
x, a part name or pin name that was not the name of an array of parts or pins.
x: unmatched parameter types:
xto an actual parameter of the wrong type. An additional line gives the value of the actual parameter.
unmatched array bounds:
x: index required for this part:
xof an array of parts was used without a subscript in specifying a pin to be connected in a wire list.
Most interactive simulator error messages should be self-explanatory and offer interactive help in correcting the error. The following error message will sometimes result from actual errors in the circuit being simulated, however, and can only be eliminated by changes to the circuit design:
Warning, bus "x" was driven with conflicting inputs:
xhad more than one bus-driver enabled at the same time, and two or more of the enbled drivers were attempting to drive the bus to differing values at the same time. In a real system, this can cause physical damage, overheating, or electrical noise and transient malfunctions; in the simulated system, it will cause no damage but the value on the three-state bus will be unpredictable until the conflict is resolved.