Skip to content

Instantly share code, notes, and snippets.

@edcote

edcote/coverage_cookbook.md

Created May 26, 2018 21:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save edcote/ee5e81b1b219b9adfa9a446620684d97 to your computer and use it in GitHub Desktop.
Save edcote/ee5e81b1b219b9adfa9a446620684d97 to your computer and use it in GitHub Desktop.
Download ZIP
Verification Academy Cover Cookbook Notes
Raw
coverage_cookbook.md

Notes

"What doesn't get measured might not get done". Coverage helps to answer the "are we done" question.

Two concepts fundamental to understand coverage.

  • Controllability: ability to influence FSMs, structure, or LOC in the design
  • Observability: ability to obseve the effects of a FSMs, structure, or LOC in the design

Kinds of coverage:

  • Implicit, relates to implementation, aka. code coverage and assertions
  • Explicit, relatces to specification, aka. functional coverage and assertions

Code coverage can activation a line of code that contains a bug, but cannot determine whether the testbench has generated the sufficient stimulus such that the effect of the bug is propagated to an observability point.

  • Toggle coverage mesaures number of times a reg or wire has toggled.
  • Line coverage measures which lines of code have been executed
  • Statement coverage measures which statement are executed during simulation. Multiple statements can be present on a single line or code. Or single statement can be present on multiple lines of code.
  • Block coverage indicates whether a block of code is executed (e.g., between begin and end)
  • Branch coverage reports whether boolean expressions in control structures evaluate to both true or false.
  • Expression coverage (or condition coverage) determine if each condition in expression evalutes to both true and false.
  • FSM coverage determins number of times state is entered, number of transitions from one state to each of its neighboring states.

Functional coverage helps to determine if the design requirements are functioning as intended. Answers question: Have all specified functional requirements been implemented? FC is explicitly stated during verification planning. Trigger conditions and controllability (enable/disable) are define for accurate measurement.

Cover group modeling consists of state values observed on buses, grouping of interface signals, registers, etc.

Cover property relates to temporal relationships between sequences of events. Examples include handshaking between sequences of events, power state transition coverage, etc.

Capturing the test plan in a fixed format is important to allow automation.

APB Test Plan

  • Assertions
    • Unknown (X,Z) signals
      • PSEL always in known state
      • if PSEL = 1 -> PADDR, PENABLE, PWRITE must be in known state
      • if PSEL = 1 && PWRITE = 1-> PWDATA must be in known state
      • etc.
    • Timing relationships
      • Once PREADY is sampled true -> PENABLE shall go low next cycle
  • Functional coverage
    • All PSEL lines have been set to active
    • We have seen reads and write take place
    • Create cross products between fields

UART Test Plan

FIR Test Plan

SOC Test Plan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment