0SCAN AND ATPG

What is scan ?
A) Scan is a DFT technique where the flip-flops in a sequential circuit are replaced with special scan
flip-flops (scan cells).
 these scan cells are then connected together to form a scan chain, which allows us to:
 Shift test data in (controllability)
 Capture circuit response
 Shift data out (observability)
 so, during test mode, the sequential circuit behaves like a combinational circuit, which makes
Fault detection much easier.

Why we need scan ?

A)  A pure sequential circuit has memory elements (FFs)  hard to control and hard to observe.
 Without scan  initializing the circuit to a known state is very difficult.
 With scan  we can directly set the state of FFs and read them out.
 This way, ATPG can easily generate test patterns and achieve high fault coverage.

 The goal of scan design is to make a difficult-to-test sequential circuit behave like an
easier-to-test combinational circuit. Achieving this goal involves replacing sequential
 elements with scannable sequential elements and then stitching the scan cells
together into scan registers, or scan chains.

Types of scans:
1. Full scan
2. Partial scan
3. Partition scan

 Full scan:- full scan is a scan design methodology that replaces all memory elements in the
design with their scan-able equivalents and then stitches them into scan chains.

 Partial scan:- in partial scan design, only a selected set of filp-flops are converted into scan
flip-flops. This idea is to balance between testability vs overhead. FFs are choosen carefully:-
hard-to-control or hard-to-observe FFs are included in scan. Others are left as normal FFs.

 Partition scan:- in partition scan design, the circuit’s FFs are divided into multiple scan chains
(partitions) instead of one very long chain. Each partition forms a separate scan chain.
 To reducing scan shift time (parallel loading/unloading possible)
 Lower test application time compared to one big chain.

Controllability :- the ability to set a node in a design to a desired state, i.e, logic 0 (or) 1.
Observability :- the ability to observe a change in logic value of a node in a design.
Testability :- if a design is well - controllable & observable it is said to be easily testable.

Scan Architecture :-

 When we insert scan, we need to decide how the scan flip-flop is built and how it connects
into scan chains.

 We cannot access the D-ff, which is internally sitting in the chip. So, we placed a 2:1
MUX before a D-ff during manufacturing.
 If scan_en = 0, then normal D-ff operation takes place.
 If scan_en = 1, then scan_data is transferred to D-ff by applying sys_clk that 1?0 is
stored in D-ff, we can access through Q.
 Types of scan Models:-
1. MUX-DFF
2. CLOCKED Scan
3. LSSD(level sensitive scan design)

 MUX-DFF :-  most common scan model (used in almost all modern SoCs).
A 2x1 multiplexer is added at the D input of the flip-flop.
 select line = Scan Enable (SE)
 Operation:-
SE=0 Functional mode (D  FF).
SE=1 Scan mode (SI  FF, acts like shift register).
 Pros:-
Simple, easy to implement, work with edge-triggered FFs.
Supported by tools like Tessent, Synopsys DFT compiler.
 Cons:-
Adds MUX delay on data path.

 Clocked Scan:- instead of MUX at data input, scan is enabled by controlling clocks.
uses functional clock + scan clock to load/shift values.
 Advantage:- No MUX delay on D path  better timing.
 Disadvantage:- Needs extra clock control logic  design complexity.

 LSSD ( level sensitive scan design):- Developed by IBM, latch-based design.

Each storage element = two latches (master-slave).
uses two non-overlapping clocks (A&B) for normal
Operation, puls separate scan clock© for scan shifting.

Scan insertion process:-

 The goal of scan insertion is, to make a difficult-to-test sequential circuit behave during
the testing process like an easier-to-test combinational ckt.
 It involves replacing sequential elements with scannable sequential elements which are
called the scan cells.
 Stitching the scan cells together into scan registers, or scan chains. For small designs, a
single scan chain is fine.
 But for large designs, one chain is not support. so, to reduce shift time, FFs are divided
into multiple scan chains.
 If chains are uneven, test time is still dominated by the longest chain equal length. This
ensures parallel shifting finishes at the same time  reduces total time.
Scan Flow:-

 First , we need files for input :- gate-level netlist  the post-synthesis/optimized

design with all flip-flops visible. Scan cell library  library cells that define mux_DFFs or
scan-DFFs and their pin names/timing. And constraint files  (SDC / clock definitions /
IO constraints / power domain info).

 SETUP mode :-

 in this step, we need to setup context to dft –scan, read in the Verilog design using
the “read_verilog”0 command, read the cell library using the “read_cell_library”
command.
 the main goal is to put tessent into scan/DFT context and local all design assets so it
