Simulate Translate Test

VTRAN® Guide to VCD/EVCD-to-ATE Translations

The task of translating event-based simulation data to cyclized ATE device test program files can be very complex. Often, errors are introduced resulting in test programs that do not work or test programs that do not properly test the device. This can be very costly in terms of time and money. Fortunately, the VTRAN® User Interface (VUI®) Utility provides an effective approach to this problem by integrating the power of VTRAN®, VCAP®, and DFTView®. The purpose of this document is to provide a guide to to this process.


The generation of quality device test programs happens in two stages. The first stage is the actual conversion of VCD/EVCD files with print on change formats (POC) files to ATE test programs files. This is done by VTRAN®. VTRAN® gathers state data from the Original Vector File, cyclizes it, applies user-specified processing, maps state characters between the two formats, applies target timing, and generates a Target Vector File. It is driven by a command file generated by the user with the optional support of the timing analysis features of VCAP®.

The second stage is verification of the test program. Does the test program preserve the waveforms presented in the original file? Does it work with the device? DFTView® is used after the translation to view and compare the ATE program with the original VCD/EVCD file. The test program functionality is verified through the creation of a testbench file that can be compiled and simulated on a Verilog or VHDL simulator.

VUI® is the graphical user interface tool that ties everything together. It is designed to guide the user through the process of generating a VTRAN® command file with the required parameters and statements. When the VTRAN® flow has been specified, a command file is created, VTRAN® is executed, and the results are presented. The original and target waveforms can be individually displayed or graphically compared using DFTView®.

Translating VCD/EVCD Simulation Files to ATE Test Program Files

 Invoke the VUI®

The VTRAN® User Interface Utility (VUI®) is a graphical user interface developed specifically for generating VTRAN® command files by presenting a series of "forms" which are used to set up the translation parameters. VUI® provides context-sensitive help for all form fields, interactive syntax checking, parameter compatibility analysis, and a seamless integration of the VCAP® Timing Analysis Tools. The VTRAN® translation process may be launched from within the VUI® and the original and target waveforms can also be displayed using DFTView® via the VUI®. The following diagram illustrates how the VUI® is organized.

The VTRAN® User Interface is typically launched without any command line arguments.


