Simulate Translate Test

Translating WGL/STIL Vector Files to Teradyne Tester Formats

The most common vector formats produced by today's leading ATPG tools are WGL and STIL. The WGL format syntax was originally developed by TSSI and has become somewhat of a defacto industry standard. Virtually all ATPG tools in use today can generate vectors in this format (although not all follow the syntax strictly). STIL (Standard Test Interface Language) is a recently IEEE-adopted standard format for test vectors that is growing in use. Many ATPG tools offer the user the option of generating vector files in either of these two formats. This Application Note focuses on the task of translating vector files in these formats to test programs for the Teradyne Catalyst, J750, J971 and J973 testers.

Overview

Vtran makes the task of translating WGL and STIL files into Teradyne test programs relatively simple. Canned readers for both of these formats are included with the vtran product bundle. As long as the WGL and STIL files follow the syntax of their respective specifications, the readers can easily handle them. If the WGL file is being generated from the Synopsys TetraMAX ATPG tool, then it is important to make sure that the option settings are such that they produce a syntactically and semantically correct WGL file. A number of the user-controlled options will result in an invalid WGL file. The option settings currently recommended for TetraMAX are as follows:

  set wgl -bidi_map -x -x

  set wgl -bidi_map z- z-

  set wgl -bidi_map 0x 0x

  set wgl -bidi_map 1x 1x

  set wgl -bidi_map xx xx

  set wgl -bidi_map z0 z0

  set wgl -bidi_map z1 z1

  set wgl -bidi_map zx zx

  set wgl -bidi_map zz zz

  set wgl -chain_list shift

  set wgl -group_bidis

  set wgl -inversion_reference master

  set wgl -last_scan

  set wgl -nomacro

  set wgl -nopad

  set wgl -pre_measured

  set wgl -scan_map dash

These settings are applicable to TetraMAX version 2.02 and later. See also the online help notes within the TetraMAX environment.

For STIL vector files, the optional "ScanStructures" block must be present. The information contained in this block is needed by the reader to fully maintain the scan data during translation to the tester formats.

The vector translation process is divided into three separate tasks or blocks, which correspond to the three blocks in the vtran command file - the OVF_BLOCK, the PROC_BLOCK and the TVF_BLOCK. The commands and parameters in these blocks direct the details of the translation. In general, the OVF_BLOCK contains information necessary for vtran to read the input file or "Original Vector File" (i.e. the WGL or STIL file). The PROC_BLOC contains commands that tell vtran what data processing functions you want performed on the simulation data during translation. This typically would be instructions such as how you would like state characters mapped between the input and output formats, or perhaps some desired signal masking. For both of these cycle-based formats, there is not very much processing that needs to be done so the OVF_BLOCK and PROC_BLOCK are typically small. Finally, the TVF_BLOCK contains commands that specify the desired output format - in this case it is the Teradyne format for either the Catalyst, J750, J971 or J973 testers. There may also be some final processing to be done or some optional user-supplied parameters that appear in the TVF_BLOCK. Now, let's take a look at some specifics for these translations.

The OVF_BLOCK

When using the vtran WGL or STIL canned reader, there is actually very little information (in the way of command instructions) needed by vtran to read the data and do any necessary mapping of state characters, in preparation for generating the Teradyne test vector file. In fact, the only command required in the OVF_BLOCK would be a "TABULAR_FORMAT" command, which might look like:

OVF_BLOCK

   BEGIN

   TABULAR_FORMAT wgl -cycle, -scan;

   END

When reading STIL files, simply replace the "wgl" with "stil". If the name of the cycle-based file is being supplied from the command line, then this is all that is needed in the OVF_BLOCK. Otherwise we might add the ORIG_FILE command to this block:

OVF_BLOCK

   BEGIN

   TABULAR_FORMAT wgl -cycle, -scan;

   ORIG_FILE = "filename";

   END