knows the world (cells, clocks, constraints).
 in read_cell_library  loads scan cell models (pin names for SI, SO, SE, etc.) and
ATPG timing information. This mapping lets tessent know: “when i insert a scan cell, i
will use this library cell.”
 add_input_constraints, add_clock ---- tells the tool about clock domains and IO
timing; crucial for correct grouping of regs into chains and for later ATPG captures.

 This input_constraint command tells the DFT/ATPG tool how certain primary inputs or
internal control signals should behave during test mode.
 Some inputs or signals in real designs:-  cannot toggle freely during test .
 should not change during scan shift .
 may cause corruption if driven incorrectly.

Tessent Scan Inputs and Outputs:-

 tessent Scan uses multiple inputs and produces several outputs during the scan
insertion process.

 Tessent Scan uses the following inputs:-

 Design (netlist) – A Verilog gate-level netlist needs to be provided as input.
  Dofile or Tcl file (circuit setup) -- this is set of commands that gives the tool
information about the circuit and how to insert test structures. You can issue these
commands interactively in the tool session or place them in a dofile ot tcl file.
 Library – the tessent cell library contains descriptions of all the cells the design uses.
The library also includes information that the tool uses to map non-scan cells to scan
cells and to select components for added test logic circuitry.
 Input TCD File:- if there are pre-existing scan segments that are described in a
*.tcd_scan file, you need to provide them as input to scan insertion. You can read them
in using the set_design_sources command. The full syntax of the tcd_scan file appears
in the scan section of the tessent shell reference manual. Also, if there are CTL models
for pre-existing scan segments, you can convert these using stil2tessent before reading
them in.
 Test Procedure File – this file defines the stimulus for shifting scan data through the
defined scan chains. This input is only necessary on designs containing pre-existing scan
circuitry or requiring initialization for test mode (test setup).

 Tessent Scan produces the following Outputs:-

 Design (Netlist) – this netlist contains the original design modified with the inserted
test structures. The output netlist format is gate-level Verilog.
 TCD (tessent core description) – this file contains all the Scan modes that were
specified during scan insertion. The ATPG tool uses this file to generate patterns. If you
read in any .tcd files from a previous insertion pass or form a lower level core, the scan
modes are appended to the input *.tcd file and written out into the tsdb_outdir
directory.

 Adding Clocks:- In order to define and operate scan chains, the appropriate clocks must be
defined.
add_clocks 0 clk
add_clocks 0 set
 Set_current_design :- sets the active design to the one just loaded for performing DFT
operations.
 Set_design_level sub_block/ chip :- Specifies that scan insertion will be applied at the sub-
block level of the design hierarchy.
 Check_design_rules :- checks the design against DFT rules for errors or warnings.

Why test logic :-

 Some designs contain uncontrollable clocks/set/reset circuitry
 Sequential devices must be controllable to be converted to scan
 Ram reads/writes and three-state logic must be controllable to be testable.
  The purpose of adding test logic in front of sequential and memory elements is to ensure
that the ATPG applications have the required control in order to make these devices
scannable.
 set_test_logic – set on –reset on –clock on :- this command to tell the tool where you want test
logic added.
 add_nonscan_instances :- you may want to instruct tessent scan to ignore a specified instance
from scan insertion process, this can be a TAP controller instance that you need to exclude from scan
insertion or may be EDT logic.
@ the tool will not perform the scannability rule checks on these non- scan instances.

 In design rule check :- it performs design rule checks -- that means it verify correct scan
operation – verify controllability flipflops.
in this step, tessent scan performs model flattening, learning analysis, rules
checking, and scannability checking to verify correct scan operations and controllability of
the flipflops.

Design rules checking is performed in the following order: First, the general rules are
checked.
• The General rules check searches for very high-level problems in the information defined
for the design.
• For example, it checks to ensure the scan circuitry, clock, and RAM definitions all make
sense.
• The violations of these rules are errors, and their handling cannot be changed.
• Next comes, the T rules or the scan chain tracing rules.
• The purpose of scan chain tracing is for the tool to identify the scan cells in the chain and
determine how to use them for control and observe points.
• Successful scan chain tracing ensures that the tools can use the cells in the chain as
control and observe points during ATPG.
 These checks use the information from the tcd_scan or test procedure file, which has
already been checked for general errors during the procedure rules checks and the defined
scan data.

 Scan/test logic insertion :-

 insert_test_logic – performs scan substitution and stitching based on settings:
 Specified number of chains
 Max length of chains
 Clock domain handling
 Other insertion options
 Scan chain ordering (via file)

 Following the tessent scan flow, after performing the design rule checks and the tool
