C Part II · Module 24 · C Reference Models and Scoreboards

Reference Model Architecture

One picture the rest of the module refers back to: a stimulus sequence driven to both the design and the model, two results, and exactly one place where a verdict is formed. Two things about the picture are load-bearing rather than decorative. The specification carries no arrow, because nothing flows from it while the simulation runs — it is an authority, not a data source. And there is one comparison, not several, because a testbench with checks scattered through it has no single answer to the question of what was actually compared.

Advanced20 min readCPart IIVerificationDPI-C

Part II · Module 24 · Chapter 24.2 · Reference Model Architecture

1. The Picture

Chapter 24.1 described the architecture in a sentence and then spent the chapter on obligations. This chapter draws it, because the next seven refer back to it constantly and it is worth having one agreed layout rather than seven sketches.

Figure 1 — the architecture the rest of the module refers back to. One stimulus sequence fans out to the design and to the model, each produces a result, and both results meet in a single comparison. Two features of the drawing are claims rather than decoration. The specification sits at the top with no arrow leaving it, because nothing flows from it while the simulation runs: it is where the model's behaviour came from, not something the model consults. And the comparison is one box rather than a band across the bottom, because a verdict is formed in exactly one place — a testbench with checks scattered through it cannot answer the question of what was compared. The two outcomes below it are the whole business of the module: agreement, which chapter 24.1 measured the worth of, and disagreement, which chapter 24.9 is about resolving.

2. The Specification Carries No Arrow

The first thing to notice is a missing line.

Every other box in the figure is connected by something that moves at run time: stimulus flows, results flow, the comparison consumes them. The specification sits at the top with nothing leaving it, and that is the point.

A specification is an authority, not a data source. It was consulted when the model was written and it is not consulted while the simulation runs. There is no mechanism by which the model could ask it anything, and no moment at which it could.

Drawing it with an arrow would suggest otherwise, and the suggestion is exactly the one that leads to Chapter 24.1's measured failure. If the model "gets its answers from somewhere" at run time, then getting them from the design looks like the same kind of operation — and a model that does that scored 0 mismatches against 51 on the same broken design.

So the missing arrow encodes Chapter 24.1's independence obligation structurally: the only thing that flows into the model is stimulus. Everything else about it was decided before the run started, by a person reading a document.

3. There Is Exactly One Comparison

The second claim is that the comparison is one box, not a band across the bottom.

A verdict is formed in one place. That is a design decision and it is worth defending, because the alternative arrives by accident: a check here in the driver, an assertion there in the monitor, a comparison in the scoreboard, and a $display somebody added while debugging and never removed.

Three things a single comparison point gives you, each of which the rest of the module depends on:

One answer to "what did we compare?" Chapter 24.1 §4 measured that order is part of the stimulus for a stateful model. If comparisons happen in three places, three different notions of "corresponding result" are in play and no one of them is written down.

One count. The numbers this module quotes — 70 checks, 0 mismatches, 70 checks, 2 mismatches — exist because something counted. A scattered design has no denominator, and Chapter 23.6 §4 measured why the count matters: a check that silently stopped running looks exactly like a check with nothing to report.

One place to make the comparison fair. Chapter 24.8 is about normalising both sides before comparing and about comparing every element rather than stopping at the first difference. Those are things you do somewhere, and "somewhere" has to be a single somewhere.

4. What Each Arrow Hides

The figure is a map of decisions, not a wiring diagram. Each arrow is a question Chapter 24.4 answers properly; naming them here is what makes the picture worth referring back to.

Stimulus to both. The same sequence must reach both sides — the same values in the same order (24.1 §4, measured: 2 of 40 outputs coincided in reverse). Whether the model is driven from the same source as the design or from a recording of it is a real choice with real failure modes.

Design to actual. When is the design's result ready, and how does the comparison know? A registered output is available a cycle after the input, which is an ordering decision, not a detail.

