APB Protocol-Rules Catalogue

You have spent fourteen modules learning how APB behaves. This module verifies it — and verification begins not with code but with a list: the complete catalogue of every rule the protocol imposes. The single idea to carry: a verification environment can only check rules it has enumerated, so the first deliverable is an exhaustive, categorised catalogue of APB's protocol rules — and every assertion, monitor, scoreboard, and coverage point downstream is a direct encoding of one or more entries in it. Miss a rule here and no amount of clever SVA, no UVM agent, no coverage closure will ever catch its violation, because nothing is looking for it. The catalogue is the source of truth; the rest of the module is implementation.

1. Problem statement

The problem is enumerating, completely and unambiguously, every rule the APB protocol imposes — so that a verification environment has a definitive checklist of what "legal APB" means, against which any waveform can be judged.

Verification is the discipline of comparing observed behaviour against a specification. For that comparison to be sound, the specification has to be made concrete and itemised — turned from prose into a list of discrete, checkable propositions. APB's rules fall into a small number of categories, and the catalogue must cover all of them without gap or overlap:

• It must be exhaustive. Any rule omitted is a rule unchecked. A catalogue that lists the phase rules but forgets the signal-stability rules will pass a slave that corrupts PADDR mid-transfer, because nothing in the environment ever asked the question. Completeness is the whole value.
• Each rule must be atomic and checkable. "The protocol works correctly" is not a rule; "PENABLE must be low in the SETUP cycle and high in the ACCESS cycle" is. Each entry must be a single proposition that maps to one assertion or one coverage bin — not a paragraph.
• It must be categorised by what it governs. Rules cluster naturally — phase sequencing, select behaviour, signal stability, the ready handshake, the error response, reset — and organising them this way makes the catalogue auditable (you can ask "do we have all the stability rules?") and maps cleanly onto where each is checked.

So the job is not "know how APB works" — you already do. It is to render that knowledge as a complete, atomic, categorised checklist that becomes the contract the entire verification environment is built to enforce.

2. Why previous knowledge is insufficient

Across Modules 3–14 you learned every APB behaviour — the setup and access phases, PREADY, PSLVERR. But that knowledge lives in your head as understanding, not as a checklist, and verification needs the checklist:

• Understanding is not enumeration. Knowing how the access phase works is different from having written down every rule it implies — that PENABLE rises exactly one cycle after PSEL, that it stays high until completion, that it returns low after. An environment checks the enumerated propositions, not your intuition, so the propositions must be made explicit and complete.
• Scattered knowledge has gaps; a catalogue exposes them. A rule you learned in Module 5 and a related one from Module 8 may never have been considered together. Assembling them into one categorised list is precisely what reveals the missing entry — the stability rule no chapter stated outright, the reset behaviour you assumed. The catalogue is a gap-finding instrument.
• The catalogue is the interface to every other verification component. Assertions (Module 15.2), the monitor, the scoreboard, and the coverage model (15.5) all consume this list — each rule becomes an assertion to prove it, a monitor check to flag it, and often a coverage point to confirm it was exercised. Without the catalogue as the shared source of truth, those components drift and disagree about what "legal" means.

So the model to add is the itemised contract: APB's behaviour re-expressed as a finite, categorised set of atomic rules, which is the artifact verification is actually built against.

3. Mental model

The model: the rules catalogue is the rulebook of a sport, and the verification environment is the officiating crew. A referee cannot call a foul that isn't in the rulebook; an assertion cannot fire on a violation that isn't a catalogued rule. So before you hire referees (write assertions) or set up replay review (the scoreboard), you write the rulebook — every rule, numbered, categorised, unambiguous — and then assign each rule to an official. The completeness of the rulebook bounds the completeness of the officiating, exactly.

Three refinements make it precise:

• Rules cluster into six categories. Phase rules (the SETUP/ACCESS sequence and PENABLE timing); select rules (PSEL/PENABLE relationship, exactly one slave selected); stability rules (address/control/write-data held constant through the transfer); ready rules (PREADY sampling, bounded completion); error rules (PSLVERR valid only at completion); and reset rules (signal states during and after PRESETn). Every APB rule lives in one of these.
• Each rule has an owner downstream. A rule is not just stated — it is assigned: to an assertion (to prove it never breaks), to the monitor (to flag it and reconstruct the transaction), and frequently to a coverage point (to confirm the scenario was hit). The catalogue is the routing table from "rule" to "who checks it."
• The catalogue is versioned with the protocol. APB2 has fewer rules (no PREADY, no PSLVERR); APB3 adds the ready and error categories; APB4 adds byte-strobe and protection rules. The catalogue must be tagged by protocol version so the environment checks the right rule set for the DUT's claimed compliance.

