Simulate Translate Test

Translating Print-on-Change FSDB Vectors to Cycle-Based Vectors for Testers

This Application Note focuses on the translation of print-on-change (or event-driven) vectors from Novas' FSDB format to cycle-based vector formats used by testers such as Credence, Teradyne and HP. The vectors include both input stimulus and expected output data. This entire translation process is performed under tight user-control. The print-on-change vectors would normally come directly from a logic simulation. However, the FSDB file also can be created with the Novas vfast utility.

FSDB Overview

Novas FSDB is a binary file format. The FSDB file provides a binary representation of several simulation data formats, including Verilog VCD and EVCD, and VHDL. The Vtran FSDB Reader supports FSDB files that are VCD and EVCD types.

Because the input file is a binary format, two command-line options are defined for the FSDB Reader, to extract information for the Vtran user. One option prints the type of the FSDB file. The other option prints the signals and signal directions.

To determine the type of the FSDB file, invoke Vtran with the following command line:

vtran -t novas_fsdb filename

where "filename" is the name of the FSDB file.

This will print one of the following messages:

    FSDB file filename type VCD
       Or
    FSDB file filename type EVCD
       Or
    FSDB file filename type unsupported

To obtain a listing of signal names and directions, invoke Vtran with the following command line:

    vtran -pins novas_fsdb filename

Again, "filename" is the name of the FSDB file. The output of this command can be captured by redirecting the output from stdout to a user-defined file name.

VTRAN® Overview

Vtran contains a number of features that simplify the task of generating test program files from simulation data files. First of all, vtran's reader technology enables it to read almost any simulation data file. Vtran includes canned readers for many print-on-change file formats. These formats typically have state data and time entries in the vector file every time there is a state change on any pin. One can consider these as flat or time-expanded vectors. Whereas in a Cycle-based vector format, there is only a single vector entry for each cycle (assuming a synchronous system), print-on-change vectors typically have numerous vector entries for each cycle indicating the time-positioning of all of the transition edges for signals in the file throughout the simulation run. See the Vtran User's Guide, Section 1.2.2 for more discussion on these differences.

The 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 Novas FSDB 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 include such functions as how to map state characters between the two formats, dealing with bi-directional data, collapsing the print-on-change data to cycle-based data and perhaps some desired signal masking. For most of the print-on-change formats, there is often some significant processing that needs to be done so the OVF_BLOCK and PROC_BLOCK can require a little effort. Finally, the TVF_BLOCK contains commands that specify the desired output format - in this case it would be one of the tester program formats (or perhaps WGL or STIL). 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 a vtran canned reader to read a Novas FSDB file, there are essentially two pieces of information needed by vtran in the OVF_BLOCK to read the data. The first would be a "SCRIPT_FORMAT" command, which defines the actual format of the vector data to be read. When specifying the format with this command, there are three options available:

    SCRIPT_FORMAT novas_fsdb;
       Or
    SCRIPT_FORMAT novas_fsdb_f;
       Or
    SCRIPT_FORMAT novas_fsdb_fq;

The difference between the first two options has to do with the signal name hierarchy contained in the FSDB file. If the novas_fsdb option is used, then all of the hierarchy is removed from the signal names, whereas if the novas_fsdb_f option is used then the module hierarchy is maintained as part of the name. For example, using the first option a signal might be named "dlatcha", whereas using the second option it might be named "top.ram_module.dlatcha". In general, it is usually easier to use the novas_fsdb option so this is preferred. However, if the low-level signal names in the FSDB file are used in more than one place - say in different instantiations of the same module in the design, then it may be necessary to use the novas_fsdb_f option and refer to signals with their full hierarchical name to distinguish one from the other. The difference between the second and third options is that, with the novas_fsdb_fq option, signals with duplicate IDs are omitted from the output. That is, if the ID of a signal matches the ID of a previously-defined signal, then the later signal is not included in the Target Vector File.

The second set of information needed in the OVF_BLOCK for standard Novas FSDB files is the names and directions of the signals you wish to have read from the file. Often times, FSDB files will contain vector information for many more signals than just those that you wish to have read and translated. Therefore, it is necessary to specify those in which you are interested. In addition, information on the direction of signals (input, output or bi-directional) is required for the translation, and in the process of specifying the signals you wish to have read and translated, the signal directions also get specified. The OVF_BLOCK commands necessary to accomplish this are the INPUTS, OUTPUTS and BIDIRECTS commands. Now, with these two sets of information, the OVF_BLOCK may look something like:

OVF_BLOCK
    BEGIN
    SCRIPT_FORMAT novas_fsdb;
    INPUTS pin1, pin2, pin3, clka, clkb, dbus[31:0];
    OUTPUTS opbus[7:0], ackn, red;
    BIDIRECTS iobus[15:0];
    INPUTS ioctrl;
    ORIG_FILE = "filename";
    END

