home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
World of Ham Radio 1997
/
WOHR97_AmSoft_(1997-02-01).iso
/
misc
/
gate_sim
/
amsoft.iii
next >
Wrap
Text File
|
1997-02-01
|
14KB
|
266 lines
GateSim(TM) - A Gate Level Simulator
Version 1.0 Demo
To run the automated demo, insert the demo disk in drive a, type a:<Enter>,
and type gatesim lights<Enter>. You may temporarily halt a simulation by
pressing the space bar. Press it again to continue. At the end of each
horizontal simulation display, you may press any key to continue.
This demo version has all the features of the production version except the
following:
1. There is a limit of 100 nodes in the netlist file.
2. The result file facility has been removed.
Please copy this diskette freely.
On your GateSim demonstration disk you should find the following files:
!readme.doc This file.
gatesim.com The main simulator executable file.
gatesim.000 These two simulator overlay files need to be in the same
gatesim.001 directory as the .com file.
gatesim.doc An on-line condensed manual for GateSim.
lights.sch An OrCAD schematic file of an example circuit. This design
can be viewed on screen if you have a copy of OrCAD 3.0.
A printout of the circuit is included with this demo disk.
lights.wir OrCAD EDIF file produced from the .sch file using OrCAD's
netlist utility with the /p option.
lights.net Net list file produced by NetTran from the OrCAD EDIF file
mapping to National Semiconductor gate array cells and
timing information. This netlist file is read into the
simulator during the demo. The netlist translator,
NetTran, and vendor mapping libraries such as for National
Semiconductor gate arrays are available separately from
Tanner Research, Inc.
lights.vec The input vector file that specifies the signals going into
the example circuit.
lights.sim This file contains the simulator commands to run the demo.
When you start the simulator by typing "gatesim lights"
simulator commands are taken from this file instead of
from the keyboard.
lights.cmp The production output test vectors. Fault simulation
compares this file with the output from a simulation of
the circuit with a fault in it. This vector set also is
used by the vendor's tester hardware.
lights.cm2 A much smaller test vector set that still gives 100% fault
coverage.
The Example Circuit
--- ------- -------
Our example circuit implements a traffic light controller. It accepts a clock
time base and produces signals for the green, yellow, and red traffic signals
in both the east-west direction and the north-south direction. In addition,
the walk and don't walk signals are generated for both directions. The don't
walk signal flashes first and then turns on solid.
Eight D flip-flops form a binary ripple counter that divides down the clock.
Various logic gates decode the states of the counter to generate the required
traffic control signals. The ripple counter outputs do not all change at once
resulting in hazards or glitches that the simulator will help uncover.
The Automatic Demo
--- --------- ----
The automated demo begins by turning on the monitoring of the simulation on
the screen. (The simulation runs faster if the monitoring is supressed.)
Next the netlist is loaded from a file. The netlist file may be hand
generated or created automatically by NetTran (available separately) from an
OrCAD schematic. The NEtfile command specifies the file (lights.net) to be
read in.
The PAttfile statement gives the name of the vector file (lights.vec) to be
read in during the simulation. The vector file contains the specification for
the input signals to be applied to the circuit during the simulation. Within
the pattern or vector file, waveforms may be generated by specifying the
signal value for each time using a .pattern statement. The .clk statement
produces repetitive waveforms. The file lights.vec has examples of both of
these methods for generating input signals.
Back in the .sim file, the VIewvector command makes the input vectors appear
in the simulator display, mixed with the simulator output. Input vectors
show up with a ">" character in the first column.
The .hex statement defines a set of up to four signals that can be viewed
during the simulation as a hex digit. Later when the name "TOP" appears
in a .TAB statement, it refers to the four signals collectively as a hex
digit.
The simulator itself has no fixed time base. Simulation times are in terms of
integers. Vendor libraries, however, are created with a specific choice of
time unit. The National Semiconductor gate array library, whose timing is
used in this netlist, was created with numbers representing 1/10ths of
nanoseconds. Thus a simulator time of 50000 represents 5usec. The DP command
sets how the time units are displayed during a simulation. In this case, we
want to display times in nanoseconds, so we specify dividing simulator units
by 10 and showing 1 digit after the decimal point.
The nodes and hex digits to be displayed during the simulation are listed in
order in a .TAble statement. The semicolons serve to space out the resulting
simulation signals across the screen.
We begin a simulation for 5usec. The node names are listed vertically at the
top of the screen and the signal values scroll vertically underneath. Since
we did not specify a display time step in the sim command, a line of display
is shown on the screen whenever any of the monitored signals changes. This is
the most detailed viewing option that will allow you to easily trace activity
through your circuit. You will see any glitches on the monitored nodes.
Notice however that the times listed along the left hand side are not evenly
spaced. There is a time corresponding to each monitored transition but there
is no time listed during periods of inactivity. We will see an alternative
display style shortly.
As the simulation progesses, you can see that there is varying amounts of
activity in the circuit depending on how far down the ripple chain a clock
signal propogates. Each time a signal changes from the previous line of
display, it is shown in a different color to highlight the change.
After the 5usec simulation completes, we decide to monitor an additional
four signals as a hex digit. We add this item to the existing display list
with the '+' option to the .TAble statement. We continue with the simulation
for another 5usec with another SImulate statement. SImulate + continues the
simulation for a length of time equal to the last simulation time.
Next we change the display from vertical scrolling to horizontal. Horizontal
mode does not allow as many signals to be displayed on the screen at once, but
more time values of the signals may be seen. The simulation continues.
The waveform statement changes to displaying signals as waveforms instead of
binary digits. Hex digits continue to be displayed using characters. In
this simulation you can clearly see a glitch on the east-west green signal
about the time that yellow is turning off and red is turning on. With this
display mode, it is hard to tell just how wide the glitch is relative to
the other signals.
We continue the simulation with a sampled display option by specifying a time
step in the sim statement. Note that this change does not affect the way the
simulator simulates your circuit, only the way you view the results. During
this simulation, we see from the clock waveform that the time is displayed
evenly but we see that the green signal glitch has disappeared. This is
because we are sampling the simulator output at exactly the clock rate so
the glitch resulting from a clock transition has gone away by the time the
waveform is next sampled for display.
We decrease the display time step and simulate again. Now we can see
just how big the glitch is relative to a clock time.
If Vdd and Gnd are used as logic signals in a circuit, the fault simulator
will note that these nodes are not testable - by definition, those nodes are
stuck at 1 or stuck at 0. We use the FOrcenode command to set these two nodes
to already tested (T) so that they won't be reported as untestable.
We begin a fault simulation using the file lights.cmp. This file or a
derivative of it will be the one sent to the vendor to run on their tester.
The goal of the designer is to choose the vectors so that the shortest set
of vectors will catch as many possible fabrication faults as possible.
The file lights.cmp is similar to a simulator output file but has several
important differences. First, tester hardware has no way of telling if a
signal is unknown (X) so their must be no Xs in the .cmp file. Instead there
may be a character (.) that instructs the tester not to compare the signal
on that cycle. Testers sample the chip outputs according to the tester clock
so the vectors in the comparison file must be on clock boundaries. Long
comparison files can also be optimized to make use of the repeat capability
of some tester hardware.
The fault simulation proceeds by forcing a node to 0 and then simulating the
circuit. If the simulation output differs from the comparison file, that
node is marked as 0-testable. The same node is then forced to 1 and another
simulation is begun. If the output differs from the comparison file then
this node is 1-testable. If the node is both 0-testable and 1-testable than
it is testable. Then another node is forced to 0 and the process repeats,
until all nodes have been checked for testability. The simulator reports the
total number of nodes checked and the number that are testable.
The NDelay command reports the delay for all possible paths between the two
specified nodes. This static timing analysis tool allows you to find critical
paths in your circuit. The -c option tells how many clock-to-Q pathways
through D flip flops to follow before abandoning a search path. In this case
we set it to a large number because we want to find all paths.
For the example circuit there are six different paths between the node
TEST_POINT and the node DONT_NS, the longest of which has a rise time delay of
11.9ns and a fall time delay of 11.8ns. Each of the paths is listed. You can
trace them along on the schematic. The node names that have three underscore
characters in them are nodes that were created when mapping the cells on the
schematic to their implementation. For example, the OR gate, U18, is
implemented by a NOR gate followed by an inverter. The node in between these
two gates was assigned the name U18___000. Unlabeled nodes that do appear on
the schematic have names like U18_P3 which refer to the node connected to pin
3 of U18.
A Self-Guided Tour of GateSim
- ---- ------ ---- -- -------
At this point you may wish to copy the entire contents of the demo diskette to
a directory on your hard disk or RAM disk, especially if you continue beyond
the automated demo and modify some files. You may also wish to print out the
files !readme.doc, lights.sim, lights.vec, and gatesim.doc for reference as
you proceed.
Here are some suggestions for exercising GateSim by executing commands not
included in the automated demo.
1. Edit the file lights.sim that contains the simulator commands for the
demo. Change one or two things (e.g. remove all the DLay commands) save the
file and type again:
>gatesim lights<Enter>
Please make a copy of lights.sim before modifying it so you or others may
later run the original automated demo file.
2. Start up GateSim without a command file by typing
>gatesim<Enter>
Now you can type commands to the simulator and have them executed immediately.
The command line allows for TopDOS or EMACS-like commands such as ^F, ^B, ^A,
and ^E for forward, backward, beginning of line and end of line. There is
also ^D for forward delete and ^K for delete to end of line. Command history
may be displayed with ^R and re-executed with ^P and ^N commands. The home,
end, and arrow keys on the numeric keypad also move the cursor or traverse the
history of commands. The Tab key performs completion on file names. Type ?
to get a help screen.
3. To start with, type in the opening commands of lights.sim to load in the
netlist and test vector file. Use the TAB command to select the nodes of
interest for viewing during a simulation.
4. Start a simulation with the SIM command. Note how you can pause the
simulation with the space bar or interrupt it by hitting any other key.
5. If you have an EGA card, try the 43 line mode (EGA ON) or try vertical
waveform output (HO OFF) and (WA ON).
6. Try to track down all the hazards and glitches in the design.
7. Shorten the fault simulation or change the comparison file so they don't
catch all faults. For example "FS 0 100000 -c lights" leaves one node
untested. Take a look at the file lights.cm2. This vector set has been
reduced from the file lights.cmp to make a shorter set but still have complete
fault coverage. This condensing is often necessary for large chips with test
vector sets that otherwise would exceed the maximum number of vectors that
hardware testers can hold.
8. Try the -t option of the NDelay command. This option shows you the path
under consideration as the simulator traverses the tree of possible paths.
The maximum delay for rise time and fall time is displayed as it progresses.
To order your full functional version of GateSim, call (818) 795-1696 or write
to us at the address below.
GateSim is a trademark of Tanner Research, Inc. Other brand and product names
are trademarks or registered trademarks of their respective holders.
Copyright (c) 1988 Tanner Research, Inc.
Tanner Research, Inc.
128 West Del Mar Boulevard
Pasadena, CA 91105
(818) 795-1696