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

  • Start Here6
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive36
  • SystemVerilog Assertions — Interview-Critical Deep Dive40
  • Functional Coverage in SystemVerilog22
  • Testbench Architecture in SystemVerilog23
  • Advanced Language & Integration25
  • Senior & Interview Preparation21
  • Principal-Level Verification28
    • Reusable Testbench Architecture
    • Checking Out-of-Order Traffic
    • Assertion Depth
    • Coverage Modelling for Real Features
    • Capstone: Out-of-Order Memory Controller
      • Spec and Plan
      • Environment
      • Checking
      • Coverage and Closure
      • Bug Hunt and Sign-Off
    • Principal Judgment
Loading lesson

‹Principal-Level Verification
  1. Topics
  2. SystemVerilog
  3. Principal-Level Verification
  4. Capstone: Out-of-Order Memory Controller

Part 9 · Principal-Level Verification · Advanced

Capstone: Out-of-Order Memory Controller

Verify a small ID-tagged memory controller end to end: spec and plan, a policy-driven environment, ID and memory checking, coverage closure, and a hunt for six planted bugs.

  • 5topics
  • 5lessons

This capstone verifies a design with the traits that make senior interviews hard: two request ports, reads that come back out of order across IDs, byte-strobed writes, back-pressure on both sides, and a reset that can land in the middle of traffic. The design is small enough to read in one sitting and real enough to hide bugs.

It reuses the patterns from the earlier topics: policy layers and an abstract BFM from Reusable Testbench Architecture, the ID scoreboard and memory model from Checking Out-of-Order Traffic, and the coverage mirror from Coverage Modelling. The last lesson plants six bugs and shows which checker catches each one, and when.

Diagram
port 0 ──req──►┌──────────────────────────┐
  port 1 ──req──►│ ooo_memctl #(BUG)         │──rsp──► sink (back-pressure)
                 │  16-word memory, strobes  │
                 │  8-entry read table       │   in order per {port, id}
                 │  round-robin on contention│   any order across them
                 └──────────────────────────┘
  policy items ─► abstract BFMs ─► pins ─► monitor ─► scoreboard + memory model
                                              ├──► coverage mirror (CV1-CV9)
                                              └──► assertions: fairness, stability, no orphan

Lesson

What it covers

Spec and Plan

The controller's rules, a risk ranking, plan rows with closure criteria, and a directed bench that checks each rule once.

Environment

Policy layers and test phases, abstract BFMs that drive through clocking blocks, reset-aware drivers, and a self-test of the plumbing.

Checking

ID scoreboard keyed by port and ID, memory snapshot at acceptance, drain accounting, assertions, and a unit test for the checkers.

Coverage and Closure

The coverage rows, covergroup and cover-property forms, merging ten seeds, and reading the holes.

Bug Hunt and Sign-Off

The complete bench, six planted bugs, which checker caught each one and at which cycle, and the sign-off review.

The design has a BUG parameter. BUG = 0 is correct; 1 to 6 select an ID swap, a dropped strobe, a lost response after reset, starvation, a duplicate response, and wrong ordering within an ID. Every bench that contains the design passes with BUG = 0 and was run against the planted bugs.

Check yourself The controller answers reads out of order. Why can the scoreboard still use queues instead of searching for a match?

Order is only free across ordering domains. Within one {port, id} the spec promises request order, so each domain gets its own queue and every response is compared with the head of its queue. Searching for a match anywhere would accept a within-ID swap, which is one of the planted bugs.

Interview

Likely question: “Walk me through how you would verify an out-of-order memory controller.” A strong answer follows this topic's order: the rules and their risks, a plan with closure criteria, an environment that can reach the risky states, checkers that encode the ordering and memory rules exactly, coverage that proves the states were reached, and evidence that the checkers catch planted bugs.

Related topics

  • Part 9: Principal-Level Verification

  • Part 8 capstone: Parameterized FIFO

  • Previous topic: Coverage Modelling

  • Next topic: Principal Judgment

PreviousNext: Spec and Plan

Up next

Up nextSpec and Plan

Sign in to save progress

Practice this lessonReport an error

See also

  • Reusable Testbench Architecture
  • Checking Out-of-Order Traffic
  • Assertion Depth