AMBA APB · Module 5

Legal and Illegal Transitions

A rigorous, protocol-checker enumeration of every legal APB state transition and exactly what makes the rest illegal — skipping setup, lingering in setup, dropping PSEL mid-access — expressed as checkable SVA properties.

Module 2 drew the APB lifecycle as a state machine and showed you the legal path. This deep-drill chapter asks the harder question a protocol checker has to answer every single cycle: of all the transitions the bus could take, which are legal — and what, exactly, makes the rest illegal? The lifecycle has only five legal edges, and every other move is a violation for a precise, nameable reason. The single idea to carry: legality is not a vibe, it is an enumeration — a finite list of allowed transitions, each with an exact condition, so that anything outside the list is a checkable assertion failure. This chapter enumerates the legal set, then walks each illegal move and the contract it breaks.

1. What problem is being solved?

The problem is deciding, mechanically and without judgement, whether any observed APB transition is allowed — so that a manager's FSM, a subordinate's expectations, and a verification checker all agree on what "a valid bus move" is.

A lifecycle diagram tells you the happy path. It does not, by itself, tell you what to reject. A protocol checker cannot run on intuition; it needs the legal set written down exhaustively, because its job is to flag the complement — every move that is not in the set. APB makes this tractable because the FSM is tiny, so the legal set is short and closed:

IDLE → SETUP — a transfer is requested (req high). The bus leaves idle and presents the access.
SETUP → ACCESS — unconditional, on the next cycle. PENABLE rises; this edge has no guard at all.
ACCESS → ACCESS — PREADY is low. The subordinate is not ready, so the access is held (the wait-state self-loop).
ACCESS → IDLE — PREADY is high and no further transfer is pending. The transfer completes and the bus idles.
ACCESS → SETUP — PREADY is high and another transfer is pending. Completion flows straight into the next setup (back-to-back).

Those five are the whole legal set. The job of this chapter is to make that set exact, and then to show that every other transition — and there are exactly five interesting ones — breaks a specific, statable rule.

2. Why the previous model is not enough

Module 2 gave you the FSM and the legal path IDLE → SETUP → ACCESS → IDLE / next SETUP. That is the constructive view: how to drive a correct transfer. This chapter is the checking view: how to prove an arbitrary waveform is correct — which is a different and stricter discipline. Three things the path-drawing view leaves implicit, and all three are where checkers and bugs live:

The legal set is closed, and the complement is the spec. Module 2 told you what the FSM does; a checker needs what it must never do. Listing five legal edges is only half the contract — the enforceable half is "and no others." A checker asserts the complement, so the complement must be enumerated as precisely as the legal set.
Each illegal move maps to one broken guarantee. It is not enough to say "that transition is wrong." IDLE → ACCESS is wrong because it removes the decode window; SETUP → SETUP is wrong because it violates the one-cycle rule and PENABLE must rise; dropping PSEL in ACCESS is wrong because it deselects the subordinate before completion. The reason is what becomes the assertion.
Signal-level violations hide between state-level ones. Some illegalities are not edges at all but signal combinations within a state — PENABLE high during SETUP collapses the two phases without ever "taking a bad edge." A purely state-transition view misses these; the checker mindset catches them because it asserts on signals, not just on state names.

So the model to add is the protocol-checker enumeration: the closed legal set, plus each illegal transition stated as a violated contract you can write as a property — the move from "I can draw a correct transfer" to "I can fail any incorrect one at the offending cycle."

3. Mental model

The model: the APB FSM is a guarded turnstile with exactly five doors, and a checker stands at every other point on the wall. A move is legal only if it passes through one of the five doors with the right ticket (its guard condition); a move that tries to go through the wall — any unlisted transition — trips the checker.

Think of an immigration hall. There is one legal sequence: queue (IDLE), present your documents at the desk (SETUP), pass through the gate when it clears (ACCESS → completion). You may be held at the gate while they verify (the wait-state self-loop) — that is allowed. What is not allowed is jumping the desk and going straight to the gate (IDLE → ACCESS, no document check), standing at the desk forever re-presenting documents (SETUP → SETUP), walking back out of the queue after your documents were taken (SETUP → IDLE), or having your visa revoked while you are mid-gate (PSEL dropped in ACCESS). Each forbidden act breaks a specific rule, and a guard is posted for each one.

Three refinements make the model precise:

Guards, not just edges. IDLE → SETUP needs req; ACCESS → IDLE and ACCESS → SETUP both need PREADY and differ only by whether a next transfer is pending; SETUP → ACCESS has no guard at all. The guard is half the legality — the same edge with the wrong guard is itself a violation.
The complement is enumerable. Because the FSM has three states and the legal set is five edges, the interesting illegal moves are a short, nameable list — not "everything else in the universe," but five specific temptations a real RTL bug actually takes.
Some violations live inside a state. PENABLE high in SETUP, or PSEL low in ACCESS, are illegal signal conditions within a legal state, not bad edges. The checker asserts on the signals, so it catches the move the state diagram cannot draw.

