Senior Questions

A senior Wishbone interview is rarely about Wishbone. The protocol is assumed. What is being tested is whether you can be handed a subsystem and be trusted with it — which means identifying what the requirements do not say, choosing anyway, and knowing what your choice cost.

The interviewer has stopped asking do you know this bus. They are asking can you own this block.

1. The Requirements Trap

Q. Design the best Wishbone arbiter.

The question is unanswerable as stated, and saying so is the first half of the answer. Best against what?

• how many masters, and are they peers?
• is there a latency target, and for whom?
• is bounded service a requirement, or merely desirable?
• does any master hold CYC_O across transfers?
• area and frequency budget?
• what happens when a master is starved — degraded audio, or a missed control loop?

Asking for the missing requirement is not evasion. It is the job. But do not stop there, because an interviewer who wanted a list of questions would have asked for one. The senior move is to name the gap, close it with a stated assumption, and continue:

"Nothing here tells me whether bounded waiting is a requirement or a preference, and that changes the answer completely. Assuming equal-priority masters and bounded waiting as a hard requirement, I would start with round-robin, because it gives a provable worst-case service interval proportional to the number of masters. If instead one master is real-time and the others are best-effort, round-robin is the wrong default and I would want priority with an anti-starvation escape hatch — and I would need to know the deadline to size it."

Then add the sentence that makes it engineering rather than opinion: and here is how the answer changes if the assumption is wrong.

One thing you may not say: that Wishbone requires any of this. B3 mandates no arbitration algorithm. The nearest it comes is a recommendation that arbitration logic often uses CYC_I, paired with a permission that a master may assert CYC_O indefinitely — a tension the specification states and leaves to you.

2. Scenario A — The SoC Interconnect

A CPU, a DMA, several low-speed peripherals, an SRAM, one slow peripheral. Predictable behaviour matters. Modest FPGA resources. Design the topology.

What is missing: the traffic mix. Whether the DMA runs concurrently with CPU execution or in bursts between them changes the answer more than anything else in the brief. Assume, and say so.

The decision that matters is not shared-bus-versus-crossbar. It is which pairs of masters and targets need to be concurrent, and the honest observation is that in this system there is exactly one plausible pair: CPU-to-peripherals while DMA-to-SRAM. A full crossbar buys concurrency for pairings nobody has, and on a modest FPGA the multiplexer and decode replication are not free.

So: a shared bus with the SRAM on a separate port if and only if the traffic mix says CPU and DMA overlap. If it does not, a shared bus is not a compromise — it is correct, and it is smaller, simpler and easier to verify.

The slow peripheral is the real design problem. On a shared bus it holds the bus for the duration of its access, and everything else waits. Three options, and the choice needs a number you have not been given:

Draw both and let the requirement choose:

What you must specify regardless of topology: the address map including what unmapped means; a default responder, because a hole that hangs is indistinguishable from a broken peripheral; and the observability you will need in Section 6 — at minimum, which target was selected per transfer, which is not recoverable from the interface afterwards.

3. Scenario B — Registered Or Combinational Termination

Would you register ACK?

Reject the folklore first. This is not combinational equals fast, registered equals slow. Both halves of that are incomplete, and the specification itself frames the trade-off in three numbered items.

Combinational is explicitly permitted, not merely unforbidden:

PERMISSION 3.30 — The assertion of ACK_O, ERR_O, and RTY_O MAY be asynchronous to the CLK_I signal (i.e. there is a combinatorial logic path between STB_I and ACK_O).

OBSERVATION 3.40 — The asynchronous assertion ... assures that the interface can accomplish one data transfer per clock cycle.

And the specification names the cost:

OBSERVATION 3.50 — In large high speed designs the asynchronous assertion ... could lead to unacceptable delay times, caused by the loopback delay from the MASTER to the SLAVE and back to the MASTER.

OBSERVATION 3.45 — ... slave wait states are easiest implemented using a registered ACK_O.

That is the whole trade-off, stated by B3 and not by anybody's blog. Now the measurement. One slave, one four-operation program, one parameter changed:

  termination      transfers  wait clocks  first ack  last ack
  combinational            4            0          2        17
  registered               4            4          3        21

  clocks from first to last completion   comb 15   reg 18
  extra clocks per transfer              1

  architectural result   comb word1 0xa1b2bbd4   reg word1 0xa1b2bbd4
  commits                comb 2             reg 2

