Design Interview Questions

Design prompts put you at the whiteboard: "design an AHB-Lite slave", "sketch an arbiter", "write the RTL for a register bank on AHB." They test whether you can turn the protocol into hardware — the production counterpart to reading a waveform. The common prompts: an AHB-Lite slave (the most common — capture the address phase, respond in the data phase, drive HREADYOUT/HRESP); a register-bank slave (decode the address to a register, handle read/write, often zero wait states); an address decoder (map HADDR to a one-hot HSEL from the address map); an arbiter (take HBUSREQ, apply a policy, drive HGRANT/HMASTER, hand over only at boundaries); a bridge FSM (accept a transfer, run the downstream protocol, stretch HREADY until done); and a master/DMA (drive the address phase a cycle ahead, sequence bursts, handle waits/errors). The approach is a discipline: clarify the requirements and assumptions → sketch the interface (ports) → make the pipeline capture explicit (register the address-phase control so it's available in the data phase a cycle later) → define the FSM/datapath → handle the corner cases (wait states, the two-cycle ERROR, bursts, back-to-back, reset) → name the verification hooks. The single most important move is to make the pipeline capture explicit — registering the address phase is the heart of every correct AHB design, the thing that separates a correct design from one that pairs data with the wrong address. And clarifying before coding signals seniority: you scope the problem instead of coding the wrong thing fast. This chapter works through the approach with a real slave skeleton.

1. What Is It?

Design questions ask you to turn the AHB protocol into hardware; answering them means following a disciplined approach anchored on the pipeline capture. The prompts and the approach:

• The prompts — an AHB-Lite slave (most common), a register-bank slave, an address decoder, an arbiter, a bridge FSM, a master/DMA.
• Clarify + interface — ask the requirements (AHB-Lite or full? which slaves? waits? bursts? multi-master?), state assumptions; sketch the ports before logic.
• Pipeline capture (the heart) — register the address-phase control (HADDR/HWRITE/HSIZE/HTRANS) so it's available in the data phase a cycle later.
• FSM/datapath + corner cases + verify — the states/logic that do the work; handle waits, the two-cycle ERROR, bursts, back-to-back, reset; name the assertions/coverage.

So design questions are the production test — interviewers use them to confirm you can build AHB hardware, not just describe it. The signal they're looking for is whether you make the pipeline capture explicit — anyone can draw an interface; a candidate who can design AHB says: "first, I register the address-phase control — the address, the write/read flag, the size — because by the data phase, HADDR has moved on to the next transfer, so I must capture it; then in the data phase I use the registered address to drive the read mux or the write enable." The explicit-pipeline-capture is the differentiator: it shows you understand the one thing that makes AHB RTL correct. And the meta-signal: a senior candidate clarifies first — scoping the problem (AHB-Lite vs full, waits, bursts) before coding — signaling judgment over speed. So design questions are the production test, anchored on the pipeline capture. So they're where the protocol becomes hardware.

2. Why Does It Exist?

Design questions exist because building AHB hardware is the output of the role (an AHB engineer writes RTL) — and the test of whether you can build it is whether you handle the pipeline correctly (capture the address phase) and the corner cases (waits, errors, bursts) — because those are exactly where AHB RTL goes wrong.

The building is the output is the root: describing AHB (the earlier rounds) is necessary but not sufficient — the job is to produce working RTL. So design questions test the output — can you build it? So they exist to test production. So building is the deliverable. So design follows description.

The the pipeline is where RTL goes wrong is the test: the single most common AHB RTL bug is using the live HADDR in the data phase (when it's already the next transfer's address) instead of the registered one. So a correct design must capture the address phase. So design questions test whether you handle the pipeline — by checking you register the address. So they exist to test the pipeline handling. So capture the address. So make it explicit.

The the corner cases are where designs break is the depth: a slave that handles the simple case but not wait states, the two-cycle ERROR, bursts, or back-to-back transfers is incomplete and breaks in integration. So design questions probe the corner cases — do you handle them? So they exist to test completeness. So handle the corners. So design questions exist because: building AHB hardware is the output of the role (the root); the test is handling the pipeline correctly (registering the address — where RTL goes wrong — the key); and the corner cases are where designs break (the depth). So design questions are the production test — passed by the disciplined approach, making the pipeline capture explicit, and handling the corner cases — demonstrating you can build AHB hardware. So this chapter prepares you to design AHB blocks. So clarify, capture the pipeline, and handle the corners.

3. Mental Model

Model an AHB design answer as a chef being asked to cook a dish for a tasting, not just name the recipe. A line cook starts chopping immediately — and discovers halfway that they didn't ask whether it's for a vegetarian, how many covers, or which course. A head chef clarifies first ("how many, any allergies, plated or family-style?"), sets up their mise en place (every ingredient prepped and within reach before the heat goes on — the capture step), cooks the core (the technique that defines the dish), then handles the edges (seasoning, resting, the garnish, the plating). The clarify-then-mise-en-place discipline is what separates a chef from someone who can recite recipes — and the mise en place (everything captured and ready before you act) is the move that makes the cooking actually work.

A test kitchen where a candidate is asked to cook a dish (design an AHB block), not just name the recipe (describe the protocol). A line cook starts chopping immediately (dives into RTL) and discovers halfway they didn't ask the basics — vegetarian? how many covers? which course? (AHB-Lite or full? waits? bursts?) — and has to redo it. A head chef works with discipline: clarify first ("how many, allergies, plated or family-style?" — scope the requirements); set up the mise en place — every ingredient prepped and within reach before the heat (the pipeline capture: register the address-phase control before the data phase needs it — everything captured and ready before you act); cook the core (the technique that defines the dish — the FSM/datapath that does the work); then handle the edges (seasoning, resting, garnish, plating — the corner cases: waits, errors, bursts, reset). The clarify-then-mise-en-place discipline is what separates a chef from a recipe-reciter — and the mise en place (everything captured and ready before you act) is the move that makes the cooking work. A cook who skips the mise en place reaches for an ingredient mid-cook and it's not ready (a slave that reaches for the address in the data phase and it's already gone).

This captures AHB design: the line cook chopping immediately = diving into RTL without clarifying; the head chef clarifying covers/allergies = clarifying the requirements (AHB-Lite/full, waits, bursts); the mise en place, everything prepped before the heat = the pipeline capture (registering the address phase before the data phase); cooking the core technique = the FSM/datapath; handling seasoning/resting/garnish = the corner cases (waits, errors, bursts, reset); reaching for an unprepped ingredient mid-cook = a slave using the live (already-advanced) HADDR in the data phase. Clarify first, set up the pipeline capture (mise en place), build the core, handle the edges — and you've designed the block, not just recited the protocol.

Here is what the pipeline capture buys you — the registered address available exactly when the data phase needs it:

The model's lesson: clarify first, make the pipeline capture explicit (the mise en place), build the core, handle the corners. In the figure, the registered addr_q holds A0 into the data phase — exactly when HWDATA (the write data for A0) arrives — while the live HADDR has already advanced to A1. Using addr_q, not the live HADDR, is what makes the slave correct.

4. Real Hardware Perspective

The substance behind a strong design answer is the RTL structure from Module 8 (the slave-design module) — so each prompt maps to a chapter, and the answer builds that structure with the pipeline capture.

The the AHB-Lite slave (the canonical prompt): build it — register the address phase; in the data phase, use the registered address to decode and drive the read mux (HRDATA) or the write enable (using HWDATA); drive HREADYOUT (high for zero-wait, low to insert waits) and HRESP (OKAY, or the two-cycle ERROR). So the answer builds the slave from the capture + response (see AHB-Lite Slave, Address/Control Capture, HREADYOUT Generation). So it's the canonical design. So capture then respond.

A slave skeleton that makes the capture explicit:

// AHB-Lite slave skeleton — the pipeline capture is the heart of it.
module ahb_lite_slave #(parameter AW = 12, DW = 32) (
  input  logic            HCLK, HRESETn,
  input  logic            HSEL,
  input  logic [AW-1:0]   HADDR,
  input  logic            HWRITE,
  input  logic [1:0]      HTRANS,
  input  logic [DW-1:0]   HWDATA,
  output logic [DW-1:0]   HRDATA,
  output logic            HREADYOUT,
  output logic            HRESP
);
  // A transfer is "active" when selected with a real (NONSEQ/SEQ) HTRANS.
  wire active = HSEL & HTRANS[1];
 
  // ---- Pipeline capture: register the ADDRESS-PHASE control ----
  // By the data phase, live HADDR has advanced to the next transfer, so we
  // MUST use these registered copies — not the live bus — to steer the write.
  logic [AW-1:0] addr_q;
  logic          write_q, active_q;
  always_ff @(posedge HCLK or negedge HRESETn)
    if (!HRESETn) begin addr_q <= '0; write_q <= 0; active_q <= 0; end
    else if (HREADYOUT) begin            // capture only at a transfer boundary
      addr_q   <= HADDR;
      write_q  <= HWRITE;
      active_q <= active;
    end
 
  // ---- Data phase: act on the CAPTURED address ----
  logic [DW-1:0] mem [0:(1<<AW)-1];
  always_ff @(posedge HCLK)
    if (active_q & write_q & HREADYOUT)  // write uses addr_q, not live HADDR
      mem[addr_q] <= HWDATA;
  assign HRDATA    = mem[addr_q];        // read mux on the captured address
  assign HREADYOUT = 1'b1;               // zero wait states (extend for slow paths)
  assign HRESP     = 1'b0;               // OKAY (add the two-cycle ERROR for faults)
endmodule

The the decoder, arbiter, and bridge: build each — the decoder is combinational (HADDR → one-hot HSEL + default slave); the arbiter is the policy FSM (HBUSREQ → HGRANT/HMASTER, boundary handover); the bridge is the FSM (IDLE → SETUP → ACCESS → DONE, stretching HREADY). So the answer builds each from its structure (see Register-Bank Slave, Write FSM, Read FSM, Bridge FSM RTL, Why Arbitration). So in practice, designing an AHB block is building its structure with the pipeline capture and the corner cases. So in practice, know the RTL structure (Module 8) and build it. So that's the preparation.

5. System Architecture Perspective

At the interview level, the design round is the can-you-build-it test — passing it (the disciplined approach, the explicit pipeline capture, the corner cases) proves you can produce AHB RTL, and the clarify-first discipline signals seniority (you scope before coding — the difference between a senior engineer and a fast junior).

The the can-you-build-it test: the earlier rounds test knowledge; the design round tests production — can you turn it into hardware? A strong design (correct pipeline capture, corner cases handled) proves you can build; a weak one (missing the capture, ignoring waits) reveals you can't (yet). So at the interview level, the design round is the can-you-build-it test. So pass it. So building proves capability.

The clarify-first signals seniority: a junior engineer codes fast (and often the wrong thing); a senior engineer clarifies first — scoping the requirements, stating assumptions, surfacing the corner cases before coding. So the clarify-first discipline signals seniority — judgment over speed. So at the interview level, how you approach the design (clarify, then capture, then corners) signals your level. So clarify first. So the approach signals seniority. So at the interview level, the design round is the can-you-build-it test (passing it proves you can produce AHB RTL) and the clarify-first discipline signals seniority (scoping before coding). So the design round is where you prove you can build AHB hardware — making the disciplined approach, the explicit pipeline capture, and the corner cases the keys to proving production capability and signaling seniority. So clarify, capture, build, handle the corners. So the design round is the production bar.

6. Engineering Tradeoffs

Answering a design question embodies the clarify-first, explicit-pipeline-capture, handle-the-corners approach.

• Clarify first vs code fast. Clarifying (scope the requirements, state assumptions) signals seniority; coding fast risks the wrong thing. Clarify first.
• Explicit pipeline capture vs implicit. Explicitly registering the address phase makes the design correct; using the live HADDR in the data phase is the bug. Make the capture explicit.
• Handle the corners vs the happy path. Handling waits, the two-cycle ERROR, bursts, back-to-back, reset makes it complete; the happy path only breaks in integration. Handle the corners.
• Name the verification vs stop at RTL. Naming the assertions/coverage you'd add closes the loop and signals rigor; stopping at RTL is incomplete. Name the verification.

The throughline: design questions ask you to turn AHB into hardware — via the approach (clarify → interface → pipeline capture → FSM/datapath → corner cases → verify). The prompts: slave, register bank, decoder, arbiter, bridge FSM, master/DMA. The meta-signal: make the pipeline capture explicit (register the address phase) — and clarify first (signals seniority). The common traps: the live HADDR in the data phase, forgetting wait states, a combinational HREADY path/glitch. The design round is the can-you-build-it test — passing it proves you can produce AHB RTL, and the clarify-first discipline signals seniority.

7. Industry Example

A typical design round — the interviewer asks you to design an AHB slave.

The interviewer says "design an AHB-Lite slave for a small memory."

• You clarify first. "A few questions: AHB-Lite, single master — yes? Is it a simple SRAM that can respond in zero wait states, or a slower memory that needs wait states? Do I need to support the full burst types, or just handle them as a sequence? And should it return ERROR on out-of-range addresses?" (Scoping — signals seniority.)
• You sketch the interface. "The ports are the AHB-Lite slave signals: inputs HCLK, HRESETn, HSEL, HADDR, HWRITE, HTRANS, HSIZE, HWDATA; outputs HRDATA, HREADYOUT, HRESP. Plus HREADY in if it's behind a mux." (Boundary first.)
• You make the pipeline capture explicit. "The heart of this is the pipeline. I register the address-phase control — HADDR, HWRITE, and whether it's an active transfer (HSEL and a real HTRANS) — into addr_q, write_q, active_q, capturing at each transfer boundary. Because by the data phase, the live HADDR has advanced to the next transfer, so I must use the registered address to steer the access." (The #1 move.)
• You build the datapath. "In the data phase, a write uses addr_q and write_q to write HWDATA into mem[addr_q]; a read drives HRDATA from mem[addr_q]. For a zero-wait SRAM, HREADYOUT is high; HRESP is OKAY." (The core.)
• You handle the corners. "If it's a slow memory, I drive HREADYOUT low for the access latency, holding the captured control, then high when ready. For out-of-range addresses, I drive the two-cycle ERROR — HRESP=ERROR with HREADYOUT low, then high. Bursts just come in as a sequence of SEQ transfers with incrementing addresses — my capture handles each beat the same way. On reset, the registers clear." (Waits, ERROR, bursts, reset.)
• You name the verification. "I'd add assertions: HREADYOUT eventually goes high (no hang); a write to addr_q matches a later read (data integrity, via a scoreboard); HRESP=ERROR only on out-of-range. And coverage on wait-state counts, the burst types, and the error path." (Closing the loop.)
• The meta-signal. You clarified first, made the pipeline capture explicit, handled the corners, and named the verification. The interviewer sees you can build AHB hardware correctly.

The example shows the design round and a strong answer: clarified first, explicit pipeline capture, corner cases handled, verification named, avoiding the traps (live HADDR, missing waits, combinational HREADY). This proves production capability and signals seniority. This is how you design an AHB block.

8. Common Mistakes

9. Interview Insight

The design round is the can-you-build-it test — the disciplined approach, the explicit pipeline capture, and handling the corners are the signals.

The way to carry the design round: follow the disciplined approach, make the pipeline capture explicit, and handle the corner cases. The interviewer is checking whether you can build AHB hardware — production, not just description. The most important move is to make the pipeline capture explicit — register the address-phase control so it's available in the data phase a cycle later, because that one thing is the heart of every correct AHB design (and using the live HADDR is the #1 bug). Clarify first (it signals seniority), handle the corners (waits, the two-cycle ERROR, bursts, back-to-back, reset), and name the verification — and you'll pass the design round and prove you can build AHB RTL.

10. Practice Challenge

Practice the design round.

1. The approach. State the six steps (clarify → interface → pipeline capture → FSM/datapath → corner cases → verify) and why clarifying first signals seniority.
2. The slave. Sketch an AHB-Lite slave — making the pipeline capture explicit (register the address phase, act in the data phase).
3. The bug. Explain the #1 AHB RTL bug (live HADDR in the data phase) and how the capture avoids it.
4. The decoder. Design an address decoder (HADDR → one-hot HSEL) and the role of the default slave.
5. The arbiter. Design a two-master arbiter — the signals, the policy, and the boundary-only handover.

11. Key Takeaways

• Design questions ask you to turn AHB into hardware — a slave, register bank, decoder, arbiter, bridge FSM, or master/DMA.
• Follow the approach — clarify → interface → pipeline capture → FSM/datapath → corner cases → verify. The order makes the design correct and complete.
• Make the pipeline capture explicit (the #1 move) — register the address-phase control so it's available in the data phase a cycle later. Using the live HADDR is the #1 AHB RTL bug.
• Clarify first (signals seniority) — scope the requirements (AHB-Lite/full, waits, bursts, multi-master) before coding.
• Handle the corner cases — wait states (HREADYOUT low), the two-cycle ERROR, bursts, back-to-back, reset. And name the verification (assertions/coverage).
• The design round is the can-you-build-it test — passing it proves you can produce AHB RTL; the clarify-first discipline signals seniority.

12. What Comes Next

You can now design AHB blocks. The next chapters cover the verification and specialized rounds:

• Verification Interview Questions (next) — checker/coverage/UVM prompts (how you'd verify the design you just built).
• Bridge Questions, Arbitration Questions, and Tricky Misconceptions — the specialized prompts and the myths to correct.

To revisit the RTL structure these designs build, see AHB-Lite Slave, Address/Control Capture, HREADYOUT Generation, Bridge FSM RTL, and Two-Cycle ERROR Response.