Application Notes > Verifying Vtran-generated Test Programs

Application Notes:
Verifying Vtran-generated Test Programs

SYNOPSIS
This Application Note focuses on the translation of test program files (from formats such as Teradyne, 93000, Credence SWAV, or Advantest) to a Verilog or VHDL Testbench file using vtran, which can then be compiled and simulated on a Verilog or VHDL simulator. The test program files typically are generated by Vtran. The Testbench includes both input stimulus and processes to check simulation output data against expected data — reporting any errors detected. The purpose of this translation is to verify the correctness of the test program, via re-simulation. This entire translation process is performed under tight user-control.

When converting simulation data to test programs, the user often provides guidance for the translation, particularly when the simulation data is event-based (VCD or EVCD, for example). The type of information provided by the user can include state translation, controls for bidirectional signals, cyclization of event-based data, and test program timing specification. The verification of the test program is intended to detect errors that might have been introduced either in the original translation of simulation data to test program, or in the process of modifying the test program while on the tester.

Vtran's ReadBack Modules support the verification of test program correctness. These modules are the first step in the translation of test program files to a testbench. There is a ReadBack Module for each of the tester formats listed above. ReadBack Modules are only guaranteed to read Vtran-generated test programs. They should not be considered general-purpose test program readers.

OVERVIEW
Vtran contains a number of features that enhance the task of generating Verilog/VHDL testbench files from test program files. First of all, vtran's reader technology enables it to read many test program files. Vtran includes canned readers for many cycle-based file formats, including all of those mentioned above (as well as WGL and STIL). These cycle-based formats typically have state data vectors on a "per-cycle" basis, with timing information in a separate section of the file and possibly scan information and data. Vtran’s canned readers will flatten this cycle data out, incorporating the specified timing, and also flatten any scan data — creating the event-driven data set required by a Verilog/VHDL testbench.

The translation process is divided into three separate tasks or blocks, which correspond to the three blocks in the vtran command file — the OVF_BLOCK, the PROC_BLOCK and the TVF_BLOCK. The commands and parameters in these blocks direct the details of the translation. In general, the OVF_BLOCK contains information necessary for vtran to read the input file or "Original Vector File" (i.e. the test program file). The PROC_BLOC contains commands that tell vtran what data processing functions you want performed on the test program data during translation. This typically would be instructions such as how you would like state characters mapped between the two formats, or perhaps some desired signal masking. For most of these cycle-based formats, there is not very much processing that needs to be done so the OVF_BLOCK and PROC_BLOCK are typically small. Finally, the TVF_BLOCK contains commands that specify the desired output format — in this case it can be Verilog_tb, Verilog_tb_readmem, VHDL_tb, or VHDL_tb_tio. There may also be some final processing to be done or some optional user-supplied parameters that appear in the TVF_BLOCK. Now, let’s take a look at some specifics for these translations.

THE OVF_BLOCK and PROC_BLOCK
When using a vtran ReadBack Module, there is actually very little information (in the way of command instructions) needed by vtran to read the data, do any necessary flattening of scan and timing, and map state characters, in preparation for generating the testbench file. In fact, for some ReadBack Modules, the only command required in the OVF_BLOCK would be a "TABULAR_FORMAT" command, which might look like:

OVF_BLOCK
      BEGIN
      TABULAR_FORMAT swav;
      END

If reading a format other than SWAV, just replace the ‘swav’ with the appropriate format name (J750, HP93000, T6600, etc.). If the name of the cycle-based file is being supplied from the command line, then this is all that is needed in the OVF_BLOCK. Otherwise we might add the ORIG_FILE command to this block:

OVF_BLOCK
      BEGIN
      TABULAR_FORMAT swav;
      ORIG_FILE = "filename";
      END

Some tester formats use one or more separate files in addition to the vector file, typically to define pin and/or timing data. For these formats, the auxiliary file name may be supplied from the command line, following the OVF file name. Otherwise, the AUX_FILE command is used to specify the file name or file name prefix. For example:

