Simulate Translate Test

VTRAN® STIL Waveform Translations Using WFC_MODE

In order to support the hardware in traditional ATE Test Systems, translations from STIL to ATE formats have used the classic, fixed formats NRZ, RZ, RO, etc... and limited pattern characters, i.e. 1,0, H,L,X,T to represent active/not-active vector states. The STIL language, however, provides greater flexibility with waveform descriptions and pattern characters. Waveform descriptions are comprised of unstructured sequences of event/edge-time pairs and are associated with user specified WaveForm Characters (WFC's). When used as pattern characters in vector statements, these WFC's assign waveforms to specific signals. Some test systems like the Advantest V93K and Advantest T2000 support these waveforms and WaveForm Characters. VTRAN®'s WFC_MODE option is used in translations where the Original Vector File format is STIL and the Target Vector File format can support flexible waveform descriptions. It is inherently accurate and is recommended when translating from STIL to ATE formats which support it. This application note describes how WFC_MODE is used and its effect on other translation options.

VTRAN® Overview

The user controls the VTRAN® translation process 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® in the S3_ROOT directory. 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

The commands and parameters in these blocks direct the details of the translation. 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. The PROC_BLOCK contains commands that tell VTRAN® the data processing functions to be performed on the simulation data during translation. In STIL to ATE translations where the WaveformTable timing and state information in the STIL file get passed directly to the output formatter (WFC_MODE), this may include signal masking, adding pins, inserting statements, etc... Finally, the TVF_BLOCK contains commands that specify the desired output format.

The WFC_MODE command is part of the VTRAN® command file OVF_BLOCK.

VTRAN® STIL Waveform Translations Using WFC_MODE

The WFC_MODE Feature

 

By default, i.e. no WFC_MODE, the VTRAN® STIL reader determines the classic format of each signal (NRZ, RO, RZ, RO2X, RZ2X, RO4X, RZ4X, and STB) and the corresponding vector states. The vector states returned by the STIL reader are:

Drive Events: 
	D Force Down, U Force Up, Z Force Off, P Force Prior

Compare Events: 
	L Compare Low, H Compare High, Xx Compare Unknown (don’t care), 
	T Compare Off, V Compare Valid, l Compare Low Window, 
	h Compare High Window, t Compare Off Window, v Compare Valid Window

Expect Events: 
	R Expect Low, G Expect High, Q Expect Off, M Marker

Unresolved Events: 
	N Force Unknown, A Logic Low, B Logic High, F Logic Z, ?  Unknown

In the following example, VTRAN® is operating in default mode. The STIL reader identifies and returns an RZ format on InSig1, an NRZ format on Insig2 and STB formats on OutSig1 and OutSig2. It identifies and returns vector states using the characters listed above.

Example 1 - Default Mode Using Classic Formats

STIL OVF File Excerpt

SignalGroups {
   Group0 = 'InSig1 + InSig2 + OutSig1 + OutSig2';
}

Timing {
   WaveformTable base1 {
      Period '400ns';
      Waveforms {
         InSig1 { 01 { '0ns' D; '100ns' D/U; '300ns' D; } }
         InSig2 { 01 { '0ns' P; '10ns' D/U; } }
         OutSig1 { LHTX { '0ns' X; '200ns' L/H/T/X; } }
         OutSig2 { LHTX { '0ns' X; '200ns' l/h/t/X; '400ns' X; } }
      }
   } // WaveformTable base1
} // Timing

Pattern pat {
   W base1;
   V { Group0 = 0 1 L L ; }
   V { Group0 = 1 0 H L ; }
   V { Group0 = 0 0 L H ; }
} //

Generic ATE output with Fixed Format Assignments:

TIMESET base1
CYCLE 400.000000
InSig1  RZ 100.000 300.000 
InSig2  NRZ 10.000 
OutSig1  EDGE_STB 200.000 
OutSig2  WINDOW_STB 200.000 400.000 
TIMESET_END
PINS InSig1  InSig2  OutSig1  OutSig2  ;
@          0.000 - DULl;
@        400.000 - UDHl;
@        800.000 - DDLh;

For most translations the state characters coming from the STIL file reader get mapped to the specific characters used by the target ATE using STATE_TRANS commands. This default mode of operation is appropriate when the target vector format supports classic, fixed formats. Using the WFC_MODE option, however, causes the STIL WaveformTable timing and state information to get passed directly to the TVF output formatter. See Example 2.

Example 2 - WFC_MODE

STIL OVF File Excerpt

SignalGroups {
   Group0 = 'InSig1 + InSig2 + OutSig1 + OutSig2';
}

Timing {
   WaveformTable base1 {
      Period '400ns';
      Waveforms {
         InSig1 { 01 { '0ns' U/D; '100ns' D/U; '300ns' U/D; } }
         InSig2 { DU { '0ns' P; '10ns' D/U; } }
         InSig2 { du { '0ns' P; '15ns' D/U; } }
         OutSig1 { LHTX { '0ns' X; '200ns' L/H/T/X; } }
         OutSig2 { LHTX { '0ns' X; '200ns' l/h/t/X; '400ns' X; } }
      }
   } // WaveformTable base1
} // Timing

Pattern pat {
   W base1;
   V { Group0 = 0 D L L ; }
   V { Group0 = 1 d H L ; }
   V { Group0 = 0 U L H ; }
} //

Generic ATE file output with flexible waveform descriptions:

TIMESET base1
CYCLE 400.000000
InSig1  { 01 { '0.000000ns' UD; '100.000000ns' DU; '300.000000ns' UD; } }
InSig2  { DU { '0.000000ns' P; '10.000000ns' DU; } du { '0.000000ns' P; '15.000000ns' DU; } }
OutSig1 { LHTX { '0.000000ns' X; '200.000000ns' LHTX; } }
OutSig2 { LHTX { '0.000000ns' X; '200.000000ns' lhtX; '400.000000ns' X; } }
TIMESET_END
PINS InSig1  InSig2  OutSig1  OutSig2  ;
@          0.000 - 0DLL;
@        400.000 - 1dHL;
@        800.000 - 0ULH;

The waveform characters (WFCs) in the vectors from the STIL file are used directly in the ATE vector, no STATE_TRANS are needed. Likewise the timing information and waveform descriptions from the STIL file are replicated exactly in the ATE waveforms. Not only are complex waveforms accurately processed, but also multiple waveforms are supported on a single signal. Multiple input waveforms, multiple output waveforms, and multiple bidirectional waveforms can be supported on one bidirectional signal.

Setting WFC_MODE

The OVF_Block with the commands necessary to specify a STIL reader and turn on WFC_MODE looks like:

ovf_block
   begin
      ORIG_FILE = "simple.stil";
      TABULAR_FORMAT STIL
         -CYCLE		{# Preserve the cycle based structure of the OVF }
			{# Must be set in order to use WFC_MODE}
         -WFC_MODE	{# Enable WFC_MODE}
         . . . . .      {# any other parameters }
      ;
   end;

Setup a STIL to ATE translation with WFC_MODE using the VUI Initial Setup and OVF_BLock forms.

See the "VTRAN® User Guide" and the "VUI VTRAN® User Interface Guide" for more details on using these and other VTRAN® commands.

WFC_MODE Constraints

WFC_MODE is supported for the STIL OVF format only. Since many output formats will not support the waveform character-based timing which this translation uses, VTRAN® supports this mode of timing translation for the following TVF formats only: STIL, Advantest V93K and Advantest T2000.

Some VTRAN® options are not compatible* with WFC_MODE. For the most part, these options simply do not make sense in the WFC_MODE paradigm. They are listed below.

STIL OVF_BLOCK

-ALLOW_UNDEF_WFC
-BIDI_ZX

STIL TVF_BLOCK

-ALT_CLK_FORMAT1
-ALT_BIDIR_WFM

The PROC_BLOCK

STATE_TRANS
STATE_TRANS_GROUP

Advantest V93K TVF_BLOCK

-NO_M_WFC
-USE_Z_DELAY
-DVC_OUTPUTS_FNZ 
MERGE_BIDIRECTS
XMODE and associated parameters 

Advantest T2000 TVF_BLOCK

-USE_Z_DELAY

*Note that the VUI automatically disables these options when the WFC_MODE is selected with a STIL OVF format.

Other Considerations

State References in the PROC_Block

Virtually all the vector processing commands available in the PROC_BLOCK for use without WFC_MODE are also available when WFC_MODE is selected. While most of these commands operate without regard to whether or not WFC_MODE is enabled, commands that use expressions that reference states read from the OVF need consideration.

The following INSERT_STATEMENT command can be applied in WFC_MODE to the STIL OVF from Example 2. It causes VTRAN® to insert the "macro "MySpecialFunction"" text when the conditional logic expression "InSig2=d" is satisfied. Notice it references the state character that appears in the STIL vector assignments as opposed to any of those returned by the STIL reader without WFC_MODE.

INSERT_STATEMENT "macro \"MySpecialFunction\" ;" @ CONDITION InSig2= d ;

Generic ATE file output with inserted statements:

PINS InSig1  InSig2  OutSig1  OutSig2  ;
@          0.000 - 0DLL;
macro "MySpecialFunction" ;
@        400.000 - 1dHL;
@        800.000 - 0ULH;

Other commands like ADD_PIN, INSERT_REPEAT, MASK_PINS, and REGISTER also use expressions that reference states read from the OVF and should be handled similarly.

PINTYPE WFC

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

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

Example:

        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 tracks, using this reference. Use the defined name in all other cases.

If the WFC does not exist, the waveform is added to the Waveform table specified. If no Waveform Table is specified, the first waveform table is updated. Multiple PINTYPE WFC statements may be specified for the same pin. Use the VTRAN® ADD_PIN and MASK_PINS commands to modify pattern values.

Advantest V93K

When using WFC_MODE, all STIL WaveformTable entries and vector waveform characters get translated directly to the 93K format without modification. This is not the case for event characters. The "N" event (Force Unknown) in STIL gets mapped by default to 0 event and the P event (Force Prior) to !Z. These mappings can be changed in the TVF_BLOCK, however, using:

N = "1",  {# map STIL N Event to 1 Event in 93K format}
P = "FN0" {# map STIL P Event to FN0 Event in 93K format}

Advantest T2000

The same situation occurs in the case of an Advantest T2000 TVF. The "N" event (Force Unknown) in STIL must get mapped to either a D or a U event for the T2000. The default is to map it to D, but this can be changed in the TVF_BLOCK using:

N = "U", {# map STIL N Event to U Event in T2000 format}

 

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