Transcript S - DVCon
Overcoming AXI Asynchronous Bridge Verification Challenges with AXI AssertionBased Verification IP (ABVIP) and Formal Datapath Scoreboards Bochra El-Meray, ST-Ericsson Jörg Müller, Cadence About the Authors ∙ Bochra Elmeray ∙ Jörg Müller ∙ Verification Engineer at ST-Ericsson Rabat ∙ Solutions Engineer at Cadence Design Systems Munich ∙ 5 years experience in IP verification ∙ 15 years experience in ASIC Design and Verification ∙ Expert in Formal Verification ∙ Expert in Formal Verification ∙ Supported ST-Ericsson for advanced verification 2 Agenda ∙ Overview GALS Design Verification ∙ Environments ∙ Formal Protocol Checking ∙ Formal Functional Checking ∙ Technology ∙ Results ∙ Conclusion 3 Overview GALS Design Verification ∙ Definition: GALS ∙ Globally Asynchronous Locally Synchronous design techniques used for SoC ∙ Solve physical implementation problems (power, timing, etc) ∙ Requires synchronization between clock domains with different frequencies ∙ 2 clock domains ∙ AXI Master ∙ AXI Slave ∙ Verification Challenges ∙ Protocol Compliance ∙ Datapath Integrity 4 AXI Master Clock Domain ∙ DUT: AXI2AXI bridge AXI Slave Clock Domain ∙ Synchronizer between domains: Asynchronous Bridges Verification Environments ∙ Traditional ∙ Constrained Random Simulation (SpecMan) ∙ Metric-Driven Analysis (Coverage and Fault) ∙ Applied on sub system level only, not on IP level ∙ Focus on known application scenarios only, missed bugs ∙ Initial Formal Environment ∙ IP-level, only protocol compliance checking ∙ Many inconclusive results due to complexity of design ∙ Debbugging failures on signal level is difficult ∙ No verification plan or progress metrics ∙ Improved Formal Environment ∙ Adding methodology and technology to fill holes ∙ Replace simulation efforts for IP level features 5 New Formal Verification Strategy ∙ Add 2 new components in the environment ∙ New AXI3 Assertion-Based Verification IP optimized for protocol checking ∙ New methodology for verifying asynchronous datapaths for functional checking ∙ Leverage formal-aware metric-driven verification and regression environment ∙ Orchestrate and distribute formal environments on server farms ∙ Collect results and provide global view of overall verification state ∙ Enables tracking of progress and assessment of completenss ∙ Take advantage of new debugging capabilities ∙ Transaction-level representation of AXI protocol activity ∙ Leverage latest formal technology available 6 Protocol Verification ∙ Goal: Guarantee protocol compliance against AXI specification ∙ Technology used: Formal and Assertion-Based VIP (ABVIP) ∙ Optimized properties for formal validation of interface protocol Cadence AXI ABVIP Interface Protocol properties Interface 7 STEricsson Async AXI2AXI bridge Interface Cadence AXI ABVIP Protocol properties Interface Data Path Functional Verification ∙ Goal: Guarantee core functionality of the bridge – data transport ∙ Methodology introduced: Formal ScoreBoard Cadence Scoreboard ABVIP Functional properties Cadence AXI ABVIP Interface Protocol properties constraints Interface 8 STEricsson Async AXI2AXI bridge Interface Cadence AXI ABVIP Protocol properties constraints Interface Formal Scoreboard Background ∙ Utilizes symbolic sequences (refers to Wolper, Stangier, Mueller) ∙ Formally verifies data integrity (specifically data transport) ∙ Implemented as formal scoreboard (provided by Cadence) vld_in data_in constrain sequence 9 vld_out DUT data_out check sequence Symbolic Sequences ∙ Using Symbol in Formal Verification ∙ Declare a non-deterministic constant that represents all possible values 1. 2. 3. 4. 5. 6. 7. always symbol never symbol first symbol one symbol only two consecutive symbol two symbol only two consecutive symbol only* * Stangier‘s approach 10 SSSSSSSSSSSSSSSSSSSS .................... S??????????????????? ...S................ ...SS??????????????? ...S...S............ ...SS............... Definition: S: Symbol .: Anything but symbol ?: Anything Implementation of Symbolic Sequences ∙ Symbol implemented as non-deterministic constant wire [31:0] symbol; // uninitialized assert property($stable(symbol)); Value chosen by the formal tool to trigger failures! ∙ For every such sequence there is an associated set of a constraint and an assertion ∙ Example sequence „one symbol only“ ...S................ ∙ Symbol used to constrain unique value in input domain sequence assume property (@(posedge in_clk) in_symbol_seen && in_dvalid |-> in_data != symbol); ∙ Symbol used to check for matching same value in the output domain sequence assert property (@(posedge out_clk) out_symbol_seen && out_dvalid |-> out_data != symbol); 11 Error Types Detected by Formal Scoreboard 1. 2. 3. 4. 5. 6. 7. 8. loss (arbitrary item) loss all (items of particular value C) creation (arbitrary value) XXXXX creation (illegal value only) duplication (same value only) XXXCX manipulation (to arbitrary value) XXXCX manipulation (to illegal value only) reordering (arbitrary items) XXCCX XXCX XXCCX XXX XXXXEX XXXXX XXXXYX XXCCXX XXXEX XXXCX XXXYX XBCXX XCBXX ∙ Different sequences can detect different type of errors ∙ All sequences overlay to full coverage of error types 12 Datapaths in the Async AXI Bridge ∙ For our AXI bridge we identified a total of 7 data transport paths 1. Write Address ID 2. Write Data ID Cadence Scoreboard ABVIP 3. Write Response ID Functional properties 4. Write Data 5. Read Address ID Cadence Interface AXI ABVIP 6. Read Response ID Protocol properties constraints 7. Read Data Interface STEricsson Async AXI2AXI bridge Interface Cadence AXI ABVIP Protocol properties constraints Interface ∙ Each receive a formal scoreboard instance to test the functional datapath across the DUT 13 Instantiating Formal Scoreboard Cadence Scoreboard ABVIP Functional properties Cadence AXI ABVIP awids Interface Protocol properties constraints Interface STEricsson Async AXI2AXI bridge awidm Interface Cadence AXI ABVIP Protocol properties constraints Interface if_scoreboard #( // Parameters .DBUS_WIDTH (ID_WIDTH), // Size of the external datapath vector .CHECK_WIDTH (CHECK_WIDTH) // Size of the internal datapath check ) sb_awid ( // Ports .rst_n (rst), // active low reset .in_clk (aclks), // input clock .in_data (awids), // input data vector .in_dvalid (awvalids && awreadys), // input valid indicator .out_clk (aclkm), // output clock .out_data (awidm), // output data vector .out_dvalid (awvalidm && awreadym) // output valid indicator ); 14 Technology in New Formal Environment ∙ Latest Engines in Incisive Enterprise Verifier ∙ Addition and improvements of formal engines and running them all in parallel ∙ Contributes to faster runtime and overall improved results ∙ Assertion-Driven Simulation (ADS) ∙ ADS runs simulation using PSL/SVA constraints as testbench ∙ Allows fast design exploration and provides instant feedback on constraints ∙ Replay ∙ Using traces obtained by formal engine to guide ADS activating other properties ∙ Contributed additional failures on previously explored properties ∙ Constraint Minimization ∙ Patent pending algorithm to identify minimized set of constraint required for proof 15 ∙ Contributed additional Fail and Pass results on previously Explored Debugging 16 Regression Suite 17 Comparing Formal Environments Config 1 Config2 Old New Old New Total 115 144 108 141 Pass 75 (65%) 8 (7%) 32 (28%) 108 (75%) 9 (6%) 27 (19%) 74 (68%) 3 (3%) 31 (29%) 109 (77%) 9 (6%) 23 (16%) Fail Explored* * The explored results were obtained with 1 hour tool effort per property 18 Finding Critical Bugs ∙ Failure Detected: ID values across locked access do not match! ∙ Scenario: Normal data without request enters bridge before lock ∙ Impact: Potentially blocking entire SoC DUT outputs IDs must be same for locked transaction DUT inputs Cause 19 Summary ∙ Pro: ∙ Positive experience with with formal verification, scoreboarding and ABVIP ∙ Effort to create formal environment ~1/3 the effort to create simulation environment ∙ Overall quality of results improved tremendously ∙ Found corner case bug missed by simulation ∙ Con: ∙ Some bounded proofs remained (although depth increased) ∙ Not a push button flow (but that was not expected either) ∙ Formal environment was a good replacement for sim environment except clock domain crossing checks (was never tried with formal) ∙ Conclusion ∙ We count on mixed formal and simulation (ADS) in future projects of that type 20 ∙ Completeness of setup (protocol + functional) gives confidence to sign THANK YOU