Simulate Translate Test

Translating Print-on-Change Vectors to a Verilog or VHDL Testbench

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 a Verilog or VHDL Testbench file using vtran, which can then be compiled and simulated on a Verilog or VHDL simulator. The Testbench includes both input stimulus and processes to check simulation output data against expected data - reporting any errors detected. 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 enhance the task of generating Verilog/VHDL testbench files from other 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 would be 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, or 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 can be Verilog_tb, Verilog_tb_readmem, VHDL_tb, or VHDL_tb_tio. 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 would 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 translatin, 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.

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 a Verilog or VHDL testbench:

        STATE_TRANS { translate some state characters }

        BIDIRECT_CONTROL { separate bi-directional data }

        CYCLE { define cycle time in vcd file }

        CHECK_WINDOW { specify window for output checking }

In a standard VCD file, the state characters are 1, 0, X, Z, x, z. For a VHDL testbench the lower-case states may need to be translated into upper-case. Also, we may want to map the Z state on outputs to an X so the checking is masked. These can be accomplished with:

        STATE_TRANS 'x'->'X', z'->'Z';

        STATE_TRANS outputs 'Z'->'X';

For standard VCD files, the state information for bi-directional pins looks identical for both driving and sensing cases (i.e. there is no way to tell from the state data if it is input data or output data). Since we need to be able to distinguish these two cases for the testbench, the BIDIRECT_CONTROL command must be used to determine the direction of this bi-directional data. Normally, a control pin is available to help with this. For example, in the following statement:

        BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

This tells VTRAN that the state data for the bi-directional bus iobus is input data (to be applied to the circuit) when the control signal ioctrl is in a logic 0 state. Otherwise (if ioctrl is a logic 1) the VCD data for iobus will be interpreted as output data (to be checked by the testbench during simulation). Multiple BIDIRECTIONAL_CONTROL statements can be used (up to one for each bi-directional pin if needed).

The final processing that typically needs to be done on a Verilog VCD file is to define the window(s) within each cycle where the testbench should check the output states of the simulation against the expected state data from the file. Since the VCD file is a print-on-change file, output signals typically make many spurious transitions prior to reaching their final valid state later in each cycle. In order to prevent the testbench from checking all of these unstable transient states, it is usually helpful to define a window (or windows) within each cycle for output checking, and masking the output data outside the window(s). This is accomplished with the CHECK_WINDOW command, plus a CYCLE statement to define the reference cycle time. An example of this would be:

        CYCLE 80;

        CHECK_WINDOW iobus @ 55, 56;

        CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

Here we are telling VTRAN to build the Verilog or VHDL testbench so that the bidirectional bus "iobus" has its output states checked at 55 ns into each 80 ns cycle, while the other outputs have their outputs checked at 70 ns each cycle. With these commands, we can now put together a complete PROC_BLOCK for translating a standard Verilog VCD file to a Verilog/VHDL testbench.

        PROC_BLOCK

         BEGIN

         STATE_TRANS 'x'->'X', 'z'->'Z';

         STATE_TRANS outputs 'Z'->'X';

         BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

         CYCLE 80;

         CHECK_WINDOW iobus @ 55, 56;

         CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

         END

THE TVF_BLOCK for Verilog Testbench

There is really only one command required in the TVF_BLOCK of the VTRAN command file for the generation of a Verilog testbench file. This is the SIMULATOR command, which specifies the target vector file format.

In order to translate an arbitrary simulation data file into a Verilog testbench file, use the VERILOG_TB, or VERILOG_TB_READMEM option with the SIMULATOR command in the TVF_BLOCK:

        SIMULATOR VERILOG_TB ;

or

        SIMULATOR VERILOG_TB_READMEM ;

The difference between these two Verilog testbench formats is that in the first form, all of the data for input state assignments and output state checking is contained in a single file and the testbench is implemented as a linear sequence of in-line assignments and checks. In the second (_READMEM) format, separate files hold the state data to be applied and checked, and the actual testbench file itself. Here, the testbench file is constructed as a loop which reads the state data from the external files using the $readmem operation. While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.

Both of the Verilog testbench formats can specified with a number of optional parameters that can be used to customize the final testbench file. For the VERILOG_TB output format, these optional parameters are:

        SIMULATOR verilog_tb,

          -VERBOSE,

          -INHIBIT_CHECKING,

          -VERIFAULT,

          TESTBENCH_MODULE = "Top_of_generic",

          COMPONENT_MODULE = "Component_of_generic",

          INSTANCE_NAME = "Instance_of_generic",

          TIMESCALE = "1ns/100ps",

          OUTPUT_GROUP = "pin3, pin4, .. "

          PSEUDO_SIGNAL = "pinname",

          TERMINATE_RUN = "$finish",

          ;

