Every Part 4 testbench caught most of its bugs with messages such as "unexpected flit", "flit 1239, expected 8d57 from input 3" and "flits still pending". None of those tests contained a check written for that bug. All of them came from the scoreboard inside the shared environment, quietly comparing every flit DCRouter sent with the flit it should have sent.

How does a scoreboard decide whether every output was right?

The obvious answer, and why it breaks

The obvious scoreboard keeps a list of expected outputs and compares each actual output with the next one on the list. For a design that reorders legally, such as a router interleaving packets from four inputs, "the next one on the list" is the wrong expectation and the scoreboard reports false failures. Its structure must follow the specification's ordering promise (lesson 2.7), and it must also notice outputs that never come.

The idea: predict, compare, account for everything

DCRouter's scoreboard

Prediction, at the inputs: each accepted flit goes into the queue of its flow, with the error flag expected on a faulty tail.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

logic [16:0] exp_q [4][4][$];   // expected {err on tail, data} per (input, output)
for (genvar i = 0; i < 4; i++) begin : g_src
  always @(posedge clk) if (!rst) begin
    if (in_vld[i] && in_rdy[i]) exp_q[i][drv[i].dst].push_back({drv[i].last && drv[i].err, drv[i].data});
    if (!(in_vld[i] && !in_rdy[i])) begin          // never change valid data while stalled
      in_vld[i] <= 0;
      if (fq[i].size() > 0 && $urandom_range(0, 99) >= gap_pct[i]) begin
        drv[i] = fq[i].pop_front();
        in_vld[i] <= 1;
        in_data[16*i +: 16] <= drv[i].data;
        in_last[i] <= drv[i].last;
      end
    end
  end
end

Comparison, at the outputs: the header of each packet names its input (the testbench put the source in the header's free bits), so every later flit of the packet is matched against that flow's queue.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// ---------------- sinks and scoreboard ----------------
int drain_pct [4] = '{100, 100, 100, 100};
int occ [4] = '{0, 0, 0, 0}, got_pkts [4] = '{0, 0, 0, 0}, got_flits [4] = '{0, 0, 0, 0};
int cur_src [4];
bit in_pkt [4] = '{0, 0, 0, 0};
for (genvar o = 0; o < 4; o++) begin : g_snk
  always @(posedge clk) begin
    int n;
    out_crd[o] <= 0;
    n = occ[o];
    if (!rst && out_vld[o]) begin
      logic [15:0] d;
      logic [16:0] e;
      d = out_data[16*o +: 16];
      n++; got_flits[o]++;
      if (!in_pkt[o]) begin cur_src[o] = int'(d[8:7]); in_pkt[o] = 1; end
      if (exp_q[cur_src[o]][o].size() == 0) fail($sformatf("out%0d: unexpected flit %h", o, d));
      else begin
        e = exp_q[cur_src[o]][o].pop_front();
        if (e[15:0] !== d) fail($sformatf("out%0d: flit %h, expected %h from input %0d", o, d, e[15:0], cur_src[o]));
        if (out_err[o] !== (out_last[o] && e[16])) fail($sformatf("out%0d: out_err %0b on flit %h, expected %0b", o, out_err[o], d, out_last[o] && e[16]));
      end
      if (out_last[o]) begin in_pkt[o] = 0; got_pkts[o]++; end
    end
    if (n > 4) fail($sformatf("out%0d: %0d flits in a 4-slot sink (credit overrun)", o, n));
    if (n > 0 && $urandom_range(0, 99) < drain_pct[o]) begin n--; out_crd[o] <= 1; end
    occ[o] = n;
  end
end

What its failures look like

Each kind of mismatch has its own message, and each names the output, the flit and, where known, the input: enough to start debugging without opening a waveform.

Design decisions in every scoreboard

• Where predictions come from: from accepted inputs, never from the design's internals (lesson 3.4).

• How deep the model is: transaction results, not cycles (lesson 5.5).

• How outputs are matched: by the specification's ordering domain, here the flow (lesson 5.6).

• How identity is carried: a source and sequence number in a free field makes matching unambiguous.

• What happens at the end: leftovers are failures (lesson 5.7).

How real teams build scoreboards

What breaks

A scoreboard (illustrative) predicted outputs from the driver's intended transactions instead of from what the design accepted. When the design back-pressured and the driver dropped a stalled transaction instead of holding it, a testbench bug, the scoreboard still expected it, and every run with heavy back-pressure failed with a lost packet the design never received. Predicting from accepted inputs makes the scoreboard judge the design, not the driver's intentions.

Key takeaways

• A scoreboard predicts from accepted inputs, matches every output, and fails on leftovers.

• Its matching structure must follow the specification's ordering promise.

• Distinct failure messages for misrouted, corrupted, mis-flagged and lost outputs make debug fast.

Related topics

• Part 5 overview: Checking

• Protocols course: Ordering-Aware Scoreboards