Figure 1 — the closed legal set of APB transitions, five edges, each with its exact guard. IDLE→SETUP fires on req (a transfer is requested). SETUP→ACCESS is unconditional on the next cycle and is where PENABLE rises — SETUP is therefore always exactly one cycle. ACCESS→ACCESS is the wait-state self-loop, taken while PREADY is low, holding the access stable. ACCESS→IDLE fires when PREADY is high and no next transfer is pending; ACCESS→SETUP fires when PREADY is high and a next transfer is pending (back-to-back, no IDLE cycle between). Completion is the single cycle where PSEL, PENABLE and PREADY are all high; everything outside these five edges is illegal by construction.

4. Real SoC / hardware context

In silicon the legal set is enforced constructively by the manager FSM and checked by bound assertions. The bridge's sequencer simply has no code path that takes an illegal edge — the absence of a branch is the guarantee — and the verification environment binds properties that fire if the synthesized logic, or a buggy third-party manager, ever does.

The manager's next-state logic is the legal set, written as a case with no escape hatches:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// APB manager next-state: the legal set, encoded as the ONLY reachable edges.
// There is deliberately no IDLE->ACCESS, no SETUP->SETUP, no SETUP->IDLE path.
always_comb begin
  next = state;
  unique case (state)
    IDLE:   if (req)    next = SETUP;             // only legal exit from IDLE
    SETUP:              next = ACCESS;            // unconditional — never repeats, never aborts
    ACCESS: if (pready) next = req ? SETUP : IDLE; // complete; else stay (wait state)
  endcase
end

Notice what is not there: IDLE has no branch to ACCESS, SETUP has no self-branch and no branch back to IDLE. Those missing branches are exactly the illegal transitions — the FSM is correct because it cannot express them. A bug that adds one (or a glitch that corrupts state) is what the checker is for.

On the verification side, the legal set becomes a small bundle of properties bound to every APB interface. They encode the guards directly: a select implies the bus is in a transfer, setup lasts exactly one cycle, and PSEL cannot drop mid-access. This is the single most valuable structural check on an APB port, because an illegal transition otherwise manifests as a corrupted or lost access with no protocol error.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// SVA: three properties that encode APB transition legality on a bound interface.
// (1) No access without select — PENABLE high implies PSEL high (no IDLE->ACCESS,
//     no PENABLE-high-in-SETUP collapse where PSEL is also low).
property p_no_enable_without_sel;
  @(posedge pclk) disable iff (!presetn)
    penable |-> psel;
endproperty
assert property (p_no_enable_without_sel);
 
// (2) SETUP lasts exactly one cycle — a setup cycle (PSEL high, PENABLE low)
//     must be followed by access (PENABLE high). Catches SETUP->SETUP and SETUP->IDLE.
property p_setup_is_one_cycle;
  @(posedge pclk) disable iff (!presetn)
    (psel && !penable) |=> penable;
endproperty
assert property (p_setup_is_one_cycle);
 
// (3) PSEL cannot drop mid-access — while in ACCESS and not yet complete,
//     PSEL must remain high next cycle. Catches dropping select before PREADY.
property p_psel_held_in_access;
  @(posedge pclk) disable iff (!presetn)
    (psel && penable && !pready) |=> psel;
endproperty
assert property (p_psel_held_in_access);

Bind those three and any manager that skips setup, lingers in setup, abandons a started transfer, or deselects mid-access fails at the offending cycle, naming the rule — instead of you debugging a dropped register write three transactions later.

5. Engineering tradeoff table

Each legality rule trades expressive freedom for a checkable, unambiguous protocol. The closed legal set is a deliberate choice: a tiny set is easy to verify exhaustively.

Legality rule	What it forbids	What it buys	Why it is correct for APB
`SETUP → ACCESS` unconditional	A multi-cycle or skippable setup	A guaranteed one-cycle decode window	The subordinate always gets exactly one cycle to decode
No `IDLE → ACCESS`	A one-cycle "fast" transfer	A single legal entry path to verify	`PENABLE` high with no setup has no decode window
No `SETUP → SETUP` / `SETUP → IDLE`	Pausing or aborting in setup	A transfer that, once started, completes	A presented access must be honoured, not retracted
`PSEL` held through `ACCESS`	Deselecting mid-transfer	A subordinate that owns completion timing	Dropping select aborts the access the subordinate is mid-serving
`PENABLE` low in `SETUP`	Collapsing the two phases	A clean phase boundary at the `PENABLE` rise	One marker, `PENABLE`, cleanly separates the phases

