Week 1, Day 2: Phases in APB

Yesterday you learned every signal. Today you learn how they dance together.

APB has exactly 3 states the bus can be in at any moment:

State PSEL PENABLE Meaning

IDLE 0 0 Bus is free, no one talking

SETUP 1 0 Master announcing intent

ACCESS. 1 1 Actual transfer happening

That's it. The entire APB protocol lives in these 3 states. Everything else — wait states, errors, read vs write — is just variation within this framework.

The Alice & Bob Story

Alice (Master) walks up to Bob's post office counter (Slave). Here's exactly what happens:

IDLE — Alice is still walking toward the counter. The counter is empty, nobody is being served.

SETUP — Alice steps up to the counter and says: "Hi Bob, I want to send a package to mailbox 0x10, here's what's inside." She places the package on the counter. Bob hasn't touched it yet — he's just heard her. This takes exactly one clock cycle, no more, no less. The purpose of this cycle is purely to let the address and data signals settle before anything is committed.

ACCESS — Alice says "Okay, go ahead and process it." Now Bob picks up the package. He either processes it instantly (PREADY=1, done in one cycle) or he holds up a finger and says "one moment please" (PREADY=0, wait states). The transfer is only truly complete when Bob says "done" (PREADY=1) while Alice is saying "go" (PENABLE=1). Both must be true at the same time.

The golden rule: You can never go from IDLE directly to ACCESS. SETUP is always mandatory for exactly one cycle.

The 3 Scenarios You Must Know Cold

Scenario A: Write, No Wait States (PREADY always 1)

This is the fastest possible transfer — 2 cycles total (1 SETUP + 1 ACCESS).

Reading it: PSEL goes high in cycle 2 (SETUP). PENABLE joins in cycle 3 (ACCESS). Since PREADY is already 1, the transfer completes immediately at the rising edge of cycle 3. PSEL drops in cycle 4 — back to IDLE.

Scenario B: Write, 2 Wait States (PREADY stretches ACCESS)

Bob needs 2 extra cycles. The ACCESS phase stretches — PSEL and PENABLE stay high, all data signals freeze.
The critical rule: While PREADY=0, Alice is frozen. PADDR, PWDATA, PWRITE, PSEL, PENABLE — all must stay exactly the same. Bob will latch them when he's ready. If Alice changes anything, it's a protocol violation.

Scenario C: Read, 1 Wait State

Same idea, but now PRDATA comes from Bob, and Alice latches it only when PREADY=1.

The trap beginners fall into: PRDATA exists on the bus during the WAIT cycle too, but its value is garbage until PREADY=1. Alice must only latch PRDATA on the rising clock edge where PREADY=1 AND PENABLE=1.

EDAPLayground link : https://edaplayground.com/x/GWAq

Interview Questions — Day 2

Q1: "Can SETUP phase last more than one cycle?"

No. SETUP is always exactly one clock cycle. Only the ACCESS phase can be extended using PREADY. This is fundamental — if someone asks you to add wait states, the answer is always PREADY in the ACCESS phase, never stretching SETUP.

Q2: "What is the minimum number of cycles for an APB transfer?"

Two cycles — one SETUP and one ACCESS (with PREADY=1 immediately). You can never do it in one cycle because SETUP is mandatory.

Q3: "What must the master do while PREADY=0?"

Absolutely nothing — freeze everything. PADDR, PWDATA, PWRITE, PSEL, and PENABLE must all hold their values unchanged. The master is not allowed to modify any signal while the slave is holding PREADY low. Any change is a protocol violation.

Q4: "What is the condition for a transfer to complete?"

PENABLE == 1 AND PREADY == 1 on the same rising clock edge. Both conditions must be true simultaneously. PREADY=1 during SETUP means nothing — the slave can have PREADY=1 the whole time, it only matters when PENABLE is also 1.

Q5: "In a back-to-back transfer, does PSEL drop between transactions?"