The INHIBIT_CHECKING flag tells vtran not to include expected output state checking in the Verilog testbench. The VERBOSE flag results in a more detailed error report when expected output data does not match simulation data. The VERIFAULT flag will produce a Verilog testbench file that can be run on Verifault. The PSEUDO_SIGNAL parameter provides for a way to identify signals in the OVF file which are not to be included in the instantiation of the component within the testbench. These signals would only be part of the testbench-level circuit, not the design component. Multiple PSEUDO_SIGNAL parameters can be used.

The default TIMESCALE for time stamps is (1) Nanoseconds, which matches the default for vtran time stamps. If more resolution is desired a combination of the vtran command SCALE and the parameter TIMESCALE should be used. For example, in order to get .1 nanosecond resolution in the VCD file, use:

        Scale = 10;

        simulator Verilog_tb, TIMESCALE = "100ps";

If the TIMESCALE parameter is missing, no timescale will be placed in the file. Vtran will place a $stop statement at the end of the testbench by default. This can be changed to $finish (or anything else desired) by using the TERMINATE_RUN parameter.

The TESTBENCH_MODULE, COMPONENT_MODULE and INSTANCE_NAME parameters allow the user to control some of the naming in the testbench. The OUTPUT_GROUP parameter provides a way for the user to control the output pin groups, which in turn affects the size of output data file. The default grouping is determined by the output strobe (sample) times specified in the input cycle-based vector files.

For the second format (VERILOG_TB_READMEM), the optional parameters are:

        SIMULATOR verilog_tb_readmem,

          -VERBOSE,

          -INHIBIT_CHECKING,

          TESTBENCH_MODULE = "Top_of_generic",

          COMPONENT_MODULE = "Component_of_generic",

          INSTANCE_NAME = "Instance_of_generic",

          TIMESCALE = "1ns/100ps",

          INPUT_GROUP = "pin1, pin2, .. "

          OUTPUT_GROUP = "pin3, pin4, .. "

          PSEUDO_SIGNAL = "pinname",

          DATAFILES = "datafilename",

          TERMINATE_RUN = "$stop",

          ;

Many of the parameters for this format are the same as for the verilog_tb format, and they perform identical functions. Additional parameters are: the DATAFILE parameter can be used to control the names of the data files that vtran generates. For a DATAFILES name of "datafilename", vtran will create state data files named datafilename0, datafilename1, datafilename2, . . . The ...0 data file contains delta times (times between events) and flags indicating which of the data files to read state data from for each event time. The ...1 file will contain state data for pure input pins, ...2 for bidir input pins and ...3 and up contain output signal expected data, grouped by their specified strobe times (CHECK_WINDOW commands in proc_block) or OUTPUT_GROUP definitions. In addition to these groupings, a user can also force specific input signals to be placed in a separate group (and hence separate data file) using the INPUT_GROUP parameter. This may be useful to help reduce overall data file sizes. For example, if the majority of event times in a set of vectors are associated with transitions of just a few clock pins, then defining these as an INPUT_GROUP would greatly reduce the size of the ...1 file (all the other input pins). Multiple INPUT_GROUP parameters can be specified.

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

THE TVF_BLOCK for VHDL Testbench

As with the Verilog testbench, there is really only one command required in the TVF_BLOCK of the vtran command file for the generation of a VHDL testbench file. This is the SIMULATOR command, which specifies the target vector file format.

In order to translate an arbitrary simulation data file into a VHDL testbench file, use the VHDL_TB, or VHDL_TB_TIO option with the SIMULATOR command in the TVF_BLOCK:

        SIMULATOR VHDL_TB ;

or

        SIMULATOR VHDL_TB_TIO ;

The difference between these two VHDL testbench formats is that in the first form, all of the data for input state assignments and output state checking is contained in a single file and the testbench is implemented as a linear sequence of in-line assignments and checks. In the second (_TIO) format, the state data to be applied and checked is placed in a file separate from the actual testbench file itself. Here, the testbench file is constructed as a loop which reads the state data from the external files using the TEXTIO operation. While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.

