AMBA APB · Module 3

PRESETn — The Active-Low Reset

PRESETn, APB's active-low reset — why it is active-low, how it is asserted asynchronously and deasserted synchronously, and the reset state every subordinate must take.

Every APB transfer you have studied so far assumed the bus was already alive — a clock running, subordinates holding sane values, a manager ready to drive. PRESETn is the signal that establishes that starting condition: it is the one input that forces every subordinate on the bus into a known, defined state before any traffic is allowed. The single idea to carry: PRESETn is active-low — the bus is in reset while it is 0, and only after it returns to 1 is any transfer legal. Until then, registers sit at their reset values and nobody drives the shared bus.

1. What problem is being solved?

The problem is bringing the whole bus to a known state at power-up, so the very first transfer starts from defined values rather than garbage.

When a chip powers on, flip-flops come up with arbitrary, unpredictable contents. A configuration register might read as anything; a subordinate's internal state machine might be in any state; a read mux might be driving an undefined value back onto the shared bus. None of the careful two-phase timing you have learned means anything if the subordinate it talks to started from noise. APB solves this with one reset input that every block on the bus obeys:

PRESETn low means the bus is in reset — every subordinate forces its registers to their defined reset values, stops driving the shared return bus, and refuses to act on any apparent transfer.
PRESETn high means reset is released — the bus is alive, subordinates hold their reset values until written, and normal two-phase transfers may begin.

That one signal is what turns "a pile of flip-flops at random values" into "a bus whose every subordinate is at a known, documented starting point." Without it, the first read after power-up would return undefined data and the first write would land in a register whose surrounding state was nonsense.

2. Why the lifecycle view is not enough

Module 2 walked the lifecycle of a transfer — IDLE, SETUP, ACCESS — and implicitly assumed the bus was already out of reset. That is the right framing for running traffic, but the lifecycle named the role of running; now PRESETn gives the signal's exact contract for the moment before any traffic exists. The lifecycle view leaves three things unstated:

The exact polarity: active-low, asserted at 0. PRESETn is in reset while it is low and out of reset while it is high — the trailing n in the name is the contract. This is the opposite of an active-high reset, and reading it backwards inverts your entire reset logic.
The exact release timing: asserted asynchronously, deasserted synchronously to PCLK. PRESETn is typically driven low without regard to the clock (so a brown-out or power glitch forces reset immediately), but its release — the rising edge back to 1 — is aligned to a PCLK rising edge so that every subordinate leaves reset cleanly on the same cycle, with no metastability on the first live edge.
What "in reset" means on the wire. While PRESETn is low, every subordinate holds its registers at reset values and is not driving the shared return bus, and no transfer is legal — PSEL and PENABLE are meaningless until release. The lifecycle never had to describe this because the lifecycle only exists after release.

Knowing the lifecycle tells you how a transfer runs; knowing the PRESETn contract tells you the defined state the bus starts from — which is what you actually need to bring up a subordinate correctly.

3. The signal's mental model

The model: PRESETn is the "hold everyone at a known starting line" wire — low means hold, high means go.

Picture a race that cannot start until every runner is physically placed on the starting line and standing still. While the marshal's flag is down (PRESETn low), nobody moves: every runner is forced to the line, no matter where they happened to be standing. The flag does not care about the starter's countdown — it can slam down at any instant if something goes wrong (asynchronous assertion). But the flag is raised only on a clean beat of the metronome (synchronous deassertion to PCLK), so all runners leave the line on the same step. Only after the flag is up is the race — any transfer — legal.

Three refinements make the model precise:

Low is the active, "held" state. Because PRESETn is active-low, the asserted (reset) state is 0. A wire that floats or is pulled low therefore defaults into reset, which is the safe default — better to hold the bus quiet than to let undefined logic run.
Release is clean and shared. The rising edge of PRESETn is aligned to PCLK so every subordinate observes "reset released" on the same clock edge and steps out of reset together. There is no skewed, runner-by-runner start.
The starting line is defined, not arbitrary. Coming out of reset, a subordinate's registers are at their documented reset values — not whatever the silicon powered up with. The whole point is that the first live cycle starts from a value you can predict and that appears in the register map.

