Simulate Translate Test

Translating CYCLE-based vectors to a Verilog or VHDL Testbench

This Application Note focuses on the translation of cycle-based simulation or test program files to VERILOG and VHDL testbenches. The cycle-based vectors may come from many sources, including ATPG tools (such as FastScan, Testcompiler and TetraMAX) and test program formats (such as Teradyne, Verigy 93000, Credence SWAV). See the Application Note "Translating WGL/STIL Vector Files to Tester Formats" for a discussion on the TetraMAX recommended settings.

The generation of test program files from simulation data is a major use of Vtran. During this process, 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 device timing specifications as well as cyclization, state translation, and bidirectional signal control directives. It is possible that errors are introduced. Vtran is able to create a Testbench by directly reading back the test program files.

While an effort has been made to make the Readback Modules cover ATE program syntax as broadly as possible, the Readback Modules used to support this test program validation flow are only guaranteed to read Vtran generated test programs and should NOT be considered general purpose test program readers.

The Testbench file can 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 purpose of this translation is to validate the correctness of the test program via a simulation of the test program. In addition, Vtran provides report statistics on the state and state transitions of signals to determine the extent to which signal activity is being checked. The creation of the testbench is intended to validate test programs before they are loaded onto expensive hardware. It can also, however, be used to validate interactive test program modifications made on the tester.

For more information on other Vtran features, see the Vtran Users' Guide and the Application Note "Print-on-change to Testbench Translations"

Overview

Vtran contains a number of features that enhance the task of generating Verilog/VHDL testbench files from cycle-based data files. 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 Vtran translation process is divided into three separate tasks that 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. The OVF_BLOCK is used to tell Vtran how to read the Original Vector File (OVF). THE PROC_BLOCK contains commands that tell Vtran what data processing functions to perform 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. As with other Vtran translation features, the user ultimately controls the process. Now, let's take a look at some specifics for these translations.

The OVF_BLOCK

The selection of the reader interface is the main function of the OVF_BLOCK. Test program files are almost always cycle-based formats that have state data vectors on a "per-cycle" basis, with separate timing information and possibly scan data. By default, each Vtran Readback Module integrates state and timing data and flattens any scan, repeat, and loop structures to create the event-driven data set required by a VERILOG Testbench. As a result, the TABULAR_FORMAT command with none or few parameters is all that is required. For example, the OVF block associated with a Credence vector source may look like:

        OVF_BLOCK

            BEGIN

            TABULAR_FORMAT swav;  {specifies Credence SWAV Readback}

            ORIG_FILE = "micro_chip.swav";  {specifies vector source file}

            END

Depending on the Readback Modules, multiple source files can be required. For example, the Verigy 93000 Readback Module expects the ORIG_FILE command to specify the name of the vector file and a second file, specified as the AUX_FILE, to contain the timing information. See below.

        OVF_BLOCK

            BEGIN

            TABULAR_FORMAT HP93000;  {specifies Verigy 93000 Readback}

            ORIG_FILE exp2.avc;  {specifies the vector source file name}

            AUX_FILE exp2.dvc;  {specifies the timing source file name}

            END

