AXI-to-APB Bridge

The AHB-to-APB bridge taught the canonical bridge shape: a system-bus slave on one face, an APB manager on the other, collapsing one upstream transaction into one two-phase APB transfer. The AXI4-Lite-to-APB bridge is the same block with a different upstream personality — and the difference is entirely on the AXI side. Where AHB hands the bridge a single pipelined address/data stream, AXI4-Lite hands it five independent channels, each with its own VALID/READY handshake, and the bridge must assemble a complete write (AW + W) or read (AR) out of those channels before it can issue a single APB transfer, then hand back a B or R response on yet another channel. The throughline to carry: an AXI4-Lite-to-APB bridge is an AXI subordinate that collects AW + W (or AR) into one APB transfer and returns B (or R) — translating five VALID/READY channels into APB's two-phase transfer, with the APB side identical to the AHB bridge's.

1. Problem statement

The problem is connecting an AXI4-Lite system fabric to a two-phase APB peripheral bus so that a CPU's register access — issued across five independent AXI channels — completes correctly as a single APB transfer with the right response returned upstream.

Modern SoCs increasingly put the CPU and DMA on AXI rather than AHB, but the peripherals — timers, GPIO, UART config, watchdogs — still live on APB for its simplicity and low power (why APB still wins for registers). Something must reconcile two protocols that disagree on almost everything about how a transaction is presented:

• AXI4-Lite is five channels; APB is one transfer. AXI4-Lite splits a transaction across five channels: AW (write address), W (write data), B (write response), AR (read address), R (read data). Each has its own VALID/READY pair and advances independently. APB has exactly one addressed two-phase transfer at a time. The bridge must gather the scattered AXI channels into the single APB transfer.
• Write address and write data arrive on separate channels. Unlike AHB (where address and data are phases of one pipeline), AXI4-Lite's AW and W are wholly independent — the master may present AWVALID before, after, or simultaneously with WVALID. The bridge cannot start the APB write until it has accepted both, because the APB transfer needs the address and the data at once.
• Every transaction owes a response on its own channel. An AXI write is not complete until the subordinate returns a B beat (BVALID/BREADY, carrying BRESP); a read returns an R beat (RVALID/RREADY, carrying RDATA and RRESP). The bridge must originate that response channel itself — APB has no response channel, only a PREADY/PSLVERR at completion that the bridge must translate into B or R.

So the job is to author a block that is a fully-compliant AXI4-Lite subordinate on five channels and a fully-compliant APB manager on one transfer — mapping the scatter-gather of AXI onto APB's serial cadence, and synthesising the B/R response AXI demands.

2. Why previous knowledge is insufficient

You already have the canonical bridge from 13.1, the AHB-to-APB bridge: system-bus slave upstream, APB manager downstream, capture-then-serialise, stall the master, translate waits and errors. And you have the AXI4-Lite primitives — why AXI4-Lite exists, the five channels, and the VALID/READY handshake. What you have not had to reason about is how those two pictures combine:

• The upstream is no longer a single pipeline — it is five handshakes. The AHB bridge captured one address phase. The AXI bridge must run three accept handshakes for a write (AW and W in, B out) and two for a read (AR in, R out), each gated by its own VALID/READY. The "capture" is now an assembly across independent channels, and the bridge must hold each channel's READY until it is ready to consume that channel.
• There is no implicit address/data pairing. AHB pairs address and data by pipeline position. AXI4-Lite gives no inherent ordering between AW and W — the bridge must explicitly wait for both and pair them itself. Reasoning that "the data follows the address" (true on AHB) is wrong on AXI and is a direct source of bugs.
• The response is a channel, not a status bit. On AHB the result rode back on HREADY/HRDATA/HRESP inline. On AXI the bridge must drive a B or R beat with its own handshake and the 2-bit BRESP/RRESP — and exactly one per transaction. That is new machinery the AHB bridge never needed.

The general mapping these examples share is abstracted in 13.3, protocol-conversion mechanics; the specific translation of PSLVERR into BRESP/RRESP is owned by 13.5, error propagation. This chapter establishes the AXI-specific assembly: five channels in, one APB transfer, one response out.

3. Mental model

The model: the bridge is an order desk that takes a multi-form request, fills it at a single slow counter, and mails back a receipt. A write order arrives as two separate forms — the address form (AW) and the contents form (W) — that may show up in either order; the desk waits until it holds both, walks the combined order to the one slow APB counter, waits for the counter to finish, then mails back a single receipt (B). A read order is one form (AR); the desk fetches the value at the counter and mails back the value plus a receipt (R). To AXI the desk is simply a subordinate that accepts forms and returns receipts; to APB it is a manager running one transfer.

Three refinements make it precise:

