Simulate Translate Test

VCD/EVCD-to-ATE Translations Using VCAP STIL_TRANS

Cyclization is the process of collapsing the event driven vector data from print-on-change (POC) formats to cycle based formats. Historically, this has been one of most difficult tasks in the translation process mostly because the hardware in traditional ATE systems is often limited to fixed formats (i.e. NRZ, RZ, RO, etc... ) and a small set of pattern characters (i.e. 1,0,H,L,T,X). A variety of timing analysis tools have been developed to address this problem. Some test systems (i.e. V93K and T2000 ATE), however, support flexible waveform descriptions. In these cases, traditional timing analysis can unnecessarily produce unresolvable signal waveforms. VTRAN®/VCAP® with STIL_TRANS is a tool suite designed to take advantage of ATE architectures that support these waveform descriptions by directly mapping waveforms observed in the simulation file to a series of unstructured sequences of event/edge-time pairs. It is inherently straight forward and accurate. The purpose of this application is to describe its operation.


VCAP® STIL_TRANS is used to create a STIL file from the original VCD/EVCD simulation. It requires the user to define the basic vector cycle time. This can be derived from device specifications or clock analysis tools such as the VCAP® CLOCK_IDENTIFIER. During execution, VCAP® makes a single pass through the source vector file. For each cycle, VCAP®:

  • collects time and state data on all signal transitions
  • analyzes these transitions and for each signal constructs a waveform description
  • optimizes each waveform description and assigns a STIL waveform character (WFC)
  • adds new waveform descriptions to a STIL waveform table as necessary
  • creates a pattern vector

If the target ATE accepts generalized STIL as input, the task is complete. Otherwise, the newly created STIL file can be used as an Original Vector File in a VTRAN® translation using WFC_MODE. Note that WFC_MODE is currently supported for the V93K and T2000 ATE Platforms, only.

VCAP® execution is controlled by a user generated command file. The VTRAN® translation process may also be driven by a command file, though the VTRAN® command file is commonly created and launched from within the VUI®. The original, intermediate, and target waveforms can all be displayed using DFTView®.

stil trans flow

Using the VTRAN®/VCAP® with STIL_TRANS Tool Suite

Running the VCAP® STIL_TRANS Feature

In this application, the VCAP® command file is composed of a SRC_BLOCK and a STIL_TRANS_BLOCK. The SRC_BLOCK is used to tell VCAP® how to read the original simulation file. For most STIL_TRANS translations, the input file will be a VERILOG VCD or EVCD file. In both cases, all of the signals and their directions will need to be specified in the SRC_BLOCK using the INPUTS/OUTPUTS/BIDIRECTS statements. In the case of VCD files, it is sometimes necessary to also include BIDIRECT_CONTROL statements to determine the direction of bidirectional signals. Syntax used in the VCAP® SRC_BLOCK for signal definition and bidirectional control is identical to that used by VTRAN®.