The INPUTS, OUTPUTS and BIDIRECTS commands can be used in any order and as many times as desired to specify all of the signals you wish to have read from the FSDB file. The ORIG_FILE command is not required if the input file name is specified from the command line when invoking vtran. For comparison, if we need to use the full path names option (novas_fsdb_f), then this might look like:

OVF_BLOCK
    BEGIN
    SCRIPT_FORMAT novas_fsdb_f;
    INPUTS top.module1.pin1, top.module1.pin2,
       top.module1.pin3, top.module1.clka,
          top.module1.clkb, top.module1.dbus[31:0];
    OUTPUTS top.module1.opbus[7:0], top.module1.ackn,
       top.module1.red;
    BIDIRECTS top.module1.iobus[15:0];
    INPUTS top.module1.ioctrl;
    ORIG_FILE = "filename";
    END

Note that in this case, the full hierarchical names must be used throughout the command file. This hierarchy could then be removed in the output file using the global string replacement version of the ALIAS command in the TVF_BLOCK to replace the hierarchy string with NULL:

ALIAS "top.module." = "";

The PROC_BLOCK

The PROC_BLOCK commands required will depend, to a large degree, on the details of the translation. When reading a standard print-on-change FDSB file, the following processes are typically required to translate the vector data into any cycle-based format. These processes are described in the order in which they occur in the vtran translation flow - see the Vtran User's Guide, Section 6.2 for more details on the processing flow:

CYCLE          { define cycle time in FSDB file }
ALIGN_TO_CYCLE { collapse print-on-change to cycle-based }
BIDIRECT_CONTROL  { separate bi-directional data}
PINTYPE          { specify timing - optional }
STATE_TRANS     { translate some state characters }

As mentioned earlier, the translations being described here involve reading a print-on-change vector file (Novas FSDB) and producing an equivalent cycle-based file (WGL or STIL or tester formats). In order to accomplish this, vtran must first be told what the cycle time is for the circuit - here we are assuming a synchronous system. This is done with the CYCLE statement, for example the following statement defines a cycle time of 125 ns.

CYCLE = 125;

