Application Notes:
Merging Multiple Vector Files

SYNOPSIS
This Application Note focuses on the translation of multiple input files (Original Vector Files). This feature is supported both for print-on-change (or event-driven) vectors and for cycle-based vectors. The files to be merged must all be in the same format. The merged vectors can be used to generate any output format supported by Vtran, including VCD, VHDL, testbenches, and numerous tester formats.  

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 or ATPG-generated data file.  Vtran includes canned readers for many print-on-change, ATPG and tester file formats.  Print-on-change 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 (with edge timing within each cycle specified separately), 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".  The PROC_BLOC contains commands that tell vtran what data processing functions you want performed on the input 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 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.  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 merging multiple input files.

THE OVF_BLOCK
When using a vtran canned reader, 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" or “TABULAR_FORMAT” command, which defines the actual format of the vector data to be read.  The second piece of information needed is the name of the original file.

An optional set of information in the OVF_BLOCK provides the names and directions of the signals you wish to have read from the file.  VCD or EVCD input 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 for reading a VCD file 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.  

Vtran also supports a User-Programmed Reader feature. The OVF_BLOCK commands for this are described in the VTRAN Users Guide.

The syntax for the merging feature adds a Merge_File block, which may contain the optional INPUTS/OUTPUTS/BIDIRECTS statements and the associated input file name(s) for each file to be merged. This block replaces the single set of input file names for the non-merge case. The command file may have a global set of INPUTS/OUTPUTS/BIDIRECTS statements outside any Merge_File block, or it may have these statements in each Merge_File block. The statements are not allowed both places. The Merge_File block looks like:

Merge_File
     [-CONCATENATE]
     [INPUTS/OUTPUTS/BIDIRECTS statements]
     orig_file = "fname";
     [aux_file = "fname.aux";]
     [time_offset = nnn; ]
end_Merge;

Here is an example which merges 3 HP93K files:

OVF_BLOCK
begin
tabular_format HP93000 ;
Merge_File
     orig_file = "tap1.avc";
     aux_file = "tap1.dvc";
end_Merge;
Merge_File
     orig_file = "tap2.avc";
     aux_file = "tap2.dvc";
end_Merge;
Merge_File
     orig_file = "tap3.avc";
     aux_file = "tap3.dvc";
end_Merge;
end

THE MERGE FEATURE
The files to be merged must all be in the same format, for example one of the tester formats, WGL, STIL, or VCD/EVCD. The vectors to be merged may be event-based vectors from the original files, event-based vectors created by using a Vtran Reader to flatten cycle-based vectors in the original files (no -cycle flag), or cycle-based vectors from the original files.

When merging cyclized vectors, the following restrictions apply:

  1. A timeset must have the same name and cycle value in all original files.

  2. If a signal is defined in more than one original file, its format and timing must be identical in the timesets in all original files.

  3. If a vector at a given cycle time is defined in more than one original file, it must have the same timeset active in all original files.

  4. Any SCAN, Shift, Loop, or Repeat constructs in the original files must be flattened by the Vtran Reader.

The original files may contain all the same signals (in which case the merge actually is a concatenation), all different signals, or there may be an overlap of some of the signals in some of the original files. If the files have common signals then there must be no conflicts in the states on these signals at any given time. A conflict will result in a warning, with undefined state assigned. For outputs, X and Z states (or equivalent) are always overridden by any other state on the same signal in other files and will not result in a conflict warning. The same applies to input states Z and X (or equivalent).

When merging files with different signals, there may be time ranges in the final merged file for which some signals do not have a state defined in the original files. A signal that does not have a defined state at time zero will be set to X for the initial vectors, until a state is defined for it. If the final merged file has vectors beyond the last vector in an original file, and a signal is only defined in that original file, an input signal will maintain its last state, while an output signal will be set to X.

The merging/concatenating occurs prior to the processing specified in the PROC_BLOCK. A couple of the older User-Programmed Readers (CADAT, Mentor List) use the state_trans command in the PROC_BLOCK of the Vtran command file. These map two-character states to a single-character state. The merge feature is not supported for original files in these formats.

