Why is there coverage loss after multi-mode and Adaptive Scan insertion?

Doc Id: 018868 Product: DFT Compiler;TetraMAX Last Modified: 10/26/2006

Question:
When I insert either multiple scan modes or Adaptive Scan into my design with DFT Compiler, I find that TetraMAX reports lower coverage across all modes than if I had just inserted simple scan chains. For Adaptive Scan, I have tried removing the faults in the compressor and decompressor logic (CODEC), but this makes no difference. Why is TetraMAX reporting lower coverage, and how can I correct this?

Answer:
When using Adaptive Scan or multi-mode scan in DFT Compiler, logic is added to the design to allow the chain architecture to change in each mode. A common example of this is Adaptive Scan, which by default inserts 2 modes. One mode applies to when the compression logic is active and you have many small scan chains in the design. The other mode applies to when the compression logic is bypassed and the short chains are linked together to form longer, uncompressed scan chains. To allow for this chain re-configuration, DFT Compiler inserts logic to control the re-configuration into the scan chains, and also in some cases it inserts logic to convert the TestMode control pins into control signals for the logic in the chains. For standard Adaptive Scan, the logic is simply MUXes or equivalent in the chains, driven directly from the TestMode signal. The re-configuration logic is held in a fixed state during ATPG in a particular 'test mode' by constraining the TestMode signals. The result is that some of this logic is untestable, which is the reason the coverage report is lower than if the design just had single mode scan chains. You can resolve the coverage issue in two ways: A. Generate incremental patterns in all test modes to catch all faults in the re-configuration logic. Normally just the chain test (pattern 0) in the other modes will be enough to catch the faults. B. As the re-configuration logic is not functional logic, you may simply want to exclude faults in this logic from the fault list. For Adaptive Scan in particular, for production testing you may only ever use the compression mode. In this case, even if there were a fault in the logic in 'bypass' mode, the functional logic can still be fully tested, and the device will be fit for use. If you choose to follow option B above, and drop the faults from the fault list, to simplify identification of the test logic, you can use the following steps: 1. In DFT Compiler, before running 'insert_dft', instance names given to any new logic inserted: set compile_instance_name_prefix DFTC_LOGIC_ change the default

2. Additionally, to ensure the above prefix is only assigned to the test logic added, disable optimization of the functional during scan insertion: set_dft_insertion_configuration -synthesis_optimization none 3. After running 'insert_dft', change the prefix name back to the normal setting and run an incremental compile to fix timing as a separate step: set compile_instance_name_prefix U compile -scan -incremental ... 4. In TetraMAX, you can now use the prefix to find and remove all faults related to the test logic inserted. If using TetraMAX in Tcl mode (tmax tcl), then you can add something similar to the following to omit the faults on the logic: foreach_in_collection pin [get_pins -filter "pin_pathname=~DFTC_LOGIC_*"] { add_nofault [get_attribute $pin pin_pathname] -stuck 01 }

The limitation of the above steps is that you can end up removing faults related to ALL the test logic inserted, including lockup latches, Autofix logic, etc., so you may want to be selective on the faults removed, and simply use the prefix name as a guide to simplify this task. An example of this would be the situation where you have inserted Adaptive Scan and want to exclude the reconfiguration logic from the fault list, but keep faults for the compression logic in the fault list. In this case, the commands to do this in Tcl mode in TetraMAX would be: set reconfig_pins [remove_from_collection \ [get_pins -filter "pin_pathname=~DFTC_LOGIC_*"] \ [get_pins -filter "pin_pathname=~*compressor*"]] foreach_in_collection pin $reconfig_pins { add_nofault [get_attribute $pin pin_pathname] -stuck 01 } DFT MAX names the compression logic '*U_compressor' and '*U_decompressor', so the above Tcl will remove this logic from the list of pins not to fault.

TetraMAX Combined Test Coverage for JTAG and ATPG Patterns

Question: I have a DFT Compiler basic scan-inserted design with boundary-scan logic (JTAG) inserted by BSD Compiler. What is the recommended methodology to get combined test coverage for both ATPG and JTAG test patterns in TetraMax?

Answer:
One can get combined test coverage for both JTAG and ATPG patterns in TetraMAX using a two-pass flow as follows: 1. Generate the BSD STIL patterns and the Verilog-DPV testbench for simulation. 2. Simulate the BSD patterns in VCS, and generate the Extended VCD (eVCD) dumpfile for TetraMax. 3. TetraMAX two pass: 3.1 TetraMAX pass-1, get ATPG stuck-at coverage. 3.2 TetraMAX pass-2, run faultsim on the JTAG patterns (eVCD file). Procedure Details: 1. In BSD Compiler, follow this procedure: ======================================== create_bsd_patterns write_test -f stil_testbench -out TOP_bsd_stil_tb This generates two files: TOP_bsd_stil_tb.v (Testbench that instantiates the patterns) TOP_bsd_stil_tb.stil (STIL pattern file) 2. In VCS Verilog Simulation, follow this procedure: =================================================== 2.1 Edit the TOP_bsd_stil_tb.v testbench file. 2.2 Add the eVCD dumpvar command in the initial block. For example, if instance name of the testbench is TOP: initial begin _failed = 0; /* Generate VCDE */ // 'ifdef vcde_out // extended VCD, see IEEE Verilog 1364-2001 $display("// %t : opening Extended VCD output file", $time); $dumpports( design.TOP, "jtag_tb.vcde"); // 'endif 2.3 Run VCS simulation:

vcs -R -Mupdate +acc+2 -P $STILDPV_HOME/lib/stildpv_vcs.tab \ -v tmax_lib/class_pur.v TOP_bsd_pat_stil_tb.v TOP_bsd.v \

$STILDPV_HOME/lib/libstildpv.a -l bsd_vcs.log

3. The two-pass, combined-coverage flow in TetraMAX is as follows: ==================================================================== 3.1. PASS 1: First, get ATPG stuck-at coverage.

#filename: atpg.cmd # Read in libraries and top-level design with BSD inserted read_netlist ./tmax_lib/class_pur.v read_netlist TOP_bsd.v run_build_model TOP run_drc top_scan.spf # Obtain the coverage of the core, exclude JTAG logic add_nofaults TOP_BSR_top_inst add_nofaults TOP_DW_tap_inst add_faults -all run_atpg -auto #Write out faultlist and ATPG patterns write_faults atpg.faults -all -replace write_patterns atpg.pats -format binary -replace quit ############################################################# 3.2. PASS 2: Next, run faultsim on the JTAG patterns.

#Filename: faultsim.cmd # Read in libraries and top-level design with BSD inserted read_net ./tmax_lib/class_pur.v read_net TOP_bsd.v run_build_model TOP test #Read in JTAG eVCD testbench and run faultsim set_patterns -external bsdc_pat.vcde -strobe_period {100 ns} \ -strobe_offset {95 ns} #add the JTAG faults to the faultlist add_faults TOP_BSR_top_inst add_faults TOP_DW_tap_inst # Run good-machine simulation to verify the functional patterns run_simulation -sequential # Fault Simulate the JTAG functional test patterns run_fault_sim -sequential #Read back in the ATPG faultlist for combined test coverage read_faults atpg.faults -force_retain report_summaries # You can use the same run in TetraMax for this flow. # After you write out the ATPG patterns and faults, run the # "set patterns external "file_name" command; and then run fault_sim" Note: see the DFT Compiler Scan User Guide and the BSD Compiler Reference Manual for basic scan and boundary scan insertion flows.