AMBA APB Sideband Signals Explained – Your VLSI Journey Starts Here

⏱ Why PWAKEUP Exists

Power management in modern SoCs requires clock gating — turning off the clock to peripherals that are not in use to eliminate dynamic power consumption. The challenge with APB is timing: if the peripheral’s clock is gated off and the APB bridge suddenly starts a transfer (asserts PSELx), the peripheral may miss the Setup phase entirely. The first cycle the peripheral sees is the Access phase, and by then it has already missed its chance to decode the address and prepare a response.

PWAKEUP solves this by giving the peripheral (and its clock domain) advance warning that a transfer is coming. The bridge asserts PWAKEUP before asserting PSELx, giving the clock controller time to re-enable the peripheral’s clock before the transfer begins.

Figure 1 — PWAKEUP in a clock-gated APB system. The bridge drives PWAKEUP to the clock controller before asserting PSELx. The clock controller re-enables PCLK to the peripheral. The peripheral (now clocked) can accept the transfer and assert PREADY. Without PWAKEUP, the peripheral might miss the Setup phase while its clock is still gated.

📋 PWAKEUP Signal Properties

Source: Requester (APB bridge) | Width: 1 bit | APB5 only | Property: Wakeup_Signal=True

PWAKEUP indicates any activity associated with the APB Requester interface. It is present only when the Wakeup_Signal property is declared True on the interface. If the property is not declared, it is considered False and PWAKEUP is absent.

The defining requirement of PWAKEUP is that it must be glitch-free. Unlike most APB signals which can be driven by combinational logic, PWAKEUP must be generated directly from a register or from a glitch-free OR tree. This is because PWAKEUP is routed to a clock controller — a glitch on PWAKEUP could incorrectly enable or disable a clock, causing metastability or functional failure anywhere in the clock domain.

PWAKEUP must be glitch-free — this is a hard requirement, not a recommendation. It is one of the few APB signals with this constraint. The recommended implementation is a flip-flop output driven directly from the bridge’s state machine: always_ff @(posedge PCLK) PWAKEUP <= transfer_pending; — never use combinational logic to drive PWAKEUP.

PWAKEUP is also synchronous to PCLK. Even though its primary consumer (the clock controller) may be in a different clock domain, PWAKEUP itself is synchronous to the APB clock. The clock controller is responsible for safely sampling it across the clock domain boundary (typically using a synchroniser chain).

📋 PWAKEUP Timing Rules

The spec defines the following rules and recommendations for PWAKEUP. Rules marked Must are mandatory; those marked Recommended are best practice.

Rule type	Rule
Must	PWAKEUP must be glitch-free — generated from a register or glitch-free OR tree
Must	PWAKEUP must be synchronous to PCLK
Must	If PWAKEUP and PSELx are both HIGH in the same cycle, PWAKEUP must remain asserted until PREADY is asserted
Recommended	PWAKEUP should be asserted at least one cycle before PSELx to prevent the acceptance of a new transaction being delayed
Recommended	PWAKEUP should be deasserted when no further transfers are required
Permitted but not recommended	Asserting PWAKEUP then deasserting it without a transfer occurring (false wakeup)
Permitted	PWAKEUP may be asserted before, during, or after the assertion of PSELx
Permitted	A Completer may wait for PWAKEUP to be asserted before asserting PREADY
Recommended	The Requester and Completer sides of a connection should be clock-gated together to avoid Setup phase being missed

⏱ PWAKEUP Timing Diagram

The recommended pattern: PWAKEUP asserts one cycle before PSELx, giving the clock controller one full cycle to re-enable the peripheral’s clock before the Setup phase begins.

Figure 2 — Recommended PWAKEUP timing. PWAKEUP is asserted at T1, one full cycle before PSELx at T2. This gives the clock controller the entire Setup cycle to re-enable the peripheral’s clock domain. PWAKEUP remains asserted until PREADY=1 at T4 (the completion cycle), then deasserts when no further transfers are pending.

