AMBA AHB · Module 17

AHB Scoreboards

Checking data integrity with a scoreboard — an independent reference model that predicts expected data and compares it against actual reads from the monitor. On a write it updates the model (expected[addr] = data); on a read it looks up the expected value and compares against the monitor's actual read data, flagging a data-integrity error (address, expected, actual) on a mismatch. The reference model must be independent of the DUT (else it shares its bugs) and honor access attributes (RO/W1C/RC). It catches wrong-data bugs that cycle-level assertions miss — assertions check timing, the scoreboard checks data; they're complementary.

Assertions (17.2) check protocol timing rules; the monitor (17.3) reconstructs transactions. But neither answers the data question: did a read return the value that was written? That's the scoreboard's job — checking data integrity. A scoreboard maintains an independent reference model — a golden model of what the design should contain — and compares its prediction against the actual data the monitor reconstructs. It subscribes to the monitor's transaction stream: on a write transaction, it updates the reference model (expected[addr] = data); on a read transaction, it looks up the expected value for that address and compares it against the actual read data — passing if they match, flagging a data-integrity error (address, expected, actual) if they differ. The reference model is deliberately simple and independent (an associative array from address to data — a "golden memory"), so a bug in the design that returns wrong data is caught by the mismatch. The subtleties: the model must honor access attributes (a read-only, write-1-to-clear, or read-to-clear register predicts differently than plain RW — 16.2) and apply transactions in order. Crucially, the scoreboard catches data-corruption bugs — like the wrong-mux-select (16.5) — that cycle-level assertions miss (they check timing, not data). Assertions and the scoreboard are complementary: assertions check protocol rules, the scoreboard checks data correctness. This chapter builds the scoreboard.

1. What Is It?

An AHB scoreboard is a data-integrity checker: an independent reference model that predicts on writes and compares on reads. Its parts:

Reference model — an independent golden model of the design's data (an associative array expected[addr] = data), honoring access attributes (RO/W1C/RC).
Predict on writes — on a write transaction, update the model (expected[addr] = data).
Compare on reads — on a read transaction, look up expected[addr] and compare against the monitor's actual read data.
Report mismatches — on a difference, flag a data-integrity error with the address, expected, and actual values.

Figure 1 — the AHB scoreboard: a reference model that predicts and compares. It subscribes to the monitor's transaction stream. On a write, it updates the reference model (an associative array expected[addr] = data — a golden memory model, honoring RO/W1C/RC attributes). On a read, it compares the monitor's actual read data against expected[addr] — match passes, differ reports a data-integrity error (address, expected, actual). An independent golden model: writes update it, reads are checked against it, so a DUT that returns wrong data is caught by the mismatch.

