Basic Simulation

Mastering the fundamental workflow of the Simic simulator.

Introduction

SIMIC performs tasks that are specified via a run command language. The commands are entered interactively or in batch operation. SIMIC supports a large repertoire of commands to control simulation options, to modify the modeled electrical properties of circuit components, and to find and eliminate problems in the design.

SIMIC allows the designer to model a logic network by using a hierarchical or “building block” approach having as many levels as desired. Ultimately, the circuit is resolvable to an interconnection of SIMIC primitive elements, either built-in or user-defined. This hierarchical approach helps to make circuit design and debugging a more manageable task by allowing the designer to verify subcircuits independently.

A SIMIC logic network description requires only two basic statements that describe the functionality of the network; a type statement and a part statement. The type statement names a logic building block or “macro”, and declares its pins (inputs, bidirectionals, and outputs). The part statement details the composition of the macro’s components and interconnections. Each part statement instantiates (includes a reference to) a type which may itself be a macro.

This chapter introduces SIMIC run commands—instructions that are entered to control SIMIC's operation—and describes the basic steps for simulating a circuit design:

  • entering SIMIC
  • leaving SIMIC
  • general syntax of SIMIC run commands
  • the minimum set of commands needed for basic simulation
  • using files that contain SIMIC run commands

Subsequent chapters of this Guide will provide details on the use and options of these commands. However, the information in this chapter is applicable to a wide range of standard situations and should provide sufficient SIMIC background to successfully begin using it.

Entering SIMIC

To begin a SIMIC session interactively, simply type the command:

simic

at the system's prompt.

Case Sensitivity

SIMIC is case insensitive by default—it converts all lowercase input to uppercase. In order to support case sensitive environments, SIMIC can be instructed to operate in case sensitive mode. This mode is invoked with the -s option on the command line: 

simic -s

When this option is activated, the case of all user-defined names (i.e., signal, subcircuit, delay, and instance names) will be preserved.

Entering Run Commands

Upon start-up, SIMIC displays a sign-on "banner", which contains the version of SIMIC currently executing. The version number has the format:

<major-release-number>.<minor-release-number>.<update-number>

After the banner, SIMIC will display its own prompt (>>:) requesting command input:

The SIMIC Logic simulator... Version 1.00.00
>>:

Each time a command is entered, SIMIC will execute the command and, after all required operations have been completed, issue another prompt to indicate that it is ready for the next command.

Attention Interrupt

Most run commands specify options for subsequent simulation, and are processed virtually instantaneously, compared to human reaction time. Some operations, such as compilation and/or simulation of large circuits, and generation of voluminous reports, will require waiting for completion. If it becomes necessary to prematurely terminate these operations (e.g., a mistake has been made, too much output has been requested, unexpected results are observed early in the simulation, etc.), simply use the system Attention key (control-C on most systems). SIMIC will stop its current operation, output an ABORT message, and issue its prompt for a new command: 

ABORT: User interrupt.
>>:

Leaving SIMIC

Once SIMIC has been invoked, a SIMIC session is ended by typing the command:

>>: quit

SIMIC will also exit if an "end of file" condition occurs during a read at the console. For example, the UNIX control-D (^D), and the VMS/MS-DOS control-Z (^Z) are equivalent to issuing a quit command.

Parts and Signals

For the purposes of SIMIC simulation, a network description consists of instantiated elements (parts) and nets (signals) that interconnect the pins of these parts. Functional attributes may be assigned to parts (boolean equations, input timing checks, etc.), and electrical attributes may be assigned to signals (rise time, decay, loading, etc.). Throughout this Guide, the terms "signal", "node", and "net" will be used interchangeably, as will "part", "component", and "element".

Example: The FULL-ADDER Circuit

The following example introduces basic simulation using the minimum set of SIMIC run commands. It is suggested that this circuit be referenced while reading further into this guide.

Full Adder Circuit Diagram

Figure 1: Full Adder Circuit

Describing the Full-Adder

This classic arithmetic circuit, shown in Figure 1, has three inputs and two outputs. Inputs a and b are operands, and carry-in implies connection to the carry-out of a previous stage. The three inputs are all fed to a 3-input Exclusive-OR gate, named xor, whose output, sum, is a logical-1 whenever there are an odd number of logical-1s at its inputs. The three inputs are also connected in all possible combinations to the inputs of three 2-input AND gates (and1, and2, and3) such that if two or more inputs are simultaneously logical-1, a logical-1 is propagated through the 3-input OR gate (or1) to output carry-out. 

c= Demonstration circuit of a Full-Adder
t=full-adder i=a,b,carry-in o=sum,carry-out

p=xor   t=exor  i=a,b,carry-in      o=sum
p=and1  t=and   i=a,carry-in
p=and2  t=and   i=b,carry-in
p=and3  t=and   i=a,b
p=or1   t=or    i=and1,and2,and3    o=carry-out