PWAKEUP asserted same cycle as PSELx (just-in-time)

The spec permits PWAKEUP to be asserted in the same cycle as PSELx. However this is not recommended — the clock controller and peripheral only have the Setup cycle to re-enable the clock before PENABLE arrives. If the clock takes more than one cycle to stabilise (common for PLLs or fractional dividers), the peripheral misses the Setup phase.

The spec recommends PWAKEUP at least one cycle before PSELx. In practice, designs with slow clock enablement paths (e.g. crystal oscillators, PLLs, power domain switching) may need PWAKEUP to be asserted multiple cycles early. The exact lead time is system-dependent and must be verified against the clock controller’s enable-to-stable latency.

📋 Deadlock Risk

The spec contains an important warning: “The interface could deadlock if PWAKEUP is present but never asserted.”

This happens in the following scenario:

The Completer’s clock is gated. Its Wakeup_Signal property is True (PWAKEUP is present).
The Completer is waiting for PWAKEUP before it will assert PREADY — a legal implementation per the spec.
The Requester asserts PSELx and PENABLE but never asserts PWAKEUP (perhaps PWAKEUP is tied LOW or the logic is broken).
Result: PENABLE=1, PSELx=1, but PREADY never goes HIGH. The interface hangs permanently.

PWAKEUP must always be asserted before or during every transfer. If your design has Wakeup_Signal=True on a Completer, ensure the Requester always drives PWAKEUP HIGH before asserting PSELx. A stuck-LOW PWAKEUP with a clock-gated peripheral that waits for PWAKEUP before asserting PREADY = deadlock. Verify this in your UVM testbench with a protocol checker.

The spec also warns about independent clock gating: “If a Completer interface clock is gated independently of the Requester clock and PWAKEUP is used to enable the Completer clock, there is a possibility that the Setup phase of a transfer is missed by the Completer.” The recommendation is to clock-gate the Requester and Completer sides of a connection together.

📋 User Signals — Introduction

APB5 defines four optional user-defined sideband signals. These exist to accommodate applications that need to carry information alongside an APB transfer that is not specified in the standard protocol — custom tags, quality-of-service attributes, trace IDs, or any other application-specific metadata.

User signals are a hook for non-standard use cases. They are attached to specific phases of the APB transfer so the sideband data is coherent with the transaction it annotates. They do not affect the core APB protocol behaviour — the transfer proceeds identically whether user signals are present or not.

The spec explicitly recommends against using user signals. The exact wording: “Generally, it is recommended that User signals are not used. The APB protocol interface does not define the function of these signals, causing interoperability problems if two components use the same User signals in an incompatible way.” Use standard APB signals for all standard functions. Only add user signals when you have verified that both ends of the connection share a well-documented, mutually agreed definition of the signal’s meaning.

📋 The Four User Signals

PAUSER

Requester → Completer | max 128 bits | USER_REQ_WIDTH

User-defined request attribute. Carries sideband information tied to the address/control phase of the transfer. Analogous to AXI AxUSER signals.

Valid when PSELx is asserted. Must have the same value in both Setup and Access phases. Must be stable for every cycle during the Access phase.

PWUSER

Requester → Completer | max DATA_WIDTH/2 | USER_DATA_WIDTH

User-defined write data attribute. Carries sideband information tied to the write data. Only meaningful during write transfers. Analogous to AXI WUSER.

Valid when PSELx and PWRITE are asserted. Same value in Setup and Access. Stable through all Access phase cycles.

PRUSER

Completer → Requester | max DATA_WIDTH/2 | USER_DATA_WIDTH

User-defined read data attribute. Carries sideband information associated with the read data returned by the Completer. Only meaningful during read transfers.

Valid when PSELx, PENABLE, PREADY are asserted and PWRITE=0 (read transfer completion).

PBUSER

Completer → Requester | max 16 bits | USER_RESP_WIDTH

User-defined response attribute. Carries sideband information associated with the transfer response (analogous to AXI BUSER). Valid for both read and write completions.