So an AHB scoreboard is the data-correctness checker — the complement to assertions' protocol-correctness checking. The core idea is an independent reference model: a separate, simple, trusted model of what the design should hold. By keeping it independent (a plain associative array, not derived from the DUT's logic), the scoreboard provides a golden prediction that's immune to the DUT's bugs — so when the DUT returns wrong data, the prediction is right and the comparison fails, catching the bug. The flow is simple: writes build the model (record what should be at each address), reads check against it (compare what the DUT actually returned to what's expected). The subtleties are in the prediction: the model must honor the same access attributes the slave does (a read-only register predicts the hardware value, not a written one; a W1C/RC register predicts the attribute-specific behavior), and apply transactions in the right order. So an AHB scoreboard is the independent golden model that catches wrong-data bugs. So it's how you check data integrity.

A scoreboard = an INDEPENDENT reference model (expected[addr]=data) that predicts on writes and compares on reads against the monitor's actual data; mismatch = data-integrity error (addr/exp/act). It catches wrong-DATA bugs assertions (timing rules) miss — they're complementary

An AHB scoreboard in one frame: a data-integrity checker built around an independent reference model — a golden model of what the design should contain (an associative array expected[addr] = data) — that predicts on writes and compares on reads. It subscribes to the monitor's (17.3) transaction stream: on a write transaction, it updates the model (expected[addr] = data); on a read transaction, it looks up expected[addr] and compares it against the actual read data the monitor reconstructed — pass if equal, data-integrity error (reporting address, expected, actual) if not. The model is independent (a simple golden memory, not derived from the DUT) so it's immune to the DUT's bugs — when the DUT returns wrong data, the prediction is right and the comparison catches it. The subtleties: the model must honor access attributes (a read-only register predicts the hardware value; a W1C register clears on a write-1; a read-to-clear register clears on read — 16.2 — so the model predicts them correctly) and apply transactions in order. Crucially, the scoreboard catches data-corruption bugs — like the wrong-mux-select (16.5) returning the wrong slave's data — that cycle-level assertions miss (assertions check protocol timing; the scoreboard checks data values). So assertions (protocol rules) and the scoreboard (data correctness) are complementary — you need both.

2. Why Does It Exist?

The scoreboard exists because data correctness is a distinct concern from protocol correctness — assertions check the rules of the bus (timing, sequencing) but not whether the data values are right; so a separate mechanism, an independent reference model, is needed to verify that reads return what was written.

The data correctness ≠ protocol correctness is the root: a design can perfectly obey the protocol (every assertion passes — stable address, two-cycle ERROR, correct HREADY) and still return wrong data — e.g. the wrong-mux-select bug (16.5) returns the wrong slave's data, but all the timing is correct. So assertions (which check timing/sequencing) can't catch it — the protocol is fine; the data is wrong. So a separate check — comparing the data values — is needed. So the scoreboard exists to check data, orthogonally to the protocol. So it's the data check. So data correctness needs its own checker.

The independent model catches DUT bugs drives the golden-model design: to check the DUT's data, you need a prediction of what's correct — and that prediction must be independent of the DUT (else a DUT bug would also corrupt the prediction, and the comparison would spuriously pass). So the scoreboard maintains an independent, simple reference model — a golden model whose correctness doesn't depend on the DUT's logic. When the DUT is wrong, the golden model is right, so the mismatch catches the bug. So the scoreboard exists with an independent model because the prediction must be trustworthy. So it's the golden reference. So independence enables catching.

The end-to-end data verification is the value: the scoreboard provides end-to-end data verification — every write's data is tracked, every read's data is checked. So any data corruption anywhere (a wrong write, a wrong read, a dropped update) is caught by an eventual read mismatch. So the scoreboard exists to give comprehensive data-integrity coverage. So it's end-to-end. So thorough data checking needs it. So the scoreboard exists because: data correctness is distinct from protocol correctness (assertions check timing, not values — the why); checking data needs an independent prediction (a golden reference model, immune to DUT bugs — the independence); and it provides end-to-end data verification (every write tracked, every read checked — the coverage). So the AHB scoreboard is the independent, golden, end-to-end data-integrity checker — the complement to assertions, catching the wrong-data bugs that correct-timing assertions can't. So this chapter builds the data check. So predict independently, compare on reads.

3. Mental Model

Model the scoreboard as an accountant keeping an independent ledger of a store's inventory, separate from the store's own records. Every time stock comes in (a write), the accountant records it in their own ledger. Every time the store claims what's on a shelf (a read returns data), the accountant checks the claim against their ledger — and if the store says "10 units" but the ledger says "12", the accountant flags the exact discrepancy (item, expected, claimed). Because the ledger is independent of the store's records, it catches the store's errors — if the accountant just trusted the store's count, they'd catch nothing.

A store (the design) with inventory (the data at each address). An accountant (the scoreboard) keeps an independent ledger (the reference model) — separate from the store's own records. The independence is the whole point: if the accountant just copied the store's own counts, they'd never catch the store's mistakes (a wrong count would be in both). By keeping their own ledger, the accountant has a trusted reference. Now the flow. Every time stock arrives (a write), the accountant records it in the ledger — "12 units of item A received" (expected[A] = 12). They track every delivery. Then, when the store claims what's on a shelf (a read returns data — the monitor reports the actual value), the accountant checks the claim against the ledger: the store says "shelf A has 10", the ledger says "should be 12" — mismatch! The accountant flags the exact discrepancy: "item A — ledger says 12, store claims 10" (the address, expected, actual). If they matched, fine — pass. The accountant must also know the rules: some items are "display only — count is fixed by the manufacturer" (a read-only register — predict the hardware value, not a "received" count); some are "consumed on inspection" (a read-to-clear — the count changes when read). So the accountant's ledger honors these rules when predicting. And they process deliveries and checks in the right order (a delivery before a sale vs after changes the expected count). So the accountant independently tracks what should be there and catches the store whenever its claim doesn't match.

This captures the scoreboard: the store = the design; the inventory = the data at each address; the accountant's independent ledger = the reference model (golden, separate from the DUT); the independence catching errors = the model being immune to DUT bugs; recording each delivery = updating expected[addr] on a write; checking the store's claim against the ledger = comparing actual read data to expected; flagging the exact discrepancy = reporting address/expected/actual; display-only and consumed-on-inspection items = read-only and read-to-clear attributes the model honors; processing in the right order = applying transactions in order. Keep an independent ledger, record every delivery, check every claim, and flag the exact discrepancy.

Watch the scoreboard catch a wrong-data read:

The scoreboard catches a wrong-data read

4 cycles

Figure 2 — the scoreboard catches a wrong-data read. Cycle group 1: a write transaction of D1 to address A — the scoreboard updates expected[A] = D1. Cycle group 2: a write of D2 to address B — expected[B] = D2. Cycle group 3: a read of address A — the monitor reports the actual read data the DUT returned. The scoreboard looks up expected[A] = D1 and compares. A correct DUT returns D1 (match → pass). A buggy DUT with a wrong read mux returns D2 (B's data) — actual (D2) differs from expected (D1), so the scoreboard reports a data-integrity ERROR: addr A, expected D1, actual D2. The 'scoreboard' row shows update, update, then CHECK→ERROR. The wrong-data bug — invisible to a timing assertion — is caught by the data comparison.

The model's lesson: keep an independent ledger, record every delivery, check every claim, and flag the exact discrepancy. In the waveform, the scoreboard predicted expected[A] = D1 from the write, and when the buggy DUT returned D2 on the read of A, the mismatch was caught — with the exact address, expected, and actual.

4. Real Hardware Perspective

In a UVM testbench, the scoreboard is a uvm_scoreboard with an analysis export (subscribing to the monitor), a reference model (an associative array, possibly an attribute-aware model), and a write method that predicts on writes and compares on reads; ordering and attribute-awareness are the correctness-critical parts.

The analysis export subscription: the scoreboard has a uvm_analysis_imp (or export) that connects to the monitor's analysis port (17.3). Each broadcast transaction arrives at the scoreboard's write(txn) method. So in UVM, the scoreboard subscribes to the monitor. So it receives transactions. So that's the input.

Figure 3 — a scoreboard catching a wrong-data read. Step 1: a write of D1 to A updates expected[A]=D1 (and a write D2→B sets expected[B]=D2). Step 2: a read of A arrives; the monitor reports the actual read data; the scoreboard looks up expected[A]=D1 and compares. If the DUT is correct it returns D1 (pass). If the DUT has a wrong read mux returning B's data, actual is D2, which differs from expected D1, so the scoreboard reports a data-integrity error (addr A, exp D1, act D2). This catches the wrong-mux-select bug that a cycle-level assertion would miss; the reference model must honor attributes (RO/RC predict differently than RW).

The predict-on-write, compare-on-read: the write(txn) method branches on the transaction: if txn.is_write, update the model — expected[txn.addr] = txn.data (or attribute-specific); if txn.is_read, look up exp = expected[txn.addr] and compare — if (txn.data !== exp) report data-integrity error(addr, exp, txn.data). So in UVM, the scoreboard's core is this predict/compare branch. So it's a method. So that's the logic.

The attribute-awareness and ordering: the reference model must honor the access attributes (16.2): a read-only register's expected value is the hardware-driven value (not a written one — so a write to it doesn't update the model; a read predicts the hardware value); a W1C register clears the written-1 bits in the model; a read-to-clear register's model clears on a read (so a subsequent read predicts the cleared value). And the scoreboard must process transactions in the order the monitor delivers them (and handle pipelining/out-of-order carefully if applicable). Getting the attribute prediction or the ordering wrong makes the scoreboard itself wrong (false errors or missed bugs). So in UVM, the scoreboard is a subscribing component with an attribute-aware reference model and a predict/compare write method — and its correctness (right prediction, right order) is as critical as the monitor's (both are load-bearing). So in UVM, build an attribute-aware, correctly-ordered reference model. So that's the implementation.

5. System Architecture Perspective

At the system level, the scoreboard is the data-correctness authority — the end-to-end guarantee that the design moves and stores data correctly — and it's the complement to assertions that, together, give complete verification: protocol (assertions) plus data (scoreboard).

The data-correctness authority: the scoreboard is the final word on data correctness — it tracks every write and checks every read, so it catches any data corruption (a wrong write address, a wrong read value, a dropped update, a wrong-mux). So at the system level, the scoreboard is the authority on "does the design handle data correctly?". So it's the data guarantee. So data integrity is its domain.

The complement to assertions: assertions check protocol (timing, sequencing, responses); the scoreboard checks data. These are orthogonal and complementary — a design could pass all assertions and fail the scoreboard (correct protocol, wrong data — the wrong-mux bug) or vice versa. So together, they cover both dimensions of correctness. So at the system level, the scoreboard + assertions form a complete checking pair. So it's the data half of the pair. So both are needed.

The golden model reusability: the reference model (the golden memory, attribute-aware) is reusable — the same model checks any AHB slave/memory (configured for its attributes). And it's part of the VIP (17.11) — a reusable data checker. So at the system level, the scoreboard is the data-correctness authority (end-to-end — every write tracked, every read checked), the complement to assertions (protocol + data = complete verification — orthogonal, both needed), and a reusable golden model (part of the AHB VIP, configured per slave). So the scoreboard is the data half of AHB verification — the independent authority that, with assertions, makes the verification complete: the bus obeys the protocol (assertions) and handles data correctly (scoreboard). So check protocol and data together — that's complete. So pair the scoreboard with assertions.

6. Engineering Tradeoffs

The AHB scoreboard embodies the independent-model, predict-compare, attribute-aware design.

Independent model vs derived-from-DUT. An independent golden model catches DUT bugs (the prediction is trustworthy); a model derived from the DUT's logic would share its bugs (spurious passes). Keep the model independent.
Simple associative array vs full functional model. A simple expected[addr] array suffices for memory/RW registers; an attribute-aware (or fully functional) model is needed for RO/W1C/RC and side effects. Model only the behavior the slave has.
Compare on read vs compare continuously. Comparing on reads (when data is observable) is natural; you can't compare internal state directly (it's not visible). Compare reads against the predicted model.
Scoreboard (data) vs assertions (protocol). Use both — they're complementary (orthogonal correctness dimensions). Relying on one alone leaves the other dimension unchecked.

