Xiushan Feng* ShaunF@nvidia.com ASIC Verification Nvidia Corporation

1. TM Xiushan Feng*ShaunF@nvidia.comASIC VerificationNvidia Corporation JayantaBhadraJayanta.Bhadra@freescale.com Technology Solutions Organization Freescale Semiconductor Automatic Verification of Dependency *The work is done when the author worked at Freescale

2. Problem Statement – Dependency Check • Dependency check is needed everywhere • E.g., Design/verification teams want to • know whether changes at inputs have any effect on an output • So they can predict verification and design updates • make sure under certain condition, inputs cannot propagate to an output • e.g, when address is not valid, don’t generate enable signals for downstream logic • Dependency checking: Under a known condition, whether a signal relies on a set of inputs. • Such a check is very useful for interface-level verification (e.g, SOC). • Freescale design teams have been requesting such a check for a long time. • Current solution: simulation with assertions • Writing sequential assertions is a big challenge • Needs to know how many cycles changes can propagate to outputs. • Cone of influences(COI) can be too big to analyze • Simulation-based approach is not complete for this check. • The quality of simulation is decided by the quality of stimuli. • May get incorrect conclusion – reporting an output doesn’t depend on a set of inputs when related input values are not used to drive the circuit.

3. Motivation for Improvements • A fully automated solution is needed. • No user efforts to analyze design • No manual assertions • reduce the huge efforts and possible user errors. • Given signals and conditions, a push-button tool is needed. • Improve the completeness of dependency check • No tedious test stimuli • Cover 100% of the state space to catch bugs in corner cases

4. Simple Example • SPEC: When Iq is 0, both countB and CountA should not depends on Input s If1 and If2 • In the code on the left, CountB depends on the signal If2 when Iq is 0 . This is an error as it is not gated by the Iq which should qualify the If2 always@(posedge clk) begin if ((If1 & Iq) | in1) countA <= countA + 1; end always@(posedge clk) begin if (If2| In2) countB <= countB + 1; end always@(posedge clk) begin if ((If1 & Iq) | in1) countA <= countA + 1; end always@(posedge clk) begin if (If2& Iq| In2) countB <= countB + 1; end Correct RTL

5. Formal Syntax for Dependency Check • In the RTL code, we want to check that CountA , CountB do not depend on If1 and If2 if Iq is low. (If1 and If2 are the fanin of the dep check. Iq is the condition non_dependency( CountA, {If1, If2}) provided (Iq == 0); non_dependency( CountB, {If1, If2}) provided (Iq == 0); • A analysis tool should give an error on CountB property stating that CountB depends on IF2 and pass the property on CountA Pass non_dependency( CountA, {If1, If2}) provided (Iq == 0); non_dependency( CountB, {If1, If2}) provided (Iq == 0); Fail

6. Proposed Solution -- Modified Miter Iq CountA Instance FOO In1 0? In2 If1 CountB If2 CountA_miter Instance BAR of the same design If1_miter 0? CountB_miter If2_miter

7. Proposed Solution – Algorithm Overview • Create a modified miter circuit with two instances of the same design. • Use XOR gates to connect the same output signals from different instances. The signals are those that we want to check dependency. E.g, CountA, CountB. • Use different inputs to drive signals that are fanins of the dep check. • If fanin signals of dep check are not PIs, insert cutpoints for them. • Conditions that are applied to signals inside fanin signals of the dep check need to be duplicated for each instances. • Given such a miter, if we can formally verify whether the outputs of XORs are always 0s. If so, we then prove that signals are not dependent on those fan-in signals. • If any XOR gives 1, then different assignments of one or some inputs cause the issue. And these inputs are fan-in signals that we want to check! e.g, where If2 is 0 or 1 can give different values for CountB

8. Flow Chart RTL Dep Checkers Yellow: nothing novel Green: novelty exists Next few slides give details on the three green boxes. Compile RTL Create MUXs (XORs) using Assumes/Asserts Create Miter Wrapper Circuit Checker 1: Pass Checker 2: Fail … Run Formal Verification Parsing Results

9. Create Miter Wrapper Circuit RTL Dep Checkers Compile RTL dep (A, B) provided Condition Foreach IO Port - P No In B? Yes No Is input? create two inputs: P and P_miter Create one input: P Create Outputs: P and P_miter

10. Create Miter Wrapper Circuit – Cont. Create two Instances – FOO and BAR for TOP module of the circuit Foreach IO of FOO and BAR -- P !exist P_miter || is(FOO)? Use P_miter to connect the port Use P to connect the port

11. Create Assertions -- Update Conditions Foreach condition cond of a checker cond = cond && new_cond_miter For example: Orig: …provided (I1 > 1) Updated: …provided ((I1 > 1) && (I1_miter > 1)) foreach input signal in_i of cond exists in_i_miter? No Yes replace in_iby in_miter and get a new cond_miter

12. Create Assertions -- Assumes for MUXs of Inputs dep (A, {If,..}) provided c1 dep (B, {If,..}) provided c2 … If MUX If_miter If_miter condition = cond1 || cond2 || … If_miter == (condition)? If_miter : If SVA: assume property (!condition |-> If_miter == If)

13. Create Assertions -- Assertions for XOR Outputs out dep (out, {If,..}) provided c1 … out_miter assert property (condition |-> out == out_miter) Create Miter Wrapper Circuit Run Formal Verification assert pass/fail asserts/assumes

14. Parsing Results – Pass/Fail of Checkers foreach assertion of a dep/non_dep checker dep (A, {If,..}) provided c1 non_dep (B, {If,..}) provided c2 … pass(assertion)? NO non_dep non_dep dep or non_dep? dep or non_dep? FAIL PASS

15. Sample Results • A production tool is developed and used by verification team. • Feedback from verification teams is very positive • Design and verification can use the tool to do quick check • Identify bugs early • In the above circuit, our tool caught the bug: registers are over-written when address is not valid. (crc_reg depends on values of addr even when the addr is not valid) User checker input: …. dep(crc_reg, {addr}) provided (addr > 4); …. Log of the tool: INFO: Results for Check 4: dep(crc_reg, {addr}) provided (addr > 4); FAIL