Note the two flags that are being passed to the readers. The first flag (-cycle) is required and tells the reader to not flatten-out the timing in the input file. Since the Teradyne test vector files are cycle-based formats (as are WGL and STIL), this flag instructs the reader to keep the signal timing information separate from the cycle vector data. The second flag (-scan) is optional. If there is no scan data in the input files, then this flag does nothing and could hence be left out. If the input WGL or STIL vector files do contain scan data, then this flag instructs the reader to maintain this scan data as separate data structures, to be passed to the Teradyne-formatted vectors as scan data. In general, this is a desirable thing to do since the resulting vector files are usually significantly smaller using scan syntax than without it. If, however, the user wishes the scan data contained in the input WGL or STIL files to be expanded into normal sequential vectors in the Teradyne test vector files, then this flag can be omitted. It is normally recommended that both of these flags be used.

The PROC_BLOCK

The PROC_BLOCK commands required for translating WGL or STIL files to Teradyne tester files will depend primarily on which input file format is being read. If we are mapping WGL state characters to those needed for Teradyne Catalyst, J750, J971 or J973, then the only mapping required would be:

PROC_BLOCK

   BEGIN

   STATE_TRANS pure_inputs '-'->'0', 'X'->'0';

   STATE_TRANS bidir_inputs '-'->'X';

   STATE_TRANS outputs '0'->'L', '1'->'H',

                       '-'->'X', 'Z'->'X';

   END

This state mapping is suggested. It accomplishes two things - first it maps WGL state characters to their equivalent Teradyne characters, and second it maps any undefined states on input pins to logic 0 (to avoid any floating inputs). The user may wish to modify these to achieve some other desired behavior. On the other hand, mapping the state characters from a STIL file takes a bit more work:

PROC_BLOCK

    BEGIN

  STATE_TRANS pure_inputs 'U'->'1', 'D'->'0', '?'->'0';

  STATE_TRANS bidir_inputs 'U'->'1', 'D'->'0', '?'->'X';

  STATE_TRANS outputs 'T'->'X', 'x'->'X','l'->'L',

      'h'->'H', 't'->'X', 'R'->'L', 'G'->'H',

      'Q'->'X', '?'->'X';

  END

Here we need to be careful about how we map the numerous state characters in a STIL file to those used by the Teradyne testers. Again, this is only a suggested mapping, the user may want to modify this for different behavior. In general, Teradyne testers recognize the following state characters:

0 Force Low

1 Force High

L Compare Low

H Compare High

M Compare Midband

X Don't care (drive tri-state, compare disabled)

The TVF_BLOCK

There is really only one command required in the TVF_BLOCK of the vtran command file for the generation of a Teradyne Catalyst, J750, J971 or J973 vector file. This is the TESTER_FORMAT (or SIMULATOR) command, which specifies the target vector file format. The syntax for this command (and the optional [ ] parameters) is:

  TESTER_FORMAT Teradyne



  [, -CATALYST | -J750 | -J971 | -J973]

  [, -USE_TSET_NAMES]               { J750 only }

  [, -AUTO_GROUP]

  [, TERMINATE = "HALT"]

  [, SCANIN_DEFAULT = "0"]

  [, WR_TIMESET_FILE = "filename"]  { Catalyst only }

  [, -ENCAPSULATE_TIMING]

  [, MAX_SCAN_GROUP_SIZE = "nnn"]   { Catalyst only }

  [, MAX_LINE_LENGTH = "nn"]

  [, TIME_STAMPS = "ON" | "OFF"]

  [, REPEAT_THRESHOLD = "nn"]       { J971/J973 only }

  [, PATTERN_NAME = "name"]         { J971/J973 only }

  [, SOURCE_SELECT_GROUP = "name"]  { J971/J973 only }

  ;

Here, the | symbol indicates "or" - one of several possible selections can be used. Use the -CATALYST, -J750, -J971, -J973 flag to specify which Teradyne tester format is being targeted. In the J750 format, the -USE_TSET_NAMES switch will cause the name of each timeset (as defined in the WGL or STIL file) to be used in the $tset field instead of an index (the default). The optional -AUTO_GROUP will cause the signals to be algorithmically grouped in the vector file for ease of viewing. When padding unequal length scan chains, the default pad character is '0', but this can be modified with the SCANIN_DEFAULT parameter. Pin timing sets will only be created for the Catalyst format if the WR_TIMESET_FILE parameter is specified with a file name. The pin timing in this file is expressed in terms that are relative to the CYCLE time (period) of the vectors. The interface supports multiple timesets. When generating this timing file, the -ENCAPSULATE_TIMING flag causes the timing in the file to be encapsulated in a C function (useful for some tools which use this information). The current J750, J971 and J973 interfaces do not generate pin timing information, although they will use pin timeset names in the output vector file, if defined in the input file.

