Download presentation
Presentation is loading. Please wait.
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
... 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 COM combinational optimization engine to reduce gate count EQV a sequential redundancy removal engine, to eliminate functionally redundant registers LOC a localization engine, to abstract the design IND a SAT-based induction engine, to perform light-weight proofs BMC a bounded model checking engine, to falsify or boundedly prove properties RET a min-area retiming engine RCH a BDD-based reachability engine CUT an input elimination engine Tilman Glökler et al.
7
Trace and Debug Bus Structure
Source 1 MERGE RAMP SPEED CONV Source 2 Source MUX Source DELAY Trace Analyzer 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
Tracedef Verification Flow and Testbench
Textual descriptions owned by design teams "Bugspray VHDL" Constrained Drivers Tracedef Description Testbench Generator Reference Model VHDL Design Traceconf Description "Bugspray VHDL Code" = "Bugspray Checker" Formal Verification with Sixth Sense Tilman Glökler et al.
9
Tracedef Formal Verification Results
Size Metric Initial COM LOC¹ COM ¹ EQV¹ Resources Inputs 33441 21492 11 792s 624MB Gates 924723 797710 596 493 Registers 142072 125520 193 Properties 128 1 ¹ Localization solves each property individually, only largest localized cone is reported Memory Controller Unit 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 Tilman Glökler et al.
10
What is "Fencing"? Control Unit Fenced Partition Irritator Partition A
activate_fence Fenced Partition Irritator Partition A Fence Logic ok error: unfenced latch! Random Logic Irritator Partition B Microprocessor Chip Actively fenced partition is supposed to hold its current state Tilman Glökler et al.
11
Formal Verification Results for Fencing
Size Metric Initial COM EQV IND Resources Inputs 548878 32362 843 211s 748MB Gates 748426 245309 43978 Registers 73368 23560 5922 Properties 4665 1837 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
Formal ABIST Verification
Shared ABIST engine ABIST result Registers in Scan Chain “array ok” 2 Address Registers 2 Data-Out Registers 2 Data-In Registers Array Tilman Glökler et al.
13
Formal ABIST Verification
Shared ABIST engine ABIST result Registers in Scan Chain “repairable failure” 2 Address Registers 2 Data-Out Registers 2 Data-In Registers Array Tilman Glökler et al.
14
Formal ABIST Verification
Shared ABIST engine ABIST result Registers in Scan Chain “unrepairable failure” 2 Address Registers 2 Data-Out Registers 2 Data-In Registers Array Tilman Glökler et al.
15
Formal ABIST Verification: Testbench
Shared ABIST engine ABIST result Registers in Scan Chain “Randomizing FSM” Fail? 2 Address Registers 2 Data-Out Registers 2 Data-In Registers 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 Memory Time per Run Total Time SixthSense 5.9GB 1611s HDL simulation 170MB 670s 670s x 129 Scenario: single-bit stuck-at fault in 128 bits or no error Tilman Glökler et al.
17
ABIST Verification Results 2/2
Size Metric Initial COM BMC 440,000 Resources Inputs 29176 29086 1611s 5976MB Gates Registers 246302 230495 Properties 6 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
ETR and EAF Overview n DBn ETR 2 1 z/System DB2 DB1
Atomic Clock 2 E A F 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 z/System 1 E A F DB2 DB1 Tilman Glökler et al.
19
EAF Overview EAF ETR TOD
DUT Testbench EAF DATA OSC ETR DATA TOD ETR Bit Stream TOD COUNTER IDLES DATA OTS s 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
Size Metric Initial COM EQV BMC 6,162 Resources Inputs 2957 18 16 1611s 5976MB Gates 72340 49489 3460 3264 Registers 9544 5576 725 Properties 3 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.
Similar presentations
