Application Notes:
Translating CYCLE-based vectors to a Verilog or VHDL Testbench
SYNOPSIS
This Application Note focuses on the translation of Cycle-based
vectors (from formats such as WGL, STIL, TSTL2 or TDL_91) to a Verilog
or VHDL Testbench file using vtran, which can then be compiled and
simulated on a Verilog or VHDL simulator. The Testbench includes
both input stimulus and processes to check simulation output data
against expected data — reporting any errors detected. This
entire translation process is performed under tight user-control.
The Cycle-based vectors may come from many sources including ATPG
tools such as FastScan, Testcompiler and TetraMAX. See the Application
Note "Translating WGL/STIL Vector Files to Tester Formats"
for a discussion on the TetraMAX recommended settings.
OVERVIEW
Vtran contains a number of features that enhance the task of generating
Verilog/VHDL testbench files from other simulation data files. First
of all, vtran's reader technology enables it to read almost any
simulation data file. Vtran includes canned readers for many cycle-based
file formats, including all of those mentioned above. 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 WGL, STIL, … file). The PROC_BLOC contains commands that tell vtran what data processing functions you want performed on the simulation 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 canned reader, 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, the only command required in the OVF_BLOCK would
be a "TABULAR_FORMAT" command, which might look like:
OVF_BLOCK
BEGIN
TABULAR_FORMAT wgl;
END
If reading a format other than WGL, just replace the ‘wgl’ with the appropriate format name (STIL, TSTL2, TDL_91, 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 wgl;
ORIG_FILE = "filename";
END
The PROC_BLOCK commands required will depend, to a large degree, on what the input file format is. If we are mapping WGL state characters to those needed in a Verilog or VHDL testbench, then the only mapping required would be:
PROC_BLOCK
BEGIN
STATE_TRANS ‘-‘->’X’;
END
This maps the ‘-‘ (dash) characters in the WGL file to an ‘X’ state character in the testbench. On the other hand, mappng the state characters from a STIL file takes a bit more work:
STATE_TRANS INPUTS ‘U’->’1’,
‘D’->’0’, ‘?’->’X’;
STATE_TRANS OUTPUTS ‘T’->’X’, ‘x’->’X’,
‘L’->’0’, ‘H’->’1’,
‘l’->’0’,
‘h’->’1’, ‘t’->’X’,
‘R’->’0’, ‘G’->’1’,
‘Q’->’X’,
‘?’->’X’;
Here we are very careful about how we map the numerous state characters in a STIL file to those used by Verilog and VHDL.
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 simulation data 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 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 simulation data sets 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 following is an example of a vtran command file for translating a WGL file into a Verilog testbench:
ovf_block
begin
orig_file = "s0.wgl";
tabular_format wgl;
end;
proc_block
begin
state_trans inputs '-'->'Z';
state_trans outputs ‘—‘->’X’;
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 any ‘-‘ state characters in the WGL file (this is a placeholder character) to a Z for inputs and an X for outputs. In the next example, the command file is translating a STIL file into a Verilog testbench using the $readmem function.
ovf_block
begin
orig_file = "s0.stil";
tabular_format STIL ;
end;
proc_block
begin
STATE_TRANS INPUTS ‘U’->’1’, ‘D’->’0’,
‘?’->’X’;
STATE_TRANS OUTPUTS ‘T’->’X’, ‘x’->’X’,
‘L’->’0’,
‘H’->’1’,‘l’->’0’,
‘h’->’1’, ‘t’->’X’,
‘R’->’0’,
‘G’->’1’,‘Q’->’X’,
‘?’->’X’;
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 a STIL — formatted vector file and translates it to a VHDL testbench for simulation verification.
ovf_block
begin
orig_file = "s0.stil";
tabular_format STIL ;
end;
proc_block
begin
STATE_TRANS INPUTS ‘U’->’1’, ‘D’->’0’,
‘?’->’X’;
STATE_TRANS OUTPUTS ‘T’->’X’, ‘x’->’X’,
‘L’->’0’,
‘H’->’1’,‘l’->’0’,
‘h’->’1’, ‘t’->’X’,
‘R’->’0’,
‘G’->’1’,‘Q’->’X’,
‘?’->’X’;
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