For scan chains, all chains are grouped into a single scan_template in the Catalyst format and are defined with scan lengths equal to the longest chain. During scan operations, scan chains that are shorter get padded appropriately. For a large scan chain, scan data must be broken into groups in the Catalyst vector file. The MAX_SCAN_GROUP_SIZE parameter can be used to specify the maximum size of these scan groups with the default being set to 500 cells. The Teradyne vector formats allow a vector or scan data line to have newlines (\n) inserted at any point. The MAX_LINE_LENGTH parameter can be used to specify how many characters per line to use in the output file - the default is 99999. Finally, vtran will normally place a comment in the end of each vector line that indicates the time stamp for this vector. This feature can be disabled with the TIME_STAMPS = "OFF" parameter (the default is "ON").

For the J971/J973 formats, scan-in and scan-out pins are forced to 0 & L respectively in the scan setup vector. Also, this format generates up to 3 files: the vector file, a pin file and (if scan is present) a scan file. When specifying the TARGET_FILE name for this interface, specify a root name - e.g. "Pattern1". The interface will then automatically create the 3 files as "Pattern1.lvmadr", "Pattern1.pinadr" and "Pattern1.scanadr". The REPEAT_THRESHOLD, PATTERN_NAME and SOURCE_SELECT_GROUP parameters apply only to the J971 and J973 tester interface.

The TERMINATE command can optionally be used to add a microcode at the beginning of the last vector line - this would usually be HALT.

Some Examples

This first example illustrates the translation of a WGL file to Teradyne Catalyst vector file. This WGL file happens to contain some scan vector data. Busses in the WGL file are also present which use the bus notation [n:m] for subscripts. Here we are using the RENAME_BUS_PINS command to change these names to legal Catalyst names. For example "iobus[5]" will become "iobus_5" in the Catalyst file.

ovf_block

  begin;

  orig_file "s0.wgl";

  tabular_format  wgl -CYCLE, -SCAN;

end;

PROC_BLOCK

  BEGIN

   STATE_TRANS pure_inputs '-'->'0', 'X'->'0';

   STATE_TRANS bidir_inputs '-'->'X';

   STATE_TRANS outputs '0'->'L', '1'->'H',

                       '-'->'X', 'Z'->'X';

  END

tvf_block

  begin;

  rename_bus_pins $bus_$vec; { flatten busses }

  tester_format Teradyne,

    -Catalyst,

    -auto_group,

    ;

  target_file "s0.tp";

end;

This next example illustrates the translation of a STIL vector file with scan data, to a J973 tester format. As indicated above, the state translations are a bit more complicated since there are more potential states in the STIL file. Also we are limiting each line to 64 characters in length to make the file more easily readable and printable. In the vector file, anytime vtran detects more than 24 consecutive identical vectors, it will used the "repeat" code to compact the vectors. For the scan pins, the source group name used is defined as "prim_src". Finally, the last vector in the vector set generated will have am "op (stop)" code in front of it.

ovf_block

  begin

  tabular_format stil -cycle -scan;

  orig_file = "s6.stil" ;

  end;

proc_block

  begin

  state_trans pure_inputs 'D'->'0', 'U'->'1', '?'->'0';

  state_trans bidir_inputs 'D'->'0', 'U'->'1', '?'->'X';

  state_trans outputs 'T'->'X', 'x'->'X', '1'->'H',

    '0'->'L', 'l'->'L', 'h'->'H', 't'->'X', 'R'->'L',

    'G'->'H', 'Q'->'X', '?'->'X';

  end;

tvf_block

  tester_format teradyne

    -J7973,

    -AUTO_GROUP,

    REPEAT_THRESHOLD = "24",

    SOURCE_SELECT_GROUP = "prim_src",

    MAX_LINE_LENGTH = "64",

    TIME_STAMPS = "OFF"

    TERMINATE = "stop",

    ;

  target_file = "s6.tp";

  end;

end;

Product Support

Customer Quotes

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