Figure 2: SNL Description of the Full Adder Circuit

Figure 2 illustrates a description of this circuit in SNL, SIMIC's network description language. SNL basics are covered in Circuit Modeling; however, a brief overview should suffice for a good understanding of the Full-Adder description. The fundamental concept to grasp is that SNL is a keyword-oriented language; each field of a line must be a keyword-field of the form keyword=value. Referring to Figure 2:

  1. The first line, beginning with C=, is simply a comment.
  2. The second line, beginning with the T= keyword, is a type statement (T is an abbreviation for TYPE) that assigns the name full-adder to the circuit, defines its input (I=) pins as a, b, and carry-in, and its output (O=) pins as sum and carry-out.
  3. The next five lines instantiate the five gates in the circuit, and specify the nets connected to their pins. They are called part statements.

For example, the first part statement, line 3, places the 3-input exclusive-or gate generating sum into the circuit. The first keyword-field of this line (P=xor) assigns the name xor to this part (P is an abbreviation for PART). The second keyword-field (T=EXOR) declares the gate's type as an exclusive-or, which is one of SIMIC's built-in primitives. The third keyword-field, (I=a,b,carry-in), specifies the exclusive-or gate's three inputs. Finally, the last keyword-field (O=sum) names the gate's output signal.

Note that the output signal names of parts and1, and2, and and3 are unspecified, since there is no O=... keyword-field in their associated part statements. If this keyword-field is omitted in a part statement instantiating a single-output component, SIMIC implicitly assigns the output signal the part's name. (This reduces the amount of typing required.) Thus, the names of the signals generated by the three AND gates are defaulted to and1, and2, and and3.

To further reduce the amount of typing required, SNL supports a shortcut that eliminates the need to enter keywords (e.g., p=, t=) in most part statements. For example, the first part statement could have been: 

xor exor a,b,carry-in sum

This method is described in Shortcuts & Formatting.

SIMIC Simulation of the Full-Adder

Figure 3 illustrates an interactive simulation session for the Full-Adder circuit. User input is shown bold. Each user input line is terminated with the appropriate key for the current system ("Enter", "Return", etc.).

Step #1: Specify default file name.

Step #2: Specify the circuit to be simulated.

Step #3a: Specify the primary input stimuli.

Step #3b: Apply the primary input stimuli.

Step #4: Specify what should be reported during simulation.

Step #5: Initiate simulation.

Step #6: Exit SIMIC

simic
The SIMIC Logic simulator... Version 1.00.00

>>: define file=fad
>>: get type=full-adder
Main Get Network : FULL-ADDER
GET completed, Circuit totals: Parts = 5; Signals = 10
Inputs = 3; Busses = 0; Outputs = 2

>>: define padd.3 = 000 001 010 011 100 101 110 111
>>: apply pattern=padd
>>: print list=a,b,carry-in**sum,carry-out
>>: simulate

Remark= Options: (Fault Free simulation)
Remark= Pattern stimuli, Near Filter, Spike Propagation
Remark= Stable Before Decay, Dynamic Delay

C=         ABC        SC
C=           A        UA
C=           R        MR
C=           R         R
C=           Y         Y
C=           -         -
C=           I         O
C=           N         U
C=                     T

     0T 1: 000        00
     0T 2: 001        10
     0T 3: 010        10
     0T 4: 011        01
     0T 5: 100        10
     0T 6: 101        01
     0T 7: 110        01
     0T 8: 111        11

>>: quit
Quit Command Issued... Leaving SIMIC
Total SIMIC CPU-time = 0.14 sec. (00:00:00.14)
........... User : 0.12 sec. (00:00:00.12)
.......... System : 0.02 sec. (00:00:00.02)
...... Page faults : 0

Figure 3: SIMIC Simulation Session for the Full Adder

Step-by-Step Explanation

Each of the commands and the corresponding SIMIC response will be discussed in detail. To begin the SIMIC interactive session type simic in response to the system prompt. Upon start-up, SIMIC prints a banner. After this banner, SIMIC issues the interactive prompt (>>:), requesting user input.

The first command entered at the prompt:

>>: define file=fad

specifies a default name, fad, for all files that SIMIC is requested to read or write. This default can be overridden for any file by specifying a different file name in the appropriate run command. If the default file name is not specified, SIMIC supplies the name, noname, as the default.

The second command:

>>: get type=full-adder

instructs SIMIC to compile the circuit, full-adder. Since no file was specified in this command, SIMIC uses the default file name defined in the previous command, fad, and the default extension for network files, net, as the name of the file to be read. It then searches this file for a circuit description named full-adder, reads the description, and compiles it. SIMIC's response to this command is: 