• Assemble before you act. For a write the bridge asserts AWREADY and WREADY to accept the AW and W beats (in any order), capturing AWADDR, WDATA, and WSTRB into holding registers. Only when both have handshaked does it have a complete APB write to issue. For a read, accepting the single AR beat (capturing ARADDR) is enough. This assembly is the AXI-specific replacement for the AHB bridge's single address capture.
• Run exactly one APB transfer per AXI transaction, serially. From the assembled request the bridge sequences one APB transfer: PSEL in SETUP, PSEL & PENABLE in ACCESS, sample PREADY. AXI4-Lite is typically one outstanding transaction, and even if the master could pipeline, APB cannot — so the bridge serialises, holding its accept-READYs low for the next transaction until this one's response has been sent.
• Close every transaction with its response beat. A write does not end at APB completion — the bridge must then drive BVALID with BRESP (OKAY, or SLVERR from PSLVERR) and wait for BREADY. A read drives RVALID with RDATA (from PRDATA) and RRESP, waiting for RREADY. Exactly one B per write, one R per read; the transaction is complete only when that beat is accepted.

4. Real SoC implementation

In RTL the bridge is an AXI4-Lite subordinate whose accept logic assembles AW + W (or AR), feeding a small FSM that runs one APB transfer and then drives the B or R response. The write path and read path share the APB SETUP/ACCESS sequence; they differ only in how the request is assembled and which response beat closes the transaction.

// AXI4-Lite-to-APB bridge core: AXI subordinate upstream, APB manager downstream.
// Assemble a write from AW + W (or a read from AR) into ONE APB transfer, then
// return exactly one B (write) or R (read) beat. One outstanding; APB serialises.
typedef enum logic [2:0] {IDLE, SETUP, ACCESS, BRESP_S, RRESP_S} state_t;
state_t state, nstate;
 
// --- AXI subordinate: accept AW and W independently and CAPTURE them ---
// Each channel completes on its own VALID & READY; we hold READY only while idle.
wire aw_hs = awvalid && awready;          // AW beat handshakes
wire w_hs  = wvalid  && wready;           // W  beat handshakes
wire ar_hs = arvalid && arready;          // AR beat handshakes
 
assign awready = (state == IDLE) && !aw_done;   // accept AW once per transaction
assign wready  = (state == IDLE) && !w_done;    // accept W  once per transaction
assign arready = (state == IDLE) && !aw_done && !w_done;  // reads only when no write pending
 
always_ff @(posedge aclk or negedge aresetn)
  if (!aresetn) begin aw_done <= 0; w_done <= 0; end
  else begin
    if (aw_hs) begin addr_q  <= awaddr; write_q <= 1'b1; aw_done <= 1; end
    if (w_hs)  begin wdata_q <= wdata;  strb_q  <= wstrb; w_done  <= 1; end
    if (ar_hs) begin addr_q  <= araddr; write_q <= 1'b0;               end
    if (state == BRESP_S && bvalid && bready) begin aw_done <= 0; w_done <= 0; end
    if (state == RRESP_S && rvalid && rready) begin aw_done <= 0; w_done <= 0; end
  end
 
// A write is ready to launch ONLY when BOTH AW and W have handshaked.
wire write_ready = aw_done && w_done;
 
always_comb begin
  nstate = state;
  unique case (state)
    IDLE:    if (write_ready)        nstate = SETUP;     // both AW & W in -> APB write
             else if (ar_hs)         nstate = SETUP;     // AR in          -> APB read
    SETUP:                            nstate = ACCESS;    // SETUP is one cycle
    ACCESS:  if (pready)             nstate = write_q ? BRESP_S : RRESP_S; // APB done
    BRESP_S: if (bready)             nstate = IDLE;       // B beat accepted -> done
    RRESP_S: if (rready)             nstate = IDLE;       // R beat accepted -> done
  endcase
end
always_ff @(posedge aclk or negedge aresetn)
  if (!aresetn) state <= IDLE; else state <= nstate;
 
// --- APB manager: drive the two-phase transfer from the assembled request ---
assign psel    = (state == SETUP) || (state == ACCESS);
assign penable = (state == ACCESS);
assign paddr   = addr_q;
assign pwrite  = write_q;
assign pwdata  = wdata_q;          // real W data — captured, never live AW-time guess
assign pstrb   = strb_q;           // AXI byte strobes map to APB PSTRB
 
// --- response channels: exactly one B per write, one R per read ---
// Capture PSLVERR / PRDATA at APB completion; map PSLVERR -> SLVERR (see 13.5).
always_ff @(posedge aclk)
  if (state == ACCESS && pready) begin
    resp_q  <= pslverr ? 2'b10 : 2'b00;   // 2'b10 = SLVERR, 2'b00 = OKAY
    rdata_q <= prdata;
  end
