An Experience of Complex Design Validation: How to Make Semiformal Verification Work

1. An Experience of Complex Design Validation: How to Make Semiformal Verification Work by Orly Cohen, Moran Gordon, Michael Lifshits, Alexander Nadel, and Vadim Ryvchin Intel

2. Agenda Michael Lifshits, Intel

3. Why Semiformal Verification? Two main approaches to RTL validation • Formal verification (FV) • exhaustive (mathematical proof) • limited DUT size, complexity ~ exponential in the size of DUT • Dynamic simulation (DV) • unlimited DUT size, complexity ~ linear in the size of DUT • functionality coverage: no practical number of runs can provide exhaustive verification Validation gap keeps increasing… Michael Lifshits, Intel

4. Dynamic Simulation • Prone to controllability and observability • Full-chip simulation with checkers runs close to 0 Hz coverage Test bench corner case bugs DUT (RTL) checking stimulus all design behaviors DV cannot detect all corner-case bugs Michael Lifshits, Intel

5. Formal Verification • reduction, constraining complex interfaces • Limited capacity & high modeling effort • applied on few blocks only • Limited verified scenarios length • cannot address deep structures deep bugs FV modeling FV DUT bug free area initial states RTL block max FV bound all design behaviors FV cannot address “deep” bugs Michael Lifshits, Intel

6. Limited Verification Bound in FV • FV examines: 2^3=8 possible input patterns #scenarios = 2^(inputs X clock cycles) Michael Lifshits, Intel

7. Semiformal Verification Aims at Deep Corner-Case RTL Bugs • Utilize user guidance to reach much deeper scenarios in FPV • Detect bugs missed today • Decrease DUT FV manual modeling effort (black boxing, pruning, etc.) Covered by DV Covered by FV Michael Lifshits, Intel

8. BMC-Based Semiformal Verification defined with SVA cover Create a path with ‘waypoints’ Search for a path for each waypoint (BMC) Check properties from last waypoint Michael Lifshits, Intel

9. deep bugs New Initial states New Initial states New Initial states initial states Max FV bound Michael Lifshits, Intel

10. Calculation of New Initial States • If a = 1 appears immediately before the last step in the waypoint witness, next BMC run must start with q2 = 1 • Reuse of: initial q1, q2, q3, q4 = ’0; will cause bogus results example: assume property (a |-> ##4 b); bit q1, q2, q3, q4; initial {q1, q2, q3, q4} = ’0; always @(posedgeclk) begin q1 <= a; q2 <= q1; q3 <= q2; q4 <= q3; end wire fail = !b && q4; Michael Lifshits, Intel

11. Calculation of New Initial States FPV towards waypoint RTL RTL Synthesized elements CEX trace Full/CONSISTENT Initial state Checkers Checkers • Synthesize: • sampled value functions ($past, $rose, etc.) • property automaton states (a-> ##10 b) Michael Lifshits, Intel

12. Multi-Threaded Search to Enhance Coverage • Randomly chosen path through waypoints may miss the bug • Multi-threaded search algorithm on multiple paths in parallel • For each waypoint Wi • Calculate a set of random witnesses (vs. single witness) • Launch a separate verification process towards Wi+1 Michael Lifshits, Intel

13. Experiments and Results: Resource Manager – a Mature CPU Block Validation goal – verify the correctness of resources management • no resource is allocated twice • no resources are lost • … FV High model complexity Insufficient bounded proof Deep scenarios not covered Complex logic with huge random coverage space Hard to define and hit corner-case scenarios DV Michael Lifshits, Intel

14. SFV Bug Detection Capability • Manually modified control logic to miscalculate STALL conditions • Premature wrap-around of “next free” pointer • Resource trampling • Waypoints – table lines are allocated wayp_i: cover property `Allocated(Table[i]); • Assertion: “resources are not lost” • SFV runs #: 3(witnesses)6(waypoints)=729 Michael Lifshits, Intel

15. Real Bugs in Resource Manager Found by SFV • Incorrect STALL calculation when very specific requests • A bug in recovery/restart event handling • Corruption of a resource integrity mechanism Michael Lifshits, Intel

16. Other Results Michael Lifshits, Intel

17. Required Expertise • Micro-architectural DUT specification • Property specification language, i.e. SVA • FPV tools and methodology to determine that SFV is the right solution Requires limited expertise in FV as model pruning and tools tuning Michael Lifshits, Intel

18. Conclusions • BMC-based semiformal verification flow provides good design space coverage and is able to detect tough bugs in complex industrial designs, missed by FV and simulation • Environment modeling for SFV is easier than for FV since SFV may handle bigger blocks without pruning • Using multi-threaded search significantly boost the design coverage and bug detection capability Michael Lifshits, Intel

19. Conclusions • Design areas that fit Semiformal Verification flow • Large DUTs, where FPV is unable to achieve sufficient confidence • DUTs including complex mixed control/datapath logic with big coverage space (long latency flows, protocols with deep pipelining and queues and/or counters) • Basic algorithm is relatively simple and may be implemented on top of existing FV tools in case of combinatorial properties Michael Lifshits, Intel

20. Backup Michael Lifshits, Intel

21. BMC-Based Semiformal Verification • Eliminates DV and FV environments synchronization issues • Can find deep bugs (5x than FV) • Manual guidance takes advantage of user knowledge of the design • Dependent on cover points and user intuition Create path with ‘waypoints’ (waypoint == SVA cover) Search for a path for each Waypoint (BMC) Check properties from last waypoint Michael Lifshits, Intel

22. Semiformal Verification Methods Taxonomy • Waypoint definition • Waypoint traversal policy • Propagation policy • Formal verification engine • Number of search threads Michael Lifshits, Intel

23. Semi formal usage modes Manual • Verify design around “stress” point(s) e.g. full queue • Requires good knowledge of DUT behavior • SF paths are specified manually Automatic • Verify design and cover all state space • Requires less knowledge of DUT behavior • SF paths are computed by the tool Michael Lifshits, Intel