No. PSEL can stay high continuously across back-to-back transfers. PENABLE drops for one cycle between them (the new SETUP cycle), but PSEL doesn't need to go low. This is how APB achieves its maximum throughput with no idle gaps.

WE ARE IN PROCESS OF DEVLOPING COMPLETE APB SERIES:

Subscribe to our email list to keep getting updates: here

Day 3: Write transfer timing — trace a write with and without wait states (PREADY low)
Day 4: Read transfer timing — trace a read with and without wait states
Day 5: PSLVERR — when slaves assert it, what the master must do in response
Day 6: Multi-slave APB — how PSEL works with a decoder, address mapping
Day 7: Read ARM IHI0024 (APB spec, free) end to end — it's short, only ~30 page

Week 2 — RTL Design: APB Slave Peripheral

Build a real peripheral, not just a register file.

Day 1: Design a simple APB-compliant register block — 4 registers, read/write, no wait states. Get it compiling
Day 2: Add PREADY support — introduce 1-2 cycle wait states on certain registers
Day 3: Add PSLVERR — illegal address ranges return an error response
Day 4: Build a more interesting peripheral — an APB UART control register block (baud rate, TX enable, RX status, interrupt enable)
Day 5: Add an APB GPIO peripheral — direction register, output register, input register
Day 6: Build an APB slave decoder/interconnect — route PSEL to multiple slaves based on address
Day 7: Integrate everything — one master port, decoder, UART slave, GPIO slave running together

Week 3 — RTL Design: APB Master

Day 1: Design a simple APB master FSM — IDLE, SETUP, ACCESS states
Day 2: Add wait state handling in the master — stay in ACCESS until PREADY
Day 3: Add PSLVERR handling — master captures error and reports it
Day 4: Build a register programming sequencer — master that executes a list of read/write commands
Day 5: Add a simple interrupt interface to your master
Day 6: Full integration — master + decoder + both slaves running end to end in simulation
Day 7: Review RTL for common mistakes — incomplete sensitivity lists, latch inference, reset issues

Week 4 — Testbench Infrastructure

Day 1: APB interface in SystemVerilog — all signals, master and slave modports
Day 2: APB transaction class — randomizable PADDR, PWDATA, PWRITE, with constraints for valid address ranges
Day 3: APB master BFM (Bus Functional Model) — drive write and read transactions
Day 4: APB monitor — passively observe and capture all transactions on the bus
Day 5: Reference model — a software model of your register map that mirrors what the RTL should do
Day 6: Scoreboard — compare monitor output against reference model predictions
Day 7: Basic directed tests — write/read back every register, verify reset values

Week 5 — Thorough Functional Verification

This is where "basics" ends and "thorough" begins.

Day 1: Constrained random stimulus — randomize addresses, data, and read/write mix. Run 1000 transactions
Day 2: Boundary value tests — address 0, last valid address, first invalid address, max data value, zero data
Day 3: Wait state stress test — randomize PREADY assertion delay (0 to 10 cycles) and verify correctness
Day 4: PSLVERR scenarios — access every invalid address, verify master captures error, verify no side effects on valid registers
Day 5: Back-to-back transactions — no idle cycles between transfers, stress the handshake
Day 6: Reset during transfer — assert PRESETn mid-transaction, verify clean recovery
Day 7: Multi-slave access patterns — randomize which slave gets accessed, verify no cross-contamination

Week 6 — Assertions, Coverage, and Sign-Off

Day 1: SVA protocol assertions — PENABLE must follow PSEL, PADDR/PWRITE stable during ACCESS, PREADY rules
Day 2: More SVA — PSLVERR only valid when PENABLE high, reset behavior assertions
Day 3: Functional coverage — covergroups for address ranges, read vs write, wait state counts, PSLVERR occurrences
Day 4: Coverage closure — analyze coverage report, write directed tests to hit uncovered bins
Day 5: Fault injection — force RTL signals to wrong values, verify assertions catch them
Day 6: Regression — run your full test suite, fix any failures, achieve 100% coverage
Day 7: Write a verification plan document — what you tested, coverage results, known limitations