Resolution of Interoperability challenges in Automatic Test Point insertion across different EDA vendors
Dr. Satish Chandra Tiwari & Manjunatha M (Sankalp Semiconductor)
Abstract: For a typical design there may be some design corners where ATPG tool/algorithm may find hard to generate patterns for fault detection. This leads to loss of coverage or increase in pattern count. To overcome this issue EDA tools(DFT/ATPG) provide options to insert Control logic on locations/nodes with poor controllability or Observe test logic on locations/nodes with poor observability, these are referred as Test Points. ATPG tools suggest Automatic Test Point (control/observe) along with insertion locations pertaining to following goals:
- Coverage improvement
- Pattern count reduction
Following are the two flows generally used for generating Automatic Test Points:
- Automatic Test Point Generation at DFT insertion stage
- Automatic Test Point Generation at ATPG stage
In both of the above cases the outcome will be a file having Test Point type and location where it has to be inserted (along with other relevant information dependent on tool eg. probable equivalent coverage improvement once the Test Point is inserted, number of faults targeted etc.). This file can be used by DFT insertion tool to insert suggested Automatic Test Points.
Challenge: All the three major EDA vendors provide DFT/ATPG tools, though one major issue in the above flow is that designers use DFT insertion tool from one EDA vendor and ATPG tool from other. So Automatic Test Point file generated from one EDA tool cannot be used as is by DFT insertion tool from other EDA vendor.
Organization of paper: This paper will first discuss different type of Test Points offered by EDA vendors followed by automatic Test Point file and their formats. Finally, a solution to the challenge will be discussed followed by conclusion.
Introduction
The control and observe Test Points offered by EDA vendors have different logical architecture (refer user guide of respective tool for further information on this). Following are the different types of Test points offered by major EDA vendors:
Control Test Points:
Tessent supported Control test Point: It is provides two types of control points:-
- AND Control Point:
- OR Control Point:
Control points are not going to change at capture cycles. The tool does not insert the AND and an OR control points in a same net, since these points are mutually exclusive.
RTL Compiler/Encounter Test supported Control Test Points: It is provides two types of control points:
- async_0 (async_1) : It inserts an asynchronous control point that forces to the value 0 (1)
- Async_any : It inserts control test point that forces the test point to take the original value or the inverted value
- control_0 (control_1) : It inserts a control test points which drives the control node to a logic 0 (1) during test mode
- Control_node : It inserts a test points which use to control the net from the interested node
- Control_scan: Inserts a flip-flop to apply a particular value at the interested location during test operation. This flop must be remapped to scan flop and connect it to a scan chain
- sync_0 (sync_1): It forces the control point to the value 0 (1) by inserting a synchronous control test point
- Sync_any : It Inserts a synchronous type control test point, it forces the control point to take the original value or the inverted value
- Control_observe_0 : It inserts a control and an observation point and control point is forced to the value 0
- Control_observe_1 : It inserts a control and an observation point and control point is forced to the value 1
- Control_observe_node : It inserts a control and an observation point and control point is forced to the value of the node which is specified by the node
- Control_scan : Inserts a flip-flop to force a particular value at the specified location during test mode operation
- Scan : It inserts a scannable control and observation test point
DFT Compiler/TeetraMAX supported Control test Points: DFT compiler divides control test points in two categories i.e. Force test points and Control test points.
- Force Test Points :
- Force_0
- Force_1
- Force_01
- Force_z0
- Force_z1
- Force_z01
- Control Test Points :
- Control_0
- Control_1
- Control_01
- Control_z0
- Control_z1
- Control_z01
(Note: for detailed description related to logic, please refer to respective tool’s user guide)
Observe Test Points:
Tessent supported observe Test Point: Here, the tool forms a new scan cells at the output of gates while inserting observe point. The tool supports both dedicated scan cell per observation point or a scan cells shared by multiple observation points. For multiple nodes sharing a single flop, it insert an XOR tree.
RTL Compiler/Encounter Test supported observe Test Point: It inserts a flip-flop to observe a specific point such that its data input is connected to the signal/node which needs to be observed.
DFT Compiler/TetraMAX supported observe test point: An observe test point here is a scan register with its data input connected to the sink signal to be observed. For multiple nodes sharing a single flop, it insert an XOR tree.
(Note: for detailed description related to logic, please refer to respective tool’s user guide)
Automatic Test point insertion flow and output Test Point file formats
Automatic Test Point insertion is a feature generally provided by all ATPG tools. Here, algorithm searches complex nodes/logic in DUT (design under test) which are hard to control/observe and suggests insertion of control/observe Test Points for that location. If this is done while doing DFT insertion, it calls ATPG tool under the hood and gets relevant information and generates a file with suggested Test Points. If this is done at ATPG level, tool generates a file with suggested control/observe Test Points.
DFT Compiler/ TetraMAX: Automatic Test Point generation command/flow:
In TetraMAX there is a command “analyze_test_points” which can give you Test Point file based on the “-target” option opted.
Since Synopsys provides different options for “-target” switch, it generates the Test Point file based on selected option.
Test Point file format
1) When “-target” is “pattern_reduction”
Where,
“obs” column is the calculated SCOAP number. A lower number indicates a fault that is easier to test.
“faults” column is number of observed faults detected by the random patterns used during the analysis
“node” column is location for Test Point insertion
2) When “-target” is “testability”
In the output file, first section lists the control Test Points and second section lists the observe Test Points.
Where,
- “type” column can be either an AND (control_0) or an OR (control_1) gate.
- “node” is the connection point for one of the inputs of the test point.
- "obs" column is the number of faults that can be observed for the recommended node. The primitive IDs in parentheses are the XOR observe test point inputs.
RTL Complier/Encounter Test: Automatic Test Point generation command/flow:-
RTL compiler does Random Resistance Fault Analysis(RRFA) and Deterministic Fault Analysis(DFA) for Test Point insertion(for further information one can refer RTL Compiler user guide). Outcome of RRFA/DFA is a Test Point file. Following is the typical command to do RRFA
Test Point file format
Where,
- “type” specifies “O” for observe type test point and C0 and C1 for control 0 and control 1 type of Test Point
- “faults” specify number of faults targeted by the suggested Test Point
- “strength” specifies effectiveness of control point
The control type either C1(control_1)/C0(control_0) type based on the complexity of the design.
Tessent: Automatic Test Point generation command/flow:-
In Tessent ATPG it is required to specify “set_test_point_analysis_options” and “set_test_point_insertion_optioms” before running “analyze_test_points”.
For the above commands the running “report_test_points” will give us a Test Point file.
Test Point file format
Where,
- “TestPointLocation” is the node selected for Test Point insertion
- “TestPointType” specifies the Test Point to be Control or Observe type
- “ControlPointType” specifies whether the control Test Point is AND type or OR type
- “ScanCell” define which scan cell will be used for Test Point
- “ScanCellClock” specifies clock for Test Point connection
- “EnableSignal” specifies the enable for Test Point
Solution
As discussed in previous section, every ATPG tool can generate Test Point file for coverage improvement or pattern reduction which can be used by DFT insertion tool to insert Test Points. Also, as we discussed earlier, designers may use DFT insertion and ATPG tools from different companies. Hence, the Test Point file generated from ATPG tool from one company cannot be used by DFT insertion tool from other company as is. Once good solution to this issue is to convert the Test Point file generated by ATPG tool to a file which has manual Test Point insertion commands native to DFT insertion tool being used. Sourcing this new Test Point file in DFT insertion tool will insert the desired Test Points.
Example 1
If Tessent ATPG is used for Test Point generation and DFT compiler is used for insertion, one can convert the Test Point file information (generated by Tessent in system mode context set as testpoint) to a file having manual Test Point insertion commands native to DFT compiler.
Typical Test point file generated by Tessent
Using script the above file can be converted to to a file having corresponding manual Test Point insertion commands for DFT compiler.
New Test Point file
Sourcing the new Test point file in DFT Compiler will insert Test Points suggested by Tessent in design.
Example 2
If Encounter Test/RTL compiler is used for Test Point generation and DFT Compiler is used for insertion, one can convert the Test Point file information (generated by ATPG tool) to a file having manual Test Point insertion commands native to DFT Compiler.
Typical Test point file generated by RTL Compiler/Encounter Test
Using script the above file can be converted to a file having corresponding manual Test Point insertion commands for DFT compiler.
New Test Point file
Conclusion
Automatic Test Point is one of the effective ways to improve the coverage or reduce patter count by leveraging the DFT/ATPG tools. However, in cases when designers use EDA tool for DFT insertion and ATPG tool from different vendors it makes automatic Test Point insertion a challenging task. To overcome this issue the automatic Test Point file can be converted to a file having manual Test Point insertion commands for corresponding locations in format accepted by DFT insertion tool. Developing a script that can convert any Test Point file in different formats acceptable to different DFT insertion tools is the highly recommendable and productive.
If you wish to download a copy of this white paper, click here
|
Related Articles
- Next Gen Scan Compression Technique to overcome Test challenges at Lower Technology Nodes (Part - I)
- AI Challenges for Next-Gen EDA
- Viewpoint: EDA vendors must focus on making silicon profitable for their customers
- Product How-To: Interoperability comes to EDA
- How to perform meaningful benchmarks on FPGAs from different vendors
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |