Enabling Large-Scale Pervasive Logic Verification through Multi-Algorithmic Formal Reasoning

1. Enabling Large-Scale Pervasive Logic Verification through Multi-Algorithmic Formal Reasoning Tilman Gloekler, Jason Baumgartner, Devi Shanmugam, Rick Seigler, Gary Van Huben, Barinjato Ramanandray, Hari Mony, Paul Roessler

2. Outline • Introduction • What is "Pervasive Logic"? • (Semi-) Formal Verification with SixthSense • Examples • Tracebus • Fencing • ABIST • Ext. Time Reference Attachment Facility • Summary and Conclusion Tilman Glökler et al.

3. What is "Pervasive Logic" (PL)? • PL includes the following functionalities: • Power-On-Reset Sequence • Initialization of latches and arrays • Interface Training • Security, Configuration etc. • Debug Features • Debug interfaces • Access to internal registers • Trace Analyzer, Performance Monitor etc. • Manufacturing Test Support • LBIST, ABIST, AVP, .... • PL Verification (PLV) has to deal with many chip level functionalities Tilman Glökler et al.

4. PLV Challenges • PL is tighly intertwined with the functional logic (FL) • long scan chains are used to initialize all the FL latches • trace bus traverses the complete hierarchy of FL • LBIST exercises the functional logic for manufacturing test • PL can usually not be isolated from FL • reasoning about designs with >10k to >100k registers required • PL properties are often sequentially very deep • POR and ABIST require >10M cycles to complete • Serially scanning of scan chains (shortest chain >2k registers) • multiple clock domains for e.g. internal logic & external interfaces (100:1) • PLV is historically based on simulation/acceleration In the following we discuss: • how we implemented testbenches to enable a formal approach • how we leveraged tuned formal algorithms for such tasks Tilman Glökler et al.

5. (Semi-) Formal Verification with SixthSense 1/2 • Sixthsense... • ... uses a "testbench" to define drivers and checkers (= verification properties) • ... is a system of cooperating algorithms: • Semi-formal algorithms for finding bugs • Formal algorithms for proving correctness • Transformation/abstraction algorithms for reducing problem complexity • Algorithms are encapsulated as synergistic engines • SixthSense has been tuned for application to large systems • PLV tasks nonetheless stretched the capacity of SixthSense Tilman Glökler et al.

6. (Semi-) Formal Verification with SixthSense 2/2 • SixthSense Engine Overview Tilman Glökler et al.

7. Source 1 Source 3 + 4 MERGE MUX Source 2 Source 5 + 6 DELAY TraceAnalyzer RAMP RAMP SPEEDCONV Trace and Debug Bus Structure • Trace/Debug Bus • Feed-Forward Tree Structure • Routes "Debug Data" to the Trace Analyzer • Simple Blocks Like Ramps, Muxes, Delays etc. • Needs Configuration Bits for Different Bus Settings Tilman Glökler et al.

8. TestbenchGenerator Tracedef Verification Flow and Testbench Textual descriptionsowned by designteams "Bugspray VHDL" ConstrainedDrivers TracedefDescription ReferenceModel VHDLDesign TraceconfDescription "BugsprayVHDL Code" = "Bugspray Checker" Formal Verification with Sixth Sense Tilman Glökler et al.

9. Tracedef Formal Verification Results • Note: problem size always includes design and testbench • Tracebus routes output of functional logic (FL) to a central location; drivers of testbench overwrite the contribution of FL with non-deterministic values • FL can be effectively removed by LOC (if design is correct!) • EQV-style induction solves the abstracted property ¹ Localization solves each property individually, only largest localized cone is reported Memory Controller Unit Tilman Glökler et al.

10. What is "Fencing"? ControlUnit activate_fence Fenced Partition IrritatorPartition A Fence Logic ok error: unfencedlatch! RandomLogic IrritatorPartition B Microprocessor Chip Actively fenced partition is supposed to hold its current state Tilman Glökler et al.

11. Formal Verification Results for Fencing • COM effective since fencing created some constants discernable by combinational analysis • EQV was useful to quickly reduce design size and eliminate simpler-to-prove non-toggling properties • IND was able to solve the remaining harder ones on the EQV-simplified design Tilman Glökler et al.

