1 / 15

Xiushan Feng* ShaunF@nvidia ASIC Verification Nvidia Corporation

TM. Jayanta Bhadra, Ross Patterson {JayantaBhadra, RossPatterson}@freescale.com Freescale Semiconductor. Xiushan Feng* ShaunF@nvidia.com ASIC Verification Nvidia Corporation. Assertion-Based Design Partition. *The work is done when the author worked at Freescale.

kale
Download Presentation

Xiushan Feng* ShaunF@nvidia ASIC Verification Nvidia Corporation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TM Jayanta Bhadra, Ross Patterson {JayantaBhadra, RossPatterson}@freescale.com Freescale Semiconductor Xiushan Feng*ShaunF@nvidia.comASIC VerificationNvidia Corporation Assertion-Based Design Partition *The work is done when the author worked at Freescale

  2. Problem Statement – Assertion-Based Design Verification Challenges • Assertion-Based Verification is broadly used in circuit verification • Increase the visibility of internal signals • Use assertions as checkers. Pass of assertions == pass of verification • Verify the correctness of design – improve the quality • For large designs, simulation speed is slow and may blow up formal verification due to exponential state space. • Slow down verification process – more resource, longer design cycles. • For certain cases, it is not feasible to verify certain assertions. • Most time, partial design is good enough to verify assertions. • For example, for SOC PAD connectivity check, assertions are written to verify that signals can propagate from source to target under certain conditions. We don’t need logic that drives sources, loads values from targets. • Unneeded logic usually is VERY big, removing them can achieve huge gains • However, manually identifying and removing unneeded logic is very hard. • Need to understand assertions and the design indent • Failing to include logic can cause false verification results. • An automatic solution is possible using Assertion-Based Partition

  3. The Current Verification Environment RTL Assertions Constraints • Compiled database is huge. • Verification is slowed down • More resources needed (licenses, engineering hours, computing machines) • This technique attempts to reduce verification cycles and improve verification quality RTL Compile Verification (simulation or formal verification) Pass/Fail & Circuit Debug

  4. The Proposed Verification Environment RTL Assertions Constraints • Signal propagation • Signal reachability Assertions1 2. Get boundary signals in ABV 3. Condition-base design partition with formal prove RTL(partitioned) Assertions2 RTL(partitioned) RTL(partitioned) Verification (simulation or formal verification) RTL Compile LEGEND: Yellow: NEW White: Prior Art Pass/Fail & Circuit Debug

  5. Definition of Signal Propagation and Reachability foo bar Signal Propagation: a is directly connected by wires to a’. i.e., a and a’ are interchangeable inside the assertions, a' a A B C D X assign B = A; assign D = C; assertion: assert property (condition |->a == ….) update assertion: assert property (condition |->a’ == …) RTL: FOO foo (.A(a), .B(X)…); BAR bar (.C(X),.D(a’)…); A Signal Reachability: If signal S1 is inside fan-in logic cone of signal S2, then S2 is reachable by S1. D is reachable by A, B, but not C. partially ordered graph D E B C D E C A B

  6. Signal Propagation and Reachability Computation state stage Compute state stage graph with all signals of assertions assertions For each assertion, compute the boundary points For each pair of signals x, y of the assertion, compute whether y can be (forward/backward) reached by x. RTL Reachable? Y X tied to z && z is on the path from x to y N Y replace x by z in assertions. Build directed edge from z to y partially ordered graph

  7. Example state stage partially ordered graph State points (Latch/Flop) inputs inputs ast0 ast0 Signal propagation and reachability output output

  8. Get Boundary Signals partially ordered graph Boundary signals Keep lower bound and upper bounds inputs inputs State points (Latch/Flop) ast0 ast0 output output

  9. Conditional RTL Partition with Formal Prove Boundary signals lower bounds  inputs (IN) upper bounds  outputs (OUT) inputs RTL ast0 Conditional compute cone of influence for all OUT Assertions1 ast1 RTL (partitioned) Assertions2 (Optimized) output Constraints

  10. Conditional RTL Partition with Formal Prove – Cont. RTL For each OUT, backward partition RTL. When hit a condition, build symbolic expression for condition and prove the condition Assertions1 Formal prove engine Constraints prove? N compute cone of influence for both cases Partition RTL only for proven case. Update assertion based proven results RTL (partitioned) Assertions2 (Optimized)

  11. R Build Symbolic Expression for Conditions and Prove get fan-ins (f_ins) of cond expr(cond) = f (f_ins) Constraints Recursively build expression for each fan-in cond Light-weight No expression blow up f_in is R/IN? N Y Constraints Terminate from the recursive procedure symbolic expression Formal prove engine R: Register IN: Input True/False

  12. R Example cond b' a A B C D assign B = A; b For example: Input X, Y; b’ = (cond)? b : C … If we can prove cond is always true, then we don’t need to trace path for signal C. we know b’ = b, and use it to update assertions and propagate signal. If we can prove cond is always false, then, we just need to trace signal C and propagate signals if feasible.

  13. Assertion Grouping and Parallel • Concept of assertion groups • Assertions have hidden “locations” • Logic regions • Assertion types • Assertion-based partition can be done on assertion groups • Assertion groups can be verified in parallel with design partitions • Groups are verified independently. • Verification results inside one region can be re-used by others. E.g., verified proves can be assumptions for others, etc. • Assume-and-guarantee is done at the boundary of groups. • One assertion can be re-written into multiple ones that belong to different groups. • Abstraction techniques are done differently for groups. • E.g., Assertions of analog behavior models are verified inside analog groups. Verification of digital groups has analog blackboxed and analog drivers properly constrained, which will be proven by analog assertions.

  14. Assertion Grouping Example • Several groups of assertions that verify a few logic regions • Logic needed to prove a group may not be necessary for another • Inputs of a region can be outputs of another • cutpoints can force internal wires as inputs • One assertion can be broken down into multiple assertions. • For example, enable and reg  R1; foo, bar, A, B  R1 • ast: enable && reg[19] && bar |-> A == B can be replaced by • ast1: enable && reg[19] |-> foo • ast2: foo && bar -> A ==B R2 output R3 inputs R1

  15. Results • We applied the ideas on Freescale PAD IO verification. • Without the ideas, original formal verification ran weeks and required VERY large machines (>100GB) • A smaller and simpler design took >1week on large machines but didn’t get good coverage. • This highlighted the need for this work • With ABP, we are able to prove 25+K assertions within 2.5 hours. • Critical SOC-level bugs were caught !

More Related