Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
    • Writing an Interface Contract
    • Safety and Liveness
    • Protocol Assertions
    • Monitors and Transaction Reconstruction
    • Ordering-Aware Scoreboards
    • Protocol Coverage
    • Formal Methods for Protocols
    • Compliance and VIP
    • Observability and Tracing
    • A Waveform Debug Method
    • Drills: Specifying and Verifying
  • Part 16: Protocols Dissected17
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 15: Specifying and Verifying
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 15: Specifying and Verifying
  4. Protocol Coverage

Part 15 · Specifying and Verifying · Senior (S)

Protocol Coverage

Passing tests prove only what they exercised. Protocol coverage lists the situations an interface must be seen to handle (stalls, back-to-back, maximum outstanding, boundaries, errors, reordering, resets) and measures whether the tests reached them.

On this page

    Note

    Level: Senior (S) · Answers: How do we know it is correct?

    Before this: Protocol Assertions

    An AXI slave passes ten thousand random tests with every assertion silent and the scoreboard clean. It goes to silicon and hangs the first time a master issues sixteen outstanding writes, because the tests never issued more than four. Every check was in place; none was ever given the situation that broke the design. Passing tests say nothing about situations the tests never created.

    How do you know your tests have exercised everything that matters about an interface?

    The obvious answer, and why it breaks

    The obvious measures are the number of tests, the number of cycles, and code coverage (lines and branches executed). Random tests cluster around typical behaviour: short stalls, few outstanding requests, mid-range addresses. And code coverage measures the design's code, not the protocol's situations: a line that handles "buffer full" can execute without the interface ever being at its outstanding limit under back-pressure. Coverage has to be stated in terms of the protocol.

    The idea: a coverage plan of protocol situations

    Area

    Cover points

    Handshake

    Ready before valid, valid before ready, same cycle; stalls of 1, 2 to 7, 8 or more cycles; back-to-back transfers with no gap

    Concurrency

    Every outstanding count from 1 to the maximum; reaching the maximum while stalled

    Ordering

    Responses in order and reordered across IDs; same-ID sequences; interleaving where allowed

    Sizes and boundaries

    Every burst length and size; bursts ending exactly at a boundary (4 KB); narrow and unaligned transfers; all strobe patterns that matter

    Errors

    Every error response type, on reads and writes, on first, middle and last beats

    Flow control

    Credits at zero; credits returning at maximum rate; credit initialisation

    Reset and power

    Reset with transactions in flight; low-power entry denied and accepted; wake with requests waiting

    Crosses

    Combinations that interact: maximum outstanding × long stalls; errors × reordering; boundary bursts × back-pressure

    How coverage is collected

    • Cover properties on the interface signals for temporal situations (a stall of at least 8 cycles, back-to-back transfers).

    • Covergroups sampled from the monitor's transactions (lesson 15.4) for values and crosses (burst length × size, outstanding count).

    • Every assertion gets a cover: the assertion's trigger condition must have been seen, or the assertion proved nothing (lesson 15.3).

    • Closure: when a point stays unhit, change the stimulus (constrain it towards the corner), do not delete the point.

    design.sv
    1
    2
    3
    4
    5
    6
    7
    // snippet: cover properties for two handshake situations
    // A stall of at least 8 cycles that then completes.
    cover property (@(posedge clk) disable iff (!rst_n)
      vld && !rdy [*8] ##1 vld && rdy);
    // Back-to-back transfers: three in consecutive cycles.
    cover property (@(posedge clk) disable iff (!rst_n)
      (vld && rdy) [*3]);

    Cover properties use the same language as assertions, but report that a situation happened instead of checking a rule.

    When is it done?

    Evidence

    What it shows

    All planned cover points hit

    The tests reached every situation in the plan

    Every assertion's trigger covered

    Every rule check was actually exercised

    Crosses of interacting features hit

    Corners where features combine were reached

    Scoreboard clean and nothing left outstanding

    Behaviour in those situations was correct

    The plan reviewed against the specification

    The plan itself is not missing situations

    How real verification does it

    Environment

    Coverage

    SystemVerilog

    Cover properties and covergroups (fact T30)

    UVM

    Coverage subscribers sampling the monitors' transactions

    Verification IP

    Ships with a protocol coverage model (lesson 15.8)

    What breaks

    The opening slave (illustrative) had 100% code coverage. A protocol coverage plan added afterwards showed the outstanding-write count had never exceeded four, and the cross of "maximum outstanding" with "response channel stalled" had never been hit. Constraining the stimulus to reach them reproduced the silicon hang in simulation within an hour.

    Why this matters

    Senior lens. Write the coverage plan from the specification, before the tests, in the protocol's terms: handshake timing, outstanding counts, ordering, boundaries, errors, flow control, reset, and the crosses where they interact. Review it with the designer, who knows which corners scare them. Then treat an unhit point as a missing test, never as a point to remove.

    Interview

    Asked: "What coverage would convince you an AXI slave is done?"

    Weak answer: 100% code coverage.

    Strong answer: Protocol coverage from a plan, not just code coverage. Handshake timing on every channel, ready before, after and with valid, short and long stalls, back-to-back; every outstanding count up to the maximum, including at the maximum under back-pressure; every burst type, length and size, bursts ending at the 4 KB boundary, narrow and unaligned transfers; same-ID ordering and reordering across IDs; every response type including errors on reads and writes; reset with transactions in flight; and crosses like maximum outstanding with a stalled response channel. Plus every assertion's trigger covered, a clean scoreboard, and the plan reviewed against the spec.

    Follow-ups: (1) Why isn't code coverage enough? (2) What do you do with a cover point you can't hit?

    Check yourself Why must every assertion have a matching cover property?

    An assertion whose trigger never occurred passes without checking anything; the cover shows it was exercised.

    Check yourself A cross of burst length × error response is unhit. What do you do?

    Constrain or direct the stimulus to produce errors on bursts of each length; do not remove the cross unless the specification makes it impossible.

    Key takeaways

    • Passing tests prove only what they exercised; measure coverage of protocol situations, not just code.

    • Plan handshake timing, outstanding counts, ordering, boundaries, errors, flow control, reset and their crosses.

    • Every assertion needs a cover; an unhit point is a missing test.

    Keep going

    Next: Lesson 15.7, Formal Methods for Protocols. Checking every possible input sequence, not just the ones you thought of.

    Related topics

    • Part 15 overview: Specifying and Verifying

    • UVM course: Coverage Model Design

    Previous

    201 / 234

    Next: Formal Methods for Protocols

    Up next

    Up nextFormal Methods for Protocols

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Writing an Interface Contract
    • Safety and Liveness
    • Protocol Assertions