assign bvalid = (state == BRESP_S);  assign bresp = resp_q;   // write response
assign rvalid = (state == RRESP_S);  assign rresp = resp_q;   // read  response
assign rdata  = rdata_q;

Three facts make this the canonical pattern. First, the write may only launch once both AW and W have handshaked — the aw_done/w_done flags and write_ready = aw_done && w_done gate are the AXI-specific heart of the bridge; AW and W are independent channels, so launching on AW alone drives the APB write with stale WDATA/WSTRB. Second, every transaction is closed by exactly one response beat — the FSM cannot return to IDLE for a write until BVALID && BREADY, nor for a read until RVALID && RREADY; dropping the response hangs the AXI master forever. Third, the APB side is identical to the AHB bridge's — the same PSEL/PENABLE/PADDR/PWRITE/PWDATA SETUP/ACCESS sequence and the same PREADY/PSLVERR sampling; only the upstream assembly and response machinery change. (The detailed PSLVERR → BRESP/RRESP mapping is error propagation, 13.5; PREADY timing is covered in PREADY timing.)

5. Engineering tradeoffs

The bridge's design choices are the AHB bridge's choices plus the AXI-channel mapping. The table below makes the per-channel mapping explicit — it is the single most useful artefact for implementing or reviewing the bridge.

Two decisions ride on top of that mapping. Outstanding depth: AXI4-Lite permits some pipelining, but APB cannot pipeline, so the simplest correct bridge holds one outstanding transaction and serialises — keeping its accept-READYs low until the current transaction's response is sent. A deeper bridge can accept the next AW/W/AR while the current response drains, but it must still serialise the APB transfers and never reorder responses past AXI's ordering rules. Write/read arbitration: when an AW/W and an AR are both presentable, the bridge must pick one (a fixed priority or round-robin) since APB does one transfer at a time; the choice only affects fairness, never correctness, as long as each accepted transaction still gets exactly one response.

6. Common RTL mistakes

7. Debugging scenario

The signature AXI4-Lite-to-APB bridge bug is a corrupted write caused by launching the APB transfer on AW alone, before the W channel has delivered the data — the bridge treats AW and W as if they were paired like AHB's address/data, when they are independent channels.

• Observed symptom: writes to APB registers intermittently land the wrong value — sometimes the previous transaction's data, sometimes garbage — even though the address is always correct. It is worst when the master delays WVALID a few cycles after AWVALID (a common AXI traffic pattern); when AW and W happen to handshake in the same cycle, the write looks fine, which makes the bug maddeningly intermittent.
• Waveform clue: on the AXI side, AWVALID && AWREADY handshakes several cycles before WVALID && WREADY. On the APB side, PSEL/PENABLE assert right after the AW handshake — before the W beat — and PWDATA/PSTRB are stale or X at the PREADY edge where the peripheral commits the write. The B beat still returns OKAY, so nothing flags the corruption.
• Root cause: the FSM transitioned IDLE → SETUP on the AW handshake alone (if (aw_hs) nstate = SETUP;) instead of waiting for both AW and W. Because W is an independent channel that arrives later, the APB write runs with whatever was in wdata_q/strb_q from before — the new data has not been captured yet.
• Correct RTL: gate the launch on both channels — wire write_ready = aw_done && w_done; and IDLE: if (write_ready) nstate = SETUP; — capturing WDATA/WSTRB into wdata_q/strb_q on the W handshake, so the APB write only starts once the real data is held. assign pwdata = wdata_q; assign pstrb = strb_q; then drive committed data.
• Verification assertion: assert the APB write never starts before both channels handshaked, and that each write yields exactly one B — assert property (@(posedge aclk) disable iff(!aresetn) (write_q && psel) |-> (aw_done && w_done)); and assert property (@(posedge aclk) disable iff(!aresetn) (bvalid && bready) |=> !bvalid until_with (state==SETUP)); (one B per write, no duplicate response).
• Debug habit: when a multi-channel bus bridge corrupts data but not address, suspect a premature launch across independent channels first — check whether the downstream transfer is gated on every required upstream channel's handshake or only the first one that arrives. On AXI4-Lite specifically, AW and W are independent; any bridge that treats them as a paired address/data phase (an AHB habit) will commit stale write data the moment the master separates them in time.

8. Verification perspective

A bridge is verified as two protocol-compliant interfaces plus the assembly and response mapping between them — and for the AXI bridge the highest-value checks live exactly where five independent channels collapse into one APB transfer.