Multiple vector files can be merged horizontally or vertically using Vtran. The original files may contain all the same signals (in which case the merge is actually a concatenation), all different signals, or there may be an overlap of some signals. See the Application Note titled "Merging Multiple Input Files" (http://www.sourceiii.com/app_notes/merge1.html) for details. On many testers, STIL is used to represent digital test vectors. Here is an example of OVF block using Vtran's STIL reader.

        OVF_BLOCK

            BEGIN

            TABULAR_FORMAT stil;  {specifies the STIL Readback Module }

            MERGE_FILE;

              ORIG_FILE part1.stil;  {specifies first vector source file }

            END_MERGE;

            MERGE_FILE;

              ORIG_FILE part2.stil;  {specifies second vector source file }

            END_MERGE;

            MERGE_FILE;

              ORIG_FILE part3.stil;  {specifies third vector source file }

            END_MERGE;

            END

Another OVF BLOCK command useful in this flow, is "COMMENTS ON". It tells Vtran to look for comments in the Original Vector File and pass them on to the Target Vector File. Some Readback Modules collect comments by default. To prevent these comments from appearing in the target testbench, especially in the case of the verilog_tb_readmem target where comments from the entire vector space appear before the header, use the "COMMENTS OFF" command.

Since most test program files generally contain enough information to allow Vtran to automatically separate I/O data on bidirectional signals, INPUTS, OUTPUTS, and BIDIRECTS commands are generally unnecessary. There are, however, some formats (like FLEX and J750+) where it is advised to use the INPUTS/OUTPUTS/BIDIRECTS statements since the rules used to determine direction from the timing file can be ambiguous. See Appendix E of the Vtran Users Guide for a complete list of Readback Modules, their parameter lists, and helpful comments.

The PROC_BLOCK

The PROC_BLOCK contains commands that tell Vtran what data processing functions you want performed. While there are many processing functions that can be applied to the vector data during translation, using Vtran for the purpose of ATE test program validation most often requires only state mapping considerations using STATE_TRANS. The only other function which maybe generally useful here is INSERT_STATEMENT.

State Mapping

The state characters used in the VERILOG Testbench are 1,0,X, and Z. The state characters returned from the Readback Module to Vtran may not be the same. All state characters in the OVF need to be mapped to 0,1,X,Z. The STATE_TRANS and STATE_TRANS_GROUP commands are used for this purpose. STATE_TRANS commands operate on pintypes (inputs or all_inputs, outputs or all_outputs, pure_inputs, pure_outputs, bidir_outputs, bidir_inputs) while STATE_TRANS_GROUP defines state translations for particular pins or groups of pins.

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.

Here is an example of the STATE_TRANS statements when the OVF has a Teradyne FLEX format:

        PROC_BLOCK

            BEGIN

            STATE_TRANS OUTPUTS 'L'->'0', 'H'->'1', 'M'->'X';

            END

In this example, We are mapping the L,H,M output state characters to 10X. The 0,1,X state characters used on the inputs of the FLEX OVF do not need mapping as the 0,1,X state characters are similarly used in the VERILOG Testbench. In some cases, i.e. when the OVF is a Verigy HP93000 format, the VERILOG Testbench uses the same set of characters as the Original Vector File and no state mapping is needed. See Appendix E of the Vtran's User Guide for information on the state characters returned from each Readback Module.

INSERT_STATEMENT

The INSERT_STATEMENT command allows the user to place arbitrary statements at specific locations in the vector space of the VERILOG_TB target testbench. Statement location may be specified on a CONDITION, TRANSITION, or TIME basis. This feature is used to enhance testbench execution and to insert comments for documentation. When used with the VERILOG Testbench, the general syntax of this command is:

        INSERT_STATEMENT "statement" @ CONDITION [-count n,]

           [-before|after,] compound_logic_expr;

or

        INSERT_STATEMENT "statement" @ TRANSITION [-count n,]

           [-before|after,] signal_name a->b ;

or

        INSERT_STATEMENT "statement" @ TIME [-before|after,] t1;

Use "-before|-after" to indicate whether the statement should appear before or after the time stamp where the CONDITION, TRANSITION, or TIME occurs. Placing the statement "-after" causes the the statement to be inserted within the same event time as the CONDITION, TRANSITION, or TIME. If the TIME control is used and there is no event at the specified time, the statement will be inserted before the event that precedes the specified time or in the first event after the specified time. "-count n" indicates the insertion is to apply to the first n occurrences of the CONDITION or TRANSITION. For example:

        INSERT_STATEMENT "// Begin ALU load" @ TRANSITION -after aenb 0->1;

This command directs Vtran to insert the "Begin ALU load" comment within every event where signal "aenb" transitions from '0' to '1', thus marking the operation.

VERILOG statements can also be inserted into the testbench. For example:

        INSERT_STATEMENT "$write($time, \"Reg = %h\\n\", QREG);" @ CONDITION

           -after -count 1 QREG_Ld = 1 ;

This command directs Vtran to insert the VERILOG write statement the first time QREG_Ld equals '1'.

Important: The CONDITION and TRANSITION controls are evaluated BEFORE any state mapping is applied, so any states referenced in this commands should be states returned from the readback of the Original Vector File.

THE TVF_BLOCK for Verilog Testbench

Simulator

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.

The VERILOG Testbench is created using 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. These optional parameters are:

        -ADD_EXPECT_PINS

        -ADD_MISMATCH_PINS

        -CHECK_FOR_Z

        COMPONENT_MODULE = ""

        -EXTENDED_HEADER

        -FAIL_REPORT

        -INHIBIT_CHECKING

        INSTANCE_NAME = ""

        MAX_MISMATCHES = ""

        MISMATCH_PINS_WIDTH = "nn"

        OUTPUT_GROUP = ""

        PSEUDO_SIGNAL = ""

        TERMINATE_RUN = ""

        TESTBENCH_MODULE = ""

        TIMESCALE = ""

         USER_INFO = ""

        -VECTOR_COUNT

        -VERBOSE

Where:

  • ADD_EXPECT_PINS is a flag to tell Vtran to add a set of wires to the testbench that represent the expect value for each output signal and, in the case of the VERILOG_TB_READMEM, each input signal. These wires are named the same as each output/input signal with a __E and __I suffix respectively. It also causes mismatches to be reported on a per signal basis.
  • ADD_MISMATCH_PINS is a flag to tell Vtran to include VERILOG statements that cause one fail signal to be added to the testbench for every output signal. These fail signals have the same name as their corresponding output signal but with a __f suffix. At any time that an output fails during a check, this fail signal goes to a logic 1 for minimum of 2ns in the verilog_tb target and exactly 2ns in the verilog_tb_readmem target. These fail signals can be dumped and viewed along with the device signals in order to generate a graphical representation of mismatches in the testbench. It also causes mismatches to be reported on a per signal basis.
  • CHECK_FOR_Z is a flag to tell Vtran to include VERILOG statements in the testbench that identify compare Z failures. The default is not to check for Z.
  • COMPONENT_MODULE, INSTANCE_NAME and TESTBENCH_MODULE allow the user to control some of the naming in the testbench.
  • EXTENDED_HEADER is a flag to tell Vtran to include more Vtran translation details in the header comments
  • FAIL_REPORT is a flag to tell Vtran to include VERILOG statements in the testbench that create compare and failure statistics at the end of the testbench simulation.
  • INHIBIT_CHECKING is a flag to tell Vtran not to include expected output state checking in the VERILOG testbench.
  • MAX_MISMATCHES causes Vtran to include in the testbench, verilog code to monitor the number of output state mismatches and terminate program execution if the number reaches this specified maximum.
  • MISMATCH_PINS_WIDTH specifies an alternative to the the 2ns width used to indicate a fail on the __f signals described above.
  • OUTPUT_GROUP provides a way for the user to control the output pin groups. This can affect the size of the testbench file which is optimized when signals with the same strobe time are grouped together. While the user can specify as many OUTPUT_GROUP(s) as needed, a given signal appears in only the last group in which it is listed. The default group contains all outputs and bidirectional signals.
  • PSEUDO_SIGNAL identifies 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.
  • TERMINATE_RUN specifies the ending statement of the testbench. The default is $stop.
  • TIMESCALE causes Vtran to specify a VERILOG timescale statement in the testbench. The format of the timescale value is "nnys/nnys" where nn is 1,10, or 100, and y = f, p, n, u, or m. For example, 100ps, or 10ns. The first value specifies how VERILOG should interpret the timestamps. The second value tells the time precision to be used for simulation. The second time parameter is always the same as or finer resolution as the first time parameter. If the TIMESCALE parameter is missing, no timescale will be placed
  • USER_INFO specifies optional header data for inclusion in the testbench when EXTENDED_HEADER has been enabled
  • VECTOR_COUNT is a flag to tell Vtran to include VERILOG statements that annotate compare failures with vector count, cycle number, active timeset value, and OVF source file in the case of MERGE_FILE usage. By default, only the absolute timestamp value is reported on failures.
  • VERBOSE is a flag to tell Vtran to include VERILOG statements that identify compare failures on a per signal basis. This results in a more detailed error report when expected output data does not match simulation data. n the file.

The following optional parameters are available for use with the VERILOG_TB_READMEM target only. They support the multifile testbench structure.

        SIMULATOR verilog_tb_readmem,

              DATAFILES = ""

              INPUT_GROUP = ""

Where:

  • 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, which are optimized when signals with the same transition times are grouped together. 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). While the user can specify as many INPUT_GROUP(s) as needed, a given signal appears in only the last group in which it is listed. The default grouping causes 2 input groups to be formed, one for pure inputs and one for bidirectional inputs.
  • The DATAFILE parameter can be used to control the names of the data files that Vtran generates. The default base name is DataFile. 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.

