Myth — "Scoreboards Are Optional"

No — assertions check local protocol correctness and coverage measures stimulus reach, but neither confirms the design produced the right outputs end to end, which is the scoreboard's job, so without a scoreboard the functional-correctness question is never asked. The three serve different purposes. Assertions check local, often temporal, protocol rules continuously — is the handshake legal, does VALID stay stable, is the response code valid — and catch violations at the exact point they occur, which is necessary and valuable but is about protocol legality, not whether the data is right. A transaction can satisfy every protocol assertion and still carry the wrong value, because the assertions check the form of the transfer, not the correctness of its payload end to end. Coverage records that scenarios were exercised, which tells you completeness of stimulus, not whether the design responded correctly in them. The scoreboard is the only component that asks did the right data come out for these inputs, by receiving the observed transactions from the monitors and comparing them against expected values, usually predicted by a reference model. Without it, a testbench drives stimulus, observes, checks protocol, and accumulates coverage, and finishes green having never compared an output to what it should be — so it can run against a functionally broken design and pass. So you cannot verify functional correctness with assertions and coverage alone; you can confirm protocol legality and stimulus reach, but the core question of whether the design computes correctly requires the scoreboard. The understanding to convey is the division of labor — assertions for local protocol, coverage for exercise, scoreboard for end-to-end correctness — and that the functional question is unasked without the scoreboard, which is why it is not optional.

An assertion checks a local, usually temporal, protocol rule at the point and time it occurs — is this handshake legal, does this signal hold stable, is this ordering respected — while a scoreboard checks end-to-end functional correctness by comparing the design's observed outputs against expected values across the whole input-to-output path. Assertions live close to the signals and the protocol: a property like a request must be granted within N cycles, or VALID must remain asserted until READY, is evaluated continuously by the simulator and fires the moment the rule is broken, which makes assertions excellent at catching protocol violations precisely and early. But an assertion's scope is the local rule it encodes; it does not know whether the data flowing through is functionally correct, only whether the transfer obeyed the protocol. The scoreboard operates at the transaction and functional level: it receives the transactions the monitors reconstructed, often predicts what the correct output should be using a reference model, and compares observed against expected, so it catches a wrong result regardless of whether the protocol was legal. The two are complementary and catch different bug classes: an assertion catches a malformed or mistimed transfer that is locally illegal; a scoreboard catches a well-formed, protocol-legal transfer that carries the wrong data or reflects a wrong computation. A design can pass all assertions and fail the scoreboard, when every transfer is protocol-correct but the function is wrong, and it can fail an assertion while the scoreboard would have agreed the intended data was right. So you need both: assertions for local protocol correctness at the point of occurrence, the scoreboard for end-to-end functional correctness of the results. The understanding to convey is local-protocol-at-the-point versus end-to-end-functional-by-comparison, and that they catch different bug classes, which is why a scoreboard is not made redundant by assertions.

Because without a scoreboard there is nothing comparing the design's outputs to expected values, so there is nothing that can fail on the data — the test drives stimulus, observes, perhaps checks protocol with assertions, accumulates coverage, and finishes, and a green result means the simulation completed without an error being raised, not that the outputs were correct. A pass in simulation is the absence of a failing check. If the only checks are assertions, they fire on protocol violations, so a design that obeys the protocol but computes wrong answers raises no assertion and the test passes. If there is no scoreboard, no component ever asks whether the observed outputs match what they should be, so a wrong output is simply not detected — it flows through, gets covered, and the run ends green. This is why a functionally broken design can pass a scoreboard-less testbench: the broken behavior is exercised and may even be well-covered, but because nothing compares it to expected, the bug is invisible. The danger is compounded by coverage, which can make the testbench look thorough — high coverage, many transactions, a clean run — while none of it confirms correctness, so people trust the green and ship. The fix is the scoreboard: a component that, for the covered scenarios, compares observed outputs against expected from a reference model, so a wrong output fails the test. The principle is that a pass is only as meaningful as the checks behind it, and with no scoreboard there is no functional check, so the pass is empty. The understanding to convey is that a green run is the absence of a failing check, that without a scoreboard there is no functional check to fail, and that this is why a broken design passes — which is the concrete danger the optional-scoreboard myth creates.

A reference model predicts what the correct output should be for given inputs, so the scoreboard has an expected value to compare the observed output against — for any behavior beyond trivial pass-through, the reference model is what makes expected meaningful. The scoreboard's job is to compare observed against expected, but expected has to come from somewhere, and for non-trivial designs it cannot just be the input echoed back. The reference model is an independent implementation of what the design is supposed to do — a golden model, an algorithmic predictor, a higher-level behavioral description — that takes the same inputs the DUT received and computes the correct result, which the scoreboard then compares against what the DUT actually produced. For a simple pass-through or a memory, expected might be trivially the written data, and a full model is unnecessary; but for a design that transforms data — a protocol converter, an arithmetic block, a processor, a packet engine — the reference model encodes the intended function so the scoreboard can check the transformation, not just the transport. Independence is important: the reference model is derived from the specification, not from the DUT's implementation, so it provides a genuinely separate notion of correct that can disagree with the DUT, which is what lets the scoreboard catch a design bug rather than echo it. The model can be at a higher abstraction than the DUT, since it only needs to predict the result, not how the hardware computes it. So the reference model is the source of expected truth in the scoreboard, the independent prediction of correct behavior against which the observed behavior is checked. The understanding to convey is that the reference model predicts the expected result independently from the spec, that it is what makes the scoreboard's comparison meaningful for non-trivial behavior, and that its independence is what lets it catch real functional bugs.

I would ask what is confirming the design's outputs are correct, because if there is no scoreboard, the answer is usually nothing — the testbench runs and passes, but a pass without a scoreboard means the simulation completed without a protocol or runtime error, not that the outputs were right, so I would want to understand what they think works means. I would frame it as a question rather than an accusation: when a test passes, what told you the design produced the correct result for the stimulus it received? If they point to assertions, I would clarify that assertions check local protocol legality — that the transfers were well-formed and well-timed — but not that the data or computation was functionally correct, so a protocol-legal but functionally-wrong design passes them. If they point to coverage, I would note that coverage measures which scenarios were exercised, not whether the design responded correctly. If they point to the test simply not erroring, I would explain that with no scoreboard there is nothing that compares outputs to expected, so there is nothing that could error on the data — the green is the absence of a check, not the presence of confirmed correctness. The concrete risk is that a functionally broken design passes their testbench, possibly with high coverage, and gets shipped, because the functional question was never asked. The fix is to add a scoreboard that, for the scenarios they cover, compares observed outputs against expected from a reference model, turning their exercise into verification. I would present it as completing the verification, not criticizing it — they have built the stimulus and observation, and the scoreboard is the missing checker. The understanding to convey is the diagnostic question what confirms correctness, the reframing of works as ran-without-error, and the concrete risk of shipping a broken design, which is how you constructively correct the optional-scoreboard belief.