Simulate Translate Test

Using Readback Modules to Validate VTRAN-generated Test Programs

This Application Note relates to VTRAN's ability to translate test program files (from formats such as Teradyne, Verigy 93000, Credence SWAV) to a VERILOG Testbench in order to validate the correctness of an ATE test program. 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. The Testbench contains both input stimulus and processes that compare simulation output data against expected data. 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.

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.

This application note focuses on the generation of the VERILOG Testbench and the VTRAN® features specific to test program verification. For a discussion on the generation of a VHDL Testbench and other VTRAN® features , see the VTRAN® Users' Guide and the Application Notes titled "Cycle-based to Testbench Translations" and "Print-on-change to Testbench Translations".

Overview

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 OVF_BLOCK is used to tell VTRAN® how to read the Original Vector File (OVF). In this case, the OVF is a test program file. In addition to standard readers for WGL and STIL, VTRAN® provides Readback Modules for most of the ATE writers in its Test Library, including Teradyne, Verigy, Credence, IMS and others. THE PROC_BLOCK contains commands that tell VTRAN® what data processing functions to perform during translation. For the Readback Modules, these are usually just state translations. Finally, the TVF_BLOCK contains commands that specify the desired output format, a VERILOG testbench in this case, and optional reporting parameters. As with other VTRAN® translation features, the user ultimately controls the process.

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. 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

There is really only one command required in the TVF_BLOCK of the VTRAN® command file for the generation of a VERILOG Testbench. This is the SIMULATOR command. It specifies the target vector file format. Other useful commands applicable to this process include RENAME_BUS_PINS, ADD_VTB_TEXT, FORCE_SEQUENTIAL_BUSSES, and CREATE_STATISTICS.

SIMULATOR

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 ;

These two VERILOG testbench formats produce identical logical results. In each case, VTRAN® generates a testbench with stimulus waveforms that exactly match those of the test program in the OVF and testbench code to validate the test program expect values. Depending on the parameter selection, the VTRAN® testbench reports miscompares between test program expect data and simulation results data on a per pin or per group basis along with the expected results, the actual results, absolute timestamp, vector count, cycle number, test program timeset, and in the case of MERGE_FILE usage in the OVF block, the original OVF file name.

The main difference between the two TVF targets, is that in the VERILOG_TB 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 VERILOG_TB_READMEM format, separate files hold the input and expect state data. Here, the testbench file is constructed as a loop which reads the state data from the external files using the $readmem operation. 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. Other differences are mostly minor and are described in the context of the affected feature.

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:

      -INHIBIT_CHECKING

      -FAIL_REPORT

      -CHECK_FOR_Z

      -VERBOSE

      -VECTOR_COUNT

      -EXTENDED_HEADER

       USER_INFO = ""

      -ADD_EXPECT_PINS

      -ADD_MISMATCH_PINS

      MISMATCH_PINS_WIDTH = "nn"

      TESTBENCH_MODULE = ""

      COMPONENT_MODULE = ""

      INSTANCE_NAME = ""

      PSEUDO_SIGNAL = ""

      OUTPUT_GROUP = ""

      MAX_MISMATCHES = ""

      TIMESCALE = ""

      TERMINATE_RUN = ""

Where:

  • INHIBIT_CHECKING is a flag to tell VTRAN® not to include expected output state checking in the VERILOG testbench.
  • 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.
  • 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.
  • VERBOSE is a flag to tell VTRAN® to include VERILOG statements that identify compare failures on a per signal basis.
  • 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.
  • EXTENDED_HEADER is a flag to tell VTRAN® to include more VTRAN® translation details in the header comments
  • USER_INFO specifies optional header data for inclusion in the testbench when EXTENDED_HEADER has been enabled
  • 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.
  • MISMATCH_PINS_WIDTH specifies an alternative to the the 2ns width used to indicate a fail on the __f signals described above.
  • TESTBENCH_MODULE, COMPONENT_MODULE and INSTANCE_NAME identify named elements in the testbench.
  • 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.
  • 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.
  • 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.
  • 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.
  • TERMINATE_RUN specifies the ending statement of the testbench. The default is $stop.

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

      INPUT_GROUP = ""

      DATAFILES = ""

Where:

  • INPUT_GROUP provides a way for the user to control the input pin groups. This can affect the size of testbench datafiles which are optimized when signals with the same transition times are grouped together. 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.
  • DATAFILES specifies the base name of the state data files. By default datafiles are named DataFile0, DataFile1, DataFile2, DataFile3. DataFile0 contains time values between events and other flags. DataFile1, DataFile2, DataFile3 contain the state data for pure input signals, bidirectional input signals, and output signals. Additional DataFile 's are added as needed to support user groups specified in the INPUT_GROUP and OUTPUT_GROUP statements.

The SIMULATOR command in the following TVF_BLOCK, results in a single VERILOG Testbench file with fail signals added for each output and with the ending statement "$finish". The names used to specify the testbench module, component module, and instance name reflect those in the command statement.

  TVF_BLOCK

      BEGIN

      SIMULATOR verilog_tb

        -ADD_MISMATCH_PINS,

        TESTBENCH_MODULE = "Top_Gun",

        COMPONENT_MODULE = "Comp_of_Gun",

        INSTANCE_NAME = "UUU21",

        TERMINATE_RUN = "$finish";

      TARGET_FILE = "Top_Gun.tb";

      END

A second example of the SIMULATOR command, this time with the "verilog_tb_readmem" target, is shown below. It results in a testbench with the same logical behavior as the example above. In this testbench, however, a series of VERILOG Testbench files with names of the form "TB_Data" are created in addition to the core testbench. VTRAN® creates the four default data files along with 5 additional data files to store state data for each of the INPUT_GROUP and OUTPUT_GROUPs listed. The core testbench loops through the vectors using VERILOG $readmem statements to read data from the data files. In this example, the signals have been strategically grouped by activity. The states for the CLOCK signal that has activity on almost every vector is stored separately. Note that if all the signals appear in the user defined groups, default state data files are not created.

  TVF_BLOCK

      BEGIN

      SIMULATOR verilog_tb_readmem

        -ADD_MISMATCH_PINS,

        INPUT_GROUP = "nrzSig1, nrzSig2, nrzSig3, nrzSig4",

        INPUT_GROUP = "OE",

        INPUT_GROUP = "CLOCK",

        OUTPUT_GROUP = "outSig1, outSig2, outSig3, outSig4",

        OUTPUT_GROUP = "bidirNrzSig,bidirRzSig, bidirRoSig",

        DATAFILES = "TB_Data",

        TESTBENCH_MODULE = "Top_Gun",

        COMPONENT_MODULE = "Comp_of_Gun",

        INSTANCE_NAME = "UUU21",

        TERMINATE_RUN = "$finish";

      TARGET_FILE = "Top_Gun.tb_readmem";

      END

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".

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". 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.

Product Support

Customer Quotes

  • 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.
  • 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.
  • 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  
  • 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
  • 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.
  • 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
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6