The throughline: APB keeps the legal set tiny and closed so the complement — the set of violations a checker must catch — is equally tiny and nameable. A protocol with a small legal set is one you can verify exhaustively, which is exactly what the control plane wants.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"A fast subordinate lets the manager go IDLE → ACCESS and skip setup." No. There is no IDLE → ACCESS edge. A fast subordinate still walks IDLE → SETUP → ACCESS; it just completes ACCESS in its first cycle. Skipping setup asserts PENABLE with no decode window — illegal.
"SETUP can repeat (SETUP → SETUP) if the manager needs another cycle to prepare." No. The SETUP → ACCESS edge is unconditional, so SETUP is exactly one cycle and PENABLE must rise. Lingering in setup violates the one-cycle rule.
"If the manager changes its mind it can go SETUP → IDLE and cancel." No. Once PSEL is asserted and the access is presented, the transfer is started; it must proceed to ACCESS. Aborting from setup abandons a presented access — there is no cancel edge in APB.
"Dropping PSEL for a cycle during ACCESS is fine as long as it comes back." No. While in ACCESS and not yet complete (PREADY low), PSEL must stay high. Dropping it deselects the subordinate mid-transfer, before it completes — the access is aborted, silently.
"PENABLE can be high during SETUP to save a cycle." No. PENABLE is low in SETUP and rises only at the SETUP → ACCESS boundary. Driving it high in setup collapses the two phases into one and erases the decode window. See the PENABLE deep dive.
"Only the edges need checking; the signals within a state are fine by definition." No. PENABLE high in SETUP and PSEL low in ACCESS are illegal signal conditions inside a state. A state-only checker misses them; assert on the signals.

Figure 2 — the illegal transitions, each crossed out in red and paired with the contract it breaks. IDLE→ACCESS skips SETUP and removes the decode window (PENABLE high with no setup cycle). SETUP→SETUP violates the one-cycle rule — PENABLE must rise into ACCESS, so setup cannot repeat. SETUP→IDLE abandons a transfer that was already started. Dropping PSEL during ACCESS deselects the subordinate before PREADY completes the access. PENABLE driven high during SETUP collapses the two phases into one. Each case is a checkable assertion: anything outside the five legal edges of Figure 1 is a protocol violation, and each maps to a specific broken guarantee.

7. Interview framing

This is the senior-level APB question that separates "I can recite the FSM" from "I can verify it." Interviewers ask you to enumerate the legal transitions and to explain why a specific tempting shortcut — usually skipping setup or pausing in setup — is illegal. The weak answer lists states; the strong answer lists the closed set of edges with guards and then names the broken contract for each illegal move.

Say it in three moves: the legal set is exactly five edges — IDLE → SETUP on req, SETUP → ACCESS unconditionally (where PENABLE rises), the ACCESS → ACCESS wait-state self-loop while PREADY is low, and ACCESS → IDLE or ACCESS → SETUP on PREADY high depending on whether a next transfer is pending; the set is closed, so anything else is illegal; and each illegal move breaks a named guarantee — IDLE → ACCESS removes the decode window, SETUP → SETUP violates the one-cycle rule, SETUP → IDLE abandons a started transfer, dropping PSEL in ACCESS deselects before completion, and PENABLE high in SETUP collapses the phases. The depth signal that lands: volunteer that each of these is a one-line SVA property — penable |-> psel, (psel && !penable) |=> penable, (psel && penable && !pready) |=> psel — because an interviewer hears that and knows you have bound these checks, not just drawn the diagram.

8. Q&A

9. Practice

Enumerate the legal set. From memory, write the five legal transitions with their exact guard conditions, and state which edge has no guard and why.
Name the broken contract. For each of IDLE → ACCESS, SETUP → SETUP, SETUP → IDLE, and PSEL dropped in ACCESS, state in one sentence the specific guarantee it violates.
Spot the signal-level violation. Given a waveform where PENABLE is high during the cycle PSEL first rises, state which rule is broken and why a state-only checker might miss it.
Write the assertions. From memory, write the three legality properties (penable |-> psel, (psel && !penable) |=> penable, (psel && penable && !pready) |=> psel) and state which illegal transition each one catches.
Audit an FSM. Given a manager case statement with an added IDLE: if (fast) next = ACCESS; branch, identify the illegal transition it introduces and which bound property would fire on it.

10. Key takeaways

The APB legal set is exactly five edges: IDLE → SETUP (on req), SETUP → ACCESS (unconditional), ACCESS → ACCESS (PREADY low), ACCESS → IDLE and ACCESS → SETUP (PREADY high, by whether a next transfer is pending).
The set is closed. Anything outside the five is illegal by construction — the complement is the bug list, which is what a protocol checker asserts.
IDLE → ACCESS removes the decode window, and SETUP → SETUP / SETUP → IDLE break the one-cycle rule. Setup is exactly one cycle because SETUP → ACCESS is unconditional and PENABLE must rise.
Some violations live inside a state. PSEL dropped in ACCESS deselects before completion; PENABLE high in SETUP collapses the phases. Assert on signals, not just state names.
Each illegal move maps to one SVA property — penable |-> psel, (psel && !penable) |=> penable, (psel && penable && !pready) |=> psel — so legality is checkable at the offending cycle.
A correct manager FSM cannot express the illegal edges. The missing case branches are the guarantee; the bound assertions catch anything — a bug or a glitch — that produces one anyway.