Both of the VHDL testbench formats can specified with a number of optional parameters that can be used to customize the final testbench file. For the VHDL_TB and VHDL_TB_TIO output formats, these optional parameters are (default values are shown):

        SIMULATOR vhdl_tb, {or SIMULATOR vhdl_tb_tio, }

            -INHIBIT_CHECKING.

            -93, {for vhdl_tb_tio only }

            LIBRARY = "NULL",

            USE = "NULL",

            UNITS = "ns",

            CONFIG_FILE = "NULL",

            CONFIG_NAME = "",

            ARCHITECTURE = "testbench",

            INSTANCE_NAME = "U0",

            ENTITY = "_tb",

            COMPONENT = "design",

            COMPONENT_ARCHITECTURE = "STRUCTURAL_VIEW",

            NINE_VALUE = "OFF",

            DONT_CARE = 'X',

            BIT_TYPE = "STD_LOGIC",

            BIT_VECTOR = "STD_LOGIC_VECTOR",

            RESULT_TYPE = "STD_LOGIC",

            RESULT_VECTOR = "STD_LOGIC_VECTOR",

            SEVERITY = "WARNING",

            LIST_ERRORS = "NULL", {vhdl_tb only }

            PSEUDO_SIGNAL = "NULL",

            MAXLINES = "nnnn", {vhdl_tb only }

            INPUT_GROUP = "NULL",

            OUTPUT_GROUP = "NULL",

            BUFFER_PORTS = "NULL",

            LINKAGE_PORTS = "NULL" ;

Multiple LIBRARY and USE parameters can be specified. These should typically specify at least the following:

        

        LIBRARY = "ieee",

        USE = "ieee.std_logic_1164.all",

        USE = "ieee.std_logic_textio.all", {vhdl_tb_tio only}

In some cases it may be desirable to build a testbench file, without actually doing the checking of expected output states - building only a stimulus file. The INHIBIT_CHECKING parameter, as in the Verilog testbench format, can be used to accomplish this in both VHDL formats. The -93 parameter can be used to force '93 compliant syntax for the declaration and opening of the textio file.

The COMPONENT, INSTANCE_NAME, ENTITY and ARCHITECTURE parameters provide control over names used in the VHDL testbench file. The COMPONENT_ARCHITECTURE parameter is used in the CONFIGURATION block.

The UNITS parameter can be used to change the time units from (the default) ns - be sure to use the SCALE command to modify the time stamps accordingly. The CONFIGURATION declaration is placed in the file specified by CONFIG_FILE. If this parameter is missing, then the declaration is placed at the bottom of the testbench file. The NINE_VALUE parameter tells vtran to check (or not check) that all states are legal IEEE states (after state_trans is applied).

The DONT_CARE parameter defines the logical state on output pins that the VHDL testbench will treat as a don't care or mask condition. This state can also, and usually should be, declared with the DONT_CARE command in the PROC_BLOCK of the command file so that masking of outputs also uses this state character. After defining this character, any output states which, in addition to this character, are to be treated as a dont_care can be mapped to this character with the STATE_TRANS command. For example, if the DONT_CARE character is defined as 'X' and we want to also ignore outputs when they are in the 'Z' state, then use:

        state_trans outputs 'Z'->'X';

There are four optional parameters related to defining the TYPE of signals, busses and results arrays. The first two (BIT_TYPE and BIT_VECTOR) are used to specify the TYPE of signals and busses in the design. The other two (RESULT_TYPE and RESULT_VECTOR) are used to specify the TYPE of the results arrays used in the testbench.

The parameter SEVERITY can be used to change the behavior of the testbench when it detects a pin whose state does not match the expected state. The testbench uses a VHDL "assertion" statement that reports the mismatch with a SEVERITY dictated by this parameter (default is WARNING). The parameter LIST_ERRORS also affects how pin state errors are handled. Normally, the vector for the entire group (BY_GROUP) is displayed with differences between expected and actual highlighted. Changing this parameter's value to BY_PIN results in the display of only those pins that mismatch, along with their expected and actual states (the LIST_ERRORS parameter is currently available only with the VHDL_TB format).

When using the VHDL_TB output format, large simulation data sets can sometimes result in a very large single process in the testbench file. For some logic simulators, this presents a problem. To get around this, the MAXLINES parameter can be used to break the long single process up into multiple smaller processes. For example:

        

        MAXLINES = "50000",

would limit the size of any given process to approximately 50,000 lines of code.

When using the VHDL_TB_TIO output format option, the main testbench file contains a single read loop for getting input stimulus, as well as expected output data from an external textio file. This testbench file also contains the output state checking and error reporting procedures. All simulation data is contained in the textio file, where it is organized in groups of pins. The primary reason for using pin groups in the textio file is to help minimize file size. By default, all pure input pins comprise a single group, while the input data for bidirectional pins comprise a second group. Output pins are grouped according to what their strobe (CHECK_WINDOW commands in proc_block) timing is. The OUTPUT_GROUP provides an alternate method of grouping output signals - for example it may be desirable to group scan output signals separately. In order to further optimize the file size of the textio file, the INPUT_GROUP parameter can be used to define additional input pin groups. Usually, this would be done for input pins that have a high degree of activity in the file - such as clock pins. An example might be:

          INPUT_GROUP = "clk1, clk2",

          INPUT_GROUP = "enb, dir_ctrl",

          OUTPUT_GROUP = "scan_out1, scan_out2",

Here we have used two INPUT_GROUP parameters to define two additional groups - the first with just the clk1 and clk2 pins, the second with enb and dir_ctrl pins. All other input pins would remain in their default groups. Likewise we have formed a group of the two output scan pins which will see a lot of activity during scan operations while other outputs are being masked.

The BUFFER_PORTS and LINKAGE_PORTS parameters can be used to define pins as buffer or linkage ports for use in the component or module instantiation. These pins must still be defined as inputs, outputs or bidirects in the OVF.

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

Some Examples

The following is an example of a vtran command file for translating a standard Verilog VCD file into a Verilog testbench:

        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

        PROC_BLOCK

          BEGIN

          STATE_TRANS 'x'->'X', 'z'->'Z';

          STATE_TRANS outputs 'Z'->'X';

          BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

          CYCLE 80;

          CHECK_WINDOW iobus @ 55, 56;

          CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

          END

        TVF_BLOCK

          BEGIN

          TARGET_FILE = tvf0;

          SIMULATOR verilog_tb, -VERBOSE,

            TESTBENCH_MODULE = "CKT_s0",

            COMPONENT_MODULE = "s0_rev1",

            TIMESCALE = "1ns/100ps";

          END

        END

Here we are using the state_trans commands to map any lowercase state characters in the VCD file to uppercase characters, and any Z states to an X (mask) for outputs.

The next example command file reads a Verilog VCD vector file and translates it to a VHDL testbench for simulation verification.

        {******************************************************}

        {*                                                    *}

        {* This VTRAN® command file will translate VCD to VHDL *}

        {*                                                    *}

        {******************************************************}

        OVF_BLOCK

           BEGIN

        orig_file = "vcd";

              SCRIPT_FORMAT verilog_vcd;

              INPUTS qavd,

               Qavs,

               avd1a,

               avs1a,

               avd2a,

               avs2a,

               avd2b,

               avs2b,

               avd2c,

               avs2c,

               xclk,

               atstb,

               iddq_en,

               bsb;

              BIDIRECTS cbi[14:0];

              OUTPUTS sclk24,

               sclk8,

               cx24[3:0],

               sclk;

              INPUTS fake_oe;

           END;

        PROC_BLOCK

        {******************************************************}

        {*                                                    *}

        {* Use this section to perform bidirect data          *}

        {* separation, to specify strobe (check) windows for  *}

        {* outputs and to do state translations.              *}

        {*                                                    *}

        {******************************************************}

            BEGIN

            cycle 250; {4 MHz cycle}

            BIDIRECT_CONTROL cbi[7:0]=input WHEN fake_oe=0;

            BIDIRECT_CONTROL cbi[14:8]=input WHEN fake_oe=1;

            check_window * @ 195, 200; { strobe all outs at 195 }

            state_trans 'x'->'X', 'z'->'Z';

            state_trans outputs 'Z'->'X'

            END;

        TVF_BLOCK

        {******************************************************}

        {*                                                    *}

        {* Define simulation configurations here. Currently   *}

        {* configured for VHDL using textio.                  *}

        {*                                                    *}

        {******************************************************}

        BEGIN

            aux_file = "one.tio";

            target_file = "one.vhd";

            SIMULATOR vhdl_tb_tio,

             -93,

             LIBRARY="IEEE",

             USE="IEEE.STD_LOGIC_1164.ALL",

             USE="IEEE.STD_LOGIC_TEXTIO.ALL",

             LIBRARY="STD",

             USE="STD.STANDARD.ALL",

             USE="STD.TEXTIO.ALL",

             BIT_TYPE="STD_LOGIC",

             BIT_VECTOR="STD_LOGIC_VECTOR",

             RESULT_TYPE="STD_LOGIC",

             CONFIG_FILE="one_cfg.vhd",

             INPUT_GROUP = "xclk, bsb";

            DELETE_PINS fake_oe; { exclude control pin from output file }

            TITLE "pm6124";

        END;

In this example, we have used the -93 flag to force VHDL '93 compliance on the textio syntax. An input group is also defined containing the clock (xclk) and other input (bsb) signals. These signals make many transitions relative to the other inputs, so placing them in a separate group will reduce the resulting textio file size. The fake_oe signal is removed from the output file since it was only an internal control signal used to determine the direction of state data on the bi-directional bus pins.

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 a Verilog or VHDL Testbench file using VTRAN, which can then be compiled and simulated on a Verilog or VHDL simulator. The Testbench includes both input stimulus and processes to check simulation output data against expected data - reporting any errors detected. 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 enhance the task of generating Verilog/VHDL testbench files from other 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 would be 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, or 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 can be Verilog_tb, Verilog_tb_readmem, VHDL_tb, or VHDL_tb_tio. 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 would 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 translatin, 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.

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 a Verilog or VHDL testbench:

        STATE_TRANS { translate some state characters }

        BIDIRECT_CONTROL { separate bi-directional data }

        CYCLE { define cycle time in vcd file }

        CHECK_WINDOW { specify window for output checking }

