JasperGold. Agenda. High-Level Formal Verification

Transcription

1 JasperGold High-Level Formal Verification Vigyan Singhal Harry D. Foster 1 Agenda Jasper introduction Model checking Block-level verification - High-level requirements - Formal testplan - Coverage Formal Testplanner PSL (Property Specification Language) 2 1

2 Jasper Design Automation Jasper is the premier electronic design automation (EDA) supplier of high-level formal functional verification software. Jasper s solution achieves 100% Actual Coverage improving the quality of electronic design, predictably and within verification schedule constraints Jasper has unique and valuable technology that changes the verification game and makes formal verification real. 3 Jasper Design Automation Founded in 1999 (originally Tempus Fugit) Over $20M in funding -- led by Foundation Capital, Accel Partners Management - Kathryn Kranen President and CEO (Verisity, Quickturn) - Vigyan Singhal CTO (Cadence, UC Berkeley) - Harry Foster Chief Methodologist (Verplex, HP) - Craig Cochran VP Marketing (Synopsys) - Craig Shirley VP Sales (Verisity) - Nafees Qureshy VP Engineering (CoWare) 9 PhDs in Formal Verification - UC Berkeley, Stanford, CalTech, Chalmers, Gothenburg 4 2

3 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a 0 0 q 0 0 p Combinational gates + flops (with initial values) 5 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a q 0 0 p 6 3

4 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a q p 7 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a q p 8 4

5 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a q p 9 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a q 1 2 p 10 5

6 Sequential Satisfiability (model checking) Is there a sequence of input assignments such that p is 1 at any finite time time? a 0 0 q 0 0 p Combinational gates + flops (with initial values) Complexity: PSPACE-hard (Aziz 93) 11 Model Checking use model Does the design have a given desirable property? Properties and Constraints Design under test Model Checker Verified or CounterExample p q Properties - Specification Constraints - Assumptions needed to prove Properties Design under test - Implementation 12 6

7 Functional Verification Today Test Bench Large hdl Verification starts late Creating the chip-level testbench can be as difficult as creating the chip model. Poor coverage Full chip verification does not provide enough coverage to find all bugs. High controllability of block-level interfaces is difficult to achieve from stimulus generated at the chip boundary. Low observability Internal errors during full chip simulation might not propagate to an observable output during the test. 13 Design and Verification Flow Spec Design Validate Chip SRAM CPU Chip testbench Test IP I/F Refine & Partition SRAM Test IP CPU I/F Super- Block FIFO Algorithm Controller Sync M U X Most of today s verification is performed at the chip level Block Timer Timer FSM Actions Actions FSM Integration & Verification Very little block-level verification is performed Unit or Module FSM Block-level testbench Timer Timer FSM Actions Actions FSM Cost of a re-spin > $1M + months of delay 14 7

8 What is necessary for FV to succeed in industry? FV solution must provide: 1. High Return-on-Effort - Measurable proof of quality 2. Ease of use (FV expert not require for successful) - Encapsulate formal expert knowledge into the tool - Strong engines + advance abstraction techniques - Guide the user to success 3. Sophisticated debug capabilities - Design illumination--enabling user to learn the design 4. Means to overcome the blank page syndrome - Specification challenge - Methodology challenge 5. Metrics to measure progress and success 15 What s the solution? Give up, accept the raw algorithm limitations and perform boundedmodel checking, or. How do we handle complexity for other applications? - For example, place-n-route is an NP-complete problem. - In place-n-route, using guidance, the tool can automatically partition the problem down into tractable pieces. To succeed, formal verification tools must combine advanced techniques with multiple, powerful search engines - For example, managed automatic tunneling,. - Encapsulate the knowledge of the formal expert into the tool! 16 8

9 JasperGold Manages Proof Capacity Tunneling, Monitors, and Abstraction High-level requirement Conventional and Hybrid Formal Tools Choke on All the Logic in the Cone of Influence. Progress and Coverage are Unknown. Inputs JasperGold Refines the Proof Space Counter Outputs RTL Block Abstracts Formal Unfriendly Structures and Displays Progress and Coverage 17 JasperGold - Ease of Use Jasper Formal Testplanner High-Level High-Level requirements requirements RTL Design Design Design Block Knowledge base of design-specific methodology and requirements templates JasperGold Proving Environment TM JasperGold Precognitive Precognitive Engine Engine TM TM Proof Proof engines engines Static, exhaustive proofs without simulation Proof navigation suggests next steps Isolates the root cause of each bug to the faulty line of RTL Functional Bugs Isolated -OR - Proven 100% Correct Interactive, context-sensitive debugging environment 18 9