Exactly one extra clock per transfer, and an identical architectural result. That is the price in latency, and it is small, bounded and easy to reason about.

And then the sentence that makes the answer honest:

  NOT MEASURED: the frequency half. No synthesis was run in
  this curriculum, so nothing here quantifies the loopback
  delay OBSERVATION 3.50 describes.

A strong answer states which half it measured. The latency cost is one clock per transfer; the frequency benefit is whatever your synthesis reports, and if you have not run it you do not know. A candidate who asserts a megahertz number they have not measured has told you something more damaging than not knowing it.

So: "I would register it in a design where this path is on, or near, the critical path — which I would confirm before deciding — and I would leave it combinational in a small slow design where one clock per transfer is a real fraction of my latency budget and the path is nowhere near critical. PERMISSION 3.10's tied ACK is available only if the slave keeps pace and ERR and RTY are unused; the moment I add an error response I have left that permission behind."

Worth adding unprompted: registering termination makes wait states natural rather than awkward, which is OBSERVATION 3.45's point and a maintainability argument, not a performance one.

4. Scenario C — Integrating The DMA

Add a DMA without disturbing CPU traffic. What do you specify?

Separate three things the question deliberately blurs.

Bus access. Arbitration, and it is local policy. If the CPU has a latency requirement, the arbiter must be able to meet it — and if the DMA is permitted to hold CYC_O across a block, the arbiter needs to be told that, because RECOMMENDATION 3.05 warns that keeping CYC_O asserted may lead to arbitration problems.

State that must survive losing the bus. The DMA will lose arbitration mid-transfer, and that is not an error. What must survive is: the read data (a holding register, or the read must be repeated at a location that may have moved); source progress, which really advanced; destination progress, which did not; and a descriptor snapshot, not a live re-read of memory another master may be editing.

Completion semantics. A transfer is source-plus-destination. Counters advance on the completion of the thing they count, never on grant and never on RTY.

Verification implications, stated in the same breath: the interesting cases are all arbitration-timed. The DMA losing the bus between its read and its write is the one that finds holding-register bugs, and it does not happen unless you construct it. Random stimulus reaches it eventually; a directed test reaches it on run one.

5. Scenario D — One Slave Can Hang Forever

A peripheral can fail in a way that means it never terminates. What do you change?

Start by refusing the false premise: this is not a protocol violation. B3 bounds no latency. A slave that never answers is behaving in a way the specification does not forbid, and an interconnect that assumes otherwise has assumed a requirement into existence.

What you change is the system, and the specification agrees:

RECOMMENDATION 3.10 — Design INTERCON modules to prevent deadlock. One solution is a watchdog timer function that monitors the MASTER's STB_O signal.

A recommendation, about an interconnect, not a rule. So:

A watchdog in the interconnect, with a timeout that comes from your requirements. Its value is a system parameter and it should be documented as one.

A synthesised ERR on expiry, so the master gets a termination and a hang becomes a reportable error. The master's reaction to ERR is supplier-defined, so the master's datasheet must say what it does.

And the hard part, which is what separates a senior answer: the late response. You timed out, you synthesised ERR, the master moved on — and the peripheral wakes up and asserts ACK. Now there is a termination on the bus for a phase that no longer exists. You need a drain or lockout state that absorbs it, and you need to decide whether the peripheral is quarantined afterwards or allowed to rejoin.

Observability, finally: record which target timed out and at what address. A watchdog that only reports something hung has converted a debuggable failure into an undebuggable one.

Say plainly which parts are protocol and which are yours. All of the above is yours.

6. Scenario E — What Would Convince You It Is Ready

The interconnect is written and the tests pass. Would you sign it off?

This question is looking for a layered argument, and it is failed by any answer that collapses into a single number — "100% functional coverage" most of all.

Layer 1 — legality. Protocol checks at more than one boundary. Chapter 27.3 measured the same RULE 3.60 property reporting 0 failures at the master port and 5 at the slave boundary on the same run; both were right. A checker at one boundary is a checker for one region.