transits to the “Analysis mode”.
  The command “insert_test_logic” will perform scan elements substitution and scan
cells stitching based on the specified number of chains you have added, the maximum
length of scan chains, how different clock domains are handled, any other insertion
options you have specified, and based on any scan chain ordering you have instructed
the tool to follow.
 Tessent scan will add a lockup latch at the transition of the two clock domains which
eliminate skew issues. By default, add a lockup latch at the transition of the two clock
domains. Having this latch would make sure that data is held for a half cycle before the
second flop is pulsed. This is done automatically, as the “-single clock domain chains”
switch is off by default.
 Balance scan chains :- by either specifying the maximum length of chains, using the
command “ add_scan_mode ” with the “ –chain_length ” switch, the tool then
calculates the number of chains accordingly.
add_scan_mode – chain_length 200  add_scan_mode – chain_count 25

 Multi-mode scan chains :- one of the most important features of the tessent scan tool
is the support for multi-mode scan insertion with optimal scan chain lengths across all
modes.  multi – mode scan chains are used for the following:
 To bulid bypass,
 Single chain bypass
 Or multi chain bypass if EDT IP is not built with one.

 Analyze_scan_chains :- what if analysis with multiple modes with analyze_scan_chains

 use of this “ analyze_scan_chains ” command after defining the modes, this
command distributes scan elements into new scan chains, and displays this information
to the screen or in a transcript.
 Do "analyze_scan_chains" one more time, and if the results are satisfactory, you
may consider performing the scan stitching with the current configuration, using the
insert_test_logic command, this is where actual implementation takes place.
 you can also use the “ report_scan_chains ” command which displays a report of all
the current scan chains.

What are test points?

 Test points are special test circuitry added to certain design locations for better
controllability and observability to increase the testability of the design.
 Design contain a number of internal nodes that are difficult to control or observe. Even in
designs that are fully scan inserted.
 By adding special test circuitry called test points to, these locations, it is possible to increase
the testability of the design.
 One input of an "OR" gate is tied to a 1 which blocks the ability to propagate the fault effects
of the second input through this "OR" gate.
  Thus, an observe test point is needed on the second input of the "OR" gate to improve
observation.
 The tied input also causes a constant 1 at the output of the "OR" gate. • This means any
circuitry downstream from the output is uncontrollable.
 The pin at the output of the gate becomes a test point to improve controllability.
 Remember one thing, inserting test points before scan only to prefer
east to handle multi-scan, multi-mode, wrapped cores.
cleaner flow
better automation
 Test points ante → extra control/observe logic improve coverage kosam.

 Tessent lo rendu options unnayi: pre-scan and post-scan insertion.

 Pre-scan → better, because tool group chesi scan insertion lo include chestundi.

 Post-scan → sari ga work avtundi only single scan group unnapudu.

 Wrapped cores unte → post-scan problematic (external scan chains create cheyyali).

 So recommend → always insert test points before scan insertion.

What are the wrapper chains?

 Wrapper chains are one type of special scan chain created around a partition/
core/ module.
purpose:- 1. Improve controllability
2. improve observability
How?
at the inputs and outputs of the block (partition), tool adds extra scan flip-
flops .
so, for outside tester direct access it.
Wrapper chains = scan flip-flops placed at partition inputs/outputs to improve test access.

Where we add wrapper chains?

 We don’t add wrapper chains everywhere. We add them only at problematic
inputs/outputs, such as:
 low controllability inputs  inputs that atpg or tester cannot directly set (e.g.,
gated, tied-off, or deeply buried signals).
 low observability outputs  outputs whose values do not propagate to chip-
level outputs (e.g, masked signals, internal feedback).
  its main goal is to make uncontrollable inputs controllable and unobservable outputs
observable during test.

How does a wrapper chain work?

 The problematic flipflops are grouped together to form a scan chain.
 Tessent adds two new design-level pins:
wrapper scan-in
wrapper scan-out
During test mode:-
1. Tester shifts values into the uncontrollable inputs  now they become controllable.
2. Tester captures values from the unobservable outputs  now they become observable.
3. These values are shifted out through the wrapper scan-out pin.
 For improving test coverage we need wrapper chains.
 Reduce test time also
Set_wrapper_analysis_options // set-dedicated_wrapper_cell_options // analyze_wrapper_cells //
report_wrapper_cells

Set_wrapper_analysis_options :- "set_wrapper_analysis_options", which sets up the parameters for

the wrapper cell analysis, parameters like:
 "output_fanin_flop_threshold", which specifies the maximum number of sequential elements