In a standard VCD file, the state characters are 1, 0, X, Z, x, z. For a VHDL testbench the lower-case states may need to be translated into upper-case. Also, we may want to map the Z state on outputs to an X so the checking is masked. These can be accomplished with:

        STATE_TRANS 'x'->'X', z'->'Z';

        STATE_TRANS outputs 'Z'->'X';

For standard VCD files, the state information for bi-directional pins looks identical for both driving and sensing cases (i.e. there is no way to tell from the state data if it is input data or output data). Since we need to be able to distinguish these two cases for the testbench, the BIDIRECT_CONTROL command must be used to determine the direction of this bi-directional data. Normally, a control pin is available to help with this. For example, in the following statement:

        BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

This tells VTRAN that the state data for the bi-directional bus iobus is input data (to be applied to the circuit) when the control signal ioctrl is in a logic 0 state. Otherwise (if ioctrl is a logic 1) the VCD data for iobus will be interpreted as output data (to be checked by the testbench during simulation). Multiple BIDIRECTIONAL_CONTROL statements can be used (up to one for each bi-directional pin if needed).

The final processing that typically needs to be done on a Verilog VCD file is to define the window(s) within each cycle where the testbench should check the output states of the simulation against the expected state data from the file. Since the VCD file is a print-on-change file, output signals typically make many spurious transitions prior to reaching their final valid state later in each cycle. In order to prevent the testbench from checking all of these unstable transient states, it is usually helpful to define a window (or windows) within each cycle for output checking, and masking the output data outside the window(s). This is accomplished with the CHECK_WINDOW command, plus a CYCLE statement to define the reference cycle time. An example of this would be:

        CYCLE 80;

        CHECK_WINDOW iobus @ 55, 56;

        CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

Here we are telling VTRAN to build the Verilog or VHDL testbench so that the bidirectional bus "iobus" has its output states checked at 55 ns into each 80 ns cycle, while the other outputs have their outputs checked at 70 ns each cycle. With these commands, we can now put together a complete PROC_BLOCK for translating a standard Verilog VCD file to a Verilog/VHDL testbench.

        PROC_BLOCK

         BEGIN

         STATE_TRANS 'x'->'X', 'z'->'Z';

         STATE_TRANS outputs 'Z'->'X';

         BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

         CYCLE 80;

         CHECK_WINDOW iobus @ 55, 56;

         CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

         END

THE TVF_BLOCK for Verilog Testbench

There is really only one command required in the TVF_BLOCK of the VTRAN command file for the generation of a Verilog testbench file. This is the SIMULATOR command, which specifies the target vector file format.

In order to translate an arbitrary simulation data file into a Verilog testbench file, use the VERILOG_TB, or VERILOG_TB_READMEM option with the SIMULATOR command in the TVF_BLOCK:

        SIMULATOR VERILOG_TB ;

or

        SIMULATOR VERILOG_TB_READMEM ;

The difference between these two Verilog testbench formats is that in the first form, all of the data for input state assignments and output state checking is contained in a single file and the testbench is implemented as a linear sequence of in-line assignments and checks. In the second (_READMEM) format, separate files hold the state data to be applied and checked, and the actual testbench file itself. Here, the testbench file is constructed as a loop which reads the state data from the external files using the $readmem operation. While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.

Both of the Verilog testbench formats can specified with a number of optional parameters that can be used to customize the final testbench file. For the VERILOG_TB output format, these optional parameters are:

        SIMULATOR verilog_tb,

          -VERBOSE,

          -INHIBIT_CHECKING,

          -VERIFAULT,

          TESTBENCH_MODULE = "Top_of_generic",

          COMPONENT_MODULE = "Component_of_generic",

          INSTANCE_NAME = "Instance_of_generic",

          TIMESCALE = "1ns/100ps",

          OUTPUT_GROUP = "pin3, pin4, .. "

          PSEUDO_SIGNAL = "pinname",

          TERMINATE_RUN = "$finish",

          ;

The INHIBIT_CHECKING flag tells VTRAN not to include expected output state checking in the Verilog testbench. The VERBOSE flag results in a more detailed error report when expected output data does not match simulation data. The VERIFAULT flag will produce a Verilog testbench file that can be run on Verifault. The PSEUDO_SIGNAL parameter provides for a way to identify signals in the OVF file which are not to be included in the instantiation of the component within the testbench. These signals would only be part of the testbench-level circuit, not the design component. Multiple PSEUDO_SIGNAL parameters can be used.

The default TIMESCALE for time stamps is (1) Nanoseconds, which matches the default for VTRAN time stamps. If more resolution is desired a combination of the VTRAN command SCALE and the parameter TIMESCALE should be used. For example, in order to get .1 nanosecond resolution in the VCD file, use:

        Scale = 10;

        simulator Verilog_tb, TIMESCALE = "100ps";

If the TIMESCALE parameter is missing, no timescale will be placed in the file. VTRAN will place a $stop statement at the end of the testbench by default. This can be changed to $finish (or anything else desired) by using the TERMINATE_RUN parameter.

The TESTBENCH_MODULE, COMPONENT_MODULE and INSTANCE_NAME parameters allow the user to control some of the naming in the testbench. The OUTPUT_GROUP parameter provides a way for the user to control the output pin groups, which in turn affects the size of output data file. The default grouping is determined by the output strobe (sample) times specified in the input cycle-based vector files.

For the second format (VERILOG_TB_READMEM), the optional parameters are:

        SIMULATOR verilog_tb_readmem,

          -VERBOSE,

          -INHIBIT_CHECKING,

          TESTBENCH_MODULE = "Top_of_generic",

          COMPONENT_MODULE = "Component_of_generic",

          INSTANCE_NAME = "Instance_of_generic",

          TIMESCALE = "1ns/100ps",

          INPUT_GROUP = "pin1, pin2, .. "

          OUTPUT_GROUP = "pin3, pin4, .. "

          PSEUDO_SIGNAL = "pinname",

          DATAFILES = "datafilename",

          TERMINATE_RUN = "$stop",

          ;

Many of the parameters for this format are the same as for the verilog_tb format, and they perform identical functions. Additional parameters are: the DATAFILE parameter can be used to control the names of the data files that VTRAN generates. For a DATAFILES name of "datafilename", VTRAN will create state data files named datafilename0, datafilename1, datafilename2, . . . The ...0 data file contains delta times (times between events) and flags indicating which of the data files to read state data from for each event time. The ...1 file will contain state data for pure input pins, ...2 for bidir input pins and ...3 and up contain output signal expected data, grouped by their specified strobe times (CHECK_WINDOW commands in proc_block) or OUTPUT_GROUP definitions. In addition to these groupings, a user can also force specific input signals to be placed in a separate group (and hence separate data file) using the INPUT_GROUP parameter. This may be useful to help reduce overall data file sizes. For example, if the majority of event times in a set of vectors are associated with transitions of just a few clock pins, then defining these as an INPUT_GROUP would greatly reduce the size of the ...1 file (all the other input pins). Multiple INPUT_GROUP parameters can be specified.

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

THE TVF_BLOCK for VHDL Testbench

As with the Verilog testbench, there is really only one command required in the TVF_BLOCK of the VTRAN command file for the generation of a VHDL testbench file. This is the SIMULATOR command, which specifies the target vector file format.

In order to translate an arbitrary simulation data file into a VHDL testbench file, use the VHDL_TB, or VHDL_TB_TIO option with the SIMULATOR command in the TVF_BLOCK:

        SIMULATOR VHDL_TB ;

or

        SIMULATOR VHDL_TB_TIO ;

The difference between these two VHDL testbench formats is that in the first form, all of the data for input state assignments and output state checking is contained in a single file and the testbench is implemented as a linear sequence of in-line assignments and checks. In the second (_TIO) format, the state data to be applied and checked is placed in a file separate from the actual testbench file itself. Here, the testbench file is constructed as a loop which reads the state data from the external files using the TEXTIO operation. While the two formats are logically equivalent, and will produce identical logical results, the first format will tend to have a longer compile time with perhaps shorter run time, while the second format will result in a very fast compile time (just the testbench loop) and perhaps slightly longer run time due to the necessity of reading external file data.

