Circuit Compilation

How Simic transforms SNL descriptions into a simulation-ready binary representation.

Introduction

Circuit compilation is the process translating a circuit's textual SNL description into a binary representation that SIMIC can use during simulation. In the process, many topological and electrical checks are performed, and a number of circuit modifications and optimizations are made to improve simulation throughput and accuracy:

Optimization and Consolidation

  1. Simple combinational gates and switches that are physically paralleled are merged into a single device, and the electrical characteristics are modified accordingly.
  2. Bidirectional switches are converted to unidirectional switches, where appropriate. This can dramatically improve the performance of switch level networks.
  3. Only the TYPEs that are actually used in the design are compiled. Besides improving compilation performance, this has the added benefit of reducing the amount of memory required for the final simulation structures.

Delay Computation

Delays are computed from delay curves and loading factors. Auxiliary procedures and/or programs are not required to produce accurate delays.

Physical Size Metrics

Physical size metrics (number of transistors, total width of cells, and number of bond pads) are computed and reported. This information can be useful for size estimates by designers and/or place and route programs.

Topological Checks

Many topological checks are performed, including:

  1. Incorrect number of input, output or bus connections.
  2. Switch connection between power rails.
  3. Both ports of switches connected to same node.
  4. Switch permanently turned off (disabled by control value).
  5. Nodes that don't have a driving element attached.
  6. Nodes that don't have any elements attached.
  7. Nodes with only driving elements attached.
  8. Wire-tied nodes with non-tristating driving element attached.

Some situations, such as incorrect number of pin connections, are fatal, and prevent the completion of circuit compilation. Others, such as wire-tied non-tristating drivers, cause SIMIC to generate warning messages that may indicate potential problems with the description. These messages are also helpful for debugging errors in a new cell library.

If any description errors are found during compilation, error messages are issued that specify the location (line number) and nature of each error. The compiler aborts when the number of fatal description errors reaches a user-specifiable limit. This prevents voluminous output in the event of a repeating problem (such as an incorrect !FORMAT statement).

The result of a successful circuit compilation is that a binary representation is loaded into memory, ready for simulation. This representation can also be saved and later retrieved to avoid the need to recompile the same circuit description in future SIMIC sessions.

Many of the SIMIC commands require that the binary circuit representation be loaded when they are issued.

The GET run command is used to initiate circuit compilation and/or retrieve a previously-compiled description.

Circuit Compilation

Initiating Circuit Compilation

The TYPE keyword initiates compilation.

Therefore, the compilation options described below should either precede, or be placed in, the GET command containing the TYPE keyword.

Compilation is invoked with the TYPE (TY) keyword option of the GET (GE) run command. If the entire circuit is contained in a single file, and if the file's name is the default name (as specified in the DEFINE FILE run command) and its extension is net, then the basic command:

GET TYPE=<main type name>

is sufficient, where <main type name> is the name of the TYPE to be compiled. This TYPE is called the main type throughout this Guide.

If, however, the name of the file does not match the default name, or if the description is contained in more than one file, the FILE (FI) keyword must be used to direct SIMIC to the correct file(s):

GET TYPE=<main type name> FILE=<list of files>

where <list of files> is a list of all the files that contain the complete description. For example, if the description of the main type, FULL_ADDER, is distributed in the files FAD and CMOSLIB, (with default extension NET) the command:

GET TYPE=full_adder FILE=fad,cmoslib

would be used to compile the circuit description. With one exception, the order in which the files are listed is not important; what matters is that the list is complete.

The !INCLUDE directive within a network description file directs SIMIC to other files required to complete the network description.

An alternative method of directing the SIMIC compiler to both files, in the above example, is to issue the command:

GET TYPE=full_adder FILE=fad

and have the following !INCLUDE statement in file FAD:

!INCLUDE cmoslib

SIMIC supports the ability to simulate multiple circuits within the same session. All that is necessary is to issue a GET command when ready to simulate the next circuit. Since all previously issued commands were associated with the previous circuit, and have no relevance for the next one, SIMIC discards prior simulation options, and restores its initial defaults, whenever the GET TYPE command is issued.

If case-sensitivity is required, start the SIMIC session with the "s" switch before compilation:

simic -s

Specifying The Compiler's Abort Limit

Since they do not conflict, compilation options may be freely mixed within the same GET command.

As previously mentioned, the SIMIC circuit compiler will abort the compilation process if the number of fatal errors reaches a predefined limit. This limit is defaulted to 20, but can be set to any level, or removed entirely. To set the limit to a new value, use the STOP keyword option:

GET STOP=<n>

where <n> is an integer specifying the new limit. The NO prefix is used to remove the limit entirely:

NO GET STOP:

Since use of the TYPE keyword initiates compilation, the STOP limit should be specified either in a separate GET statement prior to the GET command containing the TYPE, or in the same command:

GET STOP=15
GET TYPE=full-adder

or

GET TYPE=full-adder STOP=15

The NO form of the command must be issued prior to the GET TYPE command.