12. “arrayok” Formal ABIST Verification SharedABIST engine Registersin ScanChain ABISTresult 2 AddressRegisters 2 Data-OutRegisters 2 Data-InRegisters Array Tilman Glökler et al.

13. Formal ABIST Verification SharedABIST engine Registersin ScanChain ABISTresult “repairablefailure” 2 AddressRegisters 2 Data-OutRegisters 2 Data-InRegisters Array Tilman Glökler et al.

14. Formal ABIST Verification SharedABIST engine Registersin ScanChain ABISTresult “unrepairablefailure” 2 AddressRegisters 2 Data-OutRegisters 2 Data-InRegisters Array Tilman Glökler et al.

15. Formal ABIST Verification: Testbench SharedABIST engine Registersin ScanChain ABISTresult “Randomizing FSM” Fail? 2 AddressRegisters 2 Data-OutRegisters 2 Data-InRegisters Array Interceptors Tilman Glökler et al.

16. ABIST Verification Results 1/2 • Array had to be reduced to 4 words: reduction from 5,321,918 to 246,302 state bits • + ABIST engine run had to be reduced to one pattern per testbench: reduction from ~10M to ~31k cycles until ABIST complete • SixthSense BMC engine was tuned for sequentially deep designs • Results: formal vs. simulation Scenario: single-bit stuck-at fault in 128 bits or no error Tilman Glökler et al.

17. ABIST Verification Results 2/2 • sequentially extremely deep problem due to long scan chains • we know from directed simulation, how many BMC steps are needed for a proof, thus, BMC was able to prove our properties • not much potential for further reduction Tilman Glökler et al.

18. n 2 1 z/System E A F E A F E A F ETR and EAF Overview DBn ETR Atomic Clock ETR stands for “External Time Reference” and denotes a mechanism to keep all processor cores in all nodes of a system synchronized to the same (accurate) “Time Of Day” (TOD). EAF = ETR Attachment Facility DB2 DB1 Tilman Glökler et al.

19. DUT Testbench EAF DATA ETR DATA DATA DATA IDLES DATA IDLES IDLES OTS IDLES 1.048576 s OSC EAF Overview TOD TOD COUNTER ETR Bit Stream ETR and EAF are used in a multi-core system for time-of-day(TOD) synchronization Tilman Glökler et al.

20. EAF Verification Environment 1/2 Testbench EAF Port 1 Freeze 3. REG Driver Channel 2. REG ETR Sender 1 Sampler Checker 1. REG ETR Sender 0 Control / Interrupt Port 0 Freeze OSC 3. REG Channel 2. REG Sampler 1. REG Tilman Glökler et al.

21. EAF Verification Environment 2/2 Testbench: serial part Port 1 Port 1 Driver Checker ETR Sender 0 Control / Interrupt Port 0 Freeze OSC 3. REG Channel 2. REG Sampler 1. REG Tilman Glökler et al.

22. EAF Verification Environment Testbench: parallel part Port 1 Port 1 Freeze 3. REG Driver Channel 2. REG Sampler Checker 1. REG Control / Interrupt Port 0 Freeze OSC 3. REG Channel 2. REG Sampler 1. REG Tilman Glökler et al.

23. EAF Formal Verification Results for Serial Properties • sequentially very deep (multiple clock domains, significantly different rates) • COM was effective in pruning the design for parallel/sequential partitioning • EQV was very effective to reduce the problem size and speed up BMC run • usage of BMC similar to ABIST problem (upper bound of BMC steps was known in advance) Tilman Glökler et al.

24. Summary and Conclusion • PLV traditionally used only simulation and hardware acceleration due to • the high design complexity (>1M registers) • sequentially very deep problems (>1M cycles) • (Semi-) Formal Verification • was able to solve a variety of our PLV tasks after proper tuning • enabled an improved verification methodolgy • PLV still represents challenges for semi-formal approaches and is far from being a solved problem • More development on scalable algorithms/tools needed Tilman Glökler et al.