OVF_BLOCK
      BEGIN
      TABULAR_FORMAT HP93000;
      ORIG_FILE = "filename";
      AUX_FILE = "filename";
      END

The ReadBack Module automatically will flatten Scan vectors, repeated vectors, and loops in the OVF, when the -CYCLE flag is omitted from the TABULAR_FORMAT command.

The PROC_BLOCK commands required will depend, to a large degree, on what the input file format is. The existing ReadBack Modules do not require a mapping for input state characters, as they use the same 0 and 1 characters as the testbenches. A typical command to map the output state characters is:

PROC_BLOCK
      BEGIN
      STATE_TRANS OUTPUTS ‘L’->’0’, ‘H’->’1’;
      END

THE TVF_BLOCK for Verilog Testbench
There is really only one command required in the TVF_BLOCK of the vtran command file for the generation of a Verilog testbench file. This is the SIMULATOR command, which specifies the target vector file format.

In order to translate an arbitrary test program file into a Verilog testbench file, use the VERILOG_TB, or VERILOG_TB_READMEM option with the SIMULATOR command in the TVF_BLOCK:

SIMULATOR VERILOG_TB ;
or
SIMULATOR VERILOG_TB_READMEM ;

The difference between these two Verilog testbench formats is that in the first form, all of the data for input state assignments and output state checking is contained in a single file and the testbench is implemented as a linear sequence of in-line assignments and checks. In the second (_READMEM) format, separate files hold the state data to be applied and checked, and the actual testbench file itself. Here, the testbench file is constructed as a loop which reads the state data from the external files using the $readmem operation. While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.

Both of the Verilog testbench formats can be specified with a number of optional parameters that can be used to customize the final testbench file. For the VERILOG_TB output format, these optional parameters are:

SIMULATOR verilog_tb,
      -VERBOSE,
      -INHIBIT_CHECKING,
      -VERIFAULT,
      TESTBENCH_MODULE = "Top_of_generic",
      COMPONENT_MODULE = "Component_of_generic",
      INSTANCE_NAME = "Instance_of_generic",
      TIMESCALE = "1ns/100ps",
      OUTPUT_GROUP = "pin3, pin4, .. "
      PSEUDO_SIGNAL = "pinname",
      TERMINATE_RUN = "$finish",
      ;

The INHIBIT_CHECKING flag tells vtran not to include expected output state checking in the Verilog testbench. The VERBOSE flag results in a more detailed error report when expected output data does not match simulation data. The VERIFAULT flag will produce a Verilog testbench file that can be run on Verifault. The PSEUDO_SIGNAL parameter provides for a way to identify signals in the OVF file which are not to be included in the instantiation of the component within the testbench. These signals would only be part of the testbench-level circuit, not the design component. Multiple PSEUDO_SIGNAL parameters can be used.

The default TIMESCALE for time stamps is (1) Nanoseconds, which matches the default for vtran time stamps. If more resolution is desired a combination of the vtran command SCALE and the parameter TIMESCALE should be used. For example, in order to get .1 nanosecond resolution in the VCD file, use:

      SCALE = 10;
      SIMULATOR Verilog_tb, TIMESCALE = "100ps";

If the TIMESCALE parameter is missing, no timescale will be placed in the file. Vtran will place a $stop statement at the end of the testbench by default. This can be changed to $finish (or anything else desired) by using the TERMINATE_RUN parameter.

The TESTBENCH_MODULE, COMPONENT_MODULE and INSTANCE_NAME parameters allow the user to control some of the naming in the testbench. The OUTPUT_GROUP parameter provides a way for the user to control the output pin groups, which in turn affects the size of output data file. The default grouping is determined by the output strobe (sample) times specified in the input cycle-based vector files.
For the second format (VERILOG_TB_READMEM), the optional parameters are:

SIMULATOR verilog_tb_readmem,
      -VERBOSE,
      -INHIBIT_CHECKING,
      TESTBENCH_MODULE = "Top_of_generic",
      COMPONENT_MODULE = "Component_of_generic",
      INSTANCE_NAME = "Instance_of_generic",
      TIMESCALE = "1ns/100ps",
      INPUT_GROUP = "pin1, pin2, .. "
      OUTPUT_GROUP = "pin3, pin4, .. "
      PSEUDO_SIGNAL = "pinname",
      DATAFILES = "datafilename",
      TERMINATE_RUN = "$stop",
      ;

