Simulate Translate Test

Print-on-change to Cycle-based Translations

POC formats such as Verilog VCD, Mentor's LSIM, TSSI's TDS or VSS WIF 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. Cycle-based format used by testers such as Credence, Teradyne and HP, however, use a single vector to combine all the state transitions that occur in a given time period or cycle. Cyclization is the process of collapsing the event driven vector data from print-on-chage (POC) formats to cycle based formats. Depending on the waveform shapes described in the POC file, this process can be quite difficult. Fortunately, VTRAN® supports multiple cyclization flows and and can be used with POC files that have both single and multiple timesets. Here, timeset refers to a set of signal behaviors and an associated period. Multiple timeset POC file flows, use the TEMPLATE_CYCLIZATION feature of VTRAN. This flow is described in detail in a separate Application Note titled "Vtran Template Cyclization Feature". This document focuses on the single timeset POC file application.

Overview

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 to perform on the simulation data during translation. This typically includes such functions as how to map state characters between the two formats, bi-directional data control, signal masking, and cyclization commands. Finally, the TVF_BLOCK contains commands that specify the desired output format and optional reporting parameters.

The OVF_BLOCK

When using a VTRAN® canned reader to read a POC file like Verilog EVCD only the format information is really needed in the OVF_BLOCK. OVF files like Verilog VCD files also require pin declarations.

The "SCRIPT_FORMAT" command, 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.

When the OVF is a Verilog VCD file or any print-on-change file that does not allow VTRAN® to automatically determine signal direction, a declaration of the names and directions of the signals is required. Often times, VCD files will contain vector information for many more signals than just those that you wish to have read and translated. It is only necessary to specify those in which you are interested. The OVF_BLOCK commands necessary to accomplish this are the INPUTS, OUTPUTS and BIDIRECTS commands. With these two sets of information, the OVF_BLOCK may look something like:

          OVF_BLOCK

             BEGIN

             SCRIPT_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

           SCRIPT_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 ORIG_FILE command specifies the name of the input vector file. It is not required if the input file name is specified from the command line when invoking VTRAN.

It may be convenient to have VTRAN® extract the pin names from the OVF file for the use of generating pin lists.

        VTRAN® -pins verilog_vcd sim.log > pins.log

would place the names of all the pins in the simulation vector file 'sim.log in a file called pins.log

The PROC_BLOCK

The PROC_BLOCK commands specify the details of the translation. In the case of print-on-change to cycle-based translations, this generally includes cyclization commands, state mapping commands, and direction control commands (for use with OVF files that require pin declarations only).

Cyclization Commands

The cyclization commands tell VTRAN® how many print-on-change vectors should be collapsed into a cycle vector, how to gather meaningful state data, and target timing. There are several distinct approaches available within VTRAN® for use in the single timeset POC cyclization flow. Each of these approaches use some combination of the following commands: CYCLE, ALIGN_TO_CYCLE, ALIGN_TO_STEP, ALIGN_TO_SIGNAL, AUTO_ALIGN, and PINTYPE.

Approach 1: ALIGN_TO_CYCLE, CYCLE, PINTYPE

In this approach, the ALIGN_TO_CYCLE command tells VTRAN® the number of print-on-change vectors associated with each cycle-based vector in terms of time. It also tells VTRAN® where it should look for state data. ALIGN_TO_CYCLE allows you to specify a separate (possibly different) sample time in the cycle for each signal.

        

        ALIGN_TO_CYCLE [-warnings] 

                         @ 

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 pinlists. 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;

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). The optional -warnings parameter causes VTRAN® to issue a warning when a pin is not behaving as expected. An example might be when VTRAN® is directed to strobe an output @ 90 and VTRAN® detects a transition on this pin at 95. A VTRAN® command file may contain at most one ALIGN_TO_CYCLE command statement. If a signal is not specified with a sample time in the ALIGN_TO_CYCLE statement, it will be sampled at time 0 in the cycle.

Note that 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 "signal.O". In the example, bi1 - bi4 have their input states sampled at 45 and their output states (.O) at 110. The input is assigned a Z state when the pin direction is determined to be output. Similarly, the output is assigned an X state when the pin direction is determined to be input.

At the completion ofthe ALIGN_TO_CYCLE process, the print-on-change data in the OVF file has now been collapsed to cycle-based vectors. Timing which is to appear in the TVF (output file) is specified separately using CYCLE and PINTYPE commands. The timing specified by the user in these statements should reflect the device test specifications. This timing may be different than the timing from the OVF input file.

        CYCLE 

For example:

        CYCLE 100;

        PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;

        PINTYPE rz clk @ 50, 75;

        PINTYPE nrz bidir_inputs @ 40;

        PINTYPE stb all_outputs @ 90;

Notice two timings are associated with each bi-directional signal. One for the input side and one for the ouptut side. PINTYPE formats include NRZ, NRZ2, RZ, RZI, RZ2X, RO, RO2X, RC, SBC, RX, and STB. The absence of PINTYPE commands for a given signal results in a default timing assignment in the TVF.

