Waveform Interview Questions

The hardest APB interview is the silent one: the interviewer puts a capture on the screen and says nothing. You win it by running the same five-step scan on every waveform — find the PSEL rise, mark the SETUP cycle, mark the PENABLE rise as the start of ACCESS, walk PREADY to count waits, and land on the one completion edge where you read PRDATA/PSLVERR — so that a fast read, a stalled write, and a protocol violation are all decoded by the same repeatable pass. This chapter is the question bank for that skill: a dozen captures, each described cycle by cycle, each answered the way a senior engineer narrates a Saleae or ILA screenshot out loud. Memorising signal definitions is not enough here — the test is whether you can see the contract in eight noisy rows under pressure.

1. What this chapter covers

This is a waveform-reading question bank, not a definitions chapter. Every question below is a capture you must decode: rows of PCLK, PSEL, PENABLE, PWRITE, PADDR, PWDATA, PRDATA, PREADY, and PSLVERR over a handful of cycles, with one fact to extract or one bug to spot. The questions cover the full spread an interviewer reaches for:

Phase identification — telling SETUP from ACCESS at a glance, from PENABLE alone.
Wait counting — reading the number of wait states straight off PREADY without being told.
Direction — distinguishing a read from a write by PWRITE, PWDATA, and PRDATA.
Violation spotting — PENABLE with no SETUP, PADDR changing mid-access, a PREADY glitch, PSLVERR on the wrong beat, two PSEL lines high at once.
Decode — which register is being accessed, back-to-back versus an idle gap, and a PSLVERR-terminated access.

The thesis is that all of these reduce to one scan order, applied without improvisation. The rest of the chapter builds that scan, grounds it in real capture tools, then drills it across the question bank and a five-capture practice set.

2. Why waveform reading is tested

Interviewers test waveform reading because it is the one APB skill that cannot be faked by memorisation. A candidate can recite "PENABLE is high in the access phase" without ever having debugged a bus; put a capture in front of them and the recitation does not help, because the waveform does not announce its phases — you have to derive them. Reading is the proxy for real bench experience.

It is also the highest-leverage screening question. A single capture probes a dozen facts at once: whether you know the two-phase structure, where completion is sampled, what PRDATA means during a wait, whether you confuse PENABLE high with "done", and whether you check PSLVERR before trusting data. One screenshot, asked well, separates the candidate who has stared at sim waveforms from the one who has only read the spec. And it mirrors the actual job — bring-up, triage, and protocol-checker failures are all read this capture and tell me what the bus did. The interview is testing the daily task directly.

The trap the interviewer is watching for is improvisation: a candidate who invents a new reading approach per waveform will misread one. The defence is a fixed method you can run aloud, the same way every time.

3. Mental model — the five-step scan

The model: never read an APB capture by staring at all rows at once — run a fixed five-step scan, left to right, narrating each step. The scan converts a wall of signals into one sentence: direction, wait count, completion verdict.