Main Get Network : FULL-ADDER
GET completed, Circuit totals: Parts=5; Signals=10
Inputs = 3; Busses = 0; Outputs = 2

This response reiterates the type name specified by the user and, if the compilation was successful, displays the basic circuit statistics. Note that the number of signals reported is 10, not 8 as might be expected. This is because SIMIC always includes the global signals corresponding to logical-1 (ONE) and logical-0 (ZERO). If unsuccessful, SIMIC would have enumerated the error(s) found during the compilation process, and then reported an unsuccessful get.

Having successfully compiled the full-adder with a get, the next command describes the stimuli to test the circuit. This is done with another define command: 

>>: define padd.3=000 001 010 011 100 101 110 111

Stimulus definition will be discussed in detail in Input Stimuli. In this example, "simulate-until-stable" patterns are used—one of three stimulus modes supported by SIMIC. Simply, this means that the circuit must finish responding to the current stimulus before the next stimulus change is applied. This mode of operation, also called "fundamental mode", makes verification of the circuit simpler than for other stimulus modes, where relevant to circuit operation. It also simplifies stimulus specification, since application times are not required. This run command defines a pattern sequence, named padd, that can be applied to 3 primary inputs. The patterns consist of a binary sequence from 0 (000) to 7 (111).

SIMIC supports hierarchical pattern definition as well as pattern definition of subsets of primary signals. Therefore, many different sequences of stimuli may be defined, each distinguished by a unique name (e.g., padd). Which sequence is used for simulation is selected by the following command: 

>>: apply pattern=padd

This command takes the previously defined stimuli, padd, and applies them to the primary input signals in the order of their appearance in the Full-Adder's type statement. Thus, in each individual pattern of padd, the first bit is applied to signal a, the second to b and the third to carry-in. Although not used here, another keyword of the apply command allows specification of the correspondence between primary signals and ordering of values within the selected pattern.

The next run command instructs SIMIC to output specific simulation results at the terminal:

>>: print list=a,b,carry-in**sum,carry-out

The signals to be printed are a, b, carry-in, sum, and carry-out, in that order. The asterisk (*) has special meaning in the print command. It is used to force a blank vertical column in the output. Therefore two blank columns will be placed between the input signals (a, b, and carry-in) and the outputs (sum, carry-out). Because no other options were specified, SIMIC will, by default, output a line every time the circuit enters a stable state (all internal activity has ceased in response to an input change). Simulation output can also be written to a file with the write command, which will be described later in Simulation Output.

The next command initiates simulation:

>>: simulate

SIMIC will not begin true-value simulation if no simulation output has been specified (print, write, etc.; this is not true for fault simulation). This saves the user from the embarrassment of a lengthy simulation without any output to show for it.

As shown in Figure 3, the following terminal output occurs as a result of the above run commands. It consists of (a) an options banner, displaying the currently selected simulation modes as remarks (Remark=), (b) a signal header, displaying the selected signals' names in vertical columns as comments (C=), and (c) the simulation results in a truth table format.

Each line of the tabular simulation output contains:

Once simulation is complete, SIMIC issues another prompt (>>:), requesting further instructions. The quit command instructs SIMIC to exit: 

>>: quit

SIMIC responds with a sign-off banner, and displays statistics for the session. At this point, the SIMIC session is complete, and control returns to the system level.

End of Example

Run Command Syntax

The run command syntax is designed to be flexible, succinct, and easy to use. This section contains a brief overview of run command basics. Specific commands are described in detail throughout this Guide.

Run commands generally contain a command verb (or action) followed by one or more optional keyword-fields. Two commands, simulate and quit, may be issued without keyword options. The general form is: 

<command> <keyword_field> <keyword_field> ...

The command verb and the keyword-fields are separated from each other (delimited) by whitespace, which for SIMIC is one or more tabs and/or spaces.

Run command keyword-fields qualify the action of the command verbs. A run command keyword-field is a SIMIC keyword followed by one or more characters that specify an option or value. The syntax for the keyword values depends upon the command.

Keyword-fields can take two generic forms. The first form is:

<keyword>=<value_list>

where <value_list> is a list of specific values that are associated with the keyword, delimited by whitespace and/or commas. (In some cases, where noted, other delimiting characters have significance.) For example: 

print list=a,b,c

means "print the three signals named a, b, and c"

The second form of keyword-field is:

<keyword>:

When a keyword is followed by a colon, SIMIC will apply a default value for the keyword. In many situations, the colon may mean "all". For example: 

print list:

means "print all signals".

Keyword values are defined by the run command in which they appear. Unless a keyword's value is specifically modified, it will retain its value until the end of a SIMIC session (some return to their defaults after a new circuit description is loaded). To modify a keyword's value that was assigned by a previous run command, the command would simply be reissued with the keyword and its new <value_list>.