Approach 2: ALIGN_TO_STEP, CYCLE, PINTYPE

ALIGN_TO_STEP is essentially a subset of the ALIGN_TO_CYCLE process, except that it samples all signals in the OVF file at a single fixed time (step) within each cycle. Like ALIGN_TO_CYCLE command, it should be used with the CYCLE and PINTYPE commands during the POC to cycle-based vector translation.

        ALIGN_TO_STEP [-warnings]  ;

Example:

        ALIGN TO_STEP 125 30;

        CYCLE 100;

        PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;

        PINTYPE rz clk @ 50, 75;

        PINTYPE nrz bidir_inputs @ 40;

        PINTYPE stb all_outputs @ 90;

Approach 3: AUTO_ALIGN, CYCLE, PINTYPE

This approach works well when the goal is to exactly (or nearly exactly) replicate the timing found in the input file with that to appear in the output file. In the case of the AUTO_ALIGN command, the user simply specifies the PINTYPE statements to describe the desired timing and waveforms in the output file and then VTRAN® automatically calculates the correct sample for each signal in the input POC file.

Example:

        AUTO_ALIGN;

        CYCLE 100;

        PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;

        PINTYPE rz clk @ 50, 75;

        PINTYPE nrz bidir_inputs @ 40;

        PINTYPE stb all_outputs @ 90 98;

Unlike the previous approaches, AUTO_ALIGN applies the value specified by the CYCLE command to the OVF. In this example, signal clk is sampled at 50ns into each 100ns cycle. The target timing for this signal is a parameterized Return to Zero shape with postive and negative going edges at 50 and 75 ns respectively. Signals in the all_outputs signal group, are sampled the at midpoint between the 2 timing entries specified on the PINTYPE stb entry and a window strobe is created in the target timing.

Approach 4: ALIGN_TO_SIGNAL, CYCLE, PINTYPE

ALIGN_TO_SIGNAL tells VTRAN® the number of print-on-change vectors associated with each cycle-based vector in terms of a transition on a reference signal. State data for each signal is collected relative to this transition. Like ALIGN_TO_CYCLE, ALIGN_TO_SIGNAL allows you to specify a separate (possibly different) sample time in the cycle for each signal.

          ALIGN_TO_SIGNAL clk D->U pure_inputs @ 25, bidir_inputs @ 45,

                             clk @ 75, all_outputs @ 110;

          CYCLE 100;

          PINTYPE nrz inp1, inp2, inp3, inp4 @ 20;

          PINTYPE rz clk @ 50, 75;

          PINTYPE nrz bidir_inputs @ 40;

          PINTYPE stb all_outputs @ 90 98;

In this example, cycle are delineated by the positive going edge transition on the clk signal and samples are collected at offsets relative to this event. TVF timing is specified by the CYCLE and PINTYPE statements.

Bidirectional Pin Control

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).

If the OVF format contains information such that the VTRAN® reader can make a determination when data on a bidirectional pin represents an input state or an output state, BIDIRECT_CONTROL statement are not needed. Verilog EVCD is an example of this type of format.

State Mapping

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:

        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';

Important: Commands like ALIGN_TO_SIGNAL, BIDIRECT_CONTROL and MASK_PINS use the states directly from the OVF input file for logic expressions (i.e. before STATE_TRANS is applied). See the Vtran User's Guide, Section 6.2 for more details on the processing flow.

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:

        SIMULATOR WGL [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 which provide the user to customize to 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 char }

             [, 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, CREATE_STATISTICS, 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 1

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

             SCRIPT_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 pin1, pin2, pin3, pin4 @ 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

Example 2

In this example, a similar Verilog EVCD file is also translated into a Teradyne J973 test program. See that when the OVF contains information such that the VTRAN® reader can determine pin direction as is the case with the Verilog EVCD format, it is not necessary to provide VTRANS with signal direction data.

        OVF_BLOCK

           BEGIN

           SCRIPT_FORMAT Verilog_vcd ;

           ORIG_FILE = "filename.evcd";

           END

        PROC_BLOCK

          BEGIN

          CYCLE 125;

         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'->'L', 'H'->'H', 'l'->'L', 'h'->'H', 'T'->'Z', 'x'->'X',

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

          '?'->'X', 'A'->'H', 'a'->'X', 'B'->'L', 'b'->'X', 'C'->'L',

          'c'->'H', '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',

          'c'->'X';

         STATE_TRANS bidir_outputs

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

          '?'->'X', 'A'->'H', 'a'->'X', 'B'->'L', 'b'->'X', 'C'->'L',

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

          ALIGN_TO_CYCLE 125 pure_inputs @ 25, bidir_inputs @ 45,

                clka, clkb @ 75, all_outputs @ 110;

          PINTYPE nrz pin1, pin2, pin3, pin4 @ 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