Saving The Compiled Description In A File

After compilation, an image of the simulation structures can be saved into a file for quick retrieval in future simulations. This is beneficial for two reasons:

  1. The compiler uses and then frees memory during the compilation process. This causes memory fragmentation to occur. If you have limited real memory for simulation, then avoiding the compilation process will cause more efficient utilization of memory during simulation.
  2. Circuit restoration is significantly faster than circuit compilation.

By default, the compiled circuit description is not saved. The SFILE (SF) keyword may be used to override this default. The form:

GET SFILE:

implicitly instructs SIMIC to save the description in a file whose name is the default file name and whose extension is rnt, the default extension for compiled network descriptions.

In the second form:

GET SFILE=<file name>

SIMIC is directed to save the compiler output into the file named <file name>.

The NO prefix can be used to cancel a previous request to save the compiled description:

NO GET SFILE:

Since use of the TYPE keyword initiates compilation, SFILE should be specified either in a separate GET statement prior to the GET command containing the TYPE, or in the same command:

GET SFILE:
GET TYPE=full-adder

or

GET TYPE=full-adder SFILE:

The NO form of the command must be issued prior to the GET TYPE command.

Obtaining A Readable Description Of The Flattened Circuit

During the compilation process, the circuit description is flattened, that is, expanded to an interconnection of built-in and user-defined primitives. An output file, called the listing file, can be optionally generated that contains a textual representation of the flattened circuit. If not explicitly requested, this file is not generated.

The REPORT (REP) keyword option specifies the amount of detail to be written to the listing file. Valid values for this option are SYMBOLS (S), and ALL (A). The SYMBOLS value specifies that only the names of the signals and parts are to be listed, and ALL specifies that in addition to these names, the topology and electrical attributes are to be listed as well. After a successful GET, the requested information is placed into the listing file specified by the LFILE (LF) keyword. If this keyword is omitted, or is specified as LFILE:, the listing file's default name is defined by the DEFINE FILE run command, and its default extension is lst. To override the default, the LFILE keyword should explicitly specify the file's name. For example:

DEFINE FILE=fad
GET REPORT=all

request that the listing file, fad.lst, contain signal name, part name, topology and electrical attributes, whereas:

DEFINE FILE=fad
GET REPORT=symbols LFILE=fad1.out

requests that the listing file, fad1.out, contains only signal and part name information. If the listing file is not desired, after issuing the above commands, the previous requests can be cancelled by either of the following commands:

NO GET REPORT:
NO GET LFILE:

Since use of the TYPE keyword initiates compilation, the listing file options should be specified either in a separate GET statement prior to the GET command containing the TYPE, or in the same command:

GET REPORT=all LFILE:
GET TYPE=full-adder

or

GET TYPE=full-adder REPORT=all LFILE:

The NO form of the command must be issued prior to the GET TYPE command.

Retrieving A Previously-Compiled Description

If a circuit description has been previously compiled, and the binary description was saved using the SFILE option with the GET TYPE command, then this description can be retrieved with the RFILE (RF) keyword option:

GET RFILE:

if the description was saved in a file having the default name and default file extension rnt, or

GET RFILE=<file name>

if the file's name need be explicitly specified.

The TYPE and RFILE keyword options are mutually exclusive and must not be entered as options in a single GET command. If both options are specified simultaneously, they are ignored and a warning message is issued.

As with the GET TYPE command, SIMIC discards prior simulation options, and restores its initial defaults, whenever the GET RFILE command is issued.

Selecting A Timing Table

Either of three tables (delay sets), corresponding to TYPICAL, MINIMUM, and MAXIMUM timing values may be specified for delay, loading and timing-check information. By default, the TYPICAL table is selected for simulation. To specify a table, use the TIMING (TI) keyword option:

GET TIMING=<table>

where <table> is either TYPICAL, MINIMUM, or MAXIMUM.

The TIMING option may be used in conjunction with the GET TYPE or GET RFILE commands or as an independent command.

All timing specified in the network description is saved during circuit compilation, and thus can be selected at any time during a SIMIC session.

Backannotation

In addition to using the backannotation elements (LOAD and DELAY) in the network description, a separate file containing LOAD elements can be used to backannotate the circuit with loading. The loading specified by these elements is added to the loading already present at the specified nodes. The backannotation file is read with the AFILE (AF) keyword option:

GET AFILE:

or

GET AFILE=<file list>

The AFILE option can be used in conjunction with the GET TYPE or GET RFILE commands, or issued independently. Subsequent GET AFILE commands will restore the loading specified in the network description before adding the new loading.

The backannotation file has the default extension ann, and consists of (optional) SNL !FORMAT directives, comments, remarks, and part statements instantiating SIMIC LOAD elements whose OUTPUT-LOADS (OLOD) keyword-fields specify the incremental net loading. For example, the following file assigns a load of 10 units to node a and 17 units to node main.q:

Remark= This adds loading to the signals
Remark= named 'a' and 'main.q'
!format p= t= olod=
A        load    10
main.q   load    17