allowed to be reached during the backward tracing from a primary output.
 "input_fanin_flop_threshold", that specifies the maximum number of sequential elements allowed to
be reached during the forward tracing from a PI. The default value for both the parameters is 32.
 “exclude_ports", which specifies a list of ports to be excluded from wrapper analysis.
"register_undriver_output", specifies whether an output port having no functional source should
receive a dedicated wrapper cell or not, the default is off and there are a few more options.

What is a graybox?
 A graybox is a simplified scan model of a core. Instead of using the entire core netlist
(all logic, all gates), the graybox model only keeps:
 Periphery logic (boundary scan chains, wrapper chains, decompressor/compactor
connections).
 Scan chain connectivity inside the core (but not the full internal logic).
 Graybox = scan chain + boundary logic representation of the core.

Where do we use graybox?

 We use graybox models in hierarchical DFT flows, where multiple cores/blocks exit
inside a large SoC.
 core-level ATPG: run full ATPG on the complete core with full logic  generate
patterns.
 chip-level ATPG (retargeting): replacing the core’s full netlist with a graybox model
only need scan wrapper, decompressor, compactor and chain connectivity.
  Reduce memory footprint , faster runtime and scalable hierarchical flow and finally
pattern reuse we use grayboxs.

Scan operation:-

Operations :-
1. Loading:- it means loading the patterns for scan chain.
2. Shift in:- patterns should goes to SI (scan-in)
3. Capturing:- when scan enable is ‘0’, capture the functional mode.
4. Shift out:- capture response is seriallyout in scan-out [so]
5. Unloading:- in scan chain after shifting data, it will clean the circuit and prepares for next level.

1) Select shift mode, SE=1.

2) Shift-in/load scan cell values.
3) Select capture mode, SE=0.
4) Apply/force primary i/p’s.
5) Measure primary o/p’s.
6) Capture combinational logic response into scan flops.
7) Select shift mode, SE=1.
8) Shift-out / unload the scan cells data.
9) Shift-in the next scan pattern.
Process repeats again and again.

DRC rules

Rule 1:- All internal clocks must be controlled by a port level clock.
 where used?- in clocking logic and scan insertion stages.
 when checked? – at RTL linting, dft DRC, scan insertion, and ATPG.
 how to implement/fix? – insert a mux controlled by test_mode that selects b/w the functional
Clock (PLL, divider) and a primary test clock input. During scan, always drive ffs with this safe
Test clock.
 why needed? If scan flip-flops are driven by uncontrolled internal clocks, ATPG cannot shift or
capture patterns, leading to untestable elements and low coverage.

Rule 2:- Avoid combinational feedback loops.

 where used? – in combinational RTL logic such as arbiters, encoders and control logic.
 when checked? – during RTL linting and DFT DRC checks.
 how to implement/fix? – in test mode, break the feedback loop using a mux or a test-point so
The loop becomes a stable constant or is disabled.
 why needed? – combinational loops create oscillations or unpredictable values, which ATPG
Marks as untestable. Breaking the loop ensures stability in scan test mode.

Rule 3:- Asynchronous Reset/Set must be controlled by a port level reset.

 where used? – reset/set networks for sequential elements.
 when checked? – At RTL, during scan insertion, and in ATPG readiness.
 how to implement/fix? – in test mode, all asynchronous resets must come only from a
primary reset pin, internal resets generated by logic should be masked or bypassed. active-low resets
should be de-asserted during scan shift.
 why needed? – if asynchronous resets toggle randomly during scan shifting, the scan chains
breaks, causing uncontrolled x values.

Rule 4:- gated clocks must be enabled in scan mode.

 where used? – integrated clock gating (icg) cells or custom clock gating logic.
  when checked? – At scan insertion and DFT DRC.
 how to implement/fix? – force all clock gates open during test mode by driving their enable
pins with test_mode.
 why needed? – if clock gates remain closed, flipflops behind them cannot shift or capture
scan data, breaking the scan chain.

Rule 5:- Avoid latches, if present, make them transparent in test.

 where used? – in datapath storage, low-power bus holders, and asynchronous paths.
 when checked? – during RTL linting and DFT analysis.
 how to implement / fix? – in test mode, make all latches transparent by forcing their enable
signal ON, or replace them with scan- friendly flip-flops.
 why needed ? – latches are level – sensitive and introduce timing uncertainty during scan
shifting, leading to uncontrollable/ unobservable nodes.

Rule 6:- Do not replace shift registers with scan flipflops.

 where used? – in serializers, counters, and shift-based datapaths.
 when checked ? – during RTL and scan planning.
 How to implement/fix? – instead of replacing shift registers with scan ffs, introduce a scan
