Test Point Insertion (TPI)

Test Point Insertion (TPI) is an automated design-for-testability (DFT) technique that improves circuit testability by strategically inserting observation and control points into the design.

Overview

TPI analyzes testability metrics to identify hard-to-test signals and automatically inserts test points to improve fault coverage and test pattern effectiveness.

What TPI Does

• Analyzes Testability: Uses COP or SCOAP metrics to find signals with poor testability
• Designs Test Points: Creates observation and control points for maximum improvement
• Modifies Netlist: Inserts test point logic into the circuit
• Generates Verilog: Outputs enhanced design with DFT interface

Test Point Types

Observation Points

• Purpose: Make internal signals observable at primary outputs
• Implementation: Buffer inserted from internal signal to new primary output
• Benefit: Improves fault coverage by exposing internal faults

Control Points

• Purpose: Allow external control of internal signals during test mode
• Implementation: Mux inserted to select between normal signal and test input
• Benefit: Enables direct control of hard-to-reach signals

Quick Start

Prerequisites

TPI requires testability metrics from prior analysis:

# Generate COP metrics (recommended for TPI)
opentest cop -i design.v -j

# OR generate SCOAP metrics  
opentest scoap -i design.v

Basic TPI Workflow

# Step 1: Parse your Verilog design
opentest parse -i design.v

# Step 2: Generate testability metrics
opentest cop -i data/parsed/design.json -j

# Step 3: Insert test points
opentest tpi -i data/parsed/design.json \
             -m data/results/design_cop.json \
             -o design_with_testpoints.v

Command Options

tpi -i <netlist.json> -m <metrics.json> [OPTIONS]

Detailed Usage

Testability Threshold

The threshold parameter determines which signals need test points:

• Lower threshold (e.g., 20): Only worst signals get test points
• Higher threshold (e.g., 80): More signals considered for test points
• COP metrics: Signals with testability < threshold are candidates
• SCOAP metrics: Signals with high complexity scores are candidates

# Conservative - only worst signals
opentest tpi -i design.json -m metrics.json -t 20 -n 5

# Aggressive - improve many signals  
opentest tpi -i design.json -m metrics.json -t 80 -n 20

Working with COP Metrics

COP provides probabilistic testability metrics ideal for TPI:

# Generate COP metrics with JSON output
opentest cop -i design.v -j

# Use COP metrics for TPI
opentest tpi -i data/parsed/design.json \
             -m data/results/design_cop.json \
             -t 50 -n 10

COP metrics format:

{
  "analysis_type": "COP",
  "metrics": [
    {
      "output": "signal_name",
      "c1": 0.5,
      "obs": 0.2,
      "testability": 0.1
    }
  ]
}

Working with SCOAP Metrics

SCOAP provides complexity-based testability metrics:

# Generate SCOAP metrics
opentest scoap -i design.v

# Use SCOAP metrics for TPI
opentest tpi -i data/parsed/design.json \
             -m data/results/design_scoap.json \
             -t 50 -n 10

Output Format

TPI generates enhanced Verilog with professional DFT interface:

module design_tp (
    // Original interface
    clk,
    reset,
    data_in,
    data_out,
    // Test point interface - DFT
    tp_obs_internal_sig,
    tp_obs_critical_path,
    tp_ctrl_enable,
    test_mode
);

    // Original ports
    input clk, reset;
    input [7:0] data_in;
    output [7:0] data_out;
    
    // DFT ports
    output tp_obs_internal_sig;    // Observation point
    output tp_obs_critical_path;   // Observation point
    input tp_ctrl_enable;          // Control point input
    input test_mode;               // Test mode enable

    // Original logic preserved
    // ... existing gates ...

    // Test Point Gates
    BUFX2 U_TP_OBS_1 (.A(internal_sig), .Y(tp_obs_internal_sig));
    BUFX2 U_TP_OBS_2 (.A(critical_path), .Y(tp_obs_critical_path));
    MX2X1 U_TP_CTRL_1 (.A(enable), .B(tp_ctrl_enable), 
                       .S(test_mode), .Y(enable_muxed));

endmodule

Tool Compatibility

Generated Verilog is compatible with:

• Fault: ATPG (Automatic Test Pattern Generation)
• Yosys: Open-source synthesis
• OpenROAD: Physical design flow
• Verilator: Simulation and verification
• Commercial EDA tools: Synopsys, Cadence, Mentor

Example Workflows

Priority Encoder Example

# Step 1: Parse design
opentest parse -i data/input/priority_encoder.v

# Step 2: Generate COP metrics
opentest cop -i data/parsed/priority_encoder.json -j

# Step 3: Insert test points
opentest tpi -i data/parsed/priority_encoder.json \
             -m data/results/priority_encoder_cop.json \
             -t 50 -n 5

# Results
# Input: 17 gates, 34 signals
# Output: 22 gates (29.4% overhead), 5 observation points
# File: data/TPI/priority_encoder_tp.v

Large Circuit Example

# For large circuits, use higher thresholds and more test points
opentest tpi -i large_design.json \
             -m large_design_cop.json \
             -t 70 -n 50 -v

# Verbose output shows:
# - Candidate analysis
# - Test point design decisions  
# - Validation results
# - Performance statistics

Advanced Features

State Machine Workflow

TPI uses a robust state machine for reliable operation:

INITIALIZED → CANDIDATES_FOUND → CELLS_VALIDATED → 
DESIGN_COMPLETE → NETLIST_MODIFIED → VERILOG_GENERATED → COMPLETED

Technology Library Support

Currently supports Sky130 standard cells:

• Buffers: BUFX1, BUFX2, BUFX4, BUFX8
• Inverters: INVX1, INVX2, INVX4, INVX8
• Muxes: MX2X1, MX2X2 (for control points)

Validation and Reporting

TPI provides comprehensive validation:

• Signal connectivity: Ensures all connections are valid
• Bus signal handling: Proper expansion of bus declarations
• Name uniqueness: Prevents naming conflicts
• Improvement metrics: Reports testability improvement

Best Practices

Threshold Selection

• Start conservative: Use threshold 30-50 for initial runs
• Analyze results: Check if test points target critical signals
• Iterate: Adjust threshold based on coverage requirements

Test Point Count

• Balance overhead: More test points = better testability but higher area cost
• Consider routing: Physical design impact of additional I/O
• Target critical paths: Focus on signals that matter most

Metrics Selection

• COP for TPI: Generally better correlation with test quality
• SCOAP for speed: Faster analysis on very large designs
• Compare results: Try both metrics to see which works better

Troubleshooting

Common Issues

No test points inserted:

• Check threshold - may be too low
• Verify metrics file format
• Use -v for detailed analysis

Bus signal errors:

• Ensure Verilog uses proper [MSB:LSB] format
• Check for consistent bit ordering

Validation failures:

• Check original netlist quality
• Verify all signals are properly declared

Debug Options

# Enable verbose output
opentest tpi -i design.json -m metrics.json -v

# Check metrics file format
head data/results/design_cop.json

# Validate original netlist
opentest parse -i design.v -v

References

• Command Reference - Complete CLI documentation
• COP Analysis - Understanding COP metrics
• SCOAP Analysis - Understanding SCOAP metrics
• Examples - More usage examples