Combining multiple waveform files can lead to a more efficient use of resources. This may mean the reuse of functional waveforms during test development or sequentially combining pattern bursts for decreased test times. In VTRAN®, this is supported with the MERGE_FILE command. The feature is supported for both Event-based (print-on-change) and Cycle-based vectors and the merged vectors can be used to generate any output format supported by VTRAN®, including VCD, VHDL, testbenches, and numerous tester formats.
The user controls the VTRAN® translation process with an ASCII command file. Historically, the ASCII command file has been created using a text editor and VTRAN® has been launched from the command line. While, this continues to be an option, the VTRAN® User Interface Utility (VUI) is now available. It is a graphical user interface developed specifically for the VTRAN®, VCAP, and DFTView Tool Suite and is automatically installed with VTRAN®. Either way, the concepts and the results are the same.
The three blocks that make up the VTRAN® command file are:
- OVF_BLOCK - The Original Vector File Block
- PROC_BLOCK - The Process Block
- TVF_BLOCK - The Target Vector File Block
The commands and parameters in these blocks direct the details of the translation. In general, the OVF_BLOCK tells VTRAN® how to read the input file or "Original Vector File". VTRAN®'s reader technology enables it to read almost any vector file. It includes canned readers for many well known formats including STIL, WGL, VCD, and EVCD as well as support for user formats. The PROC_BLOCK contains commands that tell VTRAN® the data processing functions to be performed on the Original Vector File 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 but may also include adding pins, inserting statements, etc... The TVF_BLOCK contains commands that specify the desired output format and optional reporting parameters.
The MERGE_FILE command is applied in the OVF_Block. PROC_Block and TVF_Block commands are unaffected by the use of the MERGE_FILE feature.
- The OVF_Block
- Merging Files
- Other Notes on Using MERGE_FILE
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. This defines the actual format of the vector data to be read. The second piece of information needed is the name of the Original Vector File. (The ORIG_FILE command is actually not required if the input file name is specified from the command line when invoking VTRAN®.)
Flows with an Original Vector File (OVF) format that does not allow VTRAN® to automatically and unambiguously determine signal direction (as is the case with Verilog VCD/EVCD) also require an INPUTS/OUTPUTS/BIDIRECTS field. For some vector formats, like Verilog VCD, not only is VTRAN® unable to unambiguously determine the signal type (input, output, or bidirect) 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. It is therefore necessary to use a VTRAN® process like BIDIRECT_CONTROL (located on the PROC_Block form) to specify when states represent input data or output data, usually as a logical function of a control signal.
Example: ovf_block begin ORIG_FILE = "tc1.vcd"; SCRIPT_FORMAT VERILOG_VCD ; INPUTS nrzSig OutputEnable rzSig roSig ; OUTPUTS edgeSig windowSig ; BIDIRECTS bidirSig ; INPUTS zmarker Data Data Data Data ; COMMENTS = On; 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 MERGE_FILE command structure essentially replaces ORIG_FILE command in this application.
Syntax: Merge_File [-CONCATENATE][-COPY_TIMING] [INPUTS/OUTPUTS/BIDIRECTS statements] orig_file = "fname"; [aux_file = "fname.aux";] [time_offset = nnn;] [vcd_cycle = nnn;] end_Merge; Example: ovf_block begin SCRIPT_FORMAT VERILOG_VCD ; INPUTS nrzSig OutputEnable rzSig roSig ; OUTPUTS edgeSig windowSig ; BIDIRECTS bidirSig ; INPUTS zmarker Data Data Data Data ; COMMENTS = On; MERGE_FILE orig_file = "tc2.vcd"; end_Merge; MERGE_FILE orig_file = "tc3.vcd"; end_Merge; end;
There is one MERGE_FILE block for each file being merged. If all of the signals in each file are the same then they can be declared just once outside the MERGE_FILE blocks, as shown above. If any signals exist in one file but not in the others, however, then the signals need to be in the MERGE_FILE block associated with file where they exist. There is no limit to the number of MERGE_FILE blocks used in any given translation.
The files to be merged must all be in the same format and all of OVF_Block commands available in translations without MERGE_FILE commands, can be applied when MERGE_FILE commands are present.
MERGE_FILE is a general purpose tool that combines original vector files into a single original vector file. The signal sets of the original vector files may overlap completely, overlap partially, or be disjoint. Similarly, the time ranges may overlap completely, overlap partially, or be disjoint. The resulting file contains a union of both the signal sets and time ranges.
If a signal appears in only one of the MERGE_FILE blocks, it appears in the merged file with the state/timing specified in that block. If a signal exists in more than one file being merged, the result depends on whether or not a conflict exists.
- If both files have the same state at the same time for this signal, then the resultant merge file contains this state.
- On inputs, a Z state in one file is overwritten by 1/0 from another file.
- On outputs, an X from one file is overwritten by H/L from another file.
- If the signal is being driven to or checked for different active states (i.e. 10HL or equivalent) at the same time in both files, an error (conflict) exists. The resulting signal state is undefined '-'. If desired, use the PROC_BLOCK MASK_PINS or STATE_TRANS commands to force '-' to some other state.
Some of the more common MERGE_FILE applications include:
- Combining asynchronous waveforms in multiple Event-based files that contain different signals and a common time range.
- Creating a single pattern burst by sequentially joining several smaller bursts.
- Creating a single synchronous pattern from parallel Cycle-based bursts that contain different signals.
- Extending the time range of Event-based file by combining files with different timing ranges.
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.
When merging cyclized vectors, the following restrictions also apply:
- A timeset must have the same name and cycle value in all original files.
- Timesets must be applied the same way in each of the original files, i.e. corresponding vectors must have the same timeset.
- If a signal is defined in more than one original file, its format and timing must be identical in all the original files.
- Any Shift, Loop, or Repeat constructs in the original files are automatically flattened by the VTRAN® reader.
- Any SCAN in the original files must be flattened unless -CONCATENATE is used.
No special considerations are necessary in the PROC_Block and TVF_Block when MERGE_FILE is used. See how the cyclization commands are used in the following VCD to V93K example.
ovf_block begin SCRIPT_FORMAT VERILOG_VCD ; COMMENTS = On; MERGE_FILE orig_file = "tc2.vcd"; INPUTS nrzSig rzSig roSig ; OUTPUTS edgeSig ; end_Merge; MERGE_FILE orig_file = "tc3.vcd"; OUTPUTS windowSig ; BIDIRECTS bidirSig ; INPUTS OutputEnable zmarker Data Data Data Data ; end_Merge; end; proc_block begin AUTO_ALIGN 400; BIDIRECT_CONTROL bidirSig = input when OutputEnable = 0; DONT_CARE = "X"; DISABLE_VECTOR_FILTER; STATE_TRANS pure_inputs 'X'->'0', 'x'->'0', 'z'->'Z'; STATE_TRANS bidir_inputs 'X'->'0', 'x'->'0', 'z'->'Z'; STATE_TRANS pure_outputs '1'->'H', '0'->'L', 'x'->'X', 'Z'->'M', 'z'->'M'; STATE_TRANS bidir_outputs '1'->'H', '0'->'L', 'x'->'X', 'Z'->'M', 'z'->'M'; CYCLE = 400; PINTYPE RZ rzSig @ 100, 300 ; PINTYPE STB bidirSig @ 160 ; PINTYPE RZ bidirSig @ 120, 150 ; PINTYPE RO roSig @ 100, 300 ; PINTYPE NRZ Data Data Data Data @ 255 ; PINTYPE RO zmarker @ 100, 400 ; PINTYPE NRZ nrzSig @ 10 ; PINTYPE STB edgeSig windowSig @ 200 ; end; tvf_block begin TARGET_FILE = "test4.avc"; TESTER_FORMAT HP93000 MAX_LINE_LENGTH = "80" TIME_STAMPS = "On" DVC_FILE = "test4.dvc" ; MERGE_BIDIRECTS 10HLMZX; RESOLUTION = 1.0; end; end
In the context of MERGE_FILES, concatenation means to join files sequentially. In VTRAN® this is most conveniently accomplished using the -CONCATENATE option. It is used most often when the files to be merged all start at time 0. This option works in all translation flows: Cycle-based to Cycle-based, Cycle-based to Event-based, Event-based to Event-based, and Event-based to Cycle-based.
Use -CONCATENATE to sequentially join OVF files with cycle-based formats. Use this option whether or not the cycle structure is preserved in the translation. The next concatenated file begins exactly at the end of the last cycle of the previous file. Everything stays synchronized to the cycle period, even if that period is not constant over the entire waveform. The join is "smoothe", i.e. the event at the end of the last cycle is overwritten with the first event at time 0 of the next file.
Example where cycle structure is preserved: STIL->V93K Translation ovf_block begin TABULAR_FORMAT STIL -CYCLE -SCAN -ONE_LOOP_LEVEL -WFC_MODE ; COMMENTS = On; MERGE_FILE -concatenate orig_file = "tc1.stil"; end_Merge; MERGE_FILE orig_file = "tc2.stil"; end_Merge; end; proc_block begin DONT_CARE = "X"; DISABLE_VECTOR_FILTER; end; tvf_block begin TARGET_FILE = "test3.avc"; TESTER_FORMAT HP93000 MAX_LINE_LENGTH = "80" TIME_STAMPS = "On" DVC_FILE = "test3.dvc" N = "0" P = "!Z" ; RESOLUTION = 1.0; end; end
Multiple event-based files can be concatenated using the -CONCATENATE switch and VCD_CYCLE. This is used when the VCD/EVCD file is driven from some well-behaved cycle-based framework and the last event in the file may not fall exactly at the end of the last cycle. VTRAN® ensures that the concatenation of vcd/evcd files, stays synchronous to the clock which is active at the transition time between the files by calculating the time offset for the next file as the next multiple of the VCD_CYCLE after the last event in the current file.
For example, a VCD file from a simulation uses a 100ns clock cycle, where all inputs were driven at 20ns, the clock was "RZ @ 25, 75;" and all outputs are sampled (stable) at 70ns in each cycle. The the last event in the VCD file would occur 75ns into the last cycle. This is not on the cycle boundary. The VCD_CYCLE parameter tells VTRAN® the cycle time so that 25ns to the end of the vcd file which will then be where the next VCD file begins. Everything stays sync'ed to the 100ns cycle.
Example: ovf_block begin SCRIPT_FORMAT VERILOG_VCD DRIVE_THRESHOLD = 0 SENSE_THRESHOLD = 0 ; COMMENTS = On; MERGE_FILE -CONCATENATE orig_file = "tc1.evcd"; vcd_cycle = 400; end_Merge; MERGE_FILE orig_file = "tc2.evcd"; vcd_cycle = 500; end_Merge; MERGE_FILE orig_file = "tc3.evcd"; end_Merge; end;
VCD_CYCLE is required in the first MERGE_FILE block but is optional in all others. If a block does not contain a VCD_CYCLE value, then the value from the preceding block is carried forward. A VCD_CYCLE time of 0 will cause the last event to be overwritten.
The VUI operates in almost exactly the same way with the MERGE_FILE blocks as it does with a single input file. There are only two differences. The first is in the initial setup. The Initial Setup Form in the VUI, has a field available for the name of the Original Vector File. When using the MERGE_FILE feature, leave this field blank. "Continue" to the OVF_Block form when ready, and enter the MERGE_FILE block on this page.
The second difference is related to the launch of DFTView from the VTRAN® Results screen after VTRAN® has run. Currently, the user is not allowed to launch DFTView on the OVF when the OVF is a MERGED set of files. Instead the user must MERGE the files in a separate translation and then launch DFTView either from the VUI or command line.
VTRAN® extracts a time stamp from the OVF for each vector it loads. When used in the MERGE_FILE block the TIME_OFFSET value is added directly to each time stamp read in the OVF specified in that block.
Example: ovf_block begin SCRIPT_FORMAT VERILOG_VCD DRIVE_THRESHOLD = 0 SENSE_THRESHOLD = 0 ; COMMENTS = On; MERGE_FILE orig_file = "tc1.evcd"; end_Merge; MERGE_FILE orig_file = "tc2.evcd"; TIME_OFFSET = 15600; end_Merge; MERGE_FILE orig_file = "tc3.evcd"; TIME_OFFSET = 60000; end_Merge; end;
TIME_OFFSET is primarily used with Event-based original vector files. In particular, TIME_OFFSET can be used to concatenate Event-based ovfs when vcd_cycle is unknown or if the file waveform has multiple periods.
The first timestamp in a Cycle-based file is inherently 0. In translations from Cycle-based formats to Cycle-based formats, unexpected results may occur if the TIME_OFFSET value is not a multiple of the cycle length.
When the Original Vector Files and the Target Vector File are cycle-based, and a signal does not have a defined OVF state in later vectors, the signal may not have timing defined in the timeset active in these vectors. This can occur if the vector is based on an OVF that does not contain the signal, and the active timeset is not defined in the OVF that does contain the signal. In this case, the signal’s timing in this timeset in the merged Target Vector File is unpredictable and can be based on various default values. A VTRAN® switch is provided to copy the signal’s timing from its OVF to the TVF. The timeset active in the last vector of the signal’s OVF defines the timing to be copied to the TVF. If the TVF includes multiple timesets, this signal timing will be included in all the TVF timesets that do not otherwise include the signal. This behavior is enabled with the -COPY_TIMING switch on a MERGE_FILE block, and is only applicable to CONCATENATE mode. Like the -CONCATENATE switch, it is not required on all MERGE_FILE blocks. By default, signal timing is not copied, and default values will be used. This applies to horizontal merge cases, only.
ovf_block begin TABULAR_FORMAT STIL -CYCLE -SCAN -INCLUDE_CELLS -WFC_MODE ; COMMENTS = On; MERGE_FILE -COPY_TIMING orig_file = "tc2.stil"; end_Merge; MERGE_FILE orig_file = "tc3.stil"; end_Merge; end;
OVF Formats that Use Auxiliary Files When using some canned readers, a second file must also be specified in the OVF_BLOCK which is needed to read the vectors. This is usually when the vector data and pin data are in separate files, such as with the V93K and Flex canned readers. For these cases, the AUX_FILE command can be used as shown below:
Example: ovf_block begin TABULAR_FORMAT HP93000 -CYCLE -SCAN SCAN_PAD = "^" ; COMMENTS = On; MERGE_FILE -CONCATENATE orig_file = "test2a.avc"; aux_file = "test2a.dvc"; end_Merge; MERGE_FILE orig_file = "test2b.avc"; aux_file = "test2b.dvc"; end_Merge; end; or ovf_block begin TABULAR_FORMAT FLEX -CYCLE -SCAN ; COMMENTS = On; MERGE_FILE -CONCATENATE orig_file = "test8a.atp"; aux_file = "test8a"; end_Merge; MERGE_FILE orig_file = "test8b.atp"; aux_file = "test8b"; end_Merge; end;
The file name string may include a path prefix.
On V93K target translations that use a FREE RUNNING CLOCK, separate DVC timing and vector files are output for each free running clock. Free running clocks that share the same clockPeriod will be entered together into one DVC timing file and one AVC vector file. Currently, DFTView does not support the MERGE_FILE input structure. The user must MERGE the files in a separate V93K to VCD/EVCD translation and then launch DFTView either from the VUI or command line.
Example: ovf_block begin TABULAR_FORMAT HP93000 SCAN_PAD = "^" ; COMMENTS = On; Merge_file orig_file = "FRC1_test1.avc"; aux_file = "FRC1_test1.dvc"; end_Merge; Merge_file orig_file = "test1.avc"; aux_file = "test1.dvc"; end_Merge; end; proc_block begin DONT_CARE = "X"; STATE_TRANS pure_inputs '1'->'U', '0'->'D'; STATE_TRANS bidir_inputs '1'->'U', '0'->'D'; STATE_TRANS pure_outputs 'M'->'T'; STATE_TRANS bidir_outputs 'M'->'T'; end; tvf_block begin TARGET_FILE = "test1.evcd"; SIMULATOR VERILOG_EVCD VERSION = "126.96.36.199" TIMESCALE = "1 ns" MODULE = "TITLE" STATE_STRENGTH = "D->60, U->06, N->66, Z->00, L->60, H->06, X->66, T->00" ; MERGE_BIDIRECTS UDNLHTZX; RESOLUTION = 1.0; end; end