Hardware interview practice
Build accepted-traffic cross coverage
At most one request may be outstanding. A request is accepted on req_valid && req_ready, and its later response completes on rsp_valid && rsp_ready. Opcodes are READ, WRITE, or ATOMIC; lengths are 1 through 16; responses are OK or ERR. Write a covergroup that measures opcode × length × response only for accepted transfers.
Starting point
Question code
clk, reset_n
req_valid, req_ready, opcode, length
rsp_valid, rsp_ready, rsp_code
maximum outstanding requests = 1Reviewed example
Work through one case
Input
Case 1: Scenario: READ length 1 with OK increments READ × 1 × OK once.
Case 2: A request stalled for four cycles
Case 3: ATOMIC length 4Expected output
Case 1: Expected behavior: READ length 1 with OK increments READ × 1 × OK once.
Case 2: Causes no sample; after it is accepted, its later response handshake samples exactly once.
Case 3: Is excluded from the legal cross and reported by the protocol check.The shown result follows by applying this rule: The sample event corresponds to one complete transaction. The cases also demonstrate this requirement: Ignore illegal ATOMIC lengths other than one and flag reserved opcode values as illegal bins.
What to cover
Requirements
- Save opcode and length on the request handshake. Call the covergroup sample method exactly once on the matching response handshake, using the saved opcode and length with rsp_code.
- Create opcode bins for READ, WRITE, and ATOMIC and length bins for 1, 2–4, and 5–16.
- Create OK and ERR response bins and the opcode × length × response cross.
- Ignore illegal ATOMIC lengths other than one and flag reserved opcode values as illegal bins.