Note: VUI® presents all of the many parameters and processing options available with VTRAN®, but this Guide will focus mainly on those items essential to the generation of an ATE Test Program from simulator VCD/EVCD print-on-change files. Use the Context-Sensitive Help or The VTRAN® User's Guide ( to explore and find details on any VTRAN® option. Also, for more detailed information on using the VUI® tool itself, see the VUI® User's Guide (

Initial Setup Form

The main purpose of Initial Setup form is to select the input and output formats and file names. The choices selected on this page will then automatically customize each of the following form pages to only prompt for inputs related to the formats chosen. VTRAN® provides interfaces for almost any print-on-change and cycle-based format. VUI® currently supports only a subset of these interfaces and formats. If you don't see your interface or format listed, let us know.

See the Initial Setup for an EVCD to 93K Translation below.

Press "Continue" to move to the next form.

OVF_Block Form

The OVF Block form contains all statements applicable to the task of reading the Original Vector File. The fields that are presented are based on the declared input format.

Default values are provided and for many translations this is all that is needed.

Signal List

Flows with an Original Vector File (OVF) format that does not allow VTRAN® to automatically and unambiguously determine signal direction (as is the case with Verilog VCD/EVCD) require an INPUTS/OUTPUTS/BIDIRECTS field. This Signal List is created using the VUI® Signal Editor (see the "Launch Signal Editor" button) a utility that automatically reads all available signals from the OVF file. Here the user makes signal selections and assigns signal direction. Pressing the "Generate INPUTS/OUTPUTS/BIDIRECTS" button causes the VTRAN® statement to be populated.

The order of declarations also determines the order of the signals in the output vector file unless overridden in the TVF_Block. Another option for specifying the INPUTS/OUTPUTS/BIDIRECTS field is to use the green Edit arrow to bring up an edit window and then either cut-and-paste or directly type the signal names and directions into the file with the help of the "Show Input File Pins" tool.

Press "Continue" to move to the next form.


The PROC_BLOCK commands specify the details of the translation. In the case of print-on-change to cycle-based translations, this generally includes bidirectional control, state translation , and cyclization commands. The VCAP® Analysis Tool can be launched from the PROC_Block form for optional support of the cyclization command parameters.

Bidirectional Data Control

VTRAN® logically splits each bi-directional signal into two data streams, one for input and one for output. The input uses the defined name and is used to store the input data from the OVF. Output data is stored on the output version of the signal "signal.O". The input is assigned a Z state when the pin direction is determined to be output. Similarly, the output is assigned an X state when the pin direction is determined to be input. For source files where VTRAN® can automatically determine signal direction, as is the case with the EVCD format, all this is done without any intervention from the user.

For some vector formats like Verilog VCD, however, not only is VTRAN® unable to unambiguously determine the signal type (input, output, or bidirect) there is no distinction in the data itself for determining whether the state data on a bi-directional signal is input data or output data. It is therefore necessary to use a VTRAN® process like BIDIRECT_CONTROL (located on the PROC_Block form) to specify when states represent input data or output data, usually as a logical function of a control signal. An example of this would be the following.

State Translations

The state characters used in the Original Vector File will most likely be different than those used in the Target Vector File. For example, in a standard Verilog VCD file, the state characters are 1, 0, X, Z, x, and z. The state character set used by a target vector format tester will vary. A typical set for the 93K is 1, 0, Z, H, L, X, M. The default mapping (always provided in the VUI® PROC_Block form) in this case is shown below.

State mapping can also be used to map the Z state on outputs to an X so the checking is masked or to translate any X state on pure inputs to a valid 1 or 0 state.

Important: STATE_TRANS is one of the last processes applied to the Original Vector File. This means that most all other processes invoked by the PROC block use the states directly from the OVF input file for logic expressions (i.e. before STATE_TRANS is applied).


The VTRAN® cyclization commands are found on the PROC_Block form and tell VTRAN® how print-on-change vectors should be collapsed into a cycle vector, how to gather meaningful state data, and how to assign target timing. There are several distinct approaches available within VTRAN® for use in both the single and multiple timeset flows. The AUTO_ALIGN and ALIGN_TO_CYCLE are single timeset strategies that fully integrate the timing analysis features of VCAP® as a basis for timing and cyclization. They are described here. For more information on other single timeset cyclization functions available in the VTRAN®, see the Application Note titled "Print-on-Change to Cycle-Based Translations". For Multiple timeset POC file flows, see the Application Note titled "VTRAN® Template Cyclization Feature".

In both AUTO_ALIGN and ALIGN_TO_CYCLE, the user specifies a CYCLE value that specifies the amount of time per tester cycle. Each tester cycle may include many print-on-change vectors. It is most often a value related to the fundamental clock of the device. Both these approaches also require PINTYPE statements that specify the timing that will appear in the Target Vector File (TVF). The difference between AUTO_ALIGN and ALIGN_TO_CYCLE is that the PINTYPE statements used with AUTO_ALIGN replicate the timing in the original simulation file, while the PINTYPE statements used with ALIGN_TO_CYCLE reflect device test specifications that may be different than the timing from the OVF input file. As a result, when using AUTO_ALIGN, the sampling time used by VTRAN® to collect state data from the OVF can be derived from the PINTYPE statements, but when using ALIGN_TO_CYCLE it must be specified separately using "PINLIST @ TIME" parameters as part of the ALIGN_TO_CYCLE statement.


An excerpt of the source simulation waveforms for InputSig1 and InputSig2 is shown below.

If the intent is to preserve the timing in the source simulation, use the Cyclization Function to AUTO_ALIGN.

PINTYPE RZ InputSig1 @ 8,24;
PINTYPE NRZ InputSig2 @ 12;

Notice the timing described in the PINTYPE statements matches the waveforms in the source simulation. VTRAN® uses these PINTYPE statements to assign timing in the target test program and automatically samples InputSig1 @ 16ns (8+24)/2 and InputSig2 @ 12ns relative to the beginning of each 60ns cycle. This results in the state patterns 101 and 110 respectively.

For a variety of reasons (i.e. different or unit simulation timing, tighter timing specs, etc...) it may be desirable to apply device timing that is different than that which appears in the source. See below.

Use the Cyclization Function to ALIGN_TO_CYCLE.

ALIGN_TO_CYCLE 60 InputSig1 @ 16, InputSig2 @ 12;
PINTYPE RZ InputSig1 @ 20,24;
PINTYPE NRZ InputSig2 @ 32;

Here VTRAN® uses the PINTYPE statements to assign timing in the target test program but uses the times listed in the ALIGN_TO_CYCLE statement to sample state values in the simulation file. Again, the state patterns collected by VTRAN® are 101 and 110 respectively.

In either case, the idea is to sample the state for each signal, in the source simulation file, at a time in the cycle when it is stable or in the case of a clock, when it is active. This becomes the pattern data used to drive the timing specified in the target test program file.

Appropriate signal sample times and target test program timing can be difficult to generate manually. Fortunately, VCAP® can do this automatically by collecting data regarding input and output state transitions and then analyzing the results.

Invoke VCAP®

The primary use for running VCAP® is to provide timing information for the PINTYPE statements if using AUTO_ALIGN or the "PINLIST @ TIME" entries in the ALIGN_TO_CYCLE statement if that option is selected. In the latter case, the user would specify the PINTYPE statements manually to reflect the desired timing and waveforms for the output file. (VCAP® supports the cyclization of simulation files with a single timeset only, i.e. the signal waveforms (edge timing and clocks) do not vary throughout the vector data file.)

Note that the use of VCAP® here is entirely optional. All of the information needed by the VUI® to create a VTRAN® command file and run a successful translation can be entered manually into the PROC_Block fields.

Choose either ALIGN_TO_CYCLE or AUTO_ALIGN and specify a CYCLE time.

Press "Invoke VCAP®". VUI® captures the results of this analysis.


The "Preview PINTYPE" section shows the cycle based timing format observed by VCAP® in the original print-on-change simulation file. When applied, the statements will be used to specify the target tester program timing. In this example, HOLDA, PCHK, PLOCK, ADS, and FERR are output signals of the device. PINTYPE STB specifies the target test program strobe time. This value is based on the max rise delay and max fall delay observed in the simulation source file on a per signal basis. "PINTYPE RZ CLK @20,33" specifies a return-to-zero format on signal CLK with a rise time @ 20ns and a fall time @ 33 ns. Again, the format and edge times are based on the transition types and times observed by VCAP® in the simulation source file. Supported PINTYPE formats include STB, NRZ, RZ, RO, RZ2X, RO2X, RZ4Z, and RO4X. Bidirectional signals have 2 PINTYPE statements: one for output behavior and one for input behavior. There is no need to provide additional information when using AUTO_ALIGN. VTRAN® automatically calculates the correct sample time for each signal from the PINTYPE statement.

Apply Optimized Timing

It might be that the simulation data is inconsistent. For example, when an input signal behaves in a non-return-to-zero manner but there is more than one 0→ 1 or 1→ 0 edge time. Signals of this type are displayed in bold. When a signal is selected, VUI® highlights the signal and then lists every state transition observed on this signal in the simulation source the pane titled "Configure Pins". See an example on signal NMI below.

The PINTYPE edge values may be altered by selecting a different transition from the list in "Configure Pins" or typing directly into "Preview PINTYPE".


When the cyclization function has been set to ALIGN_TO_CYCLE, the "Preview ALIGN_TO_CYCLE" pane is added to the VCAP® Analysis display. It contains a list of signals and where they are to be sampled relative to the start of cycle. This data has been derived by the VUI® VCAP® Analysis tool from the PINTYPE statements generated by VCAP® and is usually set to the beginning or middle of the active (pattern driven) portion of the waveform. For example, CLK @ 26 comes from (20+33)/2, where 20 is the rise edge and 33 is the falling edge of this RZ signal.

Signals with inconsistent behavior in the original simulation are bolded and their behavior is detailed in the Observed Timing section.

The PINTYPE statements that initially appear in the "Preview PINTYPE" pane are those that reflect the timing in the simulation source. When using ALIGN_TO_CYCLE, however, it may NOT be desirable for target test program timing to match that found in the simulation source and in fact may be significantly different. For this reason, changes to "Preview PINTYPE" edges values are made by typing directly into the Preview pane of the VCAP Analysis tool. Changes to the "Preview ALIGN_TO_CYCLE" values are also made in this way. While large PINTYPE modifications can be made here, they can be more conveniently made in the PROC_Block form as described in the "Review Timing" section of this guide.

The standalone execution of VCAP® provides other options not currently available in VUI®. For information on these items see The VCAP® User Guide ( The entire VCAP® report file maybe viewed or saved for future reference.

Review Timing

Press "Apply VCAP® Data" to transfer VCAP® timing data to VTRAN®. Note that timing data is optimized, i.e. signals sharing identical pintypes and time information are combined into single statements.

The data displayed in the screen shown below

is used to populate VTRAN® form fields.

Review Timing

Back on the PROC_Block form, "PINTYPE" and "PINLIST @ TIME" can be conveniently edited, if necessary, by directly typing into the form field or by using an external editor such as NEdit or gVim. VCAP® Report Information remains available and it is also possible to resume the prior VCAP® Analysis Tool session.

Press "Continue" to move to the next form.

TVF_Block Form

The commands in the TVF Block tell VtRAN how to format the vectors in the Target Vector File and what if any reporting parameters are desired. The fields that are presented are based on the declared output format.

Default values are provided and for many translations this is all that is needed. Press "Continue" to move to the next form.


VUI® constructs a VTRAN® command file based on the contents of the Initial Setup, OVF_Block, PROC_Block, and TVF_Block form fields. It is displayed on the Preview form and then passed to VTRAN® when the "Run VTRAN®" button is pressed.

The command file text can be edited in the Preview window before initiating the VTRAN® run. These edits remain local to the Preview window and are not propagated back to the fields in the previous pages. The command file text can also be saved by pressing the "Save Command File" button.

The results of the VTRAN® translation are presented in the VTRAN® results window.

If the VTRAN® run is not successful, the VTRAN® results window provides information about the errors encountered. Use the "<<Back" button on the Preview window to go back to the form where edits are required.

Compare Waveforms

Now that the ATE test program has been generated, it must be validated. Ideally this happens before it is run on expensive hardware. Use DFTView® after a translation to view and compare the ATE test program with the original VCD/EVCD simulation file. DFTView® is a program that allows the user to view, edit, and compare vector files with different formats. When launched from the VUI® after a VTRAN® translation ("Compare OVF & TVF with DFTView®" button), it is configured to display both the source simulation and ATE Test program waveforms and perform the comparison operation. The graphical displays of the OVF and TVF are shown below. OVF and TVF Editor tabs are also available and both VCD/EVCD and ATE Test Program source texts can be modified. All waveform displays (graphic and textual) can be optionally synchronized.

DFTView® Source Simulation (OVF)

DFTView® ATE Test Program (TVF)

DFTView® Compare Tool

The default "Bidirectional" Compare mode is the most rigorous. It is an XOR comparison of the source and reference waveforms. The "Trans-State", "Trans-Trans", and "State-State" comparisons are triggered off of Reference File (source simulation file*) events only. All Compare Modes allow the user to have full control over the compare range (i.e. portion of the waveform to be processed). The compare algorithms can be further modified to ignore X/Z state differences between waveforms as "soft" type errors often occur when comparing VCD and ATE waveforms on bidirectional signals. Pressing the "Compare" button causes the Compare operation to proceed. Depending on the user's preference, the results appear in report and graphical form. The DFTView® Compare Result tab details user selections, signal, miscompare time, and miscompare state.

* The Source/Reference assignment can be reversed if desired. That is the ATE Test Program File can be used as the reference for compare trigger purposes.

The actual location of the miscompare can be easily traced back to the OVF and TVF file positions. In the following example, miscompare number 3 is a result of a rising edge on NMI at 18 ns into our 60ns cycle (78ns) in the OVF simulation file and a rising edge on NMI at @ 23 ns in our TVF Test Program File.

See The DFTView® User Guide ( for more detailed information on how to use DFTView®.

Generate Testbench

Functional errors are also a concern. This is especially true in the ALIGN_TO_CYCLE flow where the user specifies target timing that may be significantly different from that in the source simulation. VTRAN® is able to create a simulator testbench by reading back target test program files. The testbench contains both input stimulus and processes that compare simulation output data against expected data. The idea is to validate the correctness of the test program via a simulation of the test program applied to the actual device design database. 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. When the testbench is re-simulated without error, the test program is ready to run on tester hardware. This may require more than one iteration.

The creation of a testbench (VERILOG OR VHDL) is in itself a type of VTRAN® translation. A test program file is translated to a VERILOG/VHDL testbench format. Like the primary VCD/EVCD to ATE Translation, it begins with the Initial Setup form that specifies the test program file as input and the testbench formated file as output.

VUI® default settings designed especially for test program file to testbench translations are sufficient for this task, although it is recommended that the CREATE_STATISTICS feature on the TVF_Block form also be used. This causes VTRAN® to accumulate and report 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.

For more details on creating a VHDL/VERILOG testbench and the usage of CREATE_STATISTICS, see the Application Notes titled "Translating CYCLE-based vectors to a Verilog or VHDL Testbench" ( and "Generating Device Test Program Statistics" (

Helpful Features

Save/Restore VUI® Commands

VUI® provides a parameter save/restore feature. At any time a user may save the parameters entered so far and return to the application at a later time. This is also useful when DFTView® waveform comparisons and/or Testbench simulations show that the ATE Test Program may not yet be ready to run on tester hardware and that the translation parameters need to be modified.

Additionally, VUI® provides mechanisms to save the VTRAN® command file, the VCAP® command file, as well as all VTRAN® and VCAP® execution results.

Context-Sensative Help

Use of the VUI® is made easier via context-sensitive help. It is enabled/disabled via the Help Menu in the Upper Right Hand corner of each VUI® form. Any time the mouse pointer moves over a form field in the application window, the relevant help information is be displayed in the help viewer.

Also see The VTRAN® User's Guide ( for details on any VTRAN® option.

Flow Chart

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