Model to expected. The model is called once per transaction, and which transaction is the per-instance identity question Chapter 22.7 measured.

Both into the comparison. The two results have to be paired — this actual with that expected — and the pairing is the thing that breaks first when a design has latency or reorders.

The same picture, instantiated three times

The architecture is worth having because it is what makes a result interpretable. Measured, the same figure with three different designs in the middle box, one stimulus, one model:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

  clean DUT                 : 70 checks, 0 mismatch(es)
  saturation-bound bug      : 70 checks, 2 mismatch(es), first at check 28
  unsigned-concatenation bug: 70 checks, 51 mismatch(es), first at check 2

Three numbers, and the middle one is why the module exists.

Zero of seventy is the answer you want and the answer Chapter 24.1 warns you about reading too confidently.

Fifty-one of seventy is a gross failure. It would be found by almost any stimulus, and it was: the first mismatch is at check 2.

Two of seventy is the interesting one. It is a genuine departure from clause S3 — the design saturates the accumulator's lower bound one short of what the specification says — and 68 of the 70 checks did not notice. The first one that did was check 28, which means a test that stopped at twenty transactions would have reported a clean run.

That ratio is the argument for the whole architecture. A bug that shows in 51 of 70 checks does not need a reference model; a human watching the output would spot it. A bug that shows in 2 of 70 needs something that checks every transaction, counts them, and reports the first failure precisely — which is the figure, built properly.

5. What You Should Be Able to Say Now

One stimulus, two consumers, two results, one comparison — the picture the rest of the module refers back to.
The specification carries no arrow: it is an authority consulted when the model was written, never at run time.
The missing arrow is Chapter 24.1's independence obligation made structural — the only thing flowing into the model is stimulus.
There is exactly one comparison, and that is a decision, because scattered checks arrive by accident.
One comparison gives one answer to "what did we compare" — and order is part of that answer for a stateful model (24.1 §4).
It gives one count, which is the denominator every number in this module has.
And one place to make the comparison fair — normalising and comparing every element (24.8).
Each arrow hides a decision: driving both sides with the same sequence · when the design's result is ready · which transaction the model is being called about · how the two results are paired.
Measured, the same picture three times: 0 of 70 clean, 51 of 70 for a gross bug, 2 of 70 for a real spec departure.
The 2-of-70 is the argument for the architecture — 68 checks said nothing, and a twenty-transaction test would have reported a clean run.

6. Exercises

Redraw the figure for a block you work on, naming the real stimulus source, design, model and comparison point.
Why does the specification have no arrow? Give the failure that drawing one would license.
Find every place in a testbench you know where a comparison is made. How many are there, and can you state what each one pairs?
For a stateful model, explain why "we drove both sides with the same stimulus" is incomplete as a statement.
A design registers its output. Where in the figure does that fact live, and what does it change about the comparison?
§4 lists four hidden decisions. Pick one and describe what goes wrong if it is left implicit.
A bug appears in 2 of 70 checks. What would have to be true of a test for it to be missed entirely, and how long would such a test be?
You are told a run was clean. What three questions does this chapter suggest you ask before believing it?

7. Summary

One stimulus · two consumers · two results · one comparison.
The specification carries no arrow — an authority, not a run-time data source, which is 24.1's independence made structural.
Exactly one comparison, by decision: one answer to what was compared, one count, one place to make it fair.
Every arrow hides a decision: same values in the same order · when the result is ready · which transaction · how the two are paired.
Measured, three designs through the same picture: 0 of 70 clean, 51 of 70 gross, 2 of 70 for a real spec departure first seen at check 28.
The 2-of-70 is why the architecture is worth building — a shorter test would have called it clean.

The picture has one box whose contents have been taken on trust. A model written from the specification is the thing that makes the whole arrangement worth anything — and the way it stops being that is not dramatic, which is why the next chapter is the module's most important.

Where this fits

Part of the C Programming curriculum.