See the Vtran User's Guide and the READMEn.m file for more information

Renaming and Restructuring Busses

The VERILOG Testbench requires the sequential ordering of bus indexes. Some vector formats used in the OVF do not have this same requirement. The FORCE_SEQUENTIAL_BUSSES command can be used to ensure the correct preservation of bus structures. For example:

        FORCE_SEQUENTIAL_BUSSES +;

This command forces all busses to be listed from LSB to MSB order. A minus (-) sign forces all buses to be listed from MSB to LSB order. If no +/- is specified, the order is derived by checking to see if the first bit is smaller or larger than the last bit.

Sometimes it is useful to treat all signals like they are scalars, even though they are busses. RENAME_BUS_PINS is used to take bus signal names and convert them to individual scalar names (i.e. bit-blast them), while optionally modifying the form of the name. The name of the bus is referenced by $bus. The index is referenced by $vec. Busses of the form $bus[$vec] in the OVF can be translated as shown:

        RENAME_BUS_PINS ADR = bit$vec_of_$bus;

Here the ADR bus with the elements ADR[0], ADR[1], ... is translated to the set of scalars with names of the form bit0_of_ADR, bit1_of_ADR, ...

ADD_VTB_TEXT

This command is specific to the VERILOG testbench and can be used with both the verilog_tb and verilog_tb_readmem targets. It allows the user to place custom text at specific locations in the core testbench. Statement location may be specified on a before or after basis, relative to the following testbench items: Module, DUTInst, Initial, Terminate, or EndModule. The text is surround by quotes and can be of arbitrary length and include newlines, spaces, and tabs. For example:

