Simulating Faults of Combinational IP Core-based SOCs in a PLI Environment

1. Simulating Faults of Combinational IP Core-based SOCs in a PLI Environment Pedram A. Riahi Zainalabedin Navabi Fabrizio Lombardi Electrical and Computer Engineering Department Northeastern University DFT 2005

2. Contents • Introduction • SOC Testing • Present Solutions • Proposed Solution • Faultlist Extraction in VPI • Graph Extraction in VPI • VPI Fault Simulation Environment • Simulation Results • Conclusion DFT 2005

3. IntroductionSystem-on-Chip (SOC) • Analogous to System-on-Board • Complex Functional Block: Cores • More Reliable • Faster • Cost-Effective • Requirements: • New Chip Design Paradigm: Reusable Cores • New Test Methodologies DFT 2005

4. IntroductionReusable Cores • Core Types: • Soft (Synthesizable) • Firm • Hard • Intellectual Property (IP) • In-house Cores • IP Cores DFT 2005

5. SOC TestingParadigm • To Complex to be Testes by Traditional Test Methods • Core-Level Testing Involves: • Additional Design For Test Structures • Generating Required Test Patterns • Chip-Level Testing Involves: • Justifying Test Sequences • Propagating Test Response DFT 2005

6. SOC TestingCore Integrators Issues • Unable to Simulate Faults and Generate Tests for IP Cores • Unable to Obtain the Optimized Test Sets for a Desired Fault Coverage • Decrease in Performance • Increase in Test Time DFT 2005

7. Present SolutionsCore- and Chip-Level Testing • Core-Level Testing: • System Chip’s Functional Test • Direct Access (I/O Muxing) • Local Boundary-Scan or Collar Register • Full-Scan/Built-in-Self-Test (BIST) • Proprietary Solution • Chip-Level Testing: • Cores with Internal Parallel Scan • Wrapper Parallel Scan • Embedded Memory BIST • Other DFT Features: IDDQ Testing DFT 2005

8. Proposed SolutionHardware Description Languages • VHDL, Verilog • Programming Language Interfaces (PLIs) • VHPI • VPI • Simulators Used: • Cadence NC-Verilog • Platform Used: • C DFT 2005

9. Proposed SolutionIdeal Solution • Providing an Environment to Share Information for Core Providers and Integrators without Losing their Property Rights. DFT 2005

10. Proposed SolutionGoal • IP Core (in Compiler Intermediate Format) • Transparent while Protected IP Cores • Collapsed Chip-Level Faultlist • Optimized Test Set • Just Chip-Level Testing • Cores with Internal Parallel Scan • Embedded Memory BIST • Other DFT Features: IDDQ Testing DFT 2005

11. Faultlist Extraction in VPIRequirements • Core Providers: Post-Synthesis Circuit • Core Integrators: Post-Synthesis Circuit in Simulator’s Intermediate Format • Fault Model: Stuck-at • Gate and Switch Terminals • Wired Nets • Expanded Vector Nets • User-Defined Primitives (UPD) Terminals DFT 2005

12. Faultlist Extraction in VPIProcess • IP Core Black Box as List of Accessible net and reg Objects (Nodes) • Injecting Faults by Forcing and Releasing Values on Each Node DFT 2005

13. Faultlist Extraction in VPIVPI Routine I • Scanning All the Modules Inside the Top Module topmodItr = vpi_iterate(vpiModule, NULL); ... flist = NULL; while (topmodHndl = vpi_scan(topmodItr)) if ((modItr = vpi_iterate(vpiModule, topmodHndl))) while (modHndl = vpi_scan(modItr)) flist = insert_modulefault(modHndl); DFT 2005

14. Faultlist Extraction in VPIVPI Routine II • Extracting the Design Faultlist in insert_modulefault(modHndl). for(i=0; i<2; i++) { switch(i) { case 0: nodeItr = vpi_iterate(vpiNet, modHndl); break; case 1: nodeItr = vpi_iterate(vpiReg, modHndl); break; } if (nodeItr) { while (nodeHndl = vpi_scan(nodeItr)) { if (bitItr = vpi_iterate(vpiBit, nodeHndl)) while (bitHndl = vpi_scan(bitItr)) head = insert_faultinfo(bitHndl, i); else head = insert_faultinfo(nodeHndl, i); } } } } if (moduleItr = vpi_iterate(vpiModule, modHndl)) while (moduleHndl = vpi_scan(moduleItr)) head = insert_modulefault(moduleHndl); return(head); DFT 2005

15. Graph Extraction in VPIRequirements / Process • Core Providers: Post-Synthesis Circuit • Core Integrators: Post-Synthesis Circuit in Simulator’s Intermediate Format DFT 2005

16. Graph Extraction in VPIVPI Routine I faultPtr = flist; while (faultPtr != NULL) { faultH = vpi handle by name(faultPtr->nodeName, NULL); faultPtr->nodeIO = <intermediate node>; if (dlItr = vpi iterate(vpiDriver, faultH)) while (dlHndl = vpi scan(dlItr)) if (vpi get(vpiType, dlHndl) != vpiPrimTerm) faultPtr->nodeIO = <input node>; if (dlItr = vpi iterate(vpiLoad, faultH)) while (dlHndl = vpi scan(dlItr)) if (vpi get(vpiType, dlHndl) != vpiPrimTerm) faultPtr->nodeIO = <output node>; if (faultPtr->nodeIO == <input node>) faultPtr->gateType = NA; else if (dlItr = vpi iterate(vpiDriver, faultH)) while (dlHndl = vpi scan(dlItr)) if (vpi get(vpiType, dlHndl) == vpiPrimTerm) faultPtr->gateType = vpi get(vpiPrimType, vpi_handle(vpiPrimitive, dlHndl)); faultPtr = faultPtr->next; } faultPtr = flist; DFT 2005