Both of the VHDL testbench formats can specified with a number of optional parameters that can be used to customize the final testbench file. For the VHDL_TB and VHDL_TB_TIO output formats, these optional parameters are (default values are shown):

        SIMULATOR vhdl_tb, {or SIMULATOR vhdl_tb_tio, }

            -INHIBIT_CHECKING.

            -93, {for vhdl_tb_tio only }

            LIBRARY = "NULL",

            USE = "NULL",

            UNITS = "ns",

            CONFIG_FILE = "NULL",

            CONFIG_NAME = "",

            ARCHITECTURE = "testbench",

            INSTANCE_NAME = "U0",

            ENTITY = "_tb",

            COMPONENT = "design",

            COMPONENT_ARCHITECTURE = "STRUCTURAL_VIEW",

            NINE_VALUE = "OFF",

            DONT_CARE = 'X',

            BIT_TYPE = "STD_LOGIC",

            BIT_VECTOR = "STD_LOGIC_VECTOR",

            RESULT_TYPE = "STD_LOGIC",

            RESULT_VECTOR = "STD_LOGIC_VECTOR",

            SEVERITY = "WARNING",

            LIST_ERRORS = "NULL", {vhdl_tb only }

            PSEUDO_SIGNAL = "NULL",

            MAXLINES = "nnnn", {vhdl_tb only }

            INPUT_GROUP = "NULL",

            OUTPUT_GROUP = "NULL",

            BUFFER_PORTS = "NULL",

            LINKAGE_PORTS = "NULL" ;

Multiple LIBRARY and USE parameters can be specified. These should typically specify at least the following:

       

        LIBRARY = "ieee",

        USE = "ieee.std_logic_1164.all",

        USE = "ieee.std_logic_textio.all", {vhdl_tb_tio only}

In some cases it may be desirable to build a testbench file, without actually doing the checking of expected output states - building only a stimulus file. The INHIBIT_CHECKING parameter, as in the Verilog testbench format, can be used to accomplish this in both VHDL formats. The -93 parameter can be used to force '93 compliant syntax for the declaration and opening of the textio file.

The COMPONENT, INSTANCE_NAME, ENTITY and ARCHITECTURE parameters provide control over names used in the VHDL testbench file. The COMPONENT_ARCHITECTURE parameter is used in the CONFIGURATION block.

The UNITS parameter can be used to change the time units from (the default) ns - be sure to use the SCALE command to modify the time stamps accordingly. The CONFIGURATION declaration is placed in the file specified by CONFIG_FILE. If this parameter is missing, then the declaration is placed at the bottom of the testbench file. The NINE_VALUE parameter tells VTRAN to check (or not check) that all states are legal IEEE states (after state_trans is applied).

The DONT_CARE parameter defines the logical state on output pins that the VHDL testbench will treat as a don't care or mask condition. This state can also, and usually should be, declared with the DONT_CARE command in the PROC_BLOCK of the command file so that masking of outputs also uses this state character. After defining this character, any output states which, in addition to this character, are to be treated as a dont_care can be mapped to this character with the STATE_TRANS command. For example, if the DONT_CARE character is defined as 'X' and we want to also ignore outputs when they are in the 'Z' state, then use:

        state_trans outputs 'Z'->'X';

There are four optional parameters related to defining the TYPE of signals, busses and results arrays. The first two (BIT_TYPE and BIT_VECTOR) are used to specify the TYPE of signals and busses in the design. The other two (RESULT_TYPE and RESULT_VECTOR) are used to specify the TYPE of the results arrays used in the testbench.

The parameter SEVERITY can be used to change the behavior of the testbench when it detects a pin whose state does not match the expected state. The testbench uses a VHDL "assertion" statement that reports the mismatch with a SEVERITY dictated by this parameter (default is WARNING). The parameter LIST_ERRORS also affects how pin state errors are handled. Normally, the vector for the entire group (BY_GROUP) is displayed with differences between expected and actual highlighted. Changing this parameter's value to BY_PIN results in the display of only those pins that mismatch, along with their expected and actual states (the LIST_ERRORS parameter is currently available only with the VHDL_TB format).

When using the VHDL_TB output format, large simulation data sets can sometimes result in a very large single process in the testbench file. For some logic simulators, this presents a problem. To get around this, the MAXLINES parameter can be used to break the long single process up into multiple smaller processes. For example:

       

        MAXLINES = "50000",

would limit the size of any given process to approximately 50,000 lines of code.

When using the VHDL_TB_TIO output format option, the main testbench file contains a single read loop for getting input stimulus, as well as expected output data from an external textio file. This testbench file also contains the output state checking and error reporting procedures. All simulation data is contained in the textio file, where it is organized in groups of pins. The primary reason for using pin groups in the textio file is to help minimize file size. By default, all pure input pins comprise a single group, while the input data for bidirectional pins comprise a second group. Output pins are grouped according to what their strobe (CHECK_WINDOW commands in proc_block) timing is. The OUTPUT_GROUP provides an alternate method of grouping output signals - for example it may be desirable to group scan output signals separately. In order to further optimize the file size of the textio file, the INPUT_GROUP parameter can be used to define additional input pin groups. Usually, this would be done for input pins that have a high degree of activity in the file - such as clock pins. An example might be:

          INPUT_GROUP = "clk1, clk2",

          INPUT_GROUP = "enb, dir_ctrl",

          OUTPUT_GROUP = "scan_out1, scan_out2",

