Application Notes > Print-on-change to Cycle-based Translations

Application Notes:
Print-on-change to Cycle-based Translations

SYNOPSIS
This Application Note focuses on the translation of print-on-change (or event-driven) vectors from formats such as Verilog VCD, Mentor’s LSIM, TSSI’s TDS or VSS WIF 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.  This Application Note will emphasize issues relevant primarily to translating Verilog VCD files due to their popularity.  However, translating other print-on-change files will typically require similar strategies and processing.

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, including all of those mentioned above.  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 Verilog VCD 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 these 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).  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 Verilog VCD 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 two options available:  

   SCRIPT_FORMAT Verilog_vcd;
      Or
   SCRIPT_FORMAT Verilog_vcd_f;

The difference between these two options has to do with the signal name hierarchy contained in the VCD file.  If the Verilog_vcd option is used, then all of the hierarchy is removed from the signal names, whereas if the Verilog_vcd_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 Verilog_vcd option so this is preferred.  However, if the low-level signal names in the VCD 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 Verilog_vcd_f option and refer to signals with their full hierarchical name to distinguish one from the other.

The second set of information needed in the OVF_BLOCK for standard Verilog VCD files is the names and directions of the signals you wish to have read from the file.  Often times, VCD 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
   TABULAR_FORMAT Verilog_vcd;
   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 VCD 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 (Verilog_vcd_f), then this might look like:

OVF_BLOCK
   BEGIN
   TABULAR_FORMAT Verilog_vcd_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 VCD 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 vcd 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 (Verilog VCD) and producing an equivalent cycle-based file (wgl 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 (VCD) 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 VCD file has now been collapsed to cycle-based vectors.

The next process that gets applied to the VCD data separates the input data from the output data on bi-directional signals in the VCD file.   For VCD 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 VCD 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 VCD 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, 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 VCD file, the state characters are 1, 0, X, Z, 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:

With the commands described above, we can now put together a complete PROC_BLOCK for translating a standard Verilog VCD 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', 'X'->'1';
 STATE_TRANS bidir_inputs 'z'->'Z';
 STATE_TRANS outputs '1'->'H', '0'->'L', 'z'->'X', 'Z'->'X',
                      'x'->'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 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 for the output file, use one of the following options:

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

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 Verilog VCD file into a Teradyne J973 test program:

OVF_BLOCK
   BEGIN
   TABULAR_FORMAT Verilog_vcd ;
   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";
   END
PROC_BLOCK
  BEGIN
  CYCLE 125;
  STATE_TRANS inputs 'x'->'1', 'X'->'1';
  STATE_TRANS bidir_inputs 'z'->'Z';
  STATE_TRANS outputs '1'->'H', '0'->'L', 'z'->'M',
     'Z'->'M','x'->'X';
  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

Return to Application Notes Index