Figure 1 — the five-step scan order over one annotated APB read with a single wait state, walked against PCLK. Step 1: find where PSEL rises out of IDLE — the request begins. Step 2: the cycle after the PSEL rise, with PENABLE still low, is the SETUP cycle. Step 3: the PENABLE rise marks the start of the ACCESS phase. Step 4: walk PREADY across the access cycles — it is low on the first (one wait state, where PRDATA is don't-care) and high on the second. Step 5: the first access cycle where PSEL, PENABLE, and PREADY are all high is the single completion edge (bold dashed line), and only there are PRDATA and PSLVERR sampled. PWRITE is low so this is a read; PSLVERR is low so the captured value is trusted. The figure teaches the same scan that decodes every capture in this chapter.

The five steps, in order:

Find the PSEL rise. This is the request. Nothing before it is part of the transfer; the cycles where PSEL is low are IDLE.
Mark the SETUP cycle. It is the first cycle PSEL is high with PENABLE still low. There is exactly one.
Mark the PENABLE rise — that is ACCESS. PENABLE going high at the setup-to-access boundary defines the access phase. It then stays high across every access cycle, waits included.
Walk PREADY to count waits. Each access cycle where PREADY is low is one wait state, and PRDATA/PWDATA consumption has not happened yet. Count them.
Land on the completion edge. The first access cycle where PSEL & PENABLE & PREADY are all high is the single completion edge. Read PRDATA (for a read) there and only there, then check PSLVERR before trusting it.

Two refinements make the scan robust. Direction is read once, at step 1–2: PWRITE high with PWDATA driven is a write; PWRITE low with PRDATA returning is a read — and PWRITE is stable from setup through completion, so you read it early and never re-check. And completion is found by search, not by position — step 5 scans for the first all-high cycle, so the scan is identical whether there are zero waits or ten; only the answer at step 4 changes. This wait-count-agnostic property is the non-trivial technique: you never count to a fixed cycle, you search for the conjunction.

4. Real SoC and bench context

You run this scan on three kinds of capture during real bring-up, and the rows look slightly different in each — knowing the artefact saves you from misreading its quirks.

Logic-analyzer capture (Saleae / ILA). A Saleae Logic trace or an on-chip Xilinx ILA / Vivado integrated logic analyzer capture samples the APB pins on PCLK edges and shows them as the rows you scan. The catch: a logic analyzer shows levels, not the FSM state, so you must derive SETUP and ACCESS yourself from PSEL/PENABLE — exactly steps 2 and 3. An ILA also has finite depth, so a long stall can run off the end of the window; if you cannot find the completion edge, suspect the capture was truncated mid-access, not that the bus hung.
VCD from simulation. A .vcd dumped by the testbench and opened in GTKWave or Verdi gives you glitch-free, cycle-accurate rows — the cleanest capture you will read. Here a PREADY that drops back low after going high, or a PADDR that changes mid-access, is a real RTL bug, not a sampling artefact, because the VCD records exactly what the RTL drove.
Bus-functional / protocol-checker log. Many benches pair the waveform with an APB protocol checker (an assertion IP) that flags the illegal cycle. The checker tells you that something is wrong; the scan tells you what — and in the interview, only the scan is available to you, so you practice spotting the violation without the checker's help.

Across all three, the scan is identical. What changes is your prior about whether an oddity is a bug (VCD) or possibly an artefact (truncated ILA window).

Figure 2 — an interview 'decode this' capture over eight PCLK cycles with the full APB signal set. The phase bands read IDLE, SETUP, then ACCESS spanning three cycles labelled WAIT, WAIT, COMPLETE+ERR, then IDLE. PSEL rises into the SETUP cycle (cycle 3) with PWRITE low, so this is a read; PADDR holds a single stable value A across setup and access; PWDATA is don't-care because it is a read. PENABLE is low in setup and rises at the boundary, held high across all three access cycles. PREADY is low on the first two access cycles (cycles 4 and 5 — the two wait states, where PRDATA is don't-care) and high only on the third (cycle 6), the single completion edge marked with a bold dashed line. On that completion edge PRDATA carries a value but PSLVERR is also high (red), so the read completes yet its data is an error response to discard. The verdict triad: a read, two wait states, terminated by PSLVERR.

5. Weak read versus strong read

The difference between a weak and a strong candidate is rarely the final answer — it is how the answer was reached. The weak read jumps to a signal; the strong read runs the scan and lands on the same conclusion with a reason.

Capture cue	Weak read (jumps to a signal)	Strong read (runs the scan)	Why the strong read is correct
`PENABLE` is high for three cycles	"Three access cycles, so the data is somewhere in there."	"`PENABLE` high marks the access phase; I walk `PREADY` — low, low, high — so two waits and completion on the third."	`PENABLE` is high across waits too; only the `PREADY` search picks out the completion cycle.
`PRDATA` shows a value early in access	"There is the read data."	"That cycle has `PREADY` low — it is a wait, `PRDATA` is don't-care; I read it only on the completion edge."	`PRDATA` is required valid only at completion; an early value is in-transit garbage.
Two cycles, `PENABLE` never low	"Looks like a normal access."	"There is no `SETUP` cycle — `PENABLE` high without a preceding `PSEL`-high/`PENABLE`-low cycle is illegal."	`PENABLE` must rise after a setup cycle; high from the first selected cycle erases the boundary.
`PREADY` high then low then high	"It completed on the first high."	"`PREADY` glitched — it must stay high once asserted in an access; a drop after asserting is a violation."	`PREADY` is not allowed to deassert within an access once high; completion is a one-way event.
`PSLVERR` high one cycle before `PREADY`	"Error read."	"`PSLVERR` is only meaningful on the completion edge with `PREADY` high; high during a wait is a violation, not an error response."	`PSLVERR` is qualified by the completion handshake; off the completing beat it is meaningless.
Back-to-back transfers, no `PSEL` drop	"Pipelined like AXI."	"Completion flows straight into the next `SETUP` — adjacency, not overlap; the next access begins only after this completion."	APB is non-pipelined and single-outstanding; phases never overlap.

The throughline: every weak read in column two reasons from a single signal in a single cycle; every strong read in column three restores the phase context — which cycle is setup, which is a wait, which is completion — before judging the signal. The scan is what supplies that context.

6. Common misreads and red flags

Misreads to unlearn

