Simulate Translate Test


This application note relates to the latest VTRAN® feature: TEMPLATE CYCLIZATION. In versions through Release 6.1, VTRAN® has provided the capability to collapse print-on-change (POC) vector data (such as Verilog VCD or EVCD) to cycle-based formats (such as WGL, STIL, and numerous tester formats). This capability was limited to only a single set of timing, or TIMESET. Today's complex devices, however, often require several different cycle types. TEMPLATE CYCLIZATION makes it possible to cyclize POC vector patterns containing multiple TIMESETs with dynamically changing cycles such as a init, run, and wait. TEMPLATE CYCLIZATION is fully incorporated in the familiar VTRAN® command files. It uses many of the pre-existing features. This application note provides an overview of the entire translation process but focuses mainly on the commands and features related to TEMPLATE CYCLIZATION. Please refer to the VTRAN® Users Guide for a complete reference to the existing features or visit for more information.


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). VTRAN's reader technology enables it to read almost any simulation file. VTRAN® includes canned readers for many print-on-change formats including those mentioned earlier as well as support for user formats. THE PROC_BLOCK contains commands that tell VTRAN® what data processing functions you want performed on the simulation data during translation. This is where the TEMPLATE_CYCLIZATION feature is invoked. Finally, the TVF_BLOCK contains commands that specify the desired output format.