4. Real SoC / hardware context

In a real SoC, PRESETn is owned by the system / manager side — it is generated by the chip's reset controller (often derived from the power-on reset and any software-driven reset), distributed alongside PCLK to the APB bridge and every subordinate. A subordinate never drives PRESETn; it only consumes it. By convention PRESETn is asserted (driven low) asynchronously so a power event forces reset instantly, and deasserted (released to high) synchronously to PCLK by the reset controller's reset synchroniser, so the live edge is clean.

Inside each subordinate, PRESETn is wired straight into the asynchronous-reset path of its register flops. The whole contract reduces to one clocked block:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// APB subordinate register reset (teaching sketch — not a full subordinate).
// PRESETn is active-low: while it is 0 the registers are forced to their
// defined reset values; otherwise the block does normal operation.
always_ff @(posedge pclk or negedge presetn) begin
  if (!presetn) begin
    // Reset state: every register at its documented default. The subordinate
    // also drives no read data and is not "ready" for any transfer here.
    ctrl_reg  <= '0;     // control register clears to its defined default
    data_reg  <= '0;     // data register clears to its defined default
  end else if (psel & penable & pready & pwrite) begin
    // Normal operation: a write commits only at completion (PSEL & PENABLE
    // & PREADY), and only when PWRITE selects a write.
    if (paddr == CTRL_ADDR) ctrl_reg <= pwdata;
    if (paddr == DATA_ADDR) data_reg <= pwdata;
  end
end