CONCATENATION

The concatenation of multiple files is supported in three ways. The first mechanism is to define the time_offset field in the Merge_File block, for all but the first file. The time_offset value is the end-of-cycle time of the last cycle in the preceding file. For example, to concatenate three files with a 100ns cycle time, if the last events in the first file are at times 2500ns, 2525ns, and 2575ns, the time_offset value for the second file would be "2600ns". If the last events in the second file are at times 3500ns, 3530ns, and 3560ns, the time_offset value for the third file would be "6200ns" (the last cycle in the second file starts at 3500ns + 2600ns, or 6100ns, and so ends at 6200ns).

The second concatenation mechanism is to use the actual timestamps in the input files. For example, if the last event in the first file is at time 2575ns, and the first event in the second file is at time 2600ns or later, the vectors from the second file will follow the vectors from the first file. In this case, the time_offset field of the Merge_File block should not be defined.

The third concatenation mechanism is only valid for cyclized vectors. If the -CONCATENATE switch is used, the time offset is calculated automatically for all but the first file, which uses a time offset of zero. The -CONCATENATE switch is only needed on the first Merge_File block. If it is present along with the optional time_offset field, a warning message is generated and the time_offset field is ignored. If the -CONCATENATE switch is used with event-based vectors, an error message is generated and Vtran terminates.



SOME EXAMPLES
The following is an example of a Vtran command file for merging a set of HP93000 files and generating a Verilog testbench:

OVF_BLOCK
begin
tabular_format HP93000 ;
merge_file
     orig_file "small1.agk";
     aux_file "small1.dvc";
end_merge;
merge_file
     orig_file "small2.agk";
     aux_file "small2.dvc";
end_merge;
merge_file
     orig_file "small3.agk";
     aux_file "small3.dvc";
end_merge;
end

PROC_BLOCK
begin
state_trans outputs 'L'->'0', 'H'->'1', 'M'->'Z';
end

TVF_BLOCK
begin
SIMULATOR VERILOG_TB,
  TIMESCALE = "1ns/100ps";
target_file "small2" ;
end

The next example includes the optional INPUTS, OUTPUTS, and BIDIRECTS commands inside the Merge_File blocks. A set of VCD files are merged and Advantest T3300 files are generated:

OVF_BLOCK
begin
SCRIPT_FORMAT verilog_vcd;
merge_file
     OUTPUTS address[3..0];
     INPUTS clock;
     INPUTS data[3..0];
     OUTPUTS data_echo[3..0];
     OUTPUTS data_out[3..0];
     OUTPUTS driving_data;
     OUTPUTS oe;
     INPUTS reset;
     OUTPUTS state[2..0];
     OUTPUTS we;
     orig_file = "local1.vcd";
end_merge;
merge_file
     INPUTS clockB;
     OUTPUTS oeB;
     INPUTS resetB;
     orig_file "local2.vcd";
end_merge;
merge_file
     INPUTS clockC;
     OUTPUTS oeC;
     INPUTS resetC;
     orig_file "local3.vcd";
end_merge;
end

PROC_BLOCK
begin
CYCLE 250;
ALIGN_TO_CYCLE 250, ALL_INPUTS @ 10, ALL_OUTPUTS @ 195 ;
PINTYPE NRZ * @ 10 ;
PINTYPE RZ clock @ 30, 50;
PINTYPE RZ clockB @ 30, 50;
PINTYPE RZ clockC @ 30, 50;
PINTYPE STB * @ 195, 200;
{ #### state character translations for 'VCD'->'Advantest'#### }
state_trans outputs '0'->'L', '1'->'H', '-'->'X', 'x'->'X', 'z'->'X', 'Z'->'X';
state_trans pure_inputs '-'->'0', 'X'->'0', 'x'->'0', 'z'->'Z';
state_trans bidir_inputs '-'->'Z', 'X'->'0', 'x'->'0', 'z'->'Z';
end

TVF_BLOCK
begin
tester_format Advantest -T3300,
  MAX_LINE_LENGTH = "700",
  TIME_STAMPS = "ON",
  SCANIN_DEFAULT = "^";
target_file = "pinsLocal" ;
end


The next example uses a global set of INPUTS and OUTPUTS commands, outside the Merge_File blocks. A set of VCD files are concatenated using the timestamps in the original VCD files, and Advantest T3300 files are generated:

OVF_BLOCK
begin
SCRIPT_FORMAT verilog_vcd;

INPUTS clock;
OUTPUTS oe;
INPUTS reset;
merge_file
     orig_file "global1.vcd";
end_merge;
merge_file
     orig_file "global2.vcd";
end_merge;
merge_file
     orig_file "global3.vcd";
end_merge;
end

PROC_BLOCK
begin
DISABLE_VECTOR_FILTER;
CYCLE 250;
ALIGN_TO_CYCLE 250, ALL_INPUTS @ 10, ALL_OUTPUTS @ 195 ;

PINTYPE NRZ * @ 10 ;
PINTYPE RZ clock @ 30, 50;
PINTYPE STB * @ 195, 200;
{ #### state character translations for 'VCD'->'Advantest'#### }
state_trans outputs '0'->'L', '1'->'H', '-'->'X', 'x'->'X', 'z'->'X', 'Z'->'X';
state_trans pure_inputs '-'->'0', 'X'-> '0', 'x'->'0', 'z'->'Z';
state_trans bidir_inputs '-'->'Z', 'X'->'0', 'x'->'0', 'z'->'Z';
end

TVF_BLOCK
begin
tester_format Advantest -T3300,
  MAX_LINE_LENGTH = "700",  SCANIN_DEFAULT = "^";
target_file "pinsGlobal" ;
end;

The next example demonstrates how to concatenate multiple input files, using the time_offset field in the Merge_File block. A set of HP93000 files are merged, and a Verilog EVCD file is generated:

OVF_BLOCK
begin
tabular_format HP93000 ;
merge_file
     orig_file = "cat1.agk";
     aux_file = "cat1.dvc";
end_merge;
merge_file
     orig_file = "cat2.agk";
     aux_file = "cat2.dvc";
     time_offset = "300ns";
end_merge;
merge_file
     orig_file = "cat3.agk";
     aux_file = "cat3.dvc";
     time_offset = "600ns";
end_merge;
end

PROC_BLOCK
begin
state_trans inputs '0'->'D', '1'->'U', 'X'->'N', 'Z'->'Z' ;
state_trans outputs '0'->'L', '1'->'H', 'X'->'X', 'Z'->'T';
end

TVF_BLOCK
begin
SIMULATOR VERILOG_EVCD
  TIMESCALE = "1ns/100ps";
MERGE_BIDIRECTS UDHLNTZX;
target_file "cat2.evcd" ;
end;

The next example demonstrates how to concatenate multiple cyclized input files, using the -CONCATENATE switch. A set of HP93000 files are concatenated, and HP93000 files are generated:

OVF_BLOCK
begin
tabular_format HP93000 -cycle -expand_loops -expand_reps;
merge_file -CONCATENATE
     orig_file "cattsets1.agk";
     aux_file "cattsets1.dvc";
end_merge;
merge_file
     orig_file "cattsets2.agk";
     aux_file "cattsets1.dvc";
end_merge;
merge_file
     orig_file "cattsets3.agk";
     aux_file "cattsets1.dvc";
end_merge;
end

PROC_BLOCK
begin
disable_vector_filter;
end

TVF_BLOCK
begin
tester_format hp93000,
  SCANIN_DEFAULT = "0",
  PATTERN_NAME = "cam_runbist",
  MAX_LINE_LENGTH = "300" ,
  TIME_STAMPS = "ON",
  DVC_FILE = "cattsets.dvc",
  PIN_CONFIG_FILE = "cattsets.pins",
  TERMINATE = "halt",
  repeat_threshold = "2"
;
target_file = "cattsets.agk"   ;
end;

 

Return to Application Notes Index

 

Home    |    Contact Us    |    Site Map    |    Privacy Policy    |    Terms of Use