10 In-line assertions (PSL example) module btrack (clk,allocate,deallocate,set); input clk, allocate, set, deallocate; reg active_r, valid_r; wire active_s, valid_s, active_in, valid_in; assign active_in = ((allocate active_s) & ~deallocate); clk) active_r <= active_in set; assign active_s = active_r; assign valid_in = (active_s & (set valid_s)); clk) begin valid_r <= valid_in; assign valid_s = valid_r; // psl property deallocate_when_not_active = // always {deallocate} -> {~active_s; valid_r}; // psl assert deallocate_when_not_active; endmodule 19 A high-level requirement example [DesignCon 04 PCI Express Paper] High-level requirement = no packets are dropped, duplicated, or corrupted Tx From Fabric Tx TLP A Seq_num LCRC Increment by 1 A FIFO Over Flow Retry buffer One-hot output A Packet arbiter To PHY From RX Rx DLLP A = Implementation assertions: low-level assertions (similar to writing simulation monitors) 20 10

11 Illustrating with an Example AHB to MSIF bridge?x From AHB Master To Wishbone via MSIF Requirement: A transaction from an AHB Master on an external device must NOT get duplicated, corrupted or dropped, when it goes out to the Wishbone fabric 21 Illustrating the packet ordering requirement using a FIFO Data Transport From Wishbone C From RX DLL B Tx A Rx TLP Seq_num LCRC DLLP Retry buffer Packet arbiter A 1 2 To PHY C write_ptr C B A read_ptr 22 11

12 HLR example clk or posedge rst) if (rst) begin wrptr <= 4 d0; rdptr <= 4 d0; for (i = 0; i < 4; i = i + 1) stored[i] = 64 b0; end else begin if (datain) begin wrptr <= wrptr + 4 d1; store[wrptr] <= din; end if (dataout) rdptr <= rdptr + 4 d1; end datain din[7:0] wrptr prove { ~ ((dataout) && (dout!= store[rdptr])) } prove { ~ (((wrptr + 4 d1) == rdptr) && ~dataout && datain) } prove { ~ ((wrptr == rdptr) && (dataout)) } C B A store[] dataout dout[31:0] rdptr Notice dependency on number of transactions in flight 23 High-level Requirements: high return on effort Data Integrity Arbitration Fairness High-level Requirements End-to-end Black box Based on design intent Are harder to prove Intent Implementation Low-level Assertions Localized Implementation-specific Can find bugs faster One Hot Increment By 1 FIFO Overflow FIFO Overflow Design Behavior 24 12

13 High-Level Formal vs. Conventional Formal JasperGold operates here µ-architecture Specification RTL Coding High-Level Requirements Implementation Assertions Intent Implementation Most formal tools operate here 25 Seven steps of a formal testplan µ-arch 1 Identify good candidates identify Define interface 2 3 English list Requirements checklist 4 inputs Requirements Block outputs Formal description 5 Proof Steps Verification strategy Coverage goals 6 7 Coverage items assert_never (); Formal description 26 13

14 Formal Testplan Example Transmit Path (tx) - Packets should not lose ordering or get dropped - Packets should not get duplicated - Packets headers should not get corrupted - Link Credits sent are less than or equal to Network Credits received - No Link Credits received from the network are lost (every credit is sent downstream, or recorded locally) - No packets are retried until timer expires - Any packet not ack ed is retried - Retried packets should not lose ordering or get dropped - Retried packets should not get duplicated Receive Path (rx) - Alignment - Packet Latency - 27 Overcoming the formal specification blank-page syndrome 28 14

