Simulate Translate Test

Merging Multiple Input Files

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.

VTRAN® Overview

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.

Using the MERGE_FILE Command in VTRAN®

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[0]
          Data[1]
          Data[2]
          Data[3]
      ;
      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[0]
          Data[1]
          Data[2]
          Data[3]
      ;
      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[0]
          Data[1]
          Data[2]
          Data[3]
        ;
        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[0]
          Data[1]
          Data[2]
          Data[3]
        @ 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.

Concatenation of Cycle-Based Formats

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

Concatenation of Event-Based Formats

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.

Using MERGE_FILE in the VUI

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.

then

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.

TIME_OFFSET

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.

-COPY_TIMING

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.

V93K MERGE_FILE support for Free Running Clock

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 = "1.6.0.1"
         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

 

 

 

Product Support

Customer Quotes

  • Source III VTRAN® tool has been very efficient to translate VCD, WGL, and STIL vectors to Teradyne UFLEX and Verigy 93000 ATE formats. Their response to add or implement new features as per customer needs is impeccable and steadfast. I would highly recommend using this tool to any test engineer for vector conversion
  • We currently use VTRAN for translating WGL, EVCD and VCD vectors to be used on various Verigy and Teradyne platforms. Their feature set has allowed us to perform vector manipulation instead of writing Perl scripts. Their support has been very responsive and they are open to additional features on future releases.
  • Sanera Utilizes Full Featured VTRAN® to Convert Functional and ATPG Vectors "We chose VTRAN® because it can handle multiple simulation file formats (including VCD and WGL) from a single tool. VTRAN's commands are easy to use. The flexibility in pin mapping, masking outputs, and generating scan-based vectors proves to be tremendously helpful. And most of all, Source III provides excellent, fast response to our support needs. This helps us to get things moving very quickly - making good solid progress." Ken ChenTest Engineering Manager
  • Intrinsix Uses VTRAN® to Speed Vector Translation Flow "I had one customer who used VHDL for RTL, Verilog for gate level simulation, and sometimes used EPIC tools. Getting vectors into the various formats was a nightmare. VTRAN® made the translation process easy and seamless. Plus, WGL or STIL for the test group. Support from Source III has also been quite impressive. In one case, they wrote a bug fix for me in under a day." John Weiland Intrinsix Consultant  
  • We use VTRAN® to translate WGL or TDL vectors to Teradyne J750 and Flex format. The produced patterns work fine and adaptation to a new device pinout can be done easy and quickly.
  • VTRAN® is currently our tool of choice for converting MS digital test patterns between various logic simulation formats and WGL/STIL. Our experience with Source III has been positive and their support is extremely responsive and timely.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6