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. Drills: Specifying and Verifying

Part 15 · Specifying and Verifying · All levels

Drills: Specifying and Verifying

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 15.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself What makes an interface specification good?

    Numbered rules that can each become an assertion, stated freedoms and limits, corner cases covered, diagrams labelled as examples.

    Check yourself Is "every request gets a response" safety or liveness?

    Liveness; bound it, check for leftovers at the end of the test, or prove it formally.

    Check yourself Write an assertion that data is stable while stalled.

    assert property (@(posedge clk) disable iff (!rst_n) valid && !ready |=> $stable(data));

    Check yourself How does a monitor know a burst ended?

    It samples only on transfer cycles and closes the transaction on the protocol's end marker or final beat.

    Check yourself How do you score out-of-order responses?

    One queue of predictions per ordering domain (ID or tag); compare each response with the oldest in its own queue.

    Check yourself What coverage would convince you an interface is done?

    A protocol plan: handshake timing, outstanding counts, ordering, boundaries, errors, flow control, reset, crosses, every assertion's trigger.

    Check yourself When would you use formal on an interface?

    For handshakes, counters, credit loops, FIFOs, arbiters, ordering and deadlock: rare combinations rather than data.

    Check yourself Why buy VIP for a standard protocol?

    An independent reading of the standard, already exercised widely, with agent, checker, coverage and compliance tests.

    Check yourself What would you add to an interconnect for silicon debug?

    Status and sticky errors, counters, timestamped trace frozen by triggers, and a debug path that works when hung.

    Check yourself Walk me through debugging a stuck valid.

    Find the missing condition, the state behind it, check it with a conservation rule, go back to the first wrong cycle.

    Whiteboard exercise

    Task. You are handed DCLink (valid/ready hops, credits, tags 0 to 3, replay) to verify before tape-out. Lay out the verification plan: checks, models, coverage, formal targets, and what you would ask the designers to add for silicon debug.

    Check yourself Open a model answer

    Checks: a checker bound at every hop with hold, stable, known, bounded-length and bounded-response rules, plus credit conservation (occupancy + sender credits + credits in flight = depth) and sequence-number rules for replay. Models: passive monitors per hop rebuilding packets and completions; a reference model predicting read data; a scoreboard with one outstanding entry per tag (tags are unique while outstanding); end-of-test checks that nothing is outstanding and every replay buffer drained. Coverage: stalls of every length class, back-to-back, every outstanding count to 4 tags, reordering across tags, credits at zero, ACK and NAK paths, replay timeout, CRC error injection on first, middle and last flits, reset with traffic in flight, crosses such as NAK during credit starvation. Formal: handshake rules per hop, credit counters and conservation, the replay buffer's sequence window, the arbiter's bounded wait, and deadlock freedom of the message classes. Independence: checker and model written from the specification by someone other than the designer. Silicon debug: credit and outstanding counters, sticky CRC and replay error capture with sequence numbers, a trace buffer per hop frozen by a replay-timeout or completion-timeout trigger.

    Checkpoint: ten questions

    Check yourself 1. Why should timing diagrams not be the rules?

    A diagram is one example; it does not say which features are required.

    Check yourself 2. Give one safety and one liveness property of a credit link.

    Safety: credits never exceed the buffer depth. Liveness: every sent packet's credit eventually returns.

    Check yourself 3. Why does each assertion need a cover?

    Otherwise it may never have been triggered and proves nothing.

    Check yourself 4. What does disable iff (!rst_n) do?

    Turns the check off during reset so reset values cause no false failures.

    Check yourself 5. What goes wrong if a monitor samples on valid alone?

    Stalled words are counted several times.

    Check yourself 6. Why is searching all outstanding requests a bad scoreboard?

    It accepts illegal reorderings, wrong IDs and duplicates.

    Check yourself 7. What does a duplicate response do to a per-ID queue?

    Puts it out of step, so later responses in that ID mismatch; report the first error.

    Check yourself 8. What guards a formal setup against over-constraint?

    Cover properties showing the interesting states are still reachable.

    Check yourself 9. Where does independence come from for an in-house protocol?

    A checker and model written from the specification by someone other than the designer.

    Check yourself 10. In the batching hang, what was the conservation check?

    Credits + occupancy + owed = initial credits: 0 + 0 + 3 = 3, so credits were withheld, not lost.

    Revisit

    • 15.1 Writing an Interface Contract

    • 15.2 Safety and Liveness

    • 15.3 Protocol Assertions

    • 15.4 Monitors and Transaction Reconstruction

    • 15.5 Ordering-Aware Scoreboards

    • 15.6 Protocol Coverage

    • 15.7 Formal Methods for Protocols

    • 15.8 Compliance and VIP

    • 15.9 Observability and Tracing

    • 15.10 A Waveform Debug Method

    Keep going

    Next: Part 16: Protocols Dissected. How do real protocols answer the fifteen questions?

    Previous

    206 / 234

    Next: Part 16: Protocols Dissected

    Up next

    Up nextPart 16: Protocols Dissected

    Sign in to save progress

    Practice this lessonReport an error

    See also

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