Many of the parameters for this format are the same as for the verilog_tb format, and they perform identical functions. Additional parameters are: the DATAFILE parameter can be used to control the names of the data files that vtran generates. For a DATAFILES name of "datafilename", vtran will create state data files named datafilename0, datafilename1, datafilename2, . . . The ...0 data file contains delta times (times between events) and flags indicating which of the data files to read state data from for each event time. The ...1 file will contain state data for pure input pins, ...2 for bidir input pins and ...3 and up contain output signal expected data, grouped by their specified strobe times or OUTPUT_GROUP definitions. In addition to these groupings, a user can also force specific input signals to be placed in a separate group (and hence separate data file) using the INPUT_GROUP parameter. This may be useful to help reduce overall data file sizes. For example, if the majority of event times in a set of vectors are associated with transitions of just a few clock pins, then defining these as an INPUT_GROUP would greatly reduce the size of the ...1 file (all the other input pins). Multiple INPUT_GROUP parameters can be specified.

See the VTRAN User's Guide and the READMEn.m file for more information on these optional parameters, any new parameters, and their use.

THE TVF_BLOCK for VHDL Testbench
As with the Verilog testbench, there is really only one command required in the TVF_BLOCK of the vtran command file for the generation of a VHDL testbench file. This is the SIMULATOR command, which specifies the target vector file format.

There are two variations of VHDL testbench output formats supported in this release of vtran. Both of these are geared around the IEEE STD_LOGIC_1164 package, although the flexibility is available to use a different non-standard package. The first is a testbench format which employs one or more processes with in-line code for driving input pins with stimulus and invoking checking procedures for verifying output pin states against expected state data. This output interface is invoked as follows:

      SIMULATOR VHDL_TB;

The second testbench format uses the Textio facility of VHDL, creating two files. The first file contains the testbench driver process, along with an instantiation of the design module. The second file contains the actual time and state information and is read in a loop by the driver process. This output format is invoked as follows:

      SIMULATOR VHDL_TB_TIO;

While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.
Both of the VHDL testbench formats can specified with a number of optional parameters that can be used to customize the final testbench file. For the VHDL_TB and VHDL_TB_TIO output formats, these optional parameters are (default values are shown):

SIMULATOR vhdl_tb, {or SIMULATOR vhdl_tb_tio, }
      -INHIBIT_CHECKING.
      -93, {for vhdl_tb_tio only }
      LIBRARY = "NULL",
      USE = "NULL",
      UNITS = "ns",
      CONFIG_FILE = "NULL",
      CONFIG_NAME = "",
      ARCHITECTURE = "testbench",
      INSTANCE_NAME = "U0",
      ENTITY = "_tb",
      COMPONENT = "design",
      COMPONENT_ARCHITECTURE = "STRUCTURAL_VIEW",
      NINE_VALUE = "OFF",
      DONT_CARE = 'X',
      BIT_TYPE = "STD_LOGIC",
      BIT_VECTOR = "STD_LOGIC_VECTOR",
      RESULT_TYPE = "STD_LOGIC",
      RESULT_VECTOR = "STD_LOGIC_VECTOR",
      SEVERITY = "WARNING",
      LIST_ERRORS = "NULL", {vhdl_tb only }
      PSEUDO_SIGNAL = "NULL",
      MAXLINES = "nnnn", {vhdl_tb only }
      INPUT_GROUP = "NULL",
      OUTPUT_GROUP = "NULL",
      BUFFER_PORTS = "NULL",
      LINKAGE_PORTS = "NULL" ;

Multiple LIBRARY and USE parameters can be specified. These should typically specify at least the following:

      LIBRARY = "ieee",
      USE = "ieee.std_logic_1164.all",
      USE = "ieee.std_logic_textio.all", {vhdl_tb_tio only}

In some cases it may be desirable to build a testbench file, without actually doing the checking of expected output states - building only a stimulus file. The INHIBIT_CHECKING parameter, as in the Verilog testbench format, can be used to accomplish this in both VHDL formats. The —93 parameter can be used to force '93 compliant syntax for the declaration and opening of the textio file.

The COMPONENT, INSTANCE_NAME, ENTITY and ARCHITECTURE parameters provide control over names used in the VHDL testbench file. The COMPONENT_ARCHITECTURE parameter is used in the CONFIGURATION block.

The UNITS parameter can be used to change the time units from (the default) ns - be sure to use the SCALE command to modify the time stamps accordingly. The CONFIGURATION declaration is placed in the file specified by CONFIG_FILE. If this parameter is missing, then the declaration is placed at the bottom of the testbench file. The NINE_VALUE parameter tells vtran to check (or not check) that all states are legal IEEE states (after state_trans is applied).

The DONT_CARE parameter defines the logical state on output pins that the
VHDL testbench will treat as a don't care or mask condition. This state can also, and usually should be, declared with the DONT_CARE command in the PROC_BLOCK of the command file so that masking of outputs also uses this state character. After defining this character, any output states which, in addition to this character, are to be treated as a dont_care can be mapped to this character with the STATE_TRANS command. For example, if the DONT_CARE character is defined as 'X' and we want to also ignore outputs when they are in the 'Z' state, then use:

       state_trans outputs 'Z'->'X';

There are four optional parameters related to defining the TYPE of signals, busses and results arrays. The first two (BIT_TYPE and BIT_VECTOR) are used to specify the TYPE of signals and busses in the design. The other two (RESULT_TYPE and RESULT_VECTOR) are used to specify the TYPE of the results arrays used in the testbench.

The parameter SEVERITY can be used to change the behavior of the testbench when it detects a pin whose state does not match the expected state. The testbench uses a VHDL "assertion" statement which reports the mismatch with a SEVERITY dictated by this parameter (default is WARNING). The parameter LIST_ERRORS also affects how pin state errors are handled. Normally, the vector for the entire group (BY_GROUP) is displayed with differences between expected and actual highlighted. Changing this parameter's value to BY_PIN results in the display of only those pins which mismatch, along with their expected and actual states (the LIST_ERRORS parameter is currently available only with the VHDL_TB format).

When using the VHDL_TB output format, large test programs can sometimes result in a very large single process in the testbench file. For some logic simulators, this presents a problem. To get around this, the MAXLINES parameter can be used to break the long single process up into multiple smaller processes. For example:

MAXLINES = "50000",

would limit the size of any given process to approximately 50,000 lines of code.

When using the VHDL_TB_TIO output format option, the main testbench file contains a single read loop for getting input stimulus, as well as expected output data from an external textio file. This testbench file also contains the output state checking and error reporting procedures. All simulation data is contained in the textio file, where it is organized in groups of pins. The primary reason for using pin groups in the textio file is to help minimize file size. By default, all pure input pins comprise a single group, while the input data for bidirectional pins comprise a second group. Output pins are grouped according to what their strobe (compare) timing is. The OUTPUT_GROUP provides an alternate method of grouping output signals - for example it may be desirable to group scan output signals separately. In order to further optimize the file size of the
textio file, the INPUT_GROUP parameter can be used to define additional input pin groups. Usually, this would be done for input pins which have a high degree of activity in the file - such as clock pins. An example might be:

INPUT_GROUP = "clk1, clk2",
INPUT_GROUP = "enb, dir_ctrl",
OUTPUT_GROUP = "scan_out1, scan_out2",

Here we have used two INPUT_GROUP parameters to define two additional groups - the first with just the clk1 and clk2 pins, the second with enb and dir_ctrl pins. All other input pins would remain in their default groups. Likewise we have formed a group of the two output scan pins which will see a lot of activity during scan operations while other outputs are being masked.

The BUFFER_PORTS and LINKAGE_PORTS parameters can be used to define pins as buffer or linkage ports for use in the component or module instantiation. These pins must still be defined as inputs, outputs or bidirects in the OVF.