The STIL_TRANS feature is controlled by the STIL_TRANS_BLOCK. At a minimum it contains a CYCLE command. This specifies the cycle period (in nanoseconds) for the main clock in the source event-based file. It remains constant throughout the entire vector file. The target STIL file contains a single WaveformTable with the CYCLE value used as the period value. The CYCLE value can be determined from the functional specification of the device or by using the Clock_Identifier feature of VCAP® (described in the next section).


      source_FILE = "small.vcd";
      INPUTS nrzSig, OutputEnable, rzSig, roSig, zmarker, Data[0..3] ;
      OUTPUTS edgeSig, windowSig ;
      BIDIRECTS bidirSig ;
      BIDIRECT_CONTROL bidirSig  = input when OutputEnable = 0;

      cycle = 400;    {# specifies cycle length in nanoseconds }
      target_FILE = "test_vcd.stil";

When executed, VCAP® generates a STIL file with cyclized waveforms that duplicate the behavior of the original simulation file. This STIL file contains one WaveformTable with a period equal to the cycle value specified in the STIL_TRANS_BLOCK. It specifies waveform descriptions for each behavior, for each signal in the source file. The pattern block references the Waveform Characters (WFC's) defined in the WaveformTable.

Choosing a Cycle Length Using the VCAP® Clock Identifier

Choosing the correct cycle length is critical to the process. A cycle length that is too long can result in waveforms descriptions with too many events. A cycle length that is too short may result in a pattern with too many vectors. A cycle length that is asynchronous to the natural period of the source file waveforms may result in the generation of too many waveforms. Most often the optimal cycle length is derived from the device specifications. The CLOCK_IDENTIFIER capability in VCAP® can also be used to determine clock behavior in the simulation. For each selected signal in the simulation data file, the CLOCK_IDENTIFIER reports:

  • period length
  • RZ/RO timing behavior
  • the time of the first and last leading edge in the waveform
  • the longest duration of inactivity
  • the minimum number of consecutive pulses observed
  • total number of pulses
  • comparison between device period and target ATE cycle length

The CLOCK_IDENTIFIER feature is controlled by the CLOCK_IDENTIFIER_BLOCK in VCAP®.


      source_FILE = "test_.evcd";
      report_FILE = "clocks.rpt";

See an excerpt of the report file created by the VCAP® CLOCK_IDENTIFIER feature below.




    First Leading Edge: 74.326ns Last Leading Edge: 3311456.488ns
    Total Number of Pulses: 496758
        Period 6.666ns PINTYPE RO 1.000,4.333
        Max Consecutive # of Pulses = 496758
        Max duration of inactivity = 0.000ns

    First Leading Edge: 9.000ns Last Leading Edge: 5768457.000ns
    Total Number of Pulses: 721057
        Period 8.000ns PINTYPE RO 1.000,5.000
        Max Consecutive # of Pulses = 721057
        Max duration of inactivity = 0.000ns

Some device simulations have just one signal that maintains a consistent period with consistent edge placements. In those cases, the appropriate cycle value is clear. In this case, a possible strategy is to separate gpi_clock from the rest of the simulation by making it a free running clock and choose a cycle value of 8ns for the remaining waveforms. See the VCAP® User Guide for more information on how to use the CLOCK_IDENTIFIER feature.


There are several command options available in both the VCAP® SRC_BLOCK and STIL_TRANS_BLOCK. A subset of these is presented in this section. For a complete list, see the VCAP® User Guide.


This command is used to identify which SRC_BLOCK signals to place in the target STIL file. If the CHECK_PINS command is not present, then all pins in the SRC_BLOCK are candidates for analysis. If the command is used, then any pin not explicitly listed is ignored.

CHECK_PINS outputs ;
check_pins dbus[7, 5, 3:0], mode, iobus, iobus.O ;


DELETE_PINS is an alternative to CHECK_PINS. Use this command to list those SRC_BLOCK pins which should NOT be analyzed.

DELETE_PINS bidirSig, Data[3];
DELETE_PINS bidirSig, Data;


When used in the STIL_TRANS_BLOCK, this feature instructs VCAP® to ignore glitches in the Source vector file waveform.


Any pulse narrower than MAX_WIDTH is considered a glitch. The default width is 1 ns. PIN_LIST specifies the signals where this check is to be applied. A CHECK_PINS declaration containing the subset of signals in the pin list must precede the GLITCH_CHECK command. If no pin list is specified, all pins listed in the CHECK_PINS declaration are filtered for glitches. If the optional IGNORE_STATES parameter is specified, then the states listed will not be flagged as glitches, otherwise a glitch of any state is flagged. Multiple GLITCH_CHECK statements are allowed. If GLITCH_CHECK does not appear in the STIL_TRANS_BLOCK, all transitions are considered.


STIL associates one WaveForm Character (WFC) to each waveform description on a per signal basis. Specifying a MAX_WFC tells VCAP® STIL_TRANS the maximum number of waveforms allowed on each signal.

MAX_WFC = 25;

In theory, and by default, the maximum value that may be specified is 62. VCAP®, however, reserves some waveform characters for specific waveforms. As a result, the actual maximum number of different Waveform Characters available for assignment may be less.


This command forces the STIL output file to have no empty Vector { } statements. While these statements are correct syntactically for the case where there are no changes in signal state from the last Vector statement, some tools have difficulty with them.


Indicates the number of significant digits after the decimal on times written in the report file.

RESOLUTION = 1.0;  {# Specifies integer time stamps - the default } 
RESOLUTION = 0.0001;
RESOLUTION = 0.00001;
RESOLUTION = 0.000001;


Specifies the tolerance to be used when determining whether or not there is a match between edge transitions. Setting it to 0.5 for example means that signal edges can make a transition within +/- 0.5ns of a previously observed transition time and still be considered to be the same. This applies only to input/bidir-input signals.


SKEW = 1.8;
SKEW = 5;

The STIL File

The following is an excerpt from a STIL file generated by the VCAP® STIL_TRANS feature.

STIL 1.0 ;

Header {
  Title "VCAP Version 2.3.3" ; 
  Date "Tue Jul 28 17:12:24 PDT 2015" ;
  Source File: "small.evcd";

Signals {
  nrzSig In;
  OutputEnable In;
  rzSig In;
  roSig In;
  edgeSig Out;
  windowSig Out;
  bidirSig InOut;
  zmarker In;
  Data[0] In;
  Data[1] In;
  Data[2] In;
  Data[3] In;
SignalGroups {
  Input_Group = 'nrzSig + OutputEnable + rzSig + roSig
              + zmarker + Data[0] + Data[1] + Data[2]
              + Data[3]';
  Output_Group = 'edgeSig + windowSig';
  Bidir_Group = 'bidirSig';

Timing {
  WaveformTable VCAP_wft {
    Period '400ns' ;
    Waveforms {
      nrzSig { P {'0nS' Z; '10nS' D; } } // 0ns  1 instances 
      nrzSig { 1 {'10nS' U; } } // 400ns  9 instances 
      nrzSig { 0 {'10nS' D; } } // 800ns  28 instances 
      OutputEnable { 0 {'0nS' D; } } // 0ns  28 instances 
      OutputEnable { 1 {'0nS' U; } } // 1200ns  10 instances 
      rzSig { A {'0nS' D; '100nS' U; '300nS' D; } } // 0ns  1 instances 
      rzSig { P {'100nS' U; '300nS' D; } } // 400ns  33 instances 
      rzSig { 0 {'0nS' D; } } // 800ns  4 instances 
      roSig { A {'0nS' U; '100nS' D; '300nS' U; } } // 0ns  1 instances 
      roSig { 1 {'0nS' U; } } // 400ns  11 instances 
      roSig { P {'100nS' D; '300nS' U; } } // 800ns  26 instances 
      edgeSig { H {'0nS' X; '200nS' H; } } // 400ns  19 instances 
      edgeSig { L {'0nS' X; '200nS' L; } } // 0ns  19 instances 
      edgeSig { X {'0nS' X; } } // unused 
      edgeSig { T {'0nS' X; '200nS' T; } } // unused 
      windowSig { H {'0nS' X; '200nS' H; } } // 400ns  19 instances 
      windowSig { L {'0nS' X; '200nS' L; } } // 0ns  19 instances 
      windowSig { X {'0nS' X; } } // unused 
      windowSig { T {'0nS' X; '200nS' T; } } // unused 
      bidirSig { H {'0nS' Z; '0nS' X; '250nS' H; } } // 4400ns  1 instances 
      bidirSig { L {'0nS' Z; '0nS' X; '250nS' L; } } // 1200ns  9 instances 
      bidirSig { X {'0nS' Z; '0nS' X; } } // unused 
      bidirSig { T {'0nS' Z; '0nS' X; '250nS' T; } } // unused 
      bidirSig { 0 {'0nS' D; } } // 0ns  19 instances 
      bidirSig { P {'120nS' U; '150nS' D; } } // 400ns  7 instances 
      bidirSig { A {'0nS' D; '250nS' U; '320nS' D; } } // 11200ns  1 instances 
      bidirSig { p {'250nS' U; '320nS' D; } } // 12800ns  1 instances 
      zmarker { P {'0nS' U; '100nS' D; } } // 0ns  38 instances 
      Data[0] { P {'0nS' Z; '255nS' D; } } // 0ns  1 instances 
      Data[0] { 0 {'0nS' D; } } // 400ns  15 instances 
      Data[0] { 1 {'255nS' U; } } // 3200ns  20 instances 
      Data[0] { D {'255nS' D; } } // 6400ns  2 instances 
      Data[1] { P {'0nS' Z; '255nS' D; } } // 0ns  1 instances 
      Data[1] { 0 {'0nS' D; } } // 400ns  10 instances 
      Data[1] { 1 {'255nS' U; } } // 1600ns  26 instances 
      Data[1] { D {'255nS' D; } } // 4800ns  1 instances 
      Data[2] { P {'0nS' Z; '255nS' D; } } // 0ns  1 instances 
      Data[2] { 0 {'0nS' D; } } // 400ns  15 instances 
      Data[2] { 1 {'255nS' U; } } // 3200ns  20 instances 
      Data[2] { D {'255nS' D; } } // 6400ns  2 instances 
      Data[3] { P {'0nS' Z; '255nS' D; } } // 0ns  1 instances 
      Data[3] { 0 {'0nS' D; } } // 400ns  10 instances 
      Data[3] { 1 {'255nS' U; } } // 1600ns  26 instances 
      Data[3] { D {'255nS' D; } } // 4800ns  1 instances 

PatternBurst "_burst_" {
  PatList {
    "_pattern_" { }

PatternExec  {
  PatternBurst "_burst_" ;

Pattern "_pattern_" {
  W VCAP_wft;
  V { // 0
    Input_Group = P0AAPPPPP;
    Output_Group = LL;
    Bidir_Group = 0;
  V { // 400
    Input_Group = 10P1P0000;
    Output_Group = HH;
    Bidir_Group = P;
  V { // 800
    Input_Group = 000PP0000;
    Output_Group = HH;
    Bidir_Group = 0;
  V { // 1200
    Input_Group = 01P1P0000;
    Output_Group = LL;
    Bidir_Group = L;
  V { // 1600
    Input_Group = 00PPP0101;
    Output_Group = LL;
    Bidir_Group = 0;

Features of the STIL File include:

  • It conforms to IEEE standards and is ready for use as an original vector file in VTRAN®.
  • It can be loaded into DFTView for viewing or comparison with other waveforms.
  • There is one WaveformTable. It is called VCAP_wft. The Period value is equal to the CYCLE value specified in the STIL_TRAN_BLOCK.
  • The first instance and total number of instances for each waveform behavior appears beside each waveform description in the Waveform Table.
  • VCAP® STIL_TRANS attempts to assign intuitive WFC characters. For example, the first behavior with 0 or 1 transitions in a cycle with a final state equal to logic high is assigned a WFC of '1'. See the VCAP® User Guide for a complete description of Track Construction and WFC Assignments.
  • On output waveforms, STIL_TRANS determines the placement of the edge strobe by looking for the last transition observed in the cycle. On output signals, STIL_TRANS generates only 4 waveforms - one for L, one for H, one for X, and one for T. On bidirectional signals, STIL_TRANS generates those 4 output waveforms, input waveforms as needed, and also bidirectional waveforms as needed. The strobe placement on bidir waveforms is determined by the last state value encountered before the driver comes on or before the period ends. Bidir waveforms get 1 edge strobe per driver off region.
  • By default, VCAP® optimizes the Pattern Block with V { } statements in the case where there are no changes in signal state from the last Vector statement. Some tools have difficulty with these statements. Specifying -NO_EMPTY_VECTORS in the STIL_TRANS_BLOCK causes the previous vector statement to be duplicated instead of an empty vector statement. The results are identical.
  • Timestamps are included on each vector.

The VTRAN® Translation Using WFC_MODE

If the target ATE does not support generalized STIL input, the next step is to use VTRAN® in WFC_MODE to translate the STIL file created by VCAP® STIL_TRANS to the target test system. (WFC_MODE is available for the V93K and T2000 ATE targets.) The user controls the VTRAN® translation with an ASCII command file. Historically, the ASCII command file has been created using a text editor and VTRAN® has been launched from the command line. While this continues to be an option, the VTRAN® User Interface Utility (VUI) is now available. It is a graphical user interface developed specifically for generating VTRAN® command files and is automatically installed with VTRAN®. Either way, the concepts and the results are the same.

The three blocks that make up the VTRAN® command file are:

  • OVF_BLOCK - The Original Vector File Block
  • PROC_BLOCK - The Process Block
  • TVF_BLOCK - The Target Vector File Block

In general, the OVF_BLOCK tells VTRAN® how to read the input file or "Original Vector File". In this case, the OVF_BLOCK specifies the STIL format and WFC_MODE. The PROC_BLOCK contains commands that tell VTRAN® the data processing functions to be performed on the simulation data during translation. In STIL WFC_MODE to ATE translations where the WaveformTable timing and state information in the STIL file get passed directly to the output formatter, this may only include overriding Original Vector File timing and state information, inserting statements, etc... Finally, the TVF_BLOCK contains commands that specify the desired output format.


      ORIG_FILE = "test_vcd.stil";

      DONT_CARE = "X";

      TARGET_FILE = "test.avc";
         MAX_LINE_LENGTH = "80"
         TIME_STAMPS = "On"
         DVC_FILE = "test.dvc"
      RESOLUTION = 1.0;

VTRAN® translations using WFC_MODE tend to be simple as illustrated in the example above. Signal directions do not need to be specified, no bidirectional control is required, and no cyclization is necessary. Not even STATE_TRANS statements are required.

Two important PROC_BLOCK commands used to modify waveform descriptions and pattern states are described in the next section. See the VTRAN® User Guide and the application note titled "VTRAN® STIL Waveform Translations Using WFC_MODE" for more information on how to use the ® WFC_MODE feature.

Overriding STIL Waveforms in the PROC_BLOCK

Overriding and Adding Waveform Descriptions

PINTYPE WFC is a PROC_BLOCK command used to modify/add waveforms during the WFC_MODE translation process. The syntax is:

PINTYPE WFC pin_list @ state_list "waveform_description" [waveformtable_name];


	PINTYPE WFC bidirSig @ 01ZN "'0ns' D; '107ns' DUZN; '328ns' D;";
        PINTYPE WFC bidirSig.O @ H "'0nS' Z; '0nS' X; '150nS' H;";
        PINTYPE WFC roSig @ 01 "'0ns' U; '102ns' DU; '302ns' U;" base_wfmtbl;
        PINTYPE WFC rzSigA, rzSigB @ 1 "'35ns' U; '60ns' D;"

If the WFC already exists, the STIL Waveform Description overrides the previous timing. Notice the reference to "bidirSig.O" in the example. VTRAN® creates two internal pins versions for each bi-directional signal. 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 and is called "signal_name.O". Override output waveforms, using this name. Use the defined name in all other cases.

If the WFC does not exist, the waveform is added to the WaveformTable specified. If no WaveformTable is specified, the first WaveformTable is updated. Multiple PINTYPE WFC statements may be specified for the same pin.

Modifying Pattern Values

Pattern values (i.e. pin states) can be modified (masked) using the MASK_PINS command in the PROC_BLOCK. They can be masked within each cycle, or in multiple vectors within a time range, or when specified masking conditions are met.

MASK_PINS mask_character = 'B' nrzSig @ 1600, 2000;
MASK_PINS mask_character = 'X' edgeSig @ CONDITION (zmarker = P);

The MASK_PINS command is very powerful. See the applications note titled "Masking Pins in Target Vector File" for more information.




Product Support

Customer Quotes

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