Two facts fall straight out of that block. First, negedge presetn in the sensitivity list is what makes assertion asynchronous: the registers snap to their reset values the instant PRESETn drops, without waiting for a clock edge — exactly what you want when power is collapsing. Second, because the reset values are written explicitly ('0 here, or whatever the register map specifies), the subordinate's state coming out of reset is defined, not inherited from power-up noise. While PRESETn is low, this block holds the registers quiet; the read path (driving PRDATA) and the PADDR decode it feeds are equally inert, so the subordinate contributes nothing to the shared bus until release.

Figure 1 — PRESETn against PCLK across power-up. PRESETn is asserted low asynchronously (it can drop at any instant), and the whole bus stays quiet while it is low: PSEL and PENABLE are inactive and no transfer occurs. PRESETn is then deasserted high synchronously to a PCLK rising edge — the clean release edge. Only after that release does the first legal transfer begin; the diagram marks the first SETUP cycle as strictly later than the release edge, never during reset.

Figure 2 — the defined reset state. While PRESETn is low, every subordinate holds a known state: its registers sit at their documented reset defaults, it drives no read data onto the shared return, and no transfer is in flight. After PRESETn is released, the registers begin from those defaults and the first legal transfer can start. A subordinate that powered up in an undefined state would make the whole bus unpredictable — the point of a reset state is that the bus comes up known, not noisy.

5. Engineering tradeoff table

PRESETn is a deliberately minimal, convention-driven signal. Each property trades flexibility APB does not want for safety and uniformity it does.

`PRESETn` property	What it gives up	What it buys	Why it is correct for APB
Active-low (asserted = 0)	Active-high "intuitive" polarity	Safe default — a floated/pulled-low line resets the bus	A quiet bus is the safe failure mode at power-up
Asserted asynchronously	Clock-aligned assertion	Instant reset on brown-out / power glitch	Reset must work even before the clock is trustworthy
Deasserted synchronously to `PCLK`	A simpler one-edge reset	A clean, metastability-free first live cycle	Every subordinate leaves reset together on one edge
*Forces a defined* reset state**	Smaller, "don't-care" flops	Predictable first read/write after power-up	The register map's reset values must actually hold
System/manager-owned, one source	Per-subordinate reset control	One reset domain, no contention	The whole bus must come up coherently together

The throughline: PRESETn spends polarity intuition and clock-aligned assertion to buy a safe default and instant protection, and spends a simpler reset to buy a clean, shared release. For a control plane that must come up coherently, those are exactly the right trades.

6. Common RTL / waveform mistakes

Misconceptions to unlearn

"PRESETn high means the bus is in reset." No. PRESETn is active-low: the bus is in reset while it is 0 and out of reset while it is 1. The trailing n is the whole point — reading it as active-high inverts your reset logic.
"A transfer can run while PRESETn is low." No. While PRESETn is low, no transfer is legal: subordinates hold reset values and PSEL / PENABLE are meaningless. The first legal SETUP cycle is strictly after release.
"PRESETn is released asynchronously, like it is asserted." No. Assertion is typically asynchronous, but release is aligned to a PCLK rising edge so every subordinate leaves reset on the same clean edge without metastability.
"Coming out of reset, register values don't matter — software will write them." No. The reset state must be defined — the documented reset values in the register map — so the first read returns a known value and dependent logic starts from a predictable state.
"A subordinate should keep driving PRDATA during reset." No. In reset a subordinate holds its registers at defaults and does not actively drive meaningful data onto the shared return; it contributes nothing to the bus until release.
"Each subordinate can have its own reset polarity or timing." No. PRESETn is one system-owned signal on one polarity for the whole bus; per-block divergence is how you get half the bus alive while the other half is still in reset.

7. Interview framing

PRESETn is a quick test of whether you think about bring-up, not just steady-state traffic. The weak answer is "it resets the bus." The strong answer states the contract: PRESETn is APB's active-low reset — the bus is in reset while it is 0 — and it is typically asserted asynchronously but deasserted synchronously to PCLK.

Then deliver the two depth points. First, why active-low: the asserted state is 0, so a floated or pulled-low line defaults the bus into reset (the safe direction), and it matches the AMBA family convention. Second, why async-assert / sync-deassert: assertion must be immediate so a brown-out forces reset before the clock is even trustworthy, but release is aligned to a clock edge so no flop goes metastable on the first live cycle. Close with the rule that proves you understand the consequence: coming out of reset every subordinate is at its defined reset values and no transfer is legal until PRESETn is high — which is exactly what separates an engineer who can bring a bus up from one who only knows how a running transfer looks.

8. Q&A

9. Practice

State the polarity. From memory, write whether the bus is in reset when PRESETn is 0 or 1, and explain how the signal name tells you.
Write the reset block. Write the always_ff block for a subordinate with two registers, clearing them to their defined reset values on !presetn and doing normal operation otherwise.
Justify the edges. In two sentences, explain why PRESETn is asserted asynchronously but deasserted synchronously to PCLK, naming the hazard each choice avoids.
Trace the release. Draw PRESETn and PCLK across power-up and mark the release edge and the earliest cycle on which a legal SETUP can begin.
Spot the bug. A subordinate keeps driving its last PRDATA value while PRESETn is low and acts on a PSEL that appears during reset. State which two parts of the reset contract it breaks.

10. Key takeaways

PRESETn is APB's active-low reset: the bus is in reset while it is 0 and out of reset while it is 1 — the trailing n is the contract.
Active-low is the safe default: a floated or pulled-low reset line defaults the bus into reset, and the polarity matches the AMBA family (HRESETn, ARESETn).
Asserted asynchronously, deasserted synchronously to PCLK: assertion is instant so a brown-out forces reset immediately; release is clock-aligned so every subordinate leaves reset cleanly without metastability.
Coming out of reset, every subordinate is at a defined state: registers at their documented reset values, not driving the shared return bus — predictable, not power-up noise.
No transfer is legal until PRESETn is high. The lifecycle's IDLE → SETUP → ACCESS only exists after release; before that, PSEL and PENABLE are meaningless.
PRESETn is system/manager-owned, one source for the whole bus — modelled in RTL as the asynchronous-reset path of every register flop (@(posedge pclk or negedge presetn)).