See the VTRAN User's Guide and the READMEn.m file for more information on these optional parameters, any new parameters, and their use.

SOME EXAMPLES

The AppNote "Cycle-based to Testbench Translations" includes examples for translating from a WGL or STIL file to testbenches.

The following is an example of a vtran command file for translating a Teradyne J750 file into a Verilog testbench:

ovf_block
begin
orig_file = "s0.j750";
aux_file = "s0.teratim";
tabular_format J750;
end;
proc_block
begin
state_trans outputs ‘L’->’0’, ‘H’->’1’;
end;
tvf_block
begin
target_file = tvf0;
simulator verilog_tb, -VERBOSE,
TESTBENCH_MODULE = "CKT_s0",
COMPONENT_MODULE = "s0_rev1",
TIMESCALE = "1ns/100ps";
end;
end;

Here we are using the state_trans commands to map output state characters in the Teradyne file to a 0 for L and a 1 for H.

In the next example, the command file is translating an HP93K file into a Verilog testbench using the $readmem function.

ovf_block
begin
orig_file = "s0.agk";
aux_file = "s0.dvc";
tabular_format HP93000 ;
end;
proc_block
begin
STATE_TRANS OUTPUTS ‘L’->’0’, ‘H’->’1’,
‘M’->’Z’;
end;
tvf_block
begin
target_file = tvf;
simulator verilog_tb_readmem, -VERBOSE,
TESTBENCH_MODULE = "CKT_s0",
COMPONENT_MODULE = "s0_rev1",
TIMESCALE = "1ns/100ps",
INPUT_GROUP = "clk1, clk2, clk3",
OUTPUT_GROUP = "iobus[127:0]",
DATAFILES = "tvf_data";
end;
end

In this example we have defined a separate input pin group that contains 3 clock signals. As a result, the state data for these pins will be in a separate data file. Also, a separate output pin group is specified for the iobus, which will likewise have its state data placed in a separate data file. The reason for doing this is to reduce the total disk file space required to hold all of the state information. In general, we can save file space if input signals that have a lot of activity (like clocks), or conversely very little activity, relative to other input signals are defined in a separate group (and hence file) using the INPUT_GROUP parameter. The same is true of output pins when grouped using the OUTPUT_GROUP parameter. Note that multiple INPUT_GROUP and OUTPUT_GROUP parameters can be specified for full optimization. The names of the data files will be tvf_data0, tvf_data1, tvf_data2, etc.

The next example command file reads an SWAV — formatted vector file and translates it to a VHDL testbench for simulation verification.

ovf_block
begin
orig_file = "s0.swav";
tabular_format SWAV ;
end;
proc_block
begin
STATE_TRANS OUTPUTS ‘L’->’0’, ‘H’->’1’;
end;
tvf_block
SIMULATOR vhdl_tb_tio ,
LIBRARY="IEEE",
USE="IEEE.STD_LOGIC_1164.ALL",
USE="IEEE.STD_LOGIC_TEXTIO.ALL",
LIBRARY="STD",
USE="STD.STANDARD.ALL",
USE="STD.TEXTIO.ALL",
BIT_TYPE="STD_LOGIC",
BIT_VECTOR="STD_LOGIC_VECTOR",
RESULT_TYPE="STD_LOGIC",
INPUT_GROUP = "A_CLK, B_CLK",
INPUT_GROUP = "P_BLOCKA_TDI, P_ATSEL_TDIN", {scan-in}
OUTPUT_GROUP = "P_MUSTANG_TDO, P_ATSEL_2_N", {scan-out}
MAXLINES="10000";
target_file = "s6.vhd";
end;
end;

In this example, we have again defined a separate input group consisting of the 2 clock pins and, in addition an input group consisting of 2 scan-in pins. Likewise, the 2 scan-out pins are specified in a separate output group. This particular design has several hundred input pins and output pins, so creating separate input and output groups for the scan pins will greatly reduce the resulting size of the file.

Return to Application Notes Index