1 / 14

Full Cycle Functional Coverage: Coverage Success Stories

Full Cycle Functional Coverage: Coverage Success Stories. Avi Ziv Verification Technologies Department IBM Haifa Research Laboratory. What Is Functional Coverage?. Functional coverage is used to check that important aspects of functionality are tested Design and implementation specific

galya
Download Presentation

Full Cycle Functional Coverage: Coverage Success Stories

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. Full Cycle Functional Coverage: Coverage Success Stories Avi Ziv Verification Technologies Department IBM Haifa Research Laboratory

  2. What Is Functional Coverage? • Functional coverage is used to check that important aspects of functionality are tested • Design and implementation specific • Comes in many flavors • Black box and white box • Snapshot and temporal • Local and global scopes • A coverage model is a family of coverage tasks with common denominator and some parameters • In cross-product coverage models the coverage tasks are the cross-product of the values of the parameters (attributes) • Functional coverage is a succinct way to express test plans • Easy to maintain • Automatically measured • Comprehensive

  3. Motivation • The use of functional coverage in hardware verification is gaining momentum • Available in several coverage tools and verification environments • Much effort is being directed at increasing the efficiency of coverage measurement • More users consider coverage important part of the verification plan • Yet, there are not many functional coverage success stories • Many still do not use it or abuse it • Serious users are disappointed with results • Too much effort • Too little results • A major reason is that using functional coverage the "right" way is more an art than a science

  4. Coverage Stories • We present here two coverage success stories • Users were very satisfied with coverage process and its contribution to the verification effort • The coverage domains: • Execution units of PowerPC processor • Branch unit of S/390 processor • We describe the coverage process for each domain • Highlight key issues • This is not a scientific study

  5. Dispatch Data Fetch B1 R1 M1 S1 Execute B2 R2 M2 S2 Write Back R3 B3 M3 S3 S4f S4b Branch(B) Simple Arith (R) Complex Arith (M) Load/Store(S) First Story: PowerPC Processor Execution Units • Multithreaded • In-order execution • Up to four instructions dispatched per cycle

  6. Second Story: S/390 Branch Unit • Unit handles branch prediction and execution of branch instructions • Contains • Nine stages complex pipe • More than one instruction at the same time in some stages • instructions can enter the pipe at two places • Branch history tables • and more • 2 PY spent on verification • Done by experts with experience with similar designs • About 100,000 tests per day

  7. Coverage Model Definition – PowerPC Pipe • Model details • Model contains 7 attributes • Type, pipe and stage of first instruction (I1 ,P1 ,S1) • Same attributes for second instruction (I2, P2, S2) • Type of dependency between the instructions • RR, RW, WR, WW, None • Many restrictions exist • I1 is simple fixed point Þ P1 is R or M • P1 is not S Þ S1 is 1, 2, or 3 • After restrictions, 4418 tasks are legal • The model was designed to check that all interdependencies between two instructions in the pipeline occur

  8. Coverage Models for Branch Unit • Several models defined • Access to branch tables • Flow of a branch in the pipe • State of the pipe • State of the pipe model • Attributes contain • Location and type of each branch in the pipe in a given cycle • Reset signal • Model size: • Without restrictions ~ 15,000,000 • With restrictions ~ 1400

  9. Coverage Measurement • Make sure that you measure what you really want and what really happens • Use simpler environment and models to test and debug the measurement system • Hierarchy of models • All instructions • All pipe stages • Controlled simulation

  10. Analysis of Interdependency Model • After 25,000 tests 2810 / 4418 tasks were covered (64%)

  11. Analysis of Interdependency Model • Hole analysis detected two major areas that are lightly covered • Stages S4f and S4b that are specific to thread switching are almost always empty • Reason: not enough thread switches during tests • The address-base register in the store-and-update instruction is not shared with other registers in the test • Reason: bug in the test generator that didn’t consider the register as a modified register

  12. Coverage Progress Causes of holes are fixed

  13. Branch Unit Coverage Progress

  14. Results • S/390 Branch unit • Better understanding of the tested design • Even before coverage measurement started • Found several tricky performance bugs • PowerPC execution units • No bugs in the design found • Several bugs in the test generator • Enhanced test specification • Models re-used in follow-on designs • Overall – happy customers!!!

More Related