The throughline: an AHB scoreboard checks data integrity via an independent reference model — a golden model of the design's data (expected[addr] = data) that predicts on writes and compares on reads against the monitor's actual read data, flagging a data-integrity error (address, expected, actual) on a mismatch. The model is independent (immune to DUT bugs), must honor access attributes (RO/W1C/RC predict differently — 16.2), and must apply transactions in order. It catches data-corruption bugs (the wrong-mux-select — 16.5) that cycle-level assertions miss (assertions check timing; the scoreboard checks values). It's the data-correctness authority and the complement to assertions — together they give complete verification (protocol + data). Its correctness (right prediction, right order) is load-bearing, like the monitor's.

The reference model must be INDEPENDENT of the DUT and must honor access attributes — a model derived from the DUT shares its bugs (spurious passes), and a model that predicts RO/W1C/RC registers as plain RW reports FALSE errors (or misses real ones). Get the prediction right

The scoreboard's value hinges on the reference model being both independent and correct (attribute-aware) — and the two failure modes are opposite and both dangerous. (1) A non-independent model (spurious passes). If the reference model is derived from (or shares logic with) the DUT — e.g. it calls the DUT's read function to "predict" the expected value, or uses the same (buggy) address-decode — then a DUT bug would also corrupt the prediction, so the comparison would spuriously pass (both wrong, in the same way). The whole point of the scoreboard — an independent trusted reference — is lost. The model must be independent: a simple, separately-written golden model (a plain associative array, hand-modeled attribute logic) whose correctness does not depend on the DUT. (2) An attribute-unaware model (false errors / missed bugs). If the model predicts every register as plain RW — ignoring attributes — it mispredicts the special registers (16.2). For a read-only register: the model would predict the written value, but the DUT (correctly) ignores the write and returns the hardware value — so the model expects the written value, the DUT returns the hardware value, and the scoreboard reports a false error (the DUT is right, the model is wrong). For a write-1-to-clear register: a write of 1 clears a bit in the DUT, but the model (predicting RW) would store the 1 — so a subsequent read mismatches (false error). For a read-to-clear: the DUT clears on read, so a second read returns 0, but the model (predicting RW) still expects the original — false error. Conversely, an attribute-unaware model could miss a real bug if its (wrong) prediction happens to match a different DUT bug. So the model must honor the attributes: don't update on a write to a RO register; clear the written-1 bits for W1C; clear on read for RC. The guard: just like the monitor (17.3), the scoreboard's correctness is load-bearing — a wrong model produces false errors (wasting debug time on a "DUT bug" that's really a scoreboard bug) or missed errors (a real bug hidden by a coincidentally-matching wrong prediction). So verify the scoreboard — run it against a known-good DUT (all checks should pass — no false errors) and against a known-buggy DUT (the right check should fire). The discipline: keep the reference model independent (trustworthy prediction) and attribute-aware (correct prediction) — a correct golden model catches the wrong-data bug; a flawed one is worse than none (false confidence or false alarms). (See Register Bank Slave for the attributes the model must mirror.)

7. Industry Example

Build a scoreboard for the register-bank slave (16.2), handling its mixed attributes.

You're verifying the 16.2 register bank — CTRL (RW), STATUS (RO), IRQ (W1C), RXDATA (RC). The scoreboard's reference model must honor each.

Subscribe to the monitor. The scoreboard's analysis export connects to the monitor's port; each reconstructed transaction arrives at write(txn).
CTRL (RW) — plain prediction. On a write to CTRL: expected[CTRL] = txn.data. On a read of CTRL: compare txn.data against expected[CTRL]. Straightforward.
STATUS (RO) — predict the hardware value. On a write to STATUS: do not update the model (the DUT ignores RO writes). On a read: predict the hardware-driven status (modeled from the testbench's knowledge of the DUT state) — not any written value. (If the model wrongly predicted a written value, it would false-error against the correctly-ignoring DUT.)
IRQ (W1C) — clear on write-1. On a write to IRQ: for each bit, if (txn.data[b]) expected[IRQ][b] = 0 (write-1 clears); hardware sets bits in the model per the testbench's event model. On a read: compare against the model.
RXDATA (RC) — clear on read. On a read of RXDATA: compare txn.data against expected[RXDATA], then update the model expected[RXDATA] = 0 (read-to-clear) — so a subsequent read predicts the cleared value (or the next FIFO entry). (If the model didn't clear, the second read would false-error.)
Verifying the scoreboard. Run against a known-good register bank (all checks pass — confirming no false errors from mispredicted attributes), then against a buggy one (e.g. a STATUS that's wrongly writable, or an RXDATA that doesn't clear) — confirming the right check fires.

The example shows the scoreboard's attribute-aware reference model: each register predicted per its attribute (RW plain, RO hardware-value, W1C clear-on-1, RC clear-on-read), so the comparisons are correct — no false errors from mispredicting, and real data bugs caught. The independence (a separate golden model) and the attribute-awareness are what make it trustworthy. This is how you check a register bank's data. This is the data-correctness authority.

8. Common Mistakes

AHB-scoreboard misconceptions

"Derive the expected value from the DUT." No — the reference model must be independent (a separate golden model). A DUT-derived model shares the DUT's bugs → spurious passes.
"Predict every register as plain RW." No — honor the attributes (RO predicts the hardware value, W1C clears on write-1, RC clears on read). Mispredicting → false errors (or missed bugs).
"The scoreboard checks protocol timing." No — that's assertions. The scoreboard checks data values. They're complementary — use both.
"Compare internal state directly." No — internal state isn't observable; compare reads against the predicted model (data is observable on reads).
"Transaction order doesn't matter." No — apply transactions in the order the monitor delivers (a write before vs after a read changes the expected value). Order is correctness-critical.
"The scoreboard doesn't need verifying." No — its correctness is load-bearing. Run against a known-good DUT (no false errors) and a known-buggy one (the right check fires).

9. Interview Insight

The AHB scoreboard is a core verification interview topic — the independent-reference-model idea, the predict/compare flow, and the attribute-awareness + assertions-complement framing are the signals.

Figure 4 — a strong answer in one card: an independent reference model (expected[addr]=data) subscribing to the monitor; WRITE updates the model, READ compares actual vs expected → mismatch = error (addr/exp/act); the model must honor attributes (RO/W1C/RC) and apply transactions in order; it catches wrong-data bugs assertions miss — assertions = timing rules, scoreboard = data, complementary. The senior point: an independent golden model that predicts on writes and checks on reads, catching wrong-data bugs assertions cannot.

The answer that lands gives the independent model and the complement framing: "A scoreboard checks data integrity. It maintains an independent reference model — a golden model of what the design should contain, basically an associative array from address to expected data — and it subscribes to the monitor's transaction stream. On a write transaction, it updates the model: expected at that address equals the written data. On a read transaction, it looks up the expected value for that address and compares it against the actual read data the monitor reconstructed. If they match, pass; if they differ, it reports a data-integrity error giving the address, the expected value, and the actual value. The key word is independent: the model must not be derived from the DUT, because if it shared the DUT's logic it would share its bugs and spuriously pass. By keeping it a separate, simple golden model, when the DUT returns wrong data the prediction is right and the mismatch catches the bug. The subtlety is that the model has to honor access attributes — a read-only register predicts the hardware value not a written one, a write-one-to-clear register clears on a write of one, a read-to-clear register clears on read — otherwise you get false errors against a correct DUT. And transactions must be applied in order. The important framing is that the scoreboard is complementary to assertions. Assertions check the protocol — timing, sequencing, the two-cycle error. The scoreboard checks the data values. A design can pass every assertion and still return wrong data — like a wrong read mux that returns the wrong slave's data with perfect timing — which only the scoreboard catches. So you need both: assertions for protocol, scoreboard for data. And because the scoreboard's correctness is load-bearing, I'd verify it against a known-good DUT to confirm no false errors and a known-buggy one to confirm the check fires." The independent-model idea, the predict/compare flow, and the attribute-awareness + complement framing are the senior signals.

🔍 The discriminator: the reference model must be INDEPENDENT (else it shares DUT bugs → spurious passes) and ATTRIBUTE-AWARE (else RO/W1C/RC mispredict → false errors); and the scoreboard is COMPLEMENTARY to assertions — protocol (assertions) + data (scoreboard) = complete

The discriminator on the scoreboard is whether you stress the independent reference model and frame it as complementary to assertions. A weak answer says "the scoreboard compares read data to expected." A solid answer adds the predict-on-write, compare-on-read flow and the reference model. But the senior answer stresses two things. First, independence: the model must be a separate golden model, not derived from the DUT — because a DUT-derived model shares the DUT's bugs and spuriously passes (both wrong the same way). The whole value — a trustworthy prediction — depends on independence. Second, attribute-awareness: the model must honor the access attributes (16.2) — a read-only register predicts the hardware value (not the written one), W1C clears on write-1, RC clears on read — or it false-errors against a correct DUT (the model expects a written value the correctly-ignoring DUT doesn't store). Getting either wrong makes the scoreboard itself wrong — spurious passes (non-independent) or false errors (attribute-unaware) — and since the scoreboard's correctness is load-bearing (like the monitor's), you verify it (known-good DUT → no false errors; known-buggy → the check fires). The standout framing: the scoreboard is complementary to assertions — assertions check protocol timing, the scoreboard checks data values — and they're orthogonal: a design can pass every assertion and fail the scoreboard (the wrong-mux-select bug — 16.5 — perfect timing, wrong data) or vice versa. So complete verification needs both. A candidate who insists the model be independent and attribute-aware, frames scoreboard + assertions as the complete (data + protocol) pair, and notes the scoreboard must itself be verified demonstrates real verification depth — not just "compare the data".

10. Practice Challenge

Build and reason from the AHB scoreboard.

The structure. Describe the scoreboard: independent reference model, subscribe to the monitor, predict on writes, compare on reads.
Independence. Explain why the reference model must be independent of the DUT, and the spurious-pass bug otherwise.
Read the waveform. From Figure 2, explain how the scoreboard predicts expected[A] = D1 and catches the buggy read returning D2.
Attributes. Explain how the model must honor RO/W1C/RC attributes, and the false-error bug if it doesn't.
Complement. Explain how the scoreboard (data) complements assertions (protocol), with a bug each catches that the other misses.

11. Key Takeaways

A scoreboard checks data integrity via an independent reference model (expected[addr] = data) that predicts on writes and compares on reads against the monitor's actual data — mismatch = data-integrity error (address, expected, actual).
The model must be independent of the DUT — a DUT-derived model shares its bugs (spurious passes). An independent golden model gives a trustworthy prediction.
The model must honor access attributes (RO predicts the hardware value, W1C clears on write-1, RC clears on read — 16.2) and apply transactions in order — else false errors (or missed bugs).
It catches wrong-DATA bugs assertions miss — e.g. the wrong-mux-select (16.5) with perfect timing; assertions check protocol, the scoreboard checks values.
Scoreboard + assertions = complete — complementary, orthogonal dimensions (data + protocol); a design can pass one and fail the other. Use both.
Its correctness is load-bearing — verify it against a known-good DUT (no false errors) and a known-buggy one (the right check fires). Compare on reads (state is observable there).

12. What Comes Next

You now can check data integrity. The next chapters measure and generate — completing the verification loop:

AHB Functional Coverage (next) — define coverage for transfers, bursts, sizes, responses, and corners (measuring what was exercised).
Constrained-Random Traffic, and the targeted tests (wait/burst/error) — generate stressful, legal stimulus.

To revisit the transactions the scoreboard consumes, see AHB Monitors; for the attributes the model must mirror, see Register Bank Slave; for the protocol checks it complements, see AHB Assertions (SVA).