TEMPLATE_CYCLIZATION is how VTRAN® provides an automatic, cost effective and fast cyclization procedure. It is enabled by specifying a TEMPLATE_CYCLIZATION command along with one or more TIMESETs in PROC_BLOCK. It works by identifying pre-defined cycle types in the OVF, collecting meaningful state data, and then integrating this with user defined test specifications for final output in the TVF. As with other VTRAN® translation features, the user ultimately controls the process. See how the user provides VTRAN® with the fundamental cyclization elements in the example below.



   ORIG_FILE "exp2.evcd";

   SCRIPT_FORMAT verilog_vcd;

   { INPUTS, OUTPUTS, BIDIRECTS statements }





    TERMINATE_ON_DEFAULTS = "1", {# stop on no match }

    CYCLIZATION_SKEW = "0.5", {# edge tolerance }

    MATCH_REPORT = "match.rpt",

    MATCH_TRACE_START = 1, {# detail trace parameters }



    CYCLE 100;

    PINTYPE NRZ * @ 0; {# DEFAULT sample directive/test spec }

    PINTYPE STB * @ 90 95; {# DEFAULT sample directive/test spec }

    SAMPLE_POINT RESET @ 10; {# sample directive }

    IDENTIFIER RESET = D; {# match criteria }

    PINTYPE RZ CLOCK @ 40, 60; {# sample directive/test spec }

    PINTYPE NRZ RESET @ 5; {# test spec }

    PINTYPE NRZ data0 @ 80; {# sample directive/test spec }



    CYCLE 100;

    PINTYPE NRZ * @ 0; {# DEFAULT sample directive/test spec }

    PINTYPE STB * @ 90 95; {# DEFAULT sample directive/test spec }


         {# match criteria/sample directive/test spec }

    SAMPLE_POINT RESET @ 10; {# sample directive }

    IDENTIFIER RESET = U; {# match criteria }

    PINTYPE NRZ RESET @ 5; {# test spec }

    PINTYPE NRZ data0 @ 10; {# sample directive/test spec }



    CYCLE 500;

    SELECT_RANGE 1000,5000; {# match criteria - overrides others }

    PINTYPE NRZ * @ 0; {# DEFAULT sample directive/test spec }

    PINTYPE STB * @ 490 495; {# DEFAULT sample directive/test spec }

    PINTYPE RZ CLOCK @ 200, 400; {# sample directive/test spec }

    PINTYPE NRZ RESET @ 5; {# sample directive/test spec }

    PINTYPE NRZ data0 @ 100; {# sample directive/test spec }


   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'->'Z', 'x'->'X',

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

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

   STATE_TRANS pure_outputs

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

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

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

    'c'->'1', 'f'->'Z', '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',


   STATE_TRANS bidir_outputs

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

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

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






    AddressElement = "CycleNumber";

   TARGET_FILE = "exp.wgl";


In this example, the INIT TIMESET is applied to those waveform sections where the RESET signal is low at 10ns into the cycle. The WAIT TIMESET is applied to the waveform section corresponding to 1000ns to 5000ns. The RUN TIMESET is applied on those waveform sections where the CLOCK has an active double pulse and RESET is high at 10ns into the cycle. VTRAN® cyclization shall immediately end if a mismatch is detected since the TERMINATE_ON_DEFAULTS parameter is set to 1.


The TEMPLATE_CYCLIZATION statement initializes the cyclization process and anyone or all of the following global cyclization parameters:

   CYCLIZATION_SKEW = "m.n"; { edge tolerance in nanoseconds }

   TERMINATE_ON_DEFAULTS = "n" { termination parameter }

   MATCH_REPORT = "filename"

   MATCH_TRACE_START = n {debug trace ON specified by cycle number}

   MATCH_TRACE_STOP = m {debug trace OFF specified by cycle number}


This option allows the user to specify a SKEW (edge) tolerance to be used during waveform matching. If this parameter is not specified, the tolerance defaults to .5 fs (very small). Setting it to 0.5ns, for example, means that edges can make a transition within +-0.5ns of the match timing specified and still be considered as a match.


This option influences VTRAN's behavior when it cannot match the IO activity for a section of the POC data, to any of the user-specified match criteria described in the TIMESETS. In those cases, it needs to fall back on the default TIMESET. The user can explicitly define a default TIMESET, as will be explained later. If none is defined, the very first TIMESET definition VTRAN® encounters becomes the default TIMESET. Each time there is a -DEFAULT cycle used, a warning is sent to the screen (stderr).

Different values for the TERMINATE_ON_DEFAULTS parameter will affect the cyclization process as follows:

  • -1 Cyclization will not terminate due to default matches. Also, no warning is issued when default is used.
  • 0 Cyclization will not terminate due to default matches. Warnings will be generated when default is used.
  • N Cyclization terminates when default used n times (n>0) Warnings are generated when default TIMESET is used.


Cyclizing vectors with multiple cycle-types can be a difficult task. To aid translation, VTRAN® provides a window into its efforts by generating a detailed report of all its cycle matching. The parameters MATCH_REPORT and MATCH_TRACE direct VTRAN® to print cycle matching results in a given range. The match report contains a wealth of information useful in debugging the cyclization process and adjusting the matching criteria. The MATCH_REPORT parameter specifies a file name and directs VTRAN® to place cycle matching statistics in this file. The range specified between MATCH_TRACE_START and MATCH_TRACE_END parameters controls the length of this trace using cycle numbers. VTRAN® will not check validity of the start and stop values or the range specified therein.


The TIMESETs provide the main control of the cyclization process. VTRAN® allows the user to specify multiple TIMESETs. Cyclization is performed on the OVF data by matching the different TIMESET waveforms with the waveforms found in the POC data. In addition, TIMESETs are used to establish the sample point of each signal and the timing in the output file. Using this feature VTRAN® can cyclize a VCD file that included several different cycle types (with different cycle times and signal timing) such as say an init_cycle, a run_cycle and a wait_cycle. TIMESETs start and end with TIMESET and ENDTIMESET respectively.

Important: VTRAN® uses the time unit of ns for all timings specified in the TIMESET BLOCK. If the desired time is 50 ps, then it should be defined as 0.050.

Match Commands

The match commands identify the signals and behaviors used in the match process as well as provide specific instructions to VTRAN® during the match process. They are PINTYPE -PRIMARY (-ACTIVE_ONLY), IDENTIFIER, WEIGHT, and SELECT_RANGE.


PINTYPE -PRIMARY is usually associated with a clock. A given TIMESET can have one or more signals defined as PINTYPE -PRIMARY. This means that their PINTYPE waveform and timing behavior will be used as criteria in the cycle-matching process. In a given TIMESET, if multiple signals have a -PRIMARY flag set in their PINTYPE statements, then they become a logical AND operation from a cycle matching perspective. The -ACTIVE_ONLY flag allows a match only when the clock does a full pulse. Default behavior is passive match, which means that the TIMESET can match when no pulsing is present.

  PINTYPE -PRIMARY RZ clkA @ 25, 50;


Currently, VTRAN® will not cyclize TIMESETs with overlapping clock boundaries. Clock glitches also require special attention. Glitches need to be handled on case-by-case basis. User should evaluate the source vector-data and identify glitches and their timings. Then a Sink_TIMESET should be created for VTRAN® to match during clock glitches. Such Sink_TIMESETs can then be filtered out during post processing through filters outside VTRAN.


The IDENTIFIER statement provides logical information that can be used as an alternative to the -PRIMARY signals (or in conjunction with them) during the cycle identification (match) process. It can be any complex logical equation constructed using the signals specified in the vector source. If both an IDENTIFIER statement and -PRIMARY flags are specified, a TIMESET can match if and only if the -PRIMARY clock activity matches AND the IDENTIFIER equation is also true. The use of IDENTIFIER criteria for cycle identification and matching is strongly recommended. Since the matching algorithm produces a MISMATCH whenever any of the -PRIMARY or IDENTIFIER criteria fails, the strategy for specifying these criteria in the TIMESET blocks should focus on identifying criteria which, collectively, uniquely identify the TIMESET. Note that only one IDENTIFIER is allowed per TIMESET. IDENTIFIER statements are local to a TIMESET. They are capable of not allowing their parent TIMESET to match, but in no way do they affect matching of any other TIMESET.

  IDENTIFIER (se=1)&(reset_mode=1);

Note that the logic state values used in the IDENTIFIER statements are those state characters coming directly from the file being read, and are determined at the sample time in the cycle (State Data below).


Sometimes, more than 1 TIMESET will match a certain cyclical activity. In order to provide further guidance to the cyclization process, a WEIGHT parameter can be specified for each matched TIMESET, which will be used to resolve cycles where more than one TIMESET has a match. The WEIGHT parameter gives a TIMESET extra weight during cycle matching. A matched TIMESET with no WEIGHT will lose during a conflict with a weighted matched TIMESET.


SELECT_RANGE causes VTRAN® to make a TIMESET selection and can be used for cases where the user knows the exact times when particular TIMESETs should be used thereby improving efficiency. For example, a case where this feature can greatly improve efficiency is when TIMESET blocks used with TEMPLATE_CYCLIZATION have cycle lengths that differ from each other by orders of magnitude. The SELECT_RANGE statement in the TIMESET block allows the user to specify the time ranges where the TIMESET is to be selected.

  SELECT_RANGE 2000.0 12000.0 ;

The start time value of the SELECT_RANGE statement specifies when the TIMESET should be selected. It is included in the time sequence. The end time of the SELECT_RANGE statement is the time at which normal template cyclization should resume, or at which a different SELECT_RANGE statement may start. A TIMESET block may have multiple SELECT_RANGE statements. Active ranges may be defined for multiple TIMESETs, but must not overlap. When the selected TIMESET for a cycle is defined by a SELECT_RANGE statement, the normal template cyclization checks of PRIMARY signals and IDENTIFIERs for all TIMESETs are skipped, i.e. the SELECT_RANGE criteria , when met, overrides any other selection criteria.


VTRAN® has the facility to specify a default TIMESET (the -DEFAULT flag after the TIMESET name). If none is specified, VTRAN® chooses the first defined TIMESET as the default. This default TIMESET is the TIMESET selected when no other TIMESET matches.


The CYCLE command specifies the period value associated with this TIMESET in both the OVF and TVF.

  CYCLE = 

State (Sample) Data

The Input Sampling Time is most often derived from the the standard VTRAN® PINTYPE commands, which are also used to define the target timing and behavior of all pins. For example, an input with a PINTYPE NRZ at 1.0 will be sampled at 1.0 ns into the cycle. A clock with PINTYPE RZ at (3.0, 4.0) will be sampled at 3.5 ns into the cycle, and likewise outputs with a PINTYPE STB at (6.1, 6.2) will be sampled at 6.1 ns into the cycle. PINTYPE formats include NRZ, NRZ2, RZ, RZ2X, RO, RO2X, and STB. Some PINTYPE examples are explained below:

  PINTYPE NRZ * @ 0; { sample all inputs at start of cycle}

  PINTYPE NRZ se @ 20 { sample se 20ns into cycle}

  PINTYPE NRZ reset_mode @ 20; { sample se 20ns into cycle}

  PINTYPE RZ clk @ 20, 50; { sample clk 37.5ns into cycle}

The Output Strobe Time is also specified using standard VTRAN® commands as shown below:

  PINTYPE STB * @ 35; { sample all outputs 35ns into cycle}

  PINTYPE STB * @ 30 40; { sample outputs 35ns ([30+40]/2) into cycle }

An alternative to this automatic sample-point calculation is the use of the SAMPLE_POINT statement in the TIMESET block. This statement provides a way of explicitly specifying the time point within each TIMESET cycle where signals should have their states sampled. The syntax is:


where can be a list of signal names, or one of the pre-defined signal group names (ALL_INPUTS, ALL_OUTPUTS, PURE_INPUTS, PURE_OUTPUTS, BIDIR_INPUTS, BIDIR_OUTPUTS). Multiple SAMPLE_POINT statements can be used and they override the calculated sample times from the PINTYPE statements. The SAMPLE_POINT statement provides for a simple way to handle vector files where the timing of some signals in the input file may be different than the timing you wish to have in the output file. Output timing can then be specified with the PINTYPE statements, while the sample points for state extraction from the input file is separately specified with the SAMPLE_POINT statement.

Target Timing

During cyclization, VTRAN® sequentially processes the POC vectors. It determines the matching TIMESET and records the state for each signal at the sample time specified by the matching TIMESET. This state is then used as the vector state for that cycle and the appropriate TIMESET tags are applied. The actual output timing is specified with the CYCLE and PINTYPE statements shown earlier. The timing specified by the user in these statements should reflect the device test specifications.

Important: Any input that is not explicitly specified with a PINTYPE or SAMPLE_POINT command will be sampled @ 0ns. Any outputs without explicit PINTYPE or SAMPLE_POINT commands will be sampled @ 0.9 * . Perhaps more important, is the fact that inputs default to "PINTYPE NRZ ... @ 0" and outputs default to "PINTYPE STB ... @ 0". It is good practice to begin each TIMESET with:

  PINTYPE NRZ * @ 0; { or something non-0 if desired}

  PINTYPE STB * @ 90, 95 ; { say for a 100 ns cycle };

This ensures that the sample time used for cyclization matches the timing generated in the output file. Subsequent PINTYPE and SAMPLE_POINT commands override these defaults.

Refer to VTRAN® Users Guide for complete Cycle-Matching process description and algorithm.

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