"PENABLE high means I am looking at the access cycle that has the data." No. PENABLE is high across the entire access phase, every wait included. Only the PREADY search at step 4 finds the data cycle.
"I can read PRDATA wherever it shows a stable value." No. PRDATA is required valid only on the completion edge (the first PREADY-high access cycle). A value during a wait is in-transit don't-care; sampling it latches garbage.
"PENABLE high in the first selected cycle is fine, it is just a fast transfer." No — that is the no-SETUP violation. There must be one cycle with PSEL high and PENABLE low before PENABLE rises. PENABLE high from the first selected cycle is illegal.
"PADDR moved during access, so the address must have updated for the next transfer." No. PADDR (and PWRITE, PWDATA, PSTRB) must hold byte-for-byte from setup through completion. A mid-access change is a signal-stability violation that silently commits the wrong access.
"PREADY went high, so completion happened, even though it dropped again next cycle." No. Within an access, once PREADY is high the transfer completes and PENABLE drops; a PREADY that asserts then deasserts within the same access is a glitch/violation, not two completions.
"PSLVERR is high, so the bus retried or stalled." No. APB has no retry. PSLVERR high on the completion edge means the transfer completed but its data is an error response to discard; the bus moves on normally.
"Two PSEL lines are high, so two subordinates respond." No. With one manager only one PSEL may be high at a time (each subordinate has its own PSELx). Two high simultaneously is a decode/address-map bug.

These are the red flags the scan surfaces automatically: a missing SETUP cycle (step 2 fails), a PADDR/PWRITE/PWDATA change after the PENABLE rise (step 3–5 window broken), a PREADY that is not monotonic within an access (step 4 ambiguous), PSLVERR asserted off the completion beat (step 5 misqualified), and more than one PSELx high (step 1 ambiguous). Each violation breaks exactly one step, which both names the bug and points to the cycle.

7. Interview framing

The framing that wins the silent-capture interview is to announce the scan, then narrate it. Do not start guessing at signals; say "I will read this in five steps — request, setup, access, waits, completion," and then walk the rows aloud. The interviewer is grading the method as much as the answer, and a visible, repeatable method is the signal that you have done this on real hardware.

End every read with a one-line verdict in the same shape: direction, wait count, completion result. For Figure 2 that is "a read, two wait states, completes with PSLVERR high — discard the data." That triad proves you extracted the three facts that matter and did not stop at "it is an access." When you spot a violation, name it as which step broke and which cycle: "step 2 fails — there is no setup cycle, PENABLE is high from the first selected cycle, which is illegal per the two-phase rule." Per the APB specification (ARM IHI 0024C, §3.1 timing), PENABLE must be low for the setup cycle and rise only at the boundary, so that read is not a stylistic opinion — it is the spec. Citing the clause turns your verdict from an assertion into a fact the interviewer cannot argue with.

8. Q&A

9. Practice

Decode Figure 2 cold. Cover the caption and run the five steps aloud, ending in the direction / wait-count / completion triad. Confirm you reach "read, two waits, PSLVERR — discard."
Count the waits. For a capture where PENABLE is high across four access cycles and PREADY reads low, low, low, high, state the wait count, the completion cycle, and what PRDATA is on each of the first three.
Spot the no-SETUP violation. Sketch a capture where PENABLE is high in the first PSEL-high cycle. Name the step that fails and cite the spec clause it breaks.
Classify back-to-back vs idle. Draw two adjacent reads with PSEL staying high and PENABLE dropping to low for one cycle between them; explain why this is adjacency, not pipelining, and where the second setup begins.
Read the error beat. Given a capture with PSLVERR high one cycle before PREADY goes high, decide whether the access is an error, and justify it by where PSLVERR is qualified.

10. Key takeaways

Run one fixed scan on every capture: PSEL rise (request) → SETUP cycle → PENABLE rise (ACCESS) → walk PREADY (count waits) → completion edge (read PRDATA/PSLVERR). The same five steps decode a fast read, a stalled write, and a violation.
Derive the phases — captures do not label them. SETUP is the PSEL-high/PENABLE-low cycle; ACCESS starts at the PENABLE rise. A logic-analyzer trace shows levels, not FSM state.
Completion is found by search, not position. The first access cycle with PSEL & PENABLE & PREADY all high is the only place to read PRDATA; the scan is identical for zero waits or ten.
Every violation breaks exactly one step: no SETUP cycle (step 2), PADDR/PWDATA change mid-access (steps 3–5 window), non-monotonic PREADY glitch (step 4), PSLVERR off the completion beat (step 5), two PSELx high (step 1).
End with the triad and the spec. State direction, wait count, completion verdict; when you flag a bug, name the step and cite ARM IHI 0024C §3.1 timing. For deeper reads see read-waveform analysis, write-waveform analysis, multiple wait cycles, PENABLE behaviour, the transfer lifecycle, and the setup/access interview traps.