4. Real SoC implementation

In practice the catalogue is a structured document (often a spreadsheet or a machine-readable list) where each rule has an ID, a category, a precise statement, the protocol version it applies to, and a pointer to its assertion/coverage. Encoded close to the SVA it generates, a slice looks like this:

// A slice of the APB rules catalogue, each rule atomic and assigned an ID.
// Every entry maps 1:1 to an assertion (Module 15.2) and often a coverpoint.
//
//  ID        Category    Rule (atomic, checkable)                              Ver
//  PHASE-1   Phase       SETUP is always followed by ACCESS the next cycle     APB2+
//  PHASE-2   Phase       PENABLE is low in SETUP, high in ACCESS               APB2+
//  SEL-1     Select      PENABLE is never high unless PSEL is high             APB2+
//  SEL-2     Select      At most one PSELx is asserted at a time (one-hot)     APB2+
//  STAB-1    Stability   PADDR/PWRITE held stable from SETUP to completion     APB2+
//  STAB-2    Stability   PWDATA/PSTRB held stable through the access           APB2+/4
//  RDY-1     Ready       Manager samples PREADY only at the PCLK rising edge   APB3+
//  RDY-2     Ready       The transfer completes when PSEL & PENABLE & PREADY   APB3+
//  ERR-1     Error       PSLVERR is valid ONLY at completion (else don't-care) APB3+
//  RST-1     Reset       PENABLE (and PSEL outputs) are low during PRESETn     APB2+
 
// Each rule becomes a property. Example — STAB-1 (address stable in a transfer):
property p_stab1_addr_stable;
  @(posedge pclk) disable iff (!presetn)
    (psel && !(penable && pready)) |=> $stable(paddr) && $stable(pwrite);
endproperty
a_stab1: assert property (p_stab1_addr_stable);   // owner of catalogue rule STAB-1

Two facts make this the right way to anchor verification. First, the catalogue is the plan, not an afterthought — you write it before the assertions, so the assertion set (Module 15.2) is a complete derivation from it (one property per rule) rather than an ad-hoc collection that mysteriously misses STAB-2. Second, every other component traces to a rule ID: the monitor flags "rule SEL-2 violated," the coverage model has a bin "RDY-2 hit with N>0 waits," and the scoreboard enforces the data-integrity rules — so a coverage/assertion review becomes a simple audit of which rule IDs are covered, and a gap is a rule ID with no owner. (Wait-state rules in particular have a coverage history of being under-checked.)

5. Engineering tradeoffs

Building the catalogue is a sequence of judgement calls about granularity, scope, and authority.

The throughline: a good catalogue is atomic, versioned, spec-derived, and gap-auditable. Coarse or incomplete entries are not a style choice — they are silent holes, because the downstream environment can only be as complete as the list it was built from. The effort spent making the catalogue exhaustive and itemised is repaid as the assertion, coverage, and review work all become mechanical derivations from it.

6. Common RTL mistakes

7. Debugging scenario

The signature catalogue failure is a silent escape: a real protocol violation reaches silicon because the rule it broke was never in the catalogue, so no assertion, monitor check, or coverage point ever looked for it.

• Observed symptom: a slave passes its entire assertion-clean, coverage-closed regression, then misbehaves in integration or the lab — intermittent data corruption on a specific peripheral under back-to-back traffic. The verification sign-off said "100% assertions passing, coverage closed," yet a protocol bug shipped.
• Waveform clue: on the failing trace, the slave lets PWDATA (or PADDR) change during a wait state — the manager held the transfer with PREADY low, but the bus value drifted before the completing edge, so the wrong data committed. The bus is doing something plainly illegal, yet the regression was green.
• Root cause: the rules catalogue had the phase, select, and ready rules but was missing the signal-stability rule (STAB-1/STAB-2 — "request signals held constant from SETUP through completion"). Because the rule was never enumerated, no assertion was derived for it, the monitor never flagged it, and no coverage bin demanded the held-during-wait scenario be exercised. The environment was complete relative to its catalogue — and the catalogue had a hole.
• Correct RTL: the fix is in the catalogue first: add the stability rules as atomic entries (one per held signal), then derive their assertions — (psel && !(penable && pready)) |=> $stable(paddr) && $stable(pwdata) && $stable(pwrite) && $stable(pstrb) — and add coverage that the held-during-wait scenario was hit. The DUT bug is then caught by construction; the process fix is auditing the catalogue against the AMBA spec category by category so no category is partial.
• Verification assertion: beyond the stability property itself, add a meta-check to the sign-off: every rule ID in the catalogue must have a passing assertion and a covered scenario, and the catalogue must be reviewed against the spec for completeness — assert (catalogue_rule_ids == assertion_owned_ids) at the environment level (an audit, not a runtime SVA).
• Debug habit: when a "fully verified" design fails on a protocol violation, do not start with the assertions — start with the catalogue. Ask "was the broken rule ever enumerated?" A green regression only proves the environment checks everything in its catalogue; an escape almost always means a rule was missing from the list, not that an assertion was wrong. The fix lives at the catalogue layer, and the prevention is a spec-to-catalogue completeness audit.

8. Verification perspective

The catalogue is the verification plan, so its own quality is verified the way a plan is — by completeness audit and traceability, not by simulation.

• Audit completeness against the spec, category by category. Walk the AMBA APB specification and confirm every normative statement maps to a catalogued rule in the right category. The audit question is per-category — "do we have all the stability rules? all the reset rules?" — because gaps cluster in the categories teams find boring (stability, reset) rather than the headline ones (phase, ready). This audit is the single highest-value verification activity in the module; everything else assumes the catalogue is complete.
• Enforce traceability: every rule has an owner, every check has a rule. Maintain a bidirectional map: each rule ID points to its assertion and coverage point, and each assertion/coverpoint names the rule ID it serves. A rule with no owner is an unchecked rule; an assertion with no rule is either redundant or a hidden rule that belongs in the catalogue. Sign-off reviews this map, not just the pass/fail count.
• Version-gate the active rule set. The environment must apply exactly the rules for the DUT's claimed protocol version — APB2 rules for an APB2 slave, plus ready/error for APB3, plus strobe/protection for APB4. Verify that the version gating is correct, or you get false fails (checking PREADY rules on an APB2 slave) or, worse, false passes (skipping PSLVERR rules on an APB3 slave that should report errors).

The point: you verify the catalogue by spec-completeness audit and rule-to-check traceability, and you verify the environment applies the version-correct rule set — because the catalogue's completeness is the ceiling on everything the rest of the module can catch.

9. Interview discussion

"How would you start building an APB verification environment?" is a senior methodology question, and the answer that signals real experience is "with the rules catalogue, not with code."

Lead with the principle: a verification environment can only check rules it has enumerated, so the first deliverable is a complete, atomic, categorised catalogue of APB's protocol rules — phase, select, stability, ready, error, and reset — derived rule-by-rule from the AMBA spec. Then explain the leverage: every downstream component is a derivation from the catalogue — each rule becomes an assertion to prove it, a monitor check to flag it, and a coverage point to confirm its scenario ran — so completeness of the catalogue bounds completeness of the whole environment, and a coverage/assertion review reduces to auditing which rule IDs have owners. The depth flourishes: the most-missed rules are the unglamorous categories — signal stability during waits and reset-during-transfer behaviour — which is exactly where silent escapes come from; and the catalogue must be versioned so an APB2 DUT isn't checked against PREADY rules it doesn't have. Closing with "a green regression only proves the environment checks everything in its catalogue — so when a 'verified' design fails on a protocol bug, I look first at whether the rule was ever enumerated" demonstrates you understand that verification completeness is a catalogue property, not an assertion-count property.

10. Practice

1. Categorise the rules. List two atomic APB rules in each of the six categories (phase, select, stability, ready, error, reset), each phrased as a single checkable proposition.
2. Atomise a coarse rule. Take "the access phase works correctly" and break it into the distinct atomic rules it actually contains.
3. Version-tag. For each category, state which rules exist in APB2, which APB3 adds, and which APB4 adds.
4. Trace a rule. Pick the stability rule and describe its three downstream owners — the assertion, the monitor check, and the coverage point.
5. Find the gap. Given a catalogue with phase, select, and ready rules but no stability or reset rules, name a real bug that would escape and the category that would catch it.

11. Q&A

12. Key takeaways

• A verification environment can only check rules it has enumerated — so the first deliverable is a complete, atomic, categorised catalogue of APB's protocol rules, and everything downstream derives from it.
• The six categories are phase, select, stability, ready, error, and reset. Every APB rule belongs to exactly one, which makes the catalogue auditable category by category.
• Each rule must be atomic (one checkable proposition → one assertion / one coverage concern) and versioned (APB2 vs APB3 vs APB4), so the environment applies the right rule set and gaps are visible.
• Every rule has downstream owners — an assertion to prove it, a monitor check to flag it, a coverage point to confirm its scenario ran — so a verification review reduces to auditing which rule IDs have owners.
• The most-missed rules are the unglamorous categories — signal stability during waits and reset-during-transfer — and a missing rule is a silent escape no assertion or coverage number can reveal.
• Verify the catalogue itself by spec-completeness audit and traceability, because the catalogue's completeness is the ceiling on everything the rest of the verification module can catch.