15 JasperGold Proving Environment - Sophisticated Debug Design Illumination mode steers the user through the design - lets you get into the designer s head without talking to them Enables you to quickly expose the root cause of a bug, isolated down to the faulty line of RTL code Provides design-specific next steps and proof progress metrics 29 Are there success stories? Real examples include: - Arbiters of many different kinds - On-chip bus bridge - Power management unit - DMA controller - Host bus interface unit - Scheduler, implementing multiple virtual channels for QoS - Interrupt controller - Memory controller - Token generator - Credit manager block - Standard interface (AMBA, PCI Express, ) - Proprietary interfaces - Clock disable unit Common characteristic: concurrency, multiple data streams Multiple, concurrent streams Hard to completely verify using simulation 10 bugs per 1000 gates -Ted Scardamalia, IBM 30 15

16 Control, data transport Concurrent Handles multiple streams Corner-case bug is missed because randoms never excited that timing combination Bug example: during the first 3 cycles of a transaction start from one side of the interface, a second transaction came in on the other side of the interface and changed the config register. Design examples: arbiters, standard interface protocols (PCI), DMA controller 31 Data transform Sequential, functional Single-stream Corner-case bug is missed because testplan was not complete (spec was large) Bug example: the IFFT result is incorrect if both inputs are negative Designs: floating point unit, graphics shading unit, convolution unit in a DSP chip, MPEG decoder 32 16

17 On-chip Bridge (e.g. AHB-AHB) Master A HTRANSA HREADYA HRESPA AHB-AHB bridge HTRANS HREADY Slave Master B HTRANSB HREADYB HRESPB HRESP HLRs - Bridge transfers data correctly from one end to the other (accounting for 16-bit to 64-bit data width change, and splitting of long burst packets) - Bridge is fair to both masters - Complexity - Timing relationship between the two masters - Error responses from the slave with arbitrary timing relationship to what is happening in the master Corner-case - Bridge locks up if slave issues error on 2 nd cycle of a 4-beat request from master A, and master B makes a new request on the same cycle the error is passed on to master A 33 Verification solution must reduce collateral damage Today, design concurrency and complexity are explored late in the flow The problem is that at this state massive design interdependencies exist fully-developed RTL Late stage bugs can have significant collateral damage Exhaustively verified complexity System-level Verification Complexity explored Block-level Verification Sandbox Verification Complex bugs found late! Time 34 17

18 JasperGold Delivers Provably Correct Design 100% verified Data Integrity Flow Control Arbitration Fairness Error Handling Packet Ordering High-Level Requirements from Micro-Architecture Spec. time Prove-as-you-design Incrementally add design functionality, prove its correctness, and then ensure that it remains correct through final regressions 35 Two Reasons for Formal Verification Bugs Remaining Typical Debug Bug-Hunting Assurance Find Last bug Time By far, we [at Intel] have found that the greatest value of formal verification is assurance John O Leary, Intel Full proof provides the most value 36 18

19 Design and Verification Flow Spec Design Validate Chip SRAM CPU Chip testbench Test IP I/F Refine & Partition SRAM Test IP CPU I/F Super- Block FIFO Algorithm Controller Sync M U X Most of today s verification is performed at the chip level Block Timer Timer FSM Actions Actions FSM Integration & Verification Very little block-level verification is performed Unit or Module FSM Block-level testbench Timer Timer FSM Actions Actions FSM Cost of a re-spin > $1M + months of delay , Jasper Design Automation, Inc. All rights reserved. Design Cycle Comparison Simulation Flow Design Blocks Sanity Check Create Testbenches System Simulation Months Simulation + Formal Verification Flow Design Blocks Formal Verify Create Testbenches System Simulation Weeks Design and formal verification performed in parallel - 100% Proof 38 19

20 Retrun on Investment Simulation Methodology Easy Bugs Corner Case Bugs TAPE OUT! More Corner Cases! Block Design Unit-level Testing System-level Testing Simulations Silicon Testing Jasper Methodology Complete Verification with JasperGold during Design System-level Testing Simulations Tape-out Early Tape-out Right For every bug at system-level: Identify Block Identify Fix Re-run All Weeks* 39 Conclusion: Making Formal Verification Mainstream Higher returns - Block verification on real-sized designs - Expectation and predictability of results - For even higher results: Interactivity and methodology support User creativity always adds more Higher investment from the user - Lower investment ) marginal payoff - Cannot be factored in project schedules - Need predictable effort estimates - User interaction is acceptable, if effort can be quantified and estimated up front - Today, simulation can be replaced: launch-and-forget will not replace simulation - Don t short-change formal by applying only to local assertions 40 20