CHAPTER 6 Interfacing DAI Signalscan to Your Verilog Simulator

Overview 6-3

Advantages of the DAI Signalscan SST2 Database 6-3

Producing the SST2 Database from Your Simulator 6-3

Cadence Verilog-XL 6-5

Linking with Cadence Verilog-XL (v2.0 or later) – UNIX 6-5

Dynamically Linking with Cadence Verilog-XL (v2.6 or later) – UNIX 6-5

Link Error When Building the Verilog-XL Simulator on Solaris 6-7

Link Error When Building the Verilog-XL Simulator on SunOS 6-7

Linking with Cadence Verilog-XL (v2.6 or later) – PC 6-9

Cadence NC-Verilog 6-10

Dynamically Linking with Cadence NC-Verilog (v1.22s53 or later) – UNIX 6-10

Synopsys (a.k.a. Chronologic or Viewlogic) VCS 6-12

Linking with Synopsys VCS (v3.0 or later) – UNIX 6-12

Linking with Synopsys VCS (v4.2.1 or later) – PC 6-13

Model Technology ModelSim 6-14

Linking with MTI ModelSim VLOG EE (v5.2 or later) – UNIX 6-14

Linking with MTI ModelSim VLOG (v4.7b or later) – PC 6-15

Fintronic FinSim 6-16

Linking with Fintronic FinSim (v4_4_02 or later) – UNIX 6-16

Quickturn SpeedSim 6-17

Linking with SpeedSim (v5.0 or later) – UNIX 6-17

Linking with SpeedSim (v2.6 or later) – PC 6-17

Avant! Polaris 6-19

Linking with Polaris (v1997_2 or later) – PC 6-19

DAI Signalscan PLI System Task Examples 6-20

Simple Example 6-20

Limiting Depth of Recording Example 6-20

Compressed File Example 6-20

Specific Scopes Example 6-21

Multiple Variables and Scopes Example 6-21

Recording Fan-in Example 6-21

Recording Sequence Information Example 6-22

Recording Statement Trace Example 6-22

Recordon and Recordoff Example 6-23

DAI Signalscan PLI System Tasks 6-24

$recordfile 6-25

$recordsetup 6-27

File Names 6-29

$recordvars 6-30

$recordon and $recordoff 6-33

$recordfilecopy 6-33

$recordfilechange 6-33

$recordclose 6-34

$recordabort 6-34

$signalscan 6-34

$signalscancommand 6-36

$signalscanconnect 6-37

$signalscankill 6-37

$signalscanabort 6-37

Overview

Some Verilog simulators can create a DAI SST2 Database directly. Other simulators can create VCD files, which Signalscan can read. Signalscan can read many file formats; see the DAI web page ( http://www.designacc.com/ ) or contact DAI for more information.

If you are using a Verilog simulator, you can use the Verilog system task $dumpvars , described in your simulator documentation, to create VCD files. Signalscan can convert VCD files to SST2 Database automatically. However, in this mode of operation, you are restricted by the limitations of the VCD file format. See "Advantages of the DAI Signalscan SST2 Database" below.

Advantages of the DAI Signalscan SST2 Database

To answer many of the known limitations of VCD files, DAI created the SST2 (Signalscan Turbo 2) Database. It has numerous advantages over VCD files, including:

• · Compact, binary database; less disk space required
• · Super high performance and capacity; faster recording and analysis
• · Full logic strength information
• · Full hierarchical signal driver information to aid in fan-in debugging
• · Flexible system tasks that allow you to dynamically choose or change what information is recorded in any simulation
• · Sequence Time (see "Viewing Sequence Time and Multivalue Indication")
• · Interactive source code debugging (see "Interactive Debugging")

Producing the SST2 Database from Your Simulator

Verilog simulators have a standard interface, called PLI, for linking external C routines into the simulator. The DAI Signalscan SST2 interface is simply a set of C PLI routines that are linked into your simulator before you simulate. In some cases, you end up with a new simulator, as with Verilog-XL. In other cases, you simply compile the routines on a design-by-design basis, as with Synopsys VCS.

To produce the SST2 Database:

1. 1. Link the DAI Signalscan PLI routines into your simulator.
2. 2. Add the DAI Signalscan $recordvars system task to your design (see "DAI Signalscan PLI System Task Examples" and "$recordvars").

Cadence Verilog-XL

Linking with Cadence Verilog-XL (v2.0 or later) – UNIX

To link DAI Signalscan PLI routines with Cadence Verilog-XL:

1. 1. Run the Verilog-XL simulation build script vconfig . Check with your CAD administrator if you cannot find this script. The vconfig build script is provided by Cadence with Verilog-XL. A new version of Verilog is built when the cr_vlog script generated by vconfig is run. The vconfig script is typically located in cds/tools/verilog/bin . Make sure the script uses a C compiler, not a C++ compiler.
2. 2. When prompted for the path of the veriuser.c file, enter:

1. 3. When asked for the names of other files to be linked in, enter the path of the record-scb.a (or record-xl.a if you are using a version of Verilog-XL less than 2.6.24), daicoverscan.a , and daiMisc.a files. (Versions of Signalscan prior to 5.1 used record-xl.o instead of record-xl.a for the Sparc SunOS platform.) These files are located in the following directory paths:

1. 4. Run the script created by the vconfig program. (If the default name was used, simply type cr_vlog .) If warning messages are displayed, the path names entered in Steps 2 and 3 may be incorrect. Check the paths and edit the cr_vlog file or re-run vconfig . If the script was successful, a new Verilog executable is in the current directory.

Dynamically Linking with Cadence Verilog-XL (v2.6 or later) – UNIX

Build a libpli.so that contains PLI code and point to it, as shown in the following example:

1. 1. Make sure the Cadence environment variable is properly set.

1. 2. Compile the Signalscan veriuser-dai.c file using a C compiler ( not a C++ compiler).

1. 3. Link the object files into a dynamic library.
• · On HP hardware, use the -b option for .sl :

• · On Sun hardware, use the -G option for .so :

1. 4. Build the proper path for the dynamic libraries.
• · On HP hardware, set SHLIB_PATH :

• · On Sun hardware, set LD_LIBRARY_PATH :

1. 5. Set your path to your simulator.

1. 6. Start your simulator.

Link Error When Building the Verilog-XL Simulator on Solaris

When linking a Verilog-XL simulator on a Sun Solaris 2.6 machine, if you receive the error message:

add

after -lX11 .

Link Error When Building the Verilog-XL Simulator on SunOS

Background

When linking a Verilog-XL simulator on a Sun Sparc SunOS 4.x machine, the Verilog-XL object files reference some symbols that are part of libraries included with the Sun acc compiler. The libraries are libm.a and libansi.a . When you link using the Sun acc compiler, these libraries are included automatically. However, if you do not link using the Sun acc compiler, the libraries or object files that contain those symbols must be supplied some other way.

In the Cadence 9604 release, the libraries required by the Cadence object files are included in the release. These libraries are byte-for-byte identical to those included with Sun's acc compiler version 3.0.1. The acc compiler was not used by default for linking. Other compilers, such as gcc , could be used to re-build a simulator by using the libm.a and libansi.a libraries shipped with the Cadence release.

The Cadence 97A release does not include the libraries required by the Cadence object files. The acc compiler is now required to re-build a simulator. Since the required libraries are not included in the Cadence release, other compilers cannot be used to re-build the simulator. If you have installed acc on your computer, you should have no problems. The acc installation includes the proper libraries. If you do not have the Sun acc compiler installed, you cannot complete the link to build a new simulator.

If you do not have the Sun acc compiler and required libraries, you cannot re-build the Verilog-XL simulator. This causes problems for Cadence customers who want to link in PLI code such as that provided by DAI.

If you want to use gcc with Cadence 97A, see below for some suggestions.

Common Problems and Solutions

Below are some common problems and solutions for linking DAI Signalscan PLI routines with Verilog-XL on a Sun Sparc SunOS 4.x machine:

Problem:

Undefined references to X11 functions

Solution:

DAI's PLI requires the X11 library to be linked with the simulator. The -lX11 option must be included in the link command. For Verilog-XL, you should make sure that it is in the cr_vlog script. For Verilog-XL 2.5 (97A) or later, the -lCdsX11 option is probably used instead.

Problem:

Undefined references to Sun C++ library functions

Solution:

Verilog-XL uses its own linker, which automatically loads the Sun C++ library libC.a . If you use a different linker (for example, gcc , cc , or ld ), you need to explicitly link with libC.a .

Problem:

Undefined references to `__huge_val' , `__ansi_fflush' , `strerror' and `raise' on SunOS.

Starting with the Verilog-XL 2.5 (97A) release, Cadence no longer supplies the libraries for acc , the compiler from Sun Microsystems, that they use to compile Verilog-XL on SunOS. Instead, they rely on the acc compiler and its libraries being installed on your system.

As a result, relinking Verilog-XL with a compiler other than acc (such as gcc ) may result in several of the above undefined references in Verilog-XL itself, even if no third-party PLI libraries are used.

Solution A:

Do as Cadence suggests and purchase acc from Sun Microsystems. Linking with the acc compiler automatically pulls in the necessary acc libraries.

Solution B:

Link with the libraries libansi.a and libm.a from an older release of Verilog-XL, such as the 9604 release. The libraries should be added to the cr_vlog script after all object ( .o ) files.

Solution C:

Contact Cadence and ask them to include these libraries with their future Verilog-XL releases and to supply you with these libraries.

Solution D:

Link with the library libcdsaux.a from the DAI Signalscan distribution (in the $DAI_HOME/signalscan- version /sparc-sunos/lib directory). This library contains the symbols missing from the Cadence distribution. The library should be added to the cr_vlog script after all object ( .o ) files.

Problem:

Undefined references to `memmove'

Solution:

Fixed in Signalscan 5.2. Use Signalscan 5.2 or later. This problem only occurred in some 5.1 versions of Signalscan when linking with the 97A release of Cadence Verilog-XL (which does not have the acc libraries).

Problem:

Undefined references to `__floatdidf' , `__cmpdi2' , `__ashldi3' , and `__lshrdi3'

Solution:

Fixed in Signalscan 5.2. Use Signalscan 5.2 or later. This problem only occurred in some 5.1 versions of Signalscan.

Linking with Cadence Verilog-XL (v2.6 or later) – PC

Verilog-XL dynamically loads PLI code from libpli.dll . A pre-built version of this library is provided by DAI in the Signalscan distribution. This DLL must either be in your PATH or in the directory from which Verilog-XL is invoked.

Refer to the Cadence documentation if you want to build your own libpli.dll .

Cadence NC-Verilog

Dynamically Linking with Cadence NC-Verilog (v1.22s53 or later) – UNIX

With some versions of NC-Verilog, you may need to add the line:

to the top of your veriuser.c file if an error message reports that the symbols acc_to_vpi and vpi_to_acc are undefined. A hotfix is available from Cadence to make this unnecessary.

Build a libpli.so that contains PLI code:

1. 1. Make sure the Cadence environment variable is properly set.

1. 2. Compile the Signalscan veriuser-dai.c file using a C compiler ( not a C++ compiler).

1. 3. Link the object files into a dynamic library.
• · On HP hardware, use the -b option for .sl :

• · On Sun hardware, use the -G option for .so :

1. 4. Build the proper path for the dynamic libraries.
• · On HP hardware, set SHLIB_PATH :

• · On Sun hardware, set LD_LIBRARY_PATH :

1. 5. Set your path to your simulator.

1. 6. Start your simulator.

or

If you do not use -access +R , you will get a .dsn file but not a .trn file. Edit the ncelab.args file created by the ncprep routine to add -access +R , or pass it in on the command line as shown above.

You only need -access +W if you are going to use $signalscancommand and write the output to a variable: Signalscan needs to be able to write to that variable (see "$signalscancommand").

According to NC-Verilog documentation, you should not need to use -access +C , but in our testing we have found that you do need to specify it.

Synopsys (a.k.a. Chronologic or Viewlogic) VCS

Linking with Synopsys VCS (v3.0 or later) – UNIX

Create a simulator that contains your design and DAI Signalscan PLI:

where:

The files record.tab and record-lcb.a (or record-lcb.o for Sparc SunOS) are included in the Signalscan distribution. The dai.tab file is a system task "table" file. The files record-lcb.o or record-lcb.a specify system tasks to be linked into the simulator. If another table file is already being used, the dai.tab file may be merged with the existing table file so that only one table file must be specified.

NOTE: Do not link record-xl.o with VCS. It only works with Verilog-XL.

Linking with Synopsys VCS (v4.2.1 or later) – PC

To link Signalscan PLI routines with VCS, perform the following steps at the MSDOS prompt:

1. 1. Locate record-vcs.lib and signalscan.tab in the Signalscan distribution and copy them to your current working directory (assumed here to be C:\work> ).

The record-vcs.lib file specifies system tasks to be linked into the simulator. The signalscan.tab file is a system task "table" file. If another table file is already being used, the signalscan.tab file may be merged with the existing table file so that only one table file must be specified.

1. 2. Run the following command to perform the linking process (it is assumed here that you want to simulate your design called design.v ):

Successful completion of the above steps produces an executable called mydesign.exe in the current working directory. You can now run the following command to simulate your design:

Model Technology ModelSim

Linking with MTI ModelSim VLOG EE (v5.2 or later) – UNIX

Build a veriuser.so that contains Signalscan PLI code.

1. 1. Set your environment variables and paths.

1. 2. Compile the Signalscan veriuser-signalscan.c file using a C compiler ( not a C++ compiler).

1. 3. Link the object files into a dynamic library.
• · On HP hardware, use the -b option.
• · On Sun hardware, use the -G option.

1. 4. Add the newly created DAI Signalscan PLI to the list of Verilog PLI loadable modules.

Change the following line in modelsim.ini :

to

1. 5. Build the proper path or working directory for the dynamic library.

1. 6. Compile your simulator with the DAI Signalscan PLI.

1. 7. Start your simulator.

Linking with MTI ModelSim VLOG (v5.2 or later) – PC

To link Signalscan PLI routines with MTI ModelSim VLOG, perform the following steps at the MSDOS prompt:

1. 1. Locate record-mti.lib and veriuser-signalscan.c in the Signalscan distribution and copy them to your current working directory (assumed here to be C:\work ).
2. 2. Ensure that the environment variable MODELTECH is set to the correct installation directory of the simulator (assumed here to be C:\tools\modelsim ):

1. 3. Locate modelsim.ini in the %MODELTECH% directory and copy it to your working directory.
2. 4. Change the following line in modelsim.ini :

to

1. 5. Execute the following commands to complete the linking process:

Successful completion of the above steps produces a DLL called veriuser-signalscan.dll in the current working directory. You can now run the following command to simulate your design, called design.v in this example:

Fintronic FinSim

Linking with Fintronic FinSim (v4_4_02 or later) – UNIX

To link DAI Signalscan PLI routines with Fintronic FinSim:

1. 1. Locate the files record-lcb.a (or record-lcb.o for Sparc SunOS) and veriuser.c included in the Signalscan distribution.
2. 2. Refer to Section 16.3 and 16.4, "Running FinSim with Signalscan under Unix" and "Running FinSim with Signalscan under Windows 95/Windows NT" respectively, in the FinSim 4.3 Simulation Environment User Guide for further instructions.

Quickturn SpeedSim

Linking with SpeedSim (v5.0 or later) – UNIX

To link DAI Signalscan DX PLI routines with SpeedSim:

1. 1. Locate the files record-lcb.a (or record-lcb.o for Sparc SunOS) and veriuser.c included in the Signalscan distribution.
2. 2. Refer to the section, "Using Signalscan with SpeedSim", in the SpeedSim User Manual for further instructions.

Linking with SpeedSim (v2.6 or later) – PC

To link Signalscan PLI routines with SpeedSim, perform the following steps at the MSDOS prompt:

1. 1. Locate record-speedsim.lib and veriuser.c in the Signalscan distribution and copy them to your current working directory (assumed here to be C:\work ).
2. 2. Set the environment variable SPEEDSIM to the proper SpeedSim installation directory (assumed here to be C:\tools\speedsim-26 ):

1. 3. Execute the following commands to complete the linking process (assumed here you want to simulate your design called design.v ):

Successful completion of the above steps produces an executable called speedsim.exe and design.spd in the current working directory. You can now run the following command to simulate your design:

Avant! Polaris

Linking with Polaris (v1997_2 or later) – PC

To link Signalscan PLI routines with Polaris, perform the following steps at the MSDOS prompt:

1. 1. Locate record-polaris.lib and veriuser.c in the Signalscan distribution and copy them to your current working directory (assumed here to be C:\work ).
2. 2. Ensure that the environment variable POLARIS is set to the correct installation directory of the simulator (assumed here to be C:\tools\polaris-1997_2 ):

1. 3. Execute the following commands to complete the linking process:

Successful completion of the above steps produces an executable called polaris.exe in the current working directory. You can now run the following command to simulate your design (assume here you want to simulate your design called design.v ):

DAI Signalscan PLI System Task Examples

Simple Example

The following shows the most basic recording session. The files created are named verilog.dsn and verilog.trn . All variables are recorded, and no fan-in information is recorded (no primitives or drivers).

Limiting Depth of Recording Example

This is the same as the simple example, but records only the variables three levels deep or less in the hierarchy. The default depth is 0, which means that there is no limit.

Compressed File Example

This is the same as the simple example above, but with a user-specified design name, and the compression recording mode is turned on. The design name is used to generate the file names. The transition data in the file is compressed.

Specific Scopes Example

This is the same as the simple example, but only specific variables and scopes are recorded. In this case, only one specific variable and all variables in the scope module2 are recorded. Note that wildcards (for example, s* ) are not permitted. Variables are nets, registers, integers, time, reals, and named events. Scopes are modules, tasks, functions, and named blocks.

Multiple Variables and Scopes Example

This is a more complex example showing how to apply multiple constraints to multiple variables and scopes. In this example, the first $recordvars records three levels of variables within scope top.mod1 and all variables within top.mod2 . The second $recordvars records driver information for variables in mod1 and no driver information for variables in mod2 . Note that all options apply to all variables specified later in that $recordvars task unless overridden.

Recording Fan-in Example

This is the same as the simple example but with fan-in information recorded to allow backtracing with the Schematic Tracer and the Trace command. Be sure that you do not specify the noports option for data that you want to view in the Schematic Tracer.

Recording Sequence Information Example

Sequence information is the sequence in which events occurred. This information is used to view Sequence Time and to use the Cause Finder feature in Signalscan (see "Viewing Sequence Time and Multivalue Indication" and "Cause Finder"). Depending on your design, sequence information can be large, and sequence information cannot be compressed. You can record sequence information with either the $recordfile task or the $recordsetup task. For example:

Recording Statement Trace Example

Statement trace information is needed to get the best results from the Cause Finder feature (see "Cause Finder"). Statement trace information is not needed to use the trace features of the Schematic Tracer.

Collecting statement trace information consists of collecting sequence information in the transition ( .trn ) file and collecting trace information in the statement trace ( .stc ) file. Use both the sequence option on the $recordsetup PLI system task and the trace option on the $recordvars task as shown in the following example:

Recording statement trace information is independent of what variables you are recording. You must record variables in separate $recordvars task statements. Statement trace information is collected for the entire simulation, even if you have limited variable recording to a particular depth, scope, or variable. See also "Examples".

Collecting of statement trace information is either on or off for the entire simulation. The $recordon and $recordoff statements have no effect on recording statement trace information. Other $recordvars options, such as specifying depth or scopes , have no effect on how much statement trace information is recorded.

Sequence information is needed to correlate statements and transitions. If you collect trace information but do not collect sequence information, you will receive a warning message during your simulation.

Statement trace ( .stc ) files can be large in some cases, and collecting statement trace information can make your simulation run longer. You can delete these .stc files once you are finished using them, even if you still want to view waveforms and other transition information.

Recordon and Recordoff Example

In this example, the $recordoff and $recordon tasks are used to record variables only for a small portion of the total simulation time. The initial state is $recordon .

DAI Signalscan PLI System Tasks

The PLI system tasks that are available are described in this section. These tasks are:

• · $recordfile
• · $recordsetup
• · $recordvars
• · $recordon
• · $recordoff
• · $recordfilecopy
• · $recordfilechange
• · $recordclose
• · $recordabort
• · $signalscan
• · $signalscancommand
• · $signalscanconnect
• · $signalscankill
• · $signalscanabort

In the following definitions apply to all system task descriptions:

options

Each option is a string enclosed in double quotes, or a variable that contains the option string. See the example in "Multiple Variables and Scopes Example".

size

A number followed by B , K , M , or G to specify bytes, kilobytes, megabytes, or gigabytes. If no letter is specified, the default of megabytes is used.

$recordfile

The $recordfile task records basic design information and sets up the recording options for variables recorded with $recordvars . This task is optional, but if used it should be placed before the first $recordvars task.

Syntax

filename

is the name of the SST2 Database. It may be a string enclosed in double quotes, or it may be the name of a variable that contains the file name. Although not required, the extension .trn is recommended to identify the transition database. You can use your old $recordfile setting with an .sst file; the .sst is automatically replaced with .trn . Additionally, a .dsn file is created with the same base name as the .trn file.

Options

Each option is a string, enclosed in double quotes, or a variable that contains the option string.

"wrapsize= size "

The transition data in the SST2 Database wraps when it reaches the specified size : Only size amount of data is kept in the file, where size is defined as shown on "size". This option limits the size of the transition data and does not affect the space used by other information such as scope and variable names. When the transition data begins to occupy more than its allotted maximum, the oldest transitions are overwritten by newer transitions. However, transitions are written to the file in blocks of about 4-5 Mb, when possible, and the maximum size may be increased if it is below this amount. It is recommended that the maximum size be at least 10 Mb, if specified.

"incsize= size "

A new incremental SST2 Database file is started when the current file grows beyond the specified size , where size is defined as shown on "size". See also "$recordfilechange" for more information on incremental files.

"inctime= simtime "

A new incremental SST2 Database file is started when the current file contains the specified amount of simulation time, where simtime is a number followed by a time unit such as ps, or a number in the current time scale.

"inccpu= cputime "

A new incremental SST2 Database file is started when the specified amount of CPU time has been used by the simulator since the current file was opened, where cputime is a number followed by one of the units s (seconds), m (minutes), h (hours), or d (days). If no letter is specified, the default of seconds is used.

"incfiles= count "

A maximum of count complete incremental files are kept. When more than this number of complete incremental files have been written, the oldest files are automatically deleted. The default is " incfiles=0 ". Zero is a special value that means keep all incremental files.

"summary"

A summary file is written with the default name: the name of the design file with a .sum extension instead of a .dsn extension. By default, a summary file is written if the incsize , inctime , or inccpu options are used to write an incremental file.

"summary= summary-filename "

A summary file is written with the name specified.

"nosummary"

Do not write a summary file.

"sequence"

Save sequence information (record the sequence in which events occurred) in the SST2 Database. This information is used to view Sequence Time and to use the Cause Finder feature in Signalscan. For more information, see "Viewing Sequence Time and Multivalue Indication" and "Cause Finder". For examples, see "Recording Sequence Information Example" and "Recording Statement Trace Example".

"nosequence"

Do not save sequence information in the SST2 Database. This is the default.

"compress"

Turns on compression of the transition file when recording. Note that sequence information is not compressed.

"nocompress"

Turns off compression of the transition file when recording. This is the default.

Examples

A design file named adder.dsn is created. A transition file named adder.trn is created. The transition file is compressed. This compressed file requires a special Turbo compression key to view.

A design file named adder.dsn is created. A transition file named adder.trn is created. Sequence Time is recorded in the database.

You can use both the compress and sequence options together, but only transition information is compressed; sequence information is not compressed.

$recordsetup

The $recordsetup task records basic design information and sets up the recording options for variables recorded with $recordvars . This task is optional, but if used it should be placed before the first $recordvars task.

When $recordsetup is called, the scope hierarchy is recorded in the design file immediately. However, primitives and variables are not recorded until $recordvars is called.

Syntax

Options

Each option is a string, enclosed in double quotes, or a variable that contains the option string.

"design= str "

Specifies the design name. If the design name is not specified, the name of the first top scope found is used. See also "File Names".

"version= str "

Specifies the design version name. If the version name is not specified, the next available numeric version name is chosen based on the files in the current or specified directory (see the directory option below). See also "File Names".

"run= str "

Specifies the run name. If the run name is not specified, the next available numeric run name is chosen, based on the files in the current or specified directory (see the directory option below). See also "File Names".

"directory= str "

Specifies the directory where the files will be saved. The default is the current working directory.

"wrapsize= size "

The transition data in the SST2 Database wraps when it reaches the specified size : Only size amount of data is kept in the file, where size is defined as shown on "size". This option limits the size of the transition data and does not affect the space used by other information such as scope and variable names. When the transition data begins to occupy more than its allotted maximum, the oldest transitions are overwritten by newer transitions. However, transitions are written to the file in blocks of about 4-5 Mb, when possible, and the maximum size may be increased if it is below this amount. It is recommended that the maximum size be at least 10 Mb, if specified.

"incsize= size "

A new incremental SST2 file is started when the current file grows beyond the specified size , where size is defined as shown on "size". See also "$recordfilechange" for more information on incremental files.

"inctime= simtime "

A new incremental SST2 file is started when the current file contains the specified amount of simulation time, where simtime is a number followed by a time unit such as ps , or a number in the current time scale.

"inccpu= cputime "

A new incremental SST2 file is started when the specified amount of CPU time has been used by the simulator since the current file was opened, where cputime is a number followed by one of the units s (seconds), m (minutes), h (hours), or d (days). If no letter is specified, the default of seconds is used.

"incfiles= count "

A maximum of count complete incremental files are kept. When more than this number of complete incremental files have been written, the oldest files are automatically deleted. The default is " incfiles=0 ". Zero is a special value that means keep all incremental files.

"summary"

A summary file is written with the default name: the name of the design file with a .sum extension instead of a .dsn extension. By default, a summary file is written if the incsize , inctime , or inccpu options are used to write an incremental file.

"summary= summary-filename "

A summary file is written with the name specified.

"nosummary"

Do not write a summary file.

"sequence"

Save sequence information (record the sequence in which events occurred) in the SST2 Database. This information is used to view Sequence Time and to use the Cause Finder feature in Signalscan For more information, see "Viewing Sequence Time and Multivalue Indication" and "Cause Finder". For examples, see "Recording Sequence Information Example" and "Recording Statement Trace Example".

"nosequence"

Do not save sequence information in the SST2 Database. This is the default.

"compress"

Turns on the compression for the transition file when recording. Note that sequence information is not compressed.

"nocompress"

Turns off the compression for the transition file when recording. This is the default.

File Names

The form of the design file name is:

The form of the transition file name is:

If it is an incremental file, the form of the transition file name is:

Incremental transition files can be concatenated with the UNIX cat command to form a larger transition file.

If both design and version names are specified, the design file is overwritten if it exists.

If the design, version, and run names are specified, the transition file(s) are overwritten if they exist.

Examples

A design file named data/adder-1.dsn is created, if no other files with a name matching adder-*.dsn exist in the data directory. Otherwise the 1 is replaced with the next available number.

If adder-1-1.trn currently exists in the data directory, a transition file named data/adder-1-2.trn is created. Otherwise, a transition file named data/adder-1-1.trn is created.

A design file named data/adder-algo1.dsn is created, or replaced if it exists.

$recordvars

The $recordvars task is used in place of $dumpvars to record variables to the SST2 Database instead of a VCD file. Only one SST2 Database may be written at a time, but additional variables may be recorded to the database at any time by using $recordvars again.

The $recordvars task does not accept wildcards, but you can easily specify a subset of variables to record by using the depth option or specifying particular modules or variables. See "DAI Signalscan PLI System Task Examples" and "Examples".

Syntax

Options

Each option is a string, enclosed in double quotes, or a variable that contains the option string.

NOTE: Options apply to all following variables and scopes in the call, or to the default scopes if none are specified.

"depth= n "

When a scope is specified (see "scopes"), by default all scopes within the specified scope are recursively recorded. This depth option sets a limit, n , to the depth of this recursion. For example, if depth=1 , no child scopes are included. The default is depth=0 . Zero is a special value indicating no recursion limit.

"drivers"

Record drivers. For all variables that are recorded, their drivers are also recorded if they have more than one driver. In this context, a driver is an output terminal of a primitive. Signalscan can use this information to trace back signal states in gate-level designs.

"nodrivers"

Do not record drivers. This is the default.

"primitives"

Record primitives. For all scopes that are recorded, their primitives are recorded in addition to their variables. Signalscan can use this information to trace back signal states in gate-level designs.

"noprimitives"

Do not record primitives. This is the default.

"cells"

Record variables within a cell like any other variables. This is the default. By default, modules defined in a library are cells and other modules are not cells. A non-library module can be defined as a cell using the Verilog `celldefine directive.

"nocells"

Do not record variables within a cell, or within any scopes below the cell.

"ports"

Record a small amount of port connectivity information for each recorded module. This is the default.

"noports"

Do not record port connectivity information. This option is used primarily to work around a simulator defect that affects some designs. If this option is used, Signalscan does not display ports in different colors, the Schematic Tracer does not display port connectivity, and the Add Trace and Add Module Inputs commands do not display ports.

"trace"

Record statement trace information for the simulation. Recording statement trace information enables you to get specific results from using the Cause Finder features (see "Cause Finder"). If you use this trace option, you must also use the sequence option on either the $recordfile task or the $recordsetup task (see "Recording Statement Trace Example" and "Examples" below). Recording statement trace information is independent of what variables you are recording. You must record variables in separate $recordvars task statements in addition to the $recordvars statement where you specify the trace option. Do not specify other options in the same $recordvars statement where you specify the trace option.

variables

Variables listed as arguments are recorded in the SST2 Database. A variable may be a net, register, integer, time, real, or named event. For example: top.control.q0 .

scopes

When a scope argument is listed, all variables within the scope are recorded in the SST2 Database. In addition, variables in all child scopes are included recursively (see the depth option on ""depth=n""). A scope may be a module, task, function, or named block. For example: top.control .

Examples

If no variables or scopes are specified in a $recordvars call, all top level modules are used by default. Thus, all variables are recorded, unless the depth option is used. In many cases, this default is sufficient. An example of this usage is shown below:

In the above example, a separate module is used to invoke the $recordvars task. Alternatively, $recordvars could be placed in an initial block within some other module. A more complex example, which records a number of variables and scopes with various options, is shown below:

In the above example, the first $recordvars records all variables within scope top.mod1 and all of its descendants and three levels of variables within scope top.mod2 . The second $recordvars records driver information for variables in mod1 and driver and primitive information for variables in mod2 . The third $recordvars records explicitly named variables.

NOTE: All options apply to all variables specified later in that $recordvars task unless overridden.

The fourth $recordvars records statement trace information, which is used by the Cause Finder feature (see "Cause Finder"). Recording statement trace information is independent of what variables you are recording. You must record variables in separate $recordvars task statements in addition to the $recordvars statement where you specify the trace option, as shown above. Do not specify other options in the same $recordvars statement where you specify the trace option. See also "Recording Statement Trace Example".

Collecting of statement trace information is either on or off for the entire simulation. The $recordon and $recordoff statements have no effect on recording statement trace information. Other $recordvars options, such as specifying depth or scopes , have no effect on how much statement trace information is recorded.

$recordon and $recordoff

The $recordon and $recordoff tasks are used to turn recording on or off, respectively. These tasks take no parameters. At the beginning of the simulation, recording is on for the first SST2 Database opened. In addition, when an SST2 Database is closed or aborted, recording is reset to on for the next SST2 Database. Recording may be turned off for uninteresting periods of time during a simulation. The recordoff task does not close the database file.

Variable transitions are not recorded during the period where recording is off. This allows these parts of the simulation to be run at maximum speed, and can also save on disk space. All recorded variables are updated to their current values when recording is turned back on. Recording may be turned off and on any number of times during the simulation.

$recordfilecopy

The $recordfilecopy task is used to create a complete static copy of the currently open SST2 transition file in its current state. Because transitions are buffered before being written to the SST2 Database, the data on the disk may not be complete while the simulation is running. However, using this task, you can create a copy of the transition file that contains all of the transition data, and you can open this copy of the transition file before the original file is closed. This task can also be used to create a snapshot of the simulation at the current simulation time. The copy is not updated with new transitions after it is created.

The name of the new file can be specified as an optional argument. The name can be a string enclosed in double quotes, or the name of a variable that contains the file name. The default file name is the name of the original file with a dash and a sequence number appended before the .trn suffix.

$recordfilechange

The $recordfilechange task can be used when the incremental file options of $recordsetup have been used. This task immediately starts a new incremental file. It is useful for making incremental files that start at a particular point in the simulation.

The name of the new incremental file can be specified as an optional argument. If no name is specified, the next name in the file name sequence is used.

$recordclose

The $recordclose task is used to close a currently open SST2 Database. It stops all recording, flushes any buffered information to the database file, and closes the database file. This task takes no parameters. Any open SST2 Database is closed automatically on exit, so this task is necessary only if you are generating multiple SST2 Databases. The $recordclose task can also be used as an alternative to the $recordoff task, to stop recording at some point before the end of the simulation.

$recordabort

The $recordabort task is used to abort recording to an SST2 Database that is no longer wanted. This task takes no parameters. Any buffered information not yet written to the SST2 Database is discarded, and the incomplete file is deleted. Any current interactive connection to Signalscan is also aborted.

$signalscan

The $signalscan task is used to interactively view simulation results in Signalscan while the simulation is running. Although this task can be executed at any time, it is most often placed in an initial block, next to $recordvars , to execute Signalscan at the beginning of the simulation:

When the $signalscan task is called, Signalscan is executed on the system where the simulator is running. If the path option is given, the pathname is taken to be the absolute path to the desired Signalscan executable. Otherwise, the PATH environment variable is used to find the Signalscan executable, which must be named signalscan . The DISPLAY environment variable is used to determine where to display Signalscan windows.

All variables being recorded to the SST2 Database are available for viewing. Conversely, a variable must be recorded in the SST2 Database in order to view it with Signalscan. This means that there must be at least one call to $recordvars in order for $signalscan to be useful.

There may only be one interactive Signalscan connection at a time for each simulation. If you exit Signalscan or the simulator, or use the $signalscankill , $signalscanabort , $recordclose , or $recordabort tasks, the interactive connection is closed. The $signalscan task can then be used again to start a new interactive connection.

Syntax

Options

path= pathname

The path to the Signalscan executable, including the file name component. If this option is not specified, the PATH environment variable is used as before to find the executable, which must be named signalscan .

Argument

Arguments may be passed to the Signalscan program by specifying them as a single parameter to the $signalscan task. The parameter may be a string enclosed in double quotes, or a variable that contains the list of arguments. For example, this can be used to load a Do-File or another SST2 Database to be used with the data from the simulation. See the example below.

Example

$signalscancommand

The $signalscancommand task allows you to send Signalscan commands from Verilog code to Signalscan.

Syntax

Command

Each command is a string, enclosed in double quotes, or a variable containing the command string. See the example below.

See "DAI Signalscan Command Language Reference", for a complete list of Signalscan commands you can use.

Options

Each option is a string, enclosed in double quotes, or a variable containing the option string.

"log"

Write the output of the command, if any, to the Verilog output and log file. This is the default.

"nolog"

Do not write the output of the command to the Verilog log file.

"output= variable "

Write the output of the command into the specified variable.

Description

The task returns when the command completes. The output from the command may be captured and placed into a Verilog variable using the output option described above:

Both the command and output variables, if any, should be declared as vectors in the Verilog code.

If there is no currently active Signalscan connection, the command is discarded with no message. The output variable, if specified, is set to zeros.

$signalscanconnect

You can run Signalscan with connections to as many Verilog simulators as you like. You can either start Signalscan from one of the simulators and have the others connect to the running Signalscan, or you can start Signalscan manually or by some other means, and then have all of the simulators connect to the running Signalscan. In the first case, the simulator that starts Signalscan is the master, and controls like Continue and Pause go to that simulator. In the second case, all simulators are peers. In all situations, Signalscan can only control one simulator. The progress control of the other simulators must be handled by other means (manually or with a simulation backplane, for example).

Use the $signalscan task to start Signalscan from a simulator. You can specify an optional string argument listing options to be passed to Signalscan on start-up. Signalscan starts on the X display indicated by the DISPLAY environment variable. As usual, the $recordvars task should also be used to record some variables to an SST2 file. Each simulator writes to its own SST2 Database.

Use the $signalscanconnect task to connect to a running Signalscan. This task takes no parameters. The DISPLAY environment variable is used to find a running Signalscan and connect to it. If multiple Signalscan sessions are running on the same display, it connects to the first one it finds. If no Signalscan that accepts incoming connections is currently running, the $signalscanconnect task waits until there is one available. This avoids timing problems where Signalscan is started at the same time simulators are trying to connect.

$signalscankill

Use the $signalscankill task to kill Signalscan from the simulator. This task takes no parameters. It can be used only when Signalscan was started using the $signalscan task. After using $signalscankill , $signalscan may be used again to re-execute Signalscan. This is useful if you want to re-execute Signalscan, possibly with different arguments.

$signalscanabort

Use the $signalscanabort task to abort any current interactive connection with Signalscan that was initiated with the $signalscan or $signalscanconnect task. The $signalscanabort task takes no parameters. After using this task, Signalscan is still running, but it cannot retrieve any new simulation data. You can then use the $signalscan task again to re-execute Signalscan. This is useful if you want to re-execute Signalscan, possibly with different arguments.