• Bind a protocol checker to each face. Run a full AXI4-Lite subordinate protocol monitor on the upstream side (every channel obeys VALID stable until READY, no VALID deassert before handshake, legal BRESP/RRESP encodings) and a full APB manager monitor downstream (legal SETUP/ACCESS, PSEL/PENABLE sequencing, stable PADDR/PWDATA across the transfer), simultaneously. The bridge must be independently legal on each face before you even reason about the translation.
• Assert the assembly and response invariants every transaction. These are the AXI-specific contract: assert the APB write never starts unless both AW and W have handshaked; assert exactly one B per accepted write and exactly one R per accepted read (no missing, no duplicate response); assert read RDATA equals the PRDATA captured at PREADY and write PWDATA/PSTRB equal the captured WDATA/WSTRB; assert PSLVERR maps to BRESP/RRESP=SLVERR and a clean completion to OKAY. These catch the corruptions a pure per-protocol check sails past.
• Cover the channel-skew and serialisation corners. Functional coverage must include WVALID arriving before, after, and simultaneously with AWVALID (the skew that exposes premature-launch bugs); back-to-back AXI transactions (the bridge serialising onto APB); an APB transfer with zero and with N wait states (varying stall length surfaced as READY/VALID back-pressure); a PSLVERR on read and on write; and a delayed BREADY/RREADY (the master slow to accept the response). A bridge only ever tested with AW and W coincident, single transactions, zero wait, and instant BREADY has a coverage hole exactly where AXI bridges break.

The point: verify the bridge as two compliant interfaces and the assembly/response/data mappings between them, and cover the AW/W skew and serialisation corners — the per-protocol monitors alone will pass a bridge that still commits stale write data or drops a response at the boundary.

9. Interview discussion

"How does an AXI4-Lite-to-APB bridge work, and how does it differ from the AHB one?" is a sharp SoC-integration question, and the strong answer leads with the channel assembly and the response obligation, not a signal list.

Frame it as an AXI4-Lite subordinate on five independent VALID/READY channels and an APB manager downstream, assembling a transaction into one APB transfer. State the core sequence: for a write the bridge accepts AW and W on their separate channels (in any order), waits until it holds both, captures address, data, and WSTRB, runs one APB transfer, then drives exactly one B beat (BRESP from PSLVERR); for a read it accepts AR, runs the APB read, and drives one R beat with RDATA from PRDATA. Then deliver the depth that separates senior answers: AW and W are independent — launching the APB write on AWVALID alone commits stale data, the classic bug; every transaction owes exactly one response beat or the master hangs; and the bridge serialises onto APB because APB cannot pipeline, even though AXI could. The line that signals real breadth is the anti-overlap one: "the AXI-to-APB and AHB-to-APB bridges have an identical APB side — the same SETUP/ACCESS and PSLVERR mapping; the only difference is the upstream handshake: five independent AXI channels with their own VALID/READY versus AHB's single pipelined address/data." Closing with the general framing — that this is one instance of protocol conversion: gather the upstream transaction, serialise onto the slow bus, and synthesise the response — shows you see the pattern, not just the wires.

10. Practice

1. Name the personalities. State which protocol the bridge is a subordinate of and which it is a manager of, and list the five AXI channels with the direction (into / out of the bridge) of each.
2. Assemble a write. For one AXI write where WVALID arrives three cycles after AWVALID, walk the bridge from idle through accepting AW, accepting W, launching the APB write, and returning B — marking the earliest cycle the APB write may legally start.
3. Map the channels. For each of AW, W, B, AR, R, state what the bridge does with the channel and which APB signal(s) it drives or samples as a result.
4. Justify the both-channel gate. Explain why launching the APB write on the AW handshake alone corrupts the write, in terms of AW and W being independent channels.
5. Contrast with AHB. State what is identical between the AXI-to-APB and AHB-to-APB bridges and what is different, in one sentence each.

11. Q&A

12. Key takeaways

• The bridge is dual-personality: an AXI4-Lite subordinate upstream and an APB manager downstream, collapsing a five-channel AXI transaction into one two-phase APB transfer.
• Assemble before you act. A write must wait for both AW and W to handshake (independent channels) and capture address, WDATA, and WSTRB; a read captures ARADDR from AR. Launching the APB write on AW alone commits stale data — the signature bug.
• Close every transaction with one response beat. Exactly one B per write (BRESP) and one R per read (RDATA/RRESP); drop it and the AXI master hangs, duplicate it and the protocol breaks.
• Serialise onto APB. AXI4-Lite is typically one outstanding and APB cannot pipeline, so the bridge runs one APB transfer per transaction and holds its accept-READYs low until the response is sent.
• The APB side is identical to the AHB bridge. Same SETUP/ACCESS sequence, same PSLVERR → BRESP/RRESP mapping (13.5); the only real difference is the upstream handshake — five independent VALID/READY channels versus AHB's pipeline. The general pattern is protocol conversion.
• Verify it as two compliant interfaces plus the mapping — an AXI4-Lite subordinate monitor and an APB manager monitor, the both-channels-before-APB / one-response-per-transaction / data-correctness assertions, and coverage of AW/W skew and serialisation corners.