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
  • Advanced Language & Integration26
  • Senior & Interview Preparation23
    • Senior Debug Playbook
    • Reviewing Verification Code
    • Verification Strategy: Spec to Sign-Off
    • SystemVerilog Interview Q&A Bank
    • Capstone: Verify a Parameterized FIFO
      • Spec Analysis and Verification Plan
      • Interface and Harness
      • Generator, Driver and Environment
      • Monitor, Scoreboard and Model
      • Assertions and Coverage
      • Regression, Holes and Sign-off
  • Principal-Level Verification34
Loading lesson

←Senior & Interview Preparation
  1. Topics
  2. SystemVerilog
  3. Senior & Interview Preparation
  4. Capstone: Verify a Parameterized FIFO

Part 8 of 9Part 8 of 9/Senior & Interview PrepIntermediate

Capstone: Verify a Parameterized FIFO

A complete verification environment for a parameterized FIFO, from spec and plan to a run that catches a planted bug. It extends the PacketFIFO project.

  • 6topics
  • 6lessons

This capstone verifies a parameterized synchronous FIFO end to end. Planning, stimulus, checking, assertions, coverage and closure each appear once, in one environment.

How it extends PacketFIFO

This is the finale of the PacketFIFO project. PacketFIFO v0 is the same kind of design: a valid/ready FIFO whose in_ready is low exactly when it is full and whose out_valid is low exactly when it is empty. It stores 9-bit entries, a last bit next to each byte, in 4 slots.

The capstone FIFO is the parameterized form of that design. WIDTH and DEPTH are parameters (default 8 and 16) and it adds explicit full and empty pins. Set WIDTH to 9 and DEPTH to 4 and it holds PacketFIFO's storage. Where PacketFIFO v0 has no flag pins, derive them: full is !in_ready and empty is !out_valid.

The packet format (header with kind, dest and len, the payload, the check byte, and last) stays in the testbench. The capstone environment moves plain words and never needs to know about packets, which is why the same environment checks PacketFIFO unchanged. The packet layer sits on top: a generator that builds whole packets and a checker that compares them.

Diagram
CAPSTONE ENVIRONMENT MAP

                     ┌───────────── tb_top ─────────────┐
                     │  clk/rst gen        fifo_if      │
                     │                    ┌───────┐     │
   gen ──mailbox──► drv ════════════════►│  DUT  │     │
    │                │   (cb drive)      │ fifo  │     │
 scenario            │                   └───┬───┘     │
  knobs              │      ▲ bind: fifo_sva │         │
                     │      └────────────────┘         │
                     │  in_mon (push side)  out_mon (pop side)
                     │      │                  │       │
                     │      ▼                  ▼       │
                     │  ┌──────── scoreboard ───────┐  │
                     │  │ queue model · in-order cmp│  │
                     │  └───────────┬───────────────┘  │
                     │          coverage (cov)         │
                     └─────────────────────────────────┘

  stimulus stack:  gen → mailbox → drv → fifo_if
  checking stack:  monitors → scoreboard ← reference model
  always-on:       bound assertions + sampled coverage

Lesson

What it builds

Path

Spec Analysis and Verification Plan

The spec, the question log, features F-01 to F-11 and the plan table.

Required

Interface and Harness

The interface with its clocking blocks, the harness, and a first handshake run.

Recommended

Generator, Driver and Environment

Transactions, scenario knobs, the generator, the driver and the environment.

Recommended

Monitor, Scoreboard and Model

Passive monitors and a queue-based scoreboard.

Required

Assertions and Coverage

Bound assertions and a covergroup that tracks the plan.

Recommended

Regression, Holes and Sign-off

Regression tiers, a planted bug found by a bound assertion, hole analysis and sign-off.

Required

Path: Required is the core first pass for this topic, Recommended is what most learners should read, and Optional is reference, specialist or revision material you can skip at first.

PacketFIFO step: this is the last step. Read the plan, then run the bench in the last lesson, which has two FIFOs, one with a planted bug. Change its two parameters to 9 and 4 to give it PacketFIFO's shape, and note which plan rows still apply unchanged.

Check yourself Why is a FIFO the standard verification capstone?

It is small enough to verify completely and rich enough to need every technique. Boundaries, simultaneity, reset, backpressure and parameter corners all fit in one design.

Likely question: “Walk me through verifying a FIFO.”

  • Plan from the spec: features, corners and a coverage goal per row.

  • Stimulus in phases: fill, drain, mixed, backpressure and reset.

  • Proof in layers: scoreboard for data, assertions for flags, coverage for closure.

PreviousNext: Spec Analysis and Verification Plan

Up next

Up nextSpec Analysis and Verification Plan

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • Senior Debug Playbook
  • Reviewing Verification Code
  • Verification Strategy: Spec to Sign-Off