Valid when PSELx, PENABLE, and PREADY are all asserted (any transfer completion).

📋 Validity Windows

Each user signal has a specific phase of the transfer where it must be valid. The windows match the phase of the associated standard signal:

Figure 3 — User signal validity windows mapped to APB transfer phases. PAUSER and PWUSER (Requester-driven) are valid throughout the transfer. PRUSER and PBUSER (Completer-driven) are only valid at the completion cycle, the same window as PRDATA and PSLVERR.

⏱ User Signals in Timing

User signals follow the same stability rules as the signals they are associated with. PAUSER and PWUSER must not change between Setup and completion — any mid-transfer change is a protocol violation, same as changing PADDR mid-transfer.

Figure 4 — User signals in a write transfer timing. PAUSER is presented at T1 (Setup) alongside PADDR and remains stable through T3 (completion). PBUSER is valid only at T3 when PSEL+PENABLE+PREADY are all HIGH — the same window as PSLVERR. Before T2, PBUSER is undefined (dashed line).

📋 Why the Spec Says Avoid Them

The spec’s recommendation against user signals is worth understanding in detail. The core issue is interoperability.

Standard APB signals (PADDR, PWDATA, PPROT, etc.) have precisely defined meanings — every APB-compliant component worldwide interprets them identically. User signals have no defined meaning — their interpretation is completely implementation-specific. This creates several problems:

No standard interconnect support. An AXI-to-APB bridge that is designed to the APB spec will not know what to do with your user signals. It will either ignore them (losing the information) or require custom modification. Every interconnect component in the path must be aware of and handle the user signals.
Incompatible implementations. Two independently developed peripherals using PAUSER for different purposes cannot be connected through the same bridge without one corrupting the other’s signalling.
Verification complexity. Standard APB protocol checkers understand the standard signals. User signals require custom checker logic in your UVM environment.
Documentation burden. Any engineer connecting to your peripheral must understand your custom user signal semantics — they are not self-documenting the way standard signals are.

When user signals are acceptable: in a closed system where both the Requester and Completer are designed by the same team, with a well-documented and stable definition of the user signal semantics, and where the signal cannot be confused with any other usage. The spec specifically mentions that domain-crossing bridges and interconnects are recommended to include provision for all user signals to prevent blocking future use cases — but this is infrastructure overhead that must be justified by the actual need.

📋 Quick Reference

Item	Rule
PWAKEUP introduced in	APB5 — not available in APB4 or earlier
PWAKEUP source	Requester (APB bridge)
PWAKEUP purpose	Advance warning to clock controller to re-enable peripheral clock before transfer
PWAKEUP glitch-free	Mandatory — must be generated from a register or glitch-free OR tree, not combinational
PWAKEUP timing (recommended)	Assert at least 1 cycle before PSELx
PWAKEUP hold rule	If PWAKEUP and PSELx are both HIGH in the same cycle, PWAKEUP must stay HIGH until PREADY=1
PWAKEUP deassertion	Recommended: deassert when no further transfers are required
PWAKEUP deadlock	If Completer waits for PWAKEUP before asserting PREADY, and PWAKEUP is never asserted — deadlock
User signals	APB5 only — all optional, absent if width property is zero
PAUSER	Req→Comp, max 128 bits, valid when PSELx asserted, same in Setup and Access
PWUSER	Req→Comp, max DATA_WIDTH/2, valid when PSELx and PWRITE asserted, same in Setup and Access
PRUSER	Comp→Req, max DATA_WIDTH/2, valid at read completion (PSEL+PENABLE+PREADY=1, PWRITE=0)
PBUSER	Comp→Req, max 16 bits, valid at any completion (PSEL+PENABLE+PREADY=1)
Spec recommendation on user signals	“Generally, it is recommended that User signals are not used”
Why avoid user signals	No standard semantics → interoperability failures when two components define them differently
When user signals are acceptable	Closed system, both ends designed by same team, well-documented semantics, no risk of conflicting usage