ADD_VTB_TEXT "custom user text" before Module;

CREATE_STATISTICS

CREATE_STATISTICS is a Vtran feature than accumulates and reports statistics on the state and state transitions of the signals in the target vector file. It also details changes in direction on bidirectional signals. This information can be extremely useful when evaluating signal activity in a test program. It can be applied to any subset of signals and vectors. Example:

        CREATE_STATISTICS "tb.rpt" inputs, outputs

This causes Vtran to generate a report on all signals over the entire vector space and place it in the file named tb.rpt. For more details on the usage of CREATE_STATISTICS, see the Vtran Users' Guide and the Application Notes titled "Generating Device Test Program Statistics" (http://www.sourceiii.com/app_notes/create_statistics.html).

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, }

              -93, {for vhdl_tb_tio only }

              ARCHITECTURE = "testbench",

              BIT_TYPE = "STD_LOGIC",

              BUFFER_PORTS = "NULL",

              BIT_VECTOR = "STD_LOGIC_VECTOR",

              COMPONENT = "design",

              COMPONENT_ARCHITECTURE = "STRUCTURAL_VIEW",

              CONFIG_FILE = "NULL",

              CONFIG_NAME = "",

              DONT_CARE = 'X',

              ENTITY = "_tb",

              -INHIBIT_CHECKING,

              INPUT_GROUP = "NULL",

              INSTANCE_NAME = "U0",

              LIBRARY = "NULL",

              LINKAGE_PORTS = "NULL",

              LIST_ERRORS = "NULL", {vhdl_tb only }

              MAXLINES = "nnnn", {vhdl_tb only }

              NINE_VALUE = "OFF",

              OUTPUT_GROUP = "NULL",

              PSEUDO_SIGNAL = "NULL",

              RESULT_TYPE = "STD_LOGIC",

              RESULT_VECTOR = "STD_LOGIC_VECTOR",

              SEVERITY = "WARNING",

              UNITS = "ns",

              USE = "NULL",

        ;

Where:

  • The -93 parameter can be used to force '93 compliant syntax for the declaration and opening of the textio file.
  • The ARCHITECTURE, COMPONENT, ENTITY, and INSTANCE_NAME parameters provide control over names used in the VHDL testbench file. The COMPONENT_ARCHITECTURE parameter is used in the CONFIGURATION block.
  • 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 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.
  • 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 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';
  • 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.
  • 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 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.

  • The NINE_VALUE parameter tells Vtran to check (or not check) that all states are legal IEEE states (after state_trans is applied).
  • 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 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.

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}

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

Example 1