Here we have used two INPUT_GROUP parameters to define two additional groups - the first with just the clk1 and clk2 pins, the second with enb and dir_ctrl pins. All other input pins would remain in their default groups. Likewise we have formed a group of the two output scan pins which will see a lot of activity during scan operations while other outputs are being masked.

The BUFFER_PORTS and LINKAGE_PORTS parameters can be used to define pins as buffer or linkage ports for use in the component or module instantiation. These pins must still be defined as inputs, outputs or bidirects in the OVF.

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

Some Examples

The following is an example of a VTRAN command file for translating a standard Verilog VCD file into a Verilog testbench:

        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

        PROC_BLOCK

          BEGIN

          STATE_TRANS 'x'->'X', 'z'->'Z';

          STATE_TRANS outputs 'Z'->'X';

          BIDIRECT_CONTROL iobus[15:0] = input when ioctrl = 0;

          CYCLE 80;

          CHECK_WINDOW iobus @ 55, 56;

          CHECK_WINDOW opbus[7:0], ackn, red @ 70, 71;

          END

        TVF_BLOCK

          BEGIN

          TARGET_FILE = tvf0;

          SIMULATOR verilog_tb, -VERBOSE,

            TESTBENCH_MODULE = "CKT_s0",

            COMPONENT_MODULE = "s0_rev1",

            TIMESCALE = "1ns/100ps";

          END

        END

Here we are using the state_trans commands to map any lowercase state characters in the VCD file to uppercase characters, and any Z states to an X (mask) for outputs.

The next example command file reads a Verilog VCD vector file and translates it to a VHDL testbench for simulation verification.

        {******************************************************}

        {*                                                    *}

        {* This VTRAN® command file will translate VCD to VHDL *}

        {*                                                    *}

        {******************************************************}

        OVF_BLOCK

           BEGIN

        orig_file = "vcd";

              SCRIPT_FORMAT verilog_vcd;

              INPUTS qavd,

               Qavs,

               avd1a,

               avs1a,

               avd2a,

               avs2a,

               avd2b,

               avs2b,

               avd2c,

               avs2c,

               xclk,

               atstb,

               iddq_en,

               bsb;

              BIDIRECTS cbi[14:0];

              OUTPUTS sclk24,

               sclk8,

               cx24[3:0],

               sclk;

              INPUTS fake_oe;

           END;

        PROC_BLOCK

        {******************************************************}

        {*                                                    *}

        {* Use this section to perform bidirect data          *}

        {* separation, to specify strobe (check) windows for  *}

        {* outputs and to do state translations.              *}

        {*                                                    *}

        {******************************************************}

            BEGIN

            cycle 250; {4 MHz cycle}

            BIDIRECT_CONTROL cbi[7:0]=input WHEN fake_oe=0;

            BIDIRECT_CONTROL cbi[14:8]=input WHEN fake_oe=1;

            check_window * @ 195, 200; { strobe all outs at 195 }

            state_trans 'x'->'X', 'z'->'Z';

            state_trans outputs 'Z'->'X'

            END;

        TVF_BLOCK

        {******************************************************}

        {*                                                    *}

        {* Define simulation configurations here. Currently   *}

        {* configured for VHDL using textio.                  *}

        {*                                                    *}

        {******************************************************}

        BEGIN

            aux_file = "one.tio";

            target_file = "one.vhd";

            SIMULATOR vhdl_tb_tio,

             -93,

             LIBRARY="IEEE",

             USE="IEEE.STD_LOGIC_1164.ALL",

             USE="IEEE.STD_LOGIC_TEXTIO.ALL",

             LIBRARY="STD",

             USE="STD.STANDARD.ALL",

             USE="STD.TEXTIO.ALL",

             BIT_TYPE="STD_LOGIC",

             BIT_VECTOR="STD_LOGIC_VECTOR",

             RESULT_TYPE="STD_LOGIC",

            CONFIG_FILE="one_cfg.vhd",

             INPUT_GROUP = "xclk, bsb";

            DELETE_PINS fake_oe; { exclude control pin from output file }

            TITLE "pm6124";

        END;

In this example, we have used the -93 flag to force VHDL '93 compliance on the textio syntax. An input group is also defined containing the clock (xclk) and other input (bsb) signals. These signals make many transitions relative to the other inputs, so placing them in a separate group will reduce the resulting textio file size. The fake_oe signal is removed from the output file since it was only an internal control signal used to determine the direction of state data on the bi-directional bus pins.

 

Product Support