Next, since vtran will be producing a single vector, with a single state for each pin, for every machine cycle, we must tell vtran where within each cycle to sample the input (FSDB) vector data to determine these values. This can be accomplished with any one of several processes - ALIGN_TO_STEP, ALIGN_TO_CYCLE, or ALIGN_TO_SIGNAL. Probably the most common one used is the ALIGN_TO_CYCLE process so it will be used here for discussion (see the Vtran User's Guide for a description of the others). ALIGN_TO_CYCLE allows us to specify any number of sample points for different signals, for example:

ALIGN_TO_CYCLE 125 pure_inputs @ 25, bidir_inputs @ 45,
                    clk @ 75, all_outputs @ 110;

Here we are using the some keywords for pre-defined signal groups (pure_inputs, bidir_inputs and all_outputs) in specifying the sample times. Although the clk signal is included in the pure_inputs group, its sample time will be 75 since this is the last one specified. We could also just list specific signals with sample times such as:

ALIGN_TO_CYCLE 125 inp1, inp2, inp3, inp4, ctl @ 25,
                    bi1, bi2, bi3, bi4 @ 45,
                    clk @ 75,
                    out1, ou2, ou3, ou4, ou5,
                    bi1.O, bi2.O, bi3.O, bi4.O @ 110;

Note here that the bi-directional signals bi1 - bi4 have their input states sampled at 45 and their output states (.O) at 110 along with the rest of the outputs. In either case, the idea is to sample the state for each signal at a time in the cycle when it is stable (or for a clock, when it is active). Following the ALIGN_TO_CYCLE process the print-on-change data in the FSDB file has now been collapsed to cycle-based vectors.

The next process that gets applied to the FSDB data separates the input data from the output data on bi-directional signals in the FSDB file. For FSDB files, 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. Therefore, it is necessary to use a vtran process like BIDIRECT_CONTROL 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:

BIDIRECT_CONTROL bi1, bi2, bi3, bi4 = INPUT when ctl = 0;

Here we specify that the state data on the bi-directional signals bi1 - bi4 in the FSDB file should be interpreted as input data when the control signal ctl is a logic 0. This, by default, implies it is output state data if ctl is not a logic 0 (is a logic 1). All bi-directional signals in the FSDB file need to have their data directions specified in a manner similar to this. Multiple BIDIRECT_CONTROL statements can be used (up to one for each bi-directional pin if needed).

The PINTYPE processes provide a way of specifying the desired timing for all signals in the output vector file. For cycle-based formats, like tester formats and WGL and STIL, the timing information is contained in a separate section of the output file. An example of using PINTYPEs for this would be:

PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;
PINTYPE rz clk @ 50, 100;
PINTYPE nrz bidir_inputs @ 40;
PINTYPE stb all_outputs @ 110;

See the Vtran User's Guide, Appendix A for more information on using PINTYPE commands.

In a standard FSDB file, the state characters corresponding to value changes are 1, 0, X, Z. The state character set used by the target tester will depend somewhat on the specific tester, but a typical set (say for a Credence tester) would be 1, 0, H, L, X, Z. We may also want to map the Z state on outputs to an X so the checking is masked, and perhaps any X states on pure inputs to a valid 1 or 0 state. The state mappings required for the above example can be accomplished with:

STATE_TRANS inputs 'X'->'1';
STATE_TRANS outputs '1'->'H', '0'->'L', 'Z'->'X';

With the commands described above, we can now put together a complete PROC_BLOCK for translating a standard Novas FSDB file to a (for example) Credence tester.

PROC_BLOCK
  BEGIN
  CYCLE 125;
  ALIGN_TO_CYCLE 125 pure_inputs @ 25, bidir_inputs @ 45,
        clk @ 75, all_outputs @ 110;
  PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;
  PINTYPE rz clk @ 50, 100;
  PINTYPE nrz bidir_inputs @ 40;
  PINTYPE stb all_outputs @ 110;
  STATE_TRANS inputs 'X'->'1';
  STATE_TRANS outputs '1'->'H', '0'->'L', 'Z'->'X';
  END;

THE TVF_BLOCK for Device Tester

There is really only one command required in the TVF_BLOCK of the vtran command file for the generation of a test program or WGL or STIL file. This is the TESTER_FORMAT (or SIMULATOR for WGL) command, which specifies the target vector file format. In order to specify one of the tester formats or WGL or STIL for the output file, use one of the following options:

SIMULATOR WGL [params];
TESTER_FORMAT STIL [params];
TESTER_FORMAT SWAV [params];
TESTER_FORMAT Teradyne [params];
TESTER_FORMAT HP83000 [params];

For each output format , there are a number of optional parameters [params] which can be specified to enable the user to customize the chosen format. An example of these options for the Credence tester output format would be:

TESTER_FORMAT SWAV
      [, VERSION = "version string"]
      [, DESTINATION = "tester"]     {the tester name }
      [, SCANIN_DEFAULT = "state"]   
      [, BIDIRECTS = "bidir1"]
      [, DESIGN = "name"]            {used in header }
      [, DATE = "date"]
      [, SOURCE = "name"]            {name of source }
      [, DESIGNER = "name"]          {name of designer }
      [, TIMESCALE = "ns"]
      [, SIGNAL_FILE = "filename"]
      [, TIMESET_FILE = "filename"]
      [, MAX_LINE_LENGTH = "nn"] {default, 80 characters }
     [, REPEAT_THRESHOLD = "nn"]
     [, TIME_STAMPS = "ON" | "OFF"]
      ;

See the VTRAN® User's Guide and the READMEn.m file for more information on these optional parameters, any new parameters, and their use.

In addition to the TESTER_FORMAT (SIMULATOR) command, with the optional parameters for the specific formats, there are a number of other commands which can be used in the TVF_BLOCK to further customize output file. These include ALIAS, DELETE_PINS, RENAME_BUS_PINS, RESOLUTION, and others. See the Vtran User's Guide for more information on these. The following is a sample TVF_BLOCK for generating an HP93000 test program:

TVF_BLOCK
  begin
  RENAME_BUS_PINS $bus_$vec;
  TESTER_FORMAT HP93000
     -AUTO_GROUP,
     DVC_FILE = "s6.tms",
     MAX_LINE_LENGTH = "64",
     TIME_STAMPS = "OFF"
     ;
  TARGET_FILE = "s6.hp93";
  end;

Example

The following is an example of a vtran command file for translating a standard Novas FSDB file into a Teradyne J973 test program:

OVF_BLOCK
    BEGIN
    SCRIPT_FORMAT novas_fsdb ;
    INPUTS pin1, pin2, pin3, clka, clkb, dbus[31:0];
    OUTPUTS opbus[7:0], ackn, red;
    BIDIRECTS iobus[15:0];
    INPUTS ioctrl;
    ORIG_FILE = "filename.vcd.fsdb";
    END
PROC_BLOCK
  BEGIN
  CYCLE 125;
  STATE_TRANS inputs 'X'->'1';
  STATE_TRANS outputs '1'->'H', '0'->'L', 'Z'->'M';
  BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;
  ALIGN_TO_CYCLE 125 pure_inputs @ 25, bidir_inputs @ 45,
        clka, clkb @ 75, all_outputs @ 110;
  PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;
  PINTYPE rz clka, clkb @ 50, 100;
  PINTYPE nrz bidir_inputs @ 40;
  PINTYPE stb all_outputs @ 110;
  END
TVF_BLOCK
  BEGIN
  TARGET_FILE = "filename.hp";
  RENAME_BUS_PINS $bus$vec;     { flatten busses }
  tester_format Teradyne,
     -J973,
     -auto_group,
     pattern_name = "bar1_set",
     max_line_length = "80",
     repeat_threshold = "8",
     ;
  END
END

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