enable that freezes the shift register in test mode and allows the scan chain to bypass or work
independently.
 why needed? – functional shift registers are efficient replacing them with scan ffs increases
area and may break design functionality, properly controlled, they can be tested without replacement.

Rule 7:- Do not use clock as data.

 where used? – in designs where clock signals are mistakenly used in combinational data
paths.
 when checked? – during RTL linting and DFT DRC.
 how to implement /fix ? – in test mode, replace the clock-as-data signal with a stable
constant or a safe test signal using a mux.
 why needed? – a clock used as data creates glitches and metastability , which prevents
predictable scan shifting and ATPG capture.

Rule 8:- bypass memories in scan mode.

 where used? – for SRAM, ROMs and FIFOs.
 when checked? – during RTL design, MBIST planning, and scan insertion.
 how to implement/fix? – add test bypass muxes around memory inputs and outputs. Disable
memory operations during scan, and use MBIST controllers for memory testing instead of scan.
 why needed? – memory values are not directly controllable or observable faults through
memories.

Rule 9:- buffer the scan enable signal.

 where used? – in physical design
  when checked? – during netlist handoff, synthesis, and PnR
 How to implement/fix? Treat scan_en like a high – fanout clock signal and build a buffer tree
for it. No combinational logic should be present on this net.
 why needed? -- a weakly driven or heavily loaded scan_en net causes glitches or slow
transitions, which can result in scan shift errors.

Rule 10:- Negative-edge ffs must Align with positive-edge in test.

 where used? – in designs with mixed positive edge and –ve edge triggered ffs.
 when checked? – At scan stitching, lockup insertion, and occ integration.
 how to implement/ fix? – in test mode, invert the clock going to negative-edge flops or insert
lockup latches between opposite-edge chains. This ensure that only a single capture edge isused during
ATPG.
 why needed? – if both edges are used during capture, it creates race conditions and
unpredictable results, making the design untestable.

ATPG process
What is ATPG?
 ATPG = automatic test pattern generation
 Its purpose is to automatically generate test patterns (set of 1s and 0s) that can detect
manufacturing defects in a chip.
 The 1st input of ATPG is scan inserted netlist until and unless your design is purely
combinational logic.
 2nd input is SPF (synopsys procedure file or stil procedure file).
 3rd input is which fault model you need (stuck at fault, transition).
 4th input is design model (compression mode, bypass model).

Why do we need ATPG?

 During manufacturing, chips may have defects (shorts, opens, stuck-at, delay faults, etc.)
 These faults must be detected before shipping to ensure high yield and reliability.
 ATPG generates a minimal set of patterns that gives maximum fault coverage.
 This reduces test time, ATE cost, and ensures defect-free chips reach customers.

How ATPG works (step by step)?

1. Inputs to ATPG:-
 scan inserted netlist (design with scan chains already added).
 fault models (e.g., stuck-at, transition).
 constraints/setup files (timing, power, design restrictions).

2. Fault list creation:-

 ATPG tool creates a list of all possible faults in the design.
  example:- stuck-at-0, stuck-at-1 at each node.
3. Pattern generation:-
 For each fault → ATPG tries to:

 Activate the fault (force the node to opposite value of stuck-at).

 Propagate the fault to an observable output/scan cell.
 Justify the inputs (backtrack to primary inputs or scan chain inputs to make this
condition happen).

 Compaction:

 ATPG compresses multiple detections into fewer patterns.

 Reduces total number of test vectors.

 Outputs of ATPG:

 Test patterns (in STIL, WGL, or other tester formats).

 Fault coverage report (% of faults detected).
 Diagnostic patterns (optional, for failure analysis).

 Verification:

 Simulation testbench is run to verify generated patterns on scan-inserted netlist.

 Ensures patterns behave as expected before sending to tester.

When Do We Apply ATPG?

 After scan insertion is done and verified.

 When the design is ready for manufacturing test preparation.
 Before chip goes to ATE (Automatic Test Equipment).

So the flow is:

RTL → Synthesis → Scan Insertion → ATPG → Simulation → ATE test.

4. Fault testing flow:-

 in atpg/dft testing, when we want to detect a fault inside the circuit (ex: stuck-at-0 or stuck-
at-1), two conditions must happen:
1. Fault Activation  we must give an input pattern that makes the faulty node behave
differently from the fault-free circuit.
2. Fault Propagation  that difference must travel (propagate) through the logic and reach
an observable point.
2. Fault Activation (First Step)

