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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • Start Here5
  • SystemVerilog Language Foundations28
  • Object-Oriented SystemVerilog for Verification30
  • Constraint Randomization — Interview-Critical Deep Dive39
  • SystemVerilog Assertions — Interview-Critical Deep Dive41
  • Functional Coverage in SystemVerilog25
  • Testbench Architecture in SystemVerilog24
    • Testbench Anatomy & Layering
    • Stimulus: Generators, Transactions & Drivers
    • Monitors, Scoreboards & Reference Models
      • Monitor Design
      • Scoreboard Architecture
      • Compare and End-of-Test
      • Reference Models and Coverage
      • PacketFIFO Step: A Monitor and Scoreboard
    • Self-Checking Tests & Regression
    • From Hand-Built TB to UVM
  • Advanced Language & Integration26
  • Senior & Interview Preparation23
  • Principal-Level Verification34
Loading lesson

←Testbench Architecture in SystemVerilog
  1. Topics
  2. SystemVerilog
  3. Testbench Architecture in SystemVerilog
  4. Monitors, Scoreboards & Reference Models

Part 6 of 9Part 6 of 9/Testbench ArchitectureIntermediate

Monitors, Scoreboards & Reference Models

Passive monitors, scoreboards and reference models that prove a testbench checked the DUT.

  • 5topics
  • 5lessons

Stimulus alone proves nothing. A monitor passively rebuilds transactions from DUT pins, a reference model predicts what the DUT should have done, and a scoreboard compares the two streams.

Three rules carry the whole topic. The monitor never drives a signal, the scoreboard compares observed against predicted, and end-of-test checks prove compares happened before any PASS.

Checking-side topology: two passive observation paths meet in the scoreboard.
Checking-side topology: two passive observation paths meet in the scoreboard.

Lesson

What it covers

Path

Monitor Design

Input-only sampling, accepted-beat reconstruction, one broadcast copy per consumer.

Required

Scoreboard Architecture

FIFO compare for in-order DUTs, by-id lookup for out-of-order DUTs.

Required

Compare and End-of-Test

Field masks, first-difference dumps, drain windows, watchdogs, leftover checks.

Required

Reference Models and Coverage

Transaction-level predict functions and coverage sampled from observed traffic.

Recommended

PacketFIFO Step: A Monitor and Scoreboard

The project step: two monitors, an in-order scoreboard and end-of-test checks for PacketFIFO, in one runnable bench.

Recommended

Path tells you how to spend your time. Required is the core first pass for building a layered testbench. Recommended is what most learners should read. Optional is reference, specialist or revision material that you can return to later.

Check yourself A test passes but the scoreboard compared zero transactions. What went wrong with the verdict?

Nothing checked anything. The PASS is hollow: a broken generator, a miswired monitor, or a disabled driver all produce zero compares. End-of-test checks must fail an empty scoreboard.

“How do you know the test checked anything?” is the whole topic in one question. Answer with the three rules above, then offer the monitor sketch, the FIFO versus by-id choice, and the zero-compare guard.

Related topics

  • Self-checking regressions

PreviousNext: Monitor Design

Up next

Up nextMonitor Design

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Testbench Anatomy & Layering
  • Stimulus: Generators, Transactions & Drivers
  • Self-Checking Tests & Regression