The following example shows the minimal Vtran command file required to create a VERILOG Testbench from a Verigy 93000 Test Program. This command file directs Vtran to create a VERILOG Testbench from the "MicroChipA" Verigy HP93000 Test Program. Because the Verigy HP93000 Readback Module returns the same state characters as those used in the Verilog Testbench, i.e. 1,0,X,Z, and no other Vtran processing is desired, the PROC_BLOCK is empty. The testbench created by Vtran is simulator ready. It replicates the stimulus data of the test program and includes VERILOG statements to simulate the tester compares.

        OVF_BLOCK

            BEGIN

            TABULAR_FORMAT hp93000;

            ORIG_FILE = "MicroChipA.agk"

            AUX_FILE = "MicroChipA.dvc";

            END

        PROC_BLOCK

            BEGIN

            END

        TVF_BLOCK

            BEGIN

            SIMULATOR verilog_tb

              TESTBENCH_MODULE = "MicroChipA",

              COMPONENT_MODULE = "Comp_ChipSetA",

              INSTANCE_NAME = "UUU21";

            TARGET_FILE = "exp1.tb";

            END

Example 2

This is an example of the two Vtran command files involved in converting an EVCD into a Validated Test Program.

The first Vtran command file translates a Verilog EVCD file to a Teradyne FLEX+ tester format. The Verilog Reader is selected by the OVF_BLOCK. The cyclization commands in the PROC_BLOCK tell Vtran how to collapse the event driven data from the EVCD print-on-change format to the cycle based format used in the Teradyne device test program. See these described in the Vtran User's guide and the Application Note titled "Print-on-change to Cycle-based Translations" (http://www.sourceiii.com/app_notes/cyclize.html). The STATE_TRANS commands specify the translation between EVCD state characters and FLEX+ state characters. The Teradyne FLEX+ tester format is selected in the TVF_BLOCK. The WR_TIMESET_FILE command specifies the base name of the esets.txt, tsets.txt, and the pinmap.txt files created by Vtran. The TARGET_FILE command specifies the name of the vector file.

The second Vtran command file is used to create the VERILOG Testbench used to validate the Teradyne FLEX+ device test program created by the first Vtran command file. The original test program (OVF) consists of 4 files: exp2.flex, exp2_esets.txt, exp2_tsets.txt, and exp2_pinmap.txt. The Teradyne FLEX Readback Module, requires exp2.flex, exp2_esets.txt, and exp2_tsets.txt. The exp2.flex file is explicitly specified while the timing files are specified by their base name "exp2". Because this is a Teradyne FLEX+ test program format, Vtran needs the information provided by the INPUTS, OUTPUTS, and BIDIRECTS commands in the OVF_BLOCK to determine signal direction. In this example, the Verilog code normally generated by Vtran is enhanced to mark changes in the Data bus enable status, report failures on a per pin basis, support compare Z, provide a fail summary, and an extended header. The CREATE_STATISTICS command causes Vtran to additionally produce its own report describing signal activity. In this case, the report is limited to data collected on signal bidirNrzSig only.

        OVF_BLOCK      { EVCD -> FLEX }

            BEGIN

            SCRIPT_FORMAT Verilog_vcd;

            ORIG_FILE = "exp2.evcd";

            INPUTS pin1, pin2, pin3, pin4, clka, clkb, dbus[31:0];

            OUTPUTS opbus[7:0], ackn, red;

            BIDIRECTS iobus[15:0];

            INPUTS ioctrl;

            END

          PROC_BLOCK

            BEGIN

            CYCLE 1000;

            STATE_TRANS pure_inputs

              'D'->'0', 'U'->'1', 'n'->'X', 'N'->'X', 'd'->'0', 'u'->'1',

              'L'->'0', 'H'->'1', 'l'->'0', 'h'->'1', 'T'->'X', 'x'->'X',

              '?'->'X', 'A'->'0', 'a'->'0', 'B'->'1', 'b'->'1', 'C'->'X',

              'c'->'X', 'f'->'X', 'F'->'X';

            STATE_TRANS pure_outputs

              'L'->'L', 'H'->'H', 'l'->'L', 'h'->'H', 'T'->'M', 'x'->'X',

              'D'->'X', 'U'->'X', 'n'->'X', 'N'->'X', 'd'->'X', 'u'->'X',

              '?'->'X', 'A'->'H', 'a'->'X', 'B'->'L', 'b'->'X', 'C'->'L',

              'c'->'H', 'f'->'M', 'F'->'X';

            STATE_TRANS bidir_inputs

              'D'->'0', 'U'->'1', 'n'->'X', 'N'->'X', 'd'->'0', 'u'->'1',

              '?'->'X', 'A'->'0', 'a'->'0', 'B'->'1', 'b'->'1', 'C'->'X',

              'c'->'X';

            STATE_TRANS bidir_outputs

              'L'->'L', 'H'->'H', 'l'->'L', 'h'->'H', 'T'->'M', 'x'->'X',

              '?'->'X', 'A'->'H', 'a'->'X', 'B'->'L', 'b'->'X', 'C'->'L',

              'c'->'H', 'f'->'M', 'F'->'X';

            PINTYPE nrz pin1, pin2, pin3, pin4, dbus, ioctrl @ 20;

            PINTYPE rz clka, clkb @ 50, 100;

            PINTYPE nrz bidir_inputs @ 40;

            PINTYPE stb all_outputs @ 110;

            AUTO_ALIGN;

            END

        TVF_BLOCK

            BEGIN

            TARGET_FILE = "exp2.flex";

            TESTER_FORMAT teradyne -FLEX+

            WR_TIMESET_FILE="exp2";

            TARGET_FILE="exp2.flex";

            END

      

                  -------------------------------------------------------------

      

        OVF_BLOCK      { FLEX -> Verilog testbench to validate }

            BEGIN

            TABULAR_FORMAT FLEX

            ORIG_FILE = "exp2.flex" ;

            AUX_FILE = "exp2";

            INPUTS pin1, pin2, pin3, pin4, clka, clkb, dbus[31:0];

            OUTPUTS opbus[7:0], ackn, red;

            BIDIRECTS iobus[15:0];

            INPUTS ioctrl;

            END

        PROC_BLOCK

            BEGIN

            BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

            STATE_TRANS outputs 'L'->'0', 'H'->'1', 'M'->'Z';

            INSERT_STATEMENT "$write($time, \"IO BUS Output Enabled\\n\");"

              @ TRANSITION -after ioctrl 0->1;

            INSERT_STATEMENT "$write($time, \"IO BUS Input Enabled\\n\");"

              @ TRANSITION -after ioctrl 1->0;

            END

          TVF_BLOCK

            BEGIN

            SIMULATOR verilog_tb

              USER_INFO = "Testbench to Simulate Teradyne Test Program exp2

              Data Output Enable is marked",

              -EXTENDED_HEADER,

              -CHECK_FOR_Z,

              -FAIL_REPORT,

              TESTBENCH_MODULE = "MicroChipA",

              COMPONENT_MODULE = "Comp_ChipSetA",

              INSTANCE_NAME = "UUU21",

              MAX_MISMATCHES = "15";

            TARGET_FILE = "exp2.tb";

            CREATE_STATISTICS "MicroChipA.rpt" bidirNrzSig;

            END

When the Verilog Testbench generated by the second Vtran command file is re-simulated without error the test program is ready to run on tester hardware. This may require more than one iteration. See the diagram below.

Example 3

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.

Example 4

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.

Product Support

Customer Quotes

  • Intrinsix Uses VTRAN® to Speed Vector Translation Flow "I had one customer who used VHDL for RTL, Verilog for gate level simulation, and sometimes used EPIC tools. Getting vectors into the various formats was a nightmare. VTRAN® made the translation process easy and seamless. Plus, WGL or STIL for the test group. Support from Source III has also been quite impressive. In one case, they wrote a bug fix for me in under a day." John Weiland Intrinsix Consultant  
  • We currently use VTRAN for translating WGL, EVCD and VCD vectors to be used on various Verigy and Teradyne platforms. Their feature set has allowed us to perform vector manipulation instead of writing Perl scripts. Their support has been very responsive and they are open to additional features on future releases.
  • Sanera Utilizes Full Featured VTRAN® to Convert Functional and ATPG Vectors "We chose VTRAN® because it can handle multiple simulation file formats (including VCD and WGL) from a single tool. VTRAN's commands are easy to use. The flexibility in pin mapping, masking outputs, and generating scan-based vectors proves to be tremendously helpful. And most of all, Source III provides excellent, fast response to our support needs. This helps us to get things moving very quickly - making good solid progress." Ken ChenTest Engineering Manager
  • Source III VTRAN® tool has been very efficient to translate VCD, WGL, and STIL vectors to Teradyne UFLEX and Verigy 93000 ATE formats. Their response to add or implement new features as per customer needs is impeccable and steadfast. I would highly recommend using this tool to any test engineer for vector conversion
  • VTRAN® is currently our tool of choice for converting MS digital test patterns between various logic simulation formats and WGL/STIL. Our experience with Source III has been positive and their support is extremely responsive and timely.
  • We use VTRAN® to translate WGL or TDL vectors to Teradyne J750 and Flex format. The produced patterns work fine and adaptation to a new device pinout can be done easy and quickly.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6