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. ```hint Where bugs hide Start from the cycles in which a push and a pop arrive together, and from the points where the internal pointers wrap or the occupancy hits a limit. ``` #### 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. ```hint Fairness as a bound Phrase "fair" as a limit, in terms of `N`, on how long a requester that keeps requesting can wait. ``` #### 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. ```hint What may not change List what the sender is allowed to change while `valid` is high and `ready` is low. ``` #### 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 ### What a Strong Answer Covers - A layered testbench (drivers, monitors, scoreboard, coverage, bound assertions) whose checkers do not depend on the design's internals - A clear division between what assertions check cycle by cycle and what the scoreboard checks end to end - Corner cases reached deliberately through constraints, then confirmed by coverage - Correct reset handling in every assertion and model - Coverage goals that measure the spec, not just lines of code ### Follow-up Questions - How does the FIFO plan change if the write and read sides are in different clock domains? - How would you verify a weighted round-robin arbiter instead? - Which of these properties would you hand to a formal tool, and what assumptions would it need?