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

2. Docket – MT11774TS 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. 2

3. Docket – MT11774TS 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 3

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

5. Docket – MT11774TS 5 Formal Syntax for Dependency Check ► In the RTL code, we want to check that CountA, CountB do not depend on I f1 and I f2 if I q is low. (I f1 and I f2 are the fanin of the dep check. I q is the condition non_dependency( CountA, {I f1, I f2 }) provided (I q == 0); non_dependency( CountB, {I f1, I f2 }) provided (I q == 0); ► A analysis tool should give an error on CountB property stating that CountB depends on I F2 and pass the property on CountA non_dependency( CountA, {I f1, I f2 }) provided (I q == 0); non_dependency( CountB, {I f1, I f2 }) provided (I q == 0); Pass Fail

6. Docket – MT11774TS Proposed Solution -- Modified Miter 6 Instance FOO Instance BAR of the same design IqIq In1 In2 I f2 I f1 I f2 _miter I f1 _miter CountA CountB CountA_miter CountB_miter 0?

7. Docket – MT11774TS 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 7

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

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

10. Docket – MT11774TS Create Miter Wrapper Circuit – Cont. 10 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 to connect the port Use P_miter to connect the port

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

12. Docket – MT11774TS Create Assertions -- Assumes for MUXs of Inputs 12 MUX IfIf I f _miter condition = cond1 || cond2 || … I f _miter I f _miter == (condition)? I f _miter : I f SVA: assume property (!condition |-> I f _miter == I f ) dep (A, {I f,..}) provided c1 dep (B, {I f,..}) provided c2 …

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

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

15. Docket – MT11774TS 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) 15 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