Layer 2 — function. An independent reference model and a scoreboard. Independent means written from the interface contract, not from the RTL — a model that copies the design's own arithmetic agrees with its bugs.

Layer 3 — the things no rule covers. Decode ownership, swept over window boundaries rather than typical addresses; response provenance; side-effect counts. These are your local policy, so nothing catches them unless you wrote the check.

Layer 4 — regimes. Every functional test at zero, one and several wait states. The architectural result must be identical; a class of defect is structurally unable to exist at zero latency, so a suite that only runs there has not tested the design, it has avoided it.

Layer 5 — negative controls. For each detector, a deliberately broken variant that proves it can fail. A checker nobody has ever seen fire is a checker nobody has tested. And at least one of those broken variants should be a testbench defect that indicts a correct design, because that is the failure mode that costs the most hours.

Layer 6 — sensitivity, not coverage. Bins record that a situation occurred. Prove the stimulus could have told the difference: seed non-zero data, use non-idempotent locations, make the correct and incorrect behaviours produce different observable values.

Layer 7 — reproducibility and observability. Deterministic regression, and enough recorded state to debug a failure without re-running it: at minimum, which target was selected per transfer and which master each response went to. Neither is recoverable from the interface afterwards, and both are free at design time.

Then the answer that makes it a judgement rather than a checklist: "what I would still be uneasy about is X, and here is the experiment I would run to close it." Sign-off is a risk statement, not a ceremony.

7. The Review

Here is the return path of a four-initiator interconnect. Responses are multiplexed by the current grant. Review it.

A design review is not a list of generic concerns. It is what this design makes possible.

PROTOCOL. Each port can be individually conformant while the system is wrong — so say which rules this structure cannot break, and stop claiming those. It cannot violate RULE 3.45 by muxing. It can violate RULE 3.60 downstream if the mux changes what a target sees mid-phase.

OWNERSHIP. This is the finding. If grant can change before a response returns, the mux delivers that response to whoever is granted now. Chapter 27.4 measured 99 misdeliveries with zero specification violations. The fix is not a bigger mux — it is to make provenance stateful: latch the owner when the phase opens and route the response by the latched value, not the live grant.

FAILURE. A target that never terminates holds the grant forever under any grant-follows-CYC arbiter. Scenario D applies.

PERFORMANCE. Combinational muxing of four responses is a wide path in series with whatever the targets already cost; if termination is also combinational this is the loopback path OBSERVATION 3.50 warns about, four-way.

VERIFICATION. The provenance bug is invisible to every protocol check and to any scoreboard watching a single master. It needs a check comparing response destination against latched owner — which means the interconnect must expose the latched owner.

DEBUG. If it does not expose it, the bug is unfixable from outside. Ask for the wire.

That is six headings arising from one structural fact. Module 30 is where the reusable review checklist belongs; this is how you review when you do not have one.

8. What Makes An Answer Senior

Not vocabulary, and not more facts. Four habits:

• Naming the missing requirement, then choosing anyway. Stopping at the question is indecision; skipping it is guessing.
• Separating specification from policy in every sentence. "Wishbone requires" is a claim you can be wrong about in front of someone who has read it.
• Saying which half you measured. One clock per transfer, measured. Frequency, not measured, and no synthesis was run.
• Offering the conditions under which you would choose differently. An architecture defended without its failure envelope has not been defended.

An answer that ends "…and I would change that if the traffic mix turned out to be X" is stronger than one that ends in certainty, because the second one is usually wrong and always unfalsifiable.

9. What To Carry Forward

• Underspecified is the normal state. Name the gap, assume explicitly, solve, and state how the answer moves.
• Topology follows the concurrency you actually need, not the diagram that looks most capable.
• Registered termination costs one clock per transfer here and buys a broken combinational loop whose value only synthesis can tell you.
• A DMA losing the bus is not an error. What survives it is the design.
• A hang is a system problem, not a protocol violation — and the late response is the part people forget.
• Sign-off is a layered argument ending in a risk statement, never a coverage number.
• Provenance must be latched, not muxed by live grant.

Module 28 ends here. Everything in it was reconstructed from the protocol and from measurements this curriculum ran — which is the only preparation that survives a follow-up question.