Necessity of fault simulation

Fault simulation is not required to validate ATPG output. However, an ATPG tool will internally call a fault simulation tool. This is because once a pattern is generated to cover a specific fault, it is fault simulated to see if it covers any other faults that were not explicitly targeted. If other faults are covered they can be dropped from further consideration (unless a specific N-detect level is a requirement, but that’s a different discussion….)
Stand-alone fault simulators do also exist. They are typically used to fault grade functional vectors. Fault simulators are also included in LBIST solutions to fault grade the pseudo random patterns generated by the LBIST.

If Fault Simulation is not required to validate ATPG then why do we have an option to perform fault simulation in tools like fastscan?

Fastscan is a versatile test pattern generation and fault simulation tool. It can be used to fault grade any set of scan patterns against many types of user definable fault types. Again, for the fault types than Fastscan is capable of targeting, it is not necessary to perform a separate fault simulation run on the patterns Fastscan generates. However you can for example fault simulate those generated patterns on other fault types.

– Courtesy answered by Steve Pateras

Typical Fastscan script for ATPG pattern generation

set loggile handling <filename> -append

report version data

add scan groups grp1 <path of test procedure file>

add clocks 0 clk

add clocks 1 h_resetn

add pin constraints test_mode C1

set system mode atpg

#At this point if you encounter any drc errors, you will have to fix them before moving forward

when the above command is used the following processes occur

  1. circuit flattening
  2. learning analysis
  3. design rules checking

set fault type stuck

add faults -all

create patterns -auto

save patterns <filename> -replace -procfile -ascii -cell_placement bottom -begin 0 -all_test -mode_internal

set system mode fault

set pattern source external <pattern file path? -ascii


Typical RC script for Scan Insertion

read_netlist -top <top module name>

read_sdc <sdc filename>

set_attribute dft_scan_style muxed_scan

define_dft test_mode -name test_mode -active high test_mode

define_dft shift_enable -name scan_en -hookup_pin [find / -pin dft_fix/Z] -active high TOP/dft_fix/Z (if using an internal pin for scan enable)

define_dft scan_chain -name chain1 -sdi -sdo -shared_out -shared_select test_mode

(assuming that you are using shared scan input and scan outputs)


report dft_registers > dft_reg.rpt

report dft_setup > dft_setup.rpt

set_attribute dft_max_length_of_scan_chains

synthesize -to_mapped

connect_scan_chains -preview -auto_create_chains

connect_scan_chains -pack

report dft_chains > chain.rpt

write_hdl > <filename>

write_script > dft.tcl

write_atpg -mentor

I have found that the RC tool does not write out a really useful testproc file
I will soon upload a proc file, keep watching

Typical DFT Advisor dofile

//I do not recommend the use of the below command, rather you need to specifically define all the control signals as clocks

{analyze control signals -auto_fix


add clocks clk

add clocks rst_n}

// Define Scan pin naming conventions
// The scan pins will be named as chain1_scan_in, chain2_scan_in, etc and
// chain1_scan_out, chain2_scan_out eta
// Use the below command when not using the existing design pins for scan
//setup scan pins input -prefix chain -initial 1 -modifier 1 -suffix scan_in
//setup scan pins output -prefix chain -initial 1 -modifier 1 -suffix scan_out

//Define the test mode pin
setup scan insertion -ten scan_mode
//Define the scan clock
setup scan insertion -sclk clk_120m
//the -Isolate option can be used only for the scan enable signal of SEN type (inserted
//for regular/non-partition cells). If you specify this option, DFTAdvisor checks the global scan
//enable signal to determine if it already has fanouts. If this is true, then an AND or NOR gate is
//inserted with the second input controlled by the global test enable signal. The output of this gate
//is connected to all the new fanouts of the scan enable pin (scan enable pins of scan cells). The
//output of this gate is active for test mode and inactive for system mode. In test mode (whenever
//the global test enable pin is active), the output of this gate is identical to the scan enable signal;
//the gate acts as a buffer. Depending on the active state of the global scan enable and test enable
setup scan insertion -sen mode[0] -isolate

//If you specify the -Disabled option, then for gating purposes, DFTAdvisor will
//use the test enable signal to disable set and reset inputs of flip-flops, and the scan enable
//signal of SEN type to disable the write and read clocks.
setup scan insertion -reset rst_n -gated
setup scan insertion -set rst_n -gated
add scan pins chain1  <scan_in1>  <scan_out1>  -clock clk
add scan pins chain1  <scan_in2>  <scan_out2>  -clock clk
add scan pins chain1  <scan_in3>  <scan_out3>  -clock clk
add scan pins chain1  <scan_in4>  <scan_out4>  -clock clk


set system mode dft

setup test_point identification -control 0 -observe 0 -noverbose
report statistics

report scan chains
report sequential instances -unidentified -nonscannable
write scan identification seq_inst_rpt -replace -identified -defined_scan
insert test logic -scan on -test_point on -ram on -number 1 -hierarchical off
write netlist -replace
write atpg setup -replace