17. Graph Extraction in VPIVPI Routine II while (faultPtr != NULL) { faultH = vpi handle by name(faultPtr->nodeName, NULL); if (faultPtr->nodeIO != <output node>) { if (dlItr = vpi iterate(vpiLoad, faultH)) while (dlHndl = vpi scan(dlItr)) if (vpi get(vpiType, dlHndl) == vpiPrimTerm) { Lname = (char *)malloc(sizeof(char)*(SIZE)); strcpy(Lname, vpi get str(vpiFullName, vpi handle(vpiPrimitive, dlHndl))); tmpfaultPtr = flist; flag = ZERO; while ((tmpfaultPtr != NULL)&&(flag == ZERO)) { loadH = vpi handle by name(tmpfaultPtr->nodeName, NULL) if (ldItr = vpi iterate(vpiDriver, loadH)) while (ldHndl = vpi scan(ldItr)) if (vpi get(vpiType, ldHndl) == vpiPrimTerm) { Dname = (char *)malloc(sizeof(char)*(SIZE)); strcpy(Dname, vpi get str(vpiFullName, vpi handle(vpiPrimitive, ldHndl))); if (!strcmp(Dname, Lname)) { flag = ONE; <create node loadlist>/<create node driverlist> } } tmpfaultPtr = tmpfaultPtr->next; } } } faultPtr = faultPtr->next; } DFT 2005

18. VPI Fault Simulation EnvironmentCritical-Path Tracing / Two Value Deductive DFT 2005

19. VPI Fault Simulation EnvironmentVPI Routines I • Critical-Path Tracing • $CFS (‘‘CFS_faultlist’’); • Hierarchical node name: ».module name.net name • Stuck-at-zero (s-a-0) and Stuck-at-one (s-a-1) fields: 0: Not detected; 1: Detected. • Node critical status: 0: Not critical; 1: Critical. • Node extended status: 0: Not extended; 1: Extended. • Pointer to the next node in Stems to Check linked-list. • Pointer to the next node in Frontier linked-list. • Pointer to the next node in fault-list. • Node value status, vpiScalarVal: vpi0, vpi1, vpiZ, and vpiX. • Node input/outputs status: 0: Intermediate node; 1: Input node; 2: Output node. • Node level status (distance from the corresponding primary output of the node cone). • Gate type, vpiPrimType, which node is its output. Valid entries are: vpiAndPrim, vpiNandPrim, vpiNorPrim, vpiOrPrim, vpiBufPrim, vpiNotPrim. • Pointer to the next node in node’s driver-list. • Pointer to the next node in node’s load-list • $CFS (‘‘CFS_graph’’); • $CFS (‘‘CFS_critical’’); • $CFS (‘‘CFS_report’’); DFT 2005

20. VPI Fault Simulation EnvironmentVPI Routines II • Two-Value Deductive • $DFS (‘‘DFS_faultlist’’); • Hierarchical node name: ».module name.net name • Stuck-at-zero (s-a-0) and Stuck-at-one (s-a-1) fields: 0: Not detected; 1: Detected. • Event status: 0: No event is caused by re-evaluating the gate’s output fault-list; 1: Re-evaluated fault-list is different from gate’s output old fault-list. • Pointer to the next node in fault-list. • Node value status, vpiScalarVal: vpi0, vpi1, vpiZ, and vpiX. • Node input/outputs status: 0: Intermediate node; 1: Input node; 2: Output node. • Node level status (distance from the corresponding primary output of the node cone). • Gate type, vpiPrimType, which node is its output. Valid entries are: vpiAndPrim, vpiNandPrim, vpiNorPrim, vpiOrPrim, vpiBufPrim, vpiNotPrim. • Node tag for already detected output fault. • Pointer to the next node in node’s driver-list. • Pointer to the next node in node’s load-list • $DFS (‘‘DFS_graph’’); • $DFS (‘‘DFS_deduct’’); • $DFS (‘‘DFS_report’’); DFT 2005

21. Simulation ResultsCritical-Path Tracing / Two Value Deductive • Benchmarks: ISCAS85 • Test Sets: Generated by HITEC • Platform: Sun SPARC Workstation (1GB RAM) DFT 2005

22. Simulation ResultsComparison I • PROOFS • VPI-based Serial Fault Simulation DFT 2005

23. Simulation ResultsComparison II • VPI-based Serial Fault Simulation • Graph Extraction not Required • Protecting Core Providers’ IP • Slow Runtime and Large Memory Requirement • VPI-based Critical-Path Tracing and Two-Value Deductive Fault Simulations • Graph Extraction Required • Core Providers’ IP has to be Protected through Simulator • Improvement in both Runtime and Memory Usage DFT 2005

24. Simulation ResultsComparison III • VPI-based Critical-Path Tracing and Two-Value Deductive Fault Simulations • Require Post-Synthesis Simulator’s Intermediate Format • Large Runtime • Protects IP by introducing more restrictive features in VPI • Commercial Fault Simulators • Require Gate-Level Information of the Design • Better Runtime Due to Using Faster Algorithms • No IP Protection DFT 2005

25. Conclusion / Future Works • A New Test Methodology using PLI for Performing Fault Simulation of Combinational or Full Scan IP Core-based Designs for SOCs • Improvement over VPI-based Serial Fault Simulation • Performance Improvement: • Performing Fault Collapsing • Implementing Other Fault Simulation Algorithms • Using Mixed-Level (Behavioral/Structural) Model of the Design DFT 2005