Application
Notes > General Topics
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:
A timeset must have the same name and cycle value in all
original files.
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.
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.
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
|