👉 Idea: "Switch ON the fault"

 Suppose we have a stuck-at-0 fault on a line.

 To activate it, we must apply inputs such that in the good circuit, this line would have
become 1.
 But in the faulty circuit, since it is stuck-at-0, there will be a mismatch (1 vs 0).

🔹 Example from diagram:

If A=1, B=1 and we have an AND gate output line stuck-at-0 →

 Good circuit output = 1

 Faulty circuit output = 0
 Difference created ✅ (fault activated).

3. Fault Propagation (Second Step)

👉 Idea: "Take the fault to the output where tester can see it"

 Once the fault effect (1 vs 0 difference) is created, it must propagate through the circuit.
 For propagation, we need to give inputs that do not block the fault.

🔹 Example from diagram:

If the faulty AND output goes to an OR gate:

 To propagate, the other OR input must be 0 (so the output fully depends on faulty signal).
 If the other input = 1, fault will be masked (not visible).

Define black boxes?

 A black box is a design instance(module/block) that has no defined internal
model for the ATPG tool.
 to the tool, it looks like a “sealed box”:
 inputs – tool can apply values.
 outputs – tool cannot predict what comes out (drive X).
 inside logic is unknown (not elaborated/defined).

Why Do We Use Black Boxes?

We intentionally mark some blocks as black boxes because:
 1. Undefined Models
o Sometimes your design references modules that are missing in the netlist or
library.
o ATPG will throw errors if it sees an instance but no definition.
2. Analog/Mixed-Signal Blocks
o ATPG only works for digital logic.
o If you have analog IP (PLL, ADC, DAC, SerDes, RF, etc.), you cannot test them
with scan/ATPG.
o So we black-box them.
3. Proprietary IP / Hard Macros
o Some IP vendors don’t give gate-level models (e.g., security blocks, memory
macros, encrypted netlists).
o Instead of blocking the ATPG run, we black-box them.
4. To Continue Analysis with Incomplete Designs
o Even if parts are missing, we can still run ATPG for the rest of the design.

What Happens When You Black Box?

 Outputs of black box = drive X values (unknown).

 Inputs of black box = treated as fault sinks (you can control them, but faults don’t
propagate beyond).
 This may reduce fault coverage since faults cannot be propagated through unknown
logic.

Where Do We Use Black Boxes?

 In Scan/ATPG flows when design has:

o Analog/mixed-signal IP.

o Memories (if not modeled).

o Vendor IP without gate-level model.

o Undefined modules during netlist import.

Example flow in Tessent:

1. read_verilog (load design).

2. Tool says: Module XYZ not found.
3. You decide:
 If you have a model → load it using read_verilog / read_cell_library.
  If you don’t → use add_black_boxes [Link] (English + Telnglish)

 Black box = design block with no internal model for ATPG.

 Used when model is missing, analog IP, proprietary IP, or incomplete design.
 Tool shows warning because it cannot elaborate undefined modules.
 You solve it by either providing the missing model or black-boxing the block.
 But downside → fault coverage decreases since unknown logic drives X’s.

ATPG SETUP:- Test Procedure Files

 When you setup a circuit in tessent scan, you start with a scan – inserted gate-
level netlist, a test procedure file that contains information about the circuitry
tessent scan inserted into the design, an ATPG setup dofile.

1. Scan-inserted Gate-level Netlist

 This is your design after scan chains are inserted.
 It already contains scan flip-flops, scan enable, scan-in, scan-out, etc.
2. Test Procedure File
 Generated when Tessent inserted scan.
 Contains what test logic was added, like scan chains, wrapper chains, clock controllers,
etc.
 Think of it as a "recipe book" of what was changed/added.
3. ATPG Setup Dofile
 A script file (.do) containing Tessent commands.
 Tells Tessent how to:
 Define clocks and resets.
 Define scan-enable signals.
 Map test pins.
Handle test modes.
 Without this, Tessent won’t know how to control/test your scan environment.
4. DFT Library
 Special library with descriptions of scan cells, test points, muxes, clock gates, OCC,
etc.
 Used by Tessent to:
 Convert non-scan FF → scan FF.
 Insert test structures.
 Provide models for ATPG.
5. Design Library (Cell Library)
 Your technology library (standard cells).
 Needed to understand all gates (AND, OR, MUX, FF, etc.).

Go through the test proc file assignment ..there we can see detailed information about test proc
file. File name scan test files_rajasekhar.

DC scan insertion flow:

1. What is stil2tessent Utility?

 STIL (Standard Test Interface Language) → An IEEE standard format used to describe scan
chains, clocks, timing, and test procedures.
 Tessent tools (FastScan, TestKompress) do not work directly on raw STIL. They expect:
o A dofile (with Tessent commands).
o A test procedure file (TPF) (with timing templates).
 stil2tessent converts STIL → dofile + TPF.

2. Inputs and Options of stil2tessent

 -stil "filename" → Required Input STIL file (SPF or CTL).

 -tpf "filename" → Optional. Output Test Procedure File.
o If not given → tool auto-generates as <stilname>.proc.
 -dofile "filename" → Optional. Output dofile.
o If not given → tool auto-generates as <stilname>.do.

3. Outputs of stil2tessent

1. Dofile (.do)
o Contains Tessent shell commands.
o Defines:
 Clocks.
 Scan enable signals.
 Pin constraints.
 Scan chain grouping.
o Used during ATPG setup to tell Tessent how the design is structured for scan.
2. Test Procedure File (.proc)
o Defines timing sequences (called timeplates) for scan operations.
o Standard scan procedures:
 test_setup → put circuit into scan mode.
 load_unload → load values into scan chains / unload responses.
 shift → shift data inside scan chains.
o Basically, it tells Tessent how to toggle scan_enable, scan_clk, func_clk, etc.
during test.

ATPG setup process :-

 After scan insertion, we have:
 Scan – inserted netlist (design with scan FFs and chains).
 Dofile (tessent commands).
 Test proc file (timing definitions).

1. Setup :-
 Read scan-inserted netlist.
 Load libraries (DFT + standard cells).
 Read dofile (clocks, scan chain mapping).
 Read test procedure file (timing for scan operations).

2. Design rule checking (DRC):-

  Checks design for testability problems.
 Unconnected scan chain.
 Multiple drivers.
 Unknown X propagation.
 Missing clocks.
 You must fix these before generating patterns.

3. Configure ATPG:-
 Choose fault model: Stuck-at, Transition, Path Delay, etc.
 Set constraints (don’t care pins, tie-offs).
 Define test mode signals.

4. Generate Patterns:-
 ATPG generates a set of test patterns (vectors of 1s/0s).
 Each pattern:
o Fault activation → sensitizes a fault.
o Fault propagation → propagates faulty effect to an observable point.
 Patterns stored in STIL/WGL formats.

5. Save Results:-
 Coverage report (percentage of detected faults).
 Pattern count.
 Final ATPG database.

set_context patterns –scan:-

 tessent has different contexts (MBIST, compression, scan patterns, etc.).
here we tell tessent “ I’m going to work in ATPG/Scan context”, so that ATPG-related
commands become available.

Read_verilog <scan_inserted_netlist.v>
Read_cell_library ,dft_library.db>
 read_verilog – loads the scan-inserted netlist (already modified by tessent scan to add scan
chains, test points, etc.).
read_cell_library – loads the DFT/technology library:
- Cell timing & logical description.
- Info to map functional flops – scan flops.
- Defines components for ATPG like muxes, clock gating cells, scan cells.

Set_current_design <top_module_name>
tells tessent which module is the top-level design.
this is important because many designs have multiple modules (sub –blocks, IPs).

Add_black_boxes –modules {Ram PLL AES_core} :-

some modules (like memories, PLLs, analog IPs, encryption IPs) are not testable with scan.
black-boxing hides them from ATPG  tessent won’t try to generate patterns for their
internal logic.
instead, ATPG treats them as boundary models.

Dofile atpg_setup.dofile:-
a dofile is just a script with ATPG setup commands.
Contains: [Link] definitions, 2. Scan chain definitions, 3. Test mode & reset handling,
4. Control signals,.

Analyze_control_signals –auto_fix :-
tessent will auto-detect clocks & scan enables.

Add_clocks –name func_clk –period 10 –waveform {0 5} –pins {clk}

define each clock explicitly with period, duty cycle, and pin connections.
clocks are most critical for ATPG because fault activation/propagation depends on timing edges.

Add_input_constraints –pins {test_mode} –value 1

some signals must be fixed during ATPG, e.g:
[Link] mode = 1 (to enable scan)
2.resent_n =1 (to keep design out of reset).
3. control signals that should not toggle in test.
 There is also an older system command called "set_system_mode" analysis, which
basically does the same thing as the "check_design_rules" command.
 As part of the process, the design is flattened into an internal database.
 If there are no DRC errors reported, then the mode is set to analysis. If errors were
found, you stay in the setup system mode until the errors are fixed.
write_patterns my_patterns.stil –formate stil :- saves the ATPG patterns to a file.

What does flattening do?

1. Removes hierarchy
o Instead of modules inside modules, all gates and nets are brought into one level.
o Easier for the ATPG tool to analyze and traverse.
2. Adds scan/test info
o Includes scan chains, scan muxes, control signals.
o Stores trace of how scan cells are connected (scan trace).
 3. Stores DRC (Design Rule Check) fixes
o During ATPG setup, if Tessent finds any issues with clocks, resets, test constraints, they
get resolved.
o This info is stored inside the flattened model file.
4. Binary format
o Stored as .bin (compact and efficient).
o Used later for diagnosis (mapping tester failures back to faults in the design).

Why is Flattened Model Important?

 When you later run diagnosis (post-silicon failure analysis), Tessent needs to know:
o How scan cells are ordered.
o Which gate belongs to which fault site.
o What DRC fixes were applied.
 Instead of re-flattening every time, it just loads this flattened binary model quickly.

Which will have high fault coverage – LOC or LOS, and why?

 LOS → higher coverage, because it can launch transitions through more paths.
 But LOS = more timing violations (hold issues).
 LOC → safer, but slightly lower coverage.
  In LOS, the launch vector is directly controlled by the scan chain data during shift.
  ATPG can easily control the transition at the fault site.
  LOC depends on functional clock transitions, so some transitions may be hard to
activate.

 Standard pattern for stuck-at and transition fault – 11001100110011.

We measure Primary Outputs before capture clock because:

1. POs are driven directly by combinational logic, so their valid response is available
immediately after inputs are applied.
2. Capture clock overwrites scan FFs and internal states, which may mask or disturb PO
values.
3. In testproc file, this is defined by placing PO measurement strobes before the capture
clock event, while scan outputs are measured only after capture during shift-out.
👉 This ensures tester records the correct functional response without losing data.

Design Rule Overview:-

 Prior to scan insertion, the tool performs limited rule checks on the design as you switch from setup
to analysis mode. Part of the checking it does is scannability checking. (pg:- 3228 tshell_ref)

Retention Test pattern Generation:-

 Retention tests verify that certain scan cells, which are implemented using special retention cells,
hold their data values while the chip powered off.

Data rules:-
🔹 D1
 Rule: Checks for possible disturbance of values loaded/captured into scan cells.
 Meaning: After you load a value into a scan flop, it must stay stable until it’s shifted or
captured.
 Violation: If something (like uncontrolled clock/reset/glitch) corrupts the value.

🔹 D2
 Rule: During system capture, if a scan path from MASTER/SLAVE → COPY is
sensitized, the path must be unique.
 Meaning: Each scan flop (MASTER/SLAVE) connects to a COPY. If multiple
conflicting paths exist, capture may corrupt data.
 Violation: More than one path drives COPY at the same time → unpredictable captured
value.

🔹 D3
 Rule: For SLAVE-based scan cells, master_observe must propagate MASTER →
SLAVE correctly.
 Meaning: If a scan flop has MASTER/SLAVE pair, data should flow from MASTER
into SLAVE correctly during observation.
 Violation: If master_observe fails to sensitize the path, ATPG cannot check SLAVE
data.

🔹 D4
  Rule: In skew load procedure, data from one scan cell must propagate correctly into the
next MASTER.
 Meaning: When shifting, each preceding cell’s output must connect properly into the
next scan cell input.
 Violation: Broken/miswired chain, incorrect mux, or path blocked.

🔹 D5
 Rule: All memory elements (flops/latches) must be scannable.
 Meaning: Every storage element must either be in scan chain or flagged as non-scan
(e.g., RAM).
 Violation: If tool finds a flop/latch not included in scan chain.

🔹 D6
 Rule: All non-scan latches must behave as transparent latches.
 Meaning: If a latch is not scannable, it must pass data transparently when needed.
 Violation: If latch output is stuck or not transparent when expected → blocks test.

🔹 D7
 Rule: At the end of shift, scan flops’ clock inputs must not be 1.
 Meaning: After shifting, clock should be low (inactive), otherwise flops may capture
wrong values.
 Violation: Tool finds a scan clock still active → risk of corruption.

🔹 D8
 Rule: If MASTER → SLAVE only propagates when SLAVE is inactive, MASTER’s
clock must be active.
 Meaning: To observe SLAVE correctly, MASTER’s clock must allow propagation.
 Violation: If MASTER clock is gated/off, SLAVE becomes unobservable.
🔹 Summary (Simple)
 D1 → D4: Ensure scan data paths are stable, unique, and connected properly.
 D5 → D6: Ensure all flops/latches are scannable or transparent.
 D7 → D8: Ensure scan clocks are inactive when they should be, and observability of
MASTER/SLAVE is not blocked.