An action of a specified keyword may be cancelled by using the no prefix, which has the following form: 

no <command> <keyword_field>

The space between the no and <command> is optional. This will cancel or inhibit the action of the command verb specified by the keyword field. An example is: 

>>: no print list:

This cancels all previous print commands specifying signals to be reported, thereby disabling this terminal output. The no prefix is invalid for some commands, such as quit, that have no options to cancel.

Sticky Parameters

Most SIMIC run command options are "sticky". This means that when a run command is issued, it will remain in effect until it is explicitly removed. As an example, to print the signals a, b, and c, the following command can be issued: 

>>: print list=a,b,c

To cancel printing of these signals, issue the command:

>>: no print list=a,b,c

Otherwise, subsequent print list= commands will still result in print-outs of a, b, c, as well as the subsequently specified signals.

Some simulation options are not sticky. They are specifically indicated as non-sticky within the remaining chapters of this Guide.

Spacing and New Lines

Each command verb must begin a new line, optionally preceded by whitespace only.

The command verb must be separated (delimited) from the first keyword by whitespace. If the command contains more than one keyword field, the keyword fields must also be separated by whitespace. Whitespace can be used freely to improve readability. Values and keywords cannot contain whitespace characters unless enclosed within single or double quotes.

Blank Lines, Line Continuation

With one exception, blank lines may be freely inserted in SNL text to improve readability. Lines may be of any length, but they usually contain 80 characters or less to facilitate printing and editing. In order to enter a SNL statement spanning multiple lines, a dollar sign ($) is placed at the end of the line to be continued. The $ causes the following line to be appended, after removing any leading whitespace. Thus, if delimiting whitespace is required, it must appear before the $ character in the line being continued. If the $ is followed by an =, then the rest of the physical line is treated as a comment, and thus ignored. If any characters follow the $ without an intervening = then an error is reported. For example: 

This is $
a long sen$= This text is a comment
tence$
!

is read by SIMIC as:

This is a long sentence!

The exception noted above is a blank line immediately following a line being continued. Like any other continuation line, the blank line is appended to the continued line, thereby terminating it, since the blank line contains no $ character.

Abbreviations

Abbreviations are common and useful when working with SIMIC. Most command verbs and keywords may be abbreviated to only the first two letters; more can be included. For example, the command verb print is abbreviated pr, but may also be entered as pri or prin.

However, there are exceptions to the "two-letter" rule. Three reserved words may be abbreviated to just one letter. They are: comment (c), zero (z) and x (x). Other words may require up to five letters in the minimum abbreviation to resolve ambiguity.

Throughout this Guide, whenever a new command or keyword is introduced, the minimum abbreviation will be given in parentheses, e.g., print (pr). In addition, the Run Commands Reference contains the abbreviations of all SIMIC command verbs, keywords, and reserved words.

RUN Files

Run commands can be placed in files and SIMIC directed to do (execute) the commands. These files are called run files, and their default extension, if the full name is not specified, is run. For example, the commands for the Full-Adder example could have been placed in a run file called fad. SIMIC can be directed to read these commands by one of two methods:

1. By an interactive run command within SIMIC

Using the execute file (ex fi) command:

>>: execute file=fad

SIMIC will then proceed to do the commands in the run file, fad. Note that the execute command can also be placed into a run file, allowing "nesting" of command files. Very often it is advantageous to place the pattern definitions in a separate run file, as these can be very long. This separation allows faster modification (editing) of the other run files, since they would now be significantly smaller. If an error occurs in a command read from a run file, the error message will contain the file's name and the line number containing the error.

More than one file may be specified in each execute command. In this case each file will be executed in the order specified. Executed run files may themselves contain execute commands, to a nesting depth of 4.

2. As a parameter on the system command line invoking SIMIC

simic fad

This is equivalent to issuing the above execute command as the first interactive command to SIMIC.

As in the execute command, more than one file may be specified in the command line, separated by spaces.

Using SIMIC in Batch (Background) Mode

To use SIMIC in batch mode, create run file(s) that contain all commands necessary for simulation, and then invoke SIMIC in the usual manner for creating background jobs. Remember to redirect console output to a file! For example, under UNIX, the command might be: 

simic fad > fad.log &

and under VMS the equivalent command would be:

spawn/notify/out=fad.log simic fad

or

submit dosimic.com

where dosimic.com is a DCL command file containing the line:

simic fad

Under WINDOWS, the equivalent command would be:

START /B simic fad > fad.log

Under UNIX, and WINDOWS SIMIC can also be made to read a run file by redirecting standard input (e.g., piping, '<'). Make sure this file contains a quit run command; in background mode, end-of-file may not be properly returned by the system, and SIMIC can "hang" waiting for input that will never arrive.