Verification Plan for a FIFO, a Round-Robin Arbiter and a Valid/Ready Handshake

In a hardware design-verification interview, you are handed a small block and its spec and asked how you would verify it: the verification architecture (stimulus, monitors, a scoreboard and a reference model), constrained-random stimulus, corner cases, SystemVerilog assertions (SVA) and functional coverage. The blocks that come up are a FIFO, a round-robin arbiter and a valid/ready handshake interface. Work through each one.

Constraints and Clarifications

• Assume a single clock clk and an active-low reset rst_n for every block.
• Sizes are parameters: the FIFO holds DEPTH entries of WIDTH bits, and the arbiter serves N requesters.
• You may sketch code in SystemVerilog or in pseudo-code; the reasoning matters more than exact syntax.

Clarifying Questions

• What does the FIFO do on a push while full or a pop while empty: ignore it, flag an error, or is it illegal stimulus that the environment must never drive?
• Does the FIFO present read data in the same cycle as the pop (first-word fall-through) or one cycle later?
• Is the arbiter's grant combinational from the current requests or registered, and can a grant last more than one cycle?
• Must requesters hold their request until it is granted?

Part 1 — Verify a synchronous FIFO

The FIFO has inputs push, din[WIDTH-1:0] and pop, and outputs dout[WIDTH-1:0], full and empty. Describe the testbench architecture and reference model, how you would constrain the stimulus, the corner cases, the assertions you would write, and the functional coverage you would collect.

What This Part Should Cover

• A reference model and scoreboard that predict every output, including data order
• Stimulus that drives the FIFO to full and to empty often, not just through the middle
• Assertions on the flags and on behavior at the limits
• Coverage of occupancy levels crossed with the operations performed

Part 2 — Verify a round-robin arbiter

N requesters raise bits of req[N-1:0], and the arbiter answers with gnt[N-1:0], granting requesters in rotating priority order. State the properties that define a correct round-robin arbiter, then describe the checking, stimulus, assertions and coverage.

What This Part Should Cover

• Safety properties (at most one grant, grants only to requesters) and work conservation
• Fairness as a bounded-wait property, and the assumption it relies on
• A cycle-accurate reference model versus property-only checking
• Coverage of grant sequences, pointer wrap-around and request patterns

Part 3 — Verify a valid/ready handshake

A sender drives valid and data, and a receiver drives ready; a transfer happens on every cycle in which both valid and ready are high. State the protocol rules, then describe the assertions for each side, the scoreboard for transfers through a block that uses this interface, the back-pressure stimulus and the coverage.

What This Part Should Cover

• The protocol rules as checkable properties, split between sender and receiver
• A scoreboard that detects dropped, duplicated and reordered transfers
• Stimulus that varies both the gaps between valid beats and the ready back-pressure
• Coverage of handshake states and stall lengths