Problem A1 Failure Candidate Identification for Silicon Debug

Problem A1Failure Candidate Identification for Silicon Debug Speaker : Hsiu-Yi Lin Advisor : Chun-Yao Wang 2009.02.02

Introduction • Silicon validation: • The same test patterns are applied to both the pre-silicon netlist for simulation and the silicon for testing. • The simulation values are compared with the observed values of silicon.

Introduction(2) • Silicon debug: • Attempt to locate and fix the root-cause of mismatches • As designs aggressively grow up, it becomes complex to perform the debugging.

Problem Description • The purpose: Find the correct failure candidates • Failure candidate: the root-causes that cause the mismatches between pre-silicon simulation and silicon testing. Mismatches occur!! Is “n2” a failure candidate?

Input • Input: There are three files which represent the mismatches of silicon behavior • A pre-silicon flatten gate-level netlist in Verilog • A simulation value dump file for all signals • A silicon value dump file for the observed output signals

The pre-silicon flatten gate-level netlist in Verilog module DUT (O1, O2, O3, I1, I2, I3, I4); input I1; input I2; input I3; input I4; output O1; output O2; output O3; wire n1; wire n2; wire n3; wire n4; not G1 (n1, I1); not G2 (n2, I2); not G3 (n3, I3); or G4 (O1, n1, n2); nor G5 (n4, n2, n3); and G6 (O2, n4, I4); not G7 (O3, I4); endmodule

The simulation value dump file for all signals The silicon value dump file for the observed output signals I1 = 1 I2 = 0 I3 = 1 I4 = 1 n1 = 0 n2 = 1 n3 = 0 n4 = 0 O1 = 1 O2 = 0 O3 = 0 O1 = 0 O2 = 1 O3 = 0

“What if” analysis • A good manner to explain the mismatched behavior • Provide the ability to quickly evaluate a potential defect by changing the current value to the opposite one.

Example O1,O2,O3: 1 0 0 is the simulation values O1,O2,O3: 0 1 0 is the silicon values • Perform “what-if” analysis on “n2”

Main task • Implement a ‘what-if’ analysis engine to identify all possible final candidates. We can only apply ‘what-if’ analysis on one signal at a time. • It is impossible to apply ‘what-if’ analysis on all signals due to unaffordable run time. Therefore, we must include how to minimize the number of signals necessary to perform the ‘what-if’ analysis.

Output Number of performing the ‘what-if’ analysis: 5 n4 n2 n1 I1 I2 Number of final candidates: 2 n2 I2

Trim down the signals for ‘what if’ analysis • Static approach: • Rely on static analysis to eliminate unlikely signals. • Done before performing any ‘what-if’ analysis. • Dynamic approach: • Adaptively determine which signal is unnecessary According to the results of previous ‘what-if’ analysis

Static approach • it is needless to operate ‘what-if’ analysis on n1 • n3 is always ‘1’ n1: 01? n3: 1 n2: 1

Dynamic approach • Because n3 is not a candidate, n2 is not a candidate, too. • It is possible for n1 to be a candidate! n1: 0 n3: 1 (not a candidate) n2: 1

Program Execution Name and Syntax • The program name must be “identifyFC” • The Verilog design name is fixed to be “design.v” • The simulation value dump file name is fixed to be “sim.dump” • The observed value dump file name is fixed to be “obs.dump” • The output candidate report file name must be “FC.rpt” • The syntax of the program identifyFC is: • identifyFC -netlistdesign.v -sim_dumpsim.dump -obs_dumpobs.dump -out FC.rpt

Language/Platform • Language: C or C++ • Platform: SUN OS/Solaris, Linux OS

Evaluation • Correctness (40%) • Algorithm (40%) • CPU time and memory usage (20%)

Remark • We must ensure the correctness of the set of final candidates, and then minimize the number of signals necessary to perform the ‘what-if’ analysis as possible as we can. • The multiple input of one gate is existed. • The debug is based on single fault assumption(just perform ‘what-if analysis on the single signal’).

Problem A1 Failure Candidate Identification for Silicon Debug