Interview Question · Code Reading
A Fixed-Priority Arbiter Under Load
The Question
The interviewer asks
Requester 0 asks on every other cycle and requester 3 asks every cycle, for 100 cycles. How many grants does each get from this arbiter?
module arb_fixed (input logic [3:0] req, output logic [3:0] gnt);
always_comb begin
gnt = 4'b0000;
if (req[0]) gnt = 4'b0001; // requester 0 always wins
else if (req[1]) gnt = 4'b0010;
else if (req[2]) gnt = 4'b0100;
else if (req[3]) gnt = 4'b1000;
end
endmodule
You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Requester 0 wins every cycle it asks, so it gets 50 grants. Requester 3 wins only in the cycles where requester 0 is quiet, which is the other 50. The if-else chain is a priority encoder: each later branch is reached only when all earlier requests are low. If requester 0 asked every cycle, requester 3 would get nothing.
- Cycle 0
Cycle e2: all four ask. The lowest request wins, so
grantis 0001. - Cycle 1
Cycle e3:
readyis 1, so requester 0 makes its transfer at edge 4. - Cycle 2
Cycle e4: requester 0 asks again at once and wins again. Requesters 1 to 3 never see a grant.
Measured in lesson R5.4 on a different bench: all four requesters ask every cycle. Requester 0 makes all 8 transfers, and the others never get a grant.
The arbiter for 100 cycles: requester 0 on even cycles, requester 3 always.
r0 every other cycle, r3 always: grants r0=50 r1=0 r2=0 r3=50Self-Check
Tick each key point you covered in your answer.
What Interviewers Listen For (Fresher)
A good fresher answer walks the if-else chain one branch at a time and gets 50 grants for each requester. It also says what happens if requester 0 never stops asking.
What Interviewers Listen For (Junior)
A good junior answer names the problem: starvation, where a low-priority requester never gets a turn. It asks how often the top requester may ask, and offers round robin or a request limit as the fix.
Cross-Questions
Where the interviewer goes next. Open a node to practise that follow-up.
WhyWhat IfProve ItCompareScale It
- A Fixed-Priority Arbiter Under Load
-
WhyThe Arbiter as a Priority EncoderL0 FresherL1 Junior
Why is a fixed-priority arbiter the same as a priority encoder, and how can you write it without a chain of ifs?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Both pick the lowest-numbered active input. In two's complement,
req & -reqkeeps only the lowest set bit, which is exactly the grant. Synthesis gives about the same gates for either form, so choose the one the team reads most easily.Self-Check
Tick each key point you covered in your answer.
Misconception
"
req & -reqgives the highest requester."Negating flips every bit above the lowest 1 and keeps that 1. The AND leaves only the lowest set bit.
Source Sutherland, RTL Modeling with SystemVerilog (2017) ch. 5.12 Arithmetic operators
-
Prove ItSolve R1.5.1: A Priority Encoder with a Collision FlagSimulator-graded
Show it, don't just say it: this Silicon Lab problem is graded by the simulator.
-
CompareFixed Priority Versus Round RobinL1 Junior
Compare fixed priority with round robin. When would you choose each?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Fixed priority is tiny, has no state, and gives a guaranteed fast response to the top requester. But it can starve the rest. Round robin needs a little state and gives each active requester a turn within N grants. Use fixed priority for rare urgent requests and round robin for peers that share a resource.
Self-Check
Tick each key point you covered in your answer.
Half-Truth
"Round robin guarantees each requester the same latency."
It bounds the wait to N - 1 other grants. The actual latency depends on how long each of those grants holds the resource.
Source Lesson P1.9, Arbitration, fairness and atomic access (round robin bounds every requester's wait; fixed priority is fair only for the top requester)
-
Scale ItMixing Urgent and Normal RequestersL2 Mid-Level
You have one urgent requester and eight normal ones. How would you combine the two schemes?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Use two levels. The urgent requester has fixed priority over a round robin of the eight. To stop it from starving everyone, limit it. Use a maximum request rate, or let one normal grant through after a few urgent ones. Then you can state a worst-case wait for both classes.
Self-Check
Tick each key point you covered in your answer.
Missed Corner
"Give the urgent one priority; it rarely asks."
"Rarely" must be a number in the spec. If the urgent source can misbehave, the others starve with nothing to stop it.
Source Lesson P1.9, Arbitration, fairness and atomic access (round robin bounds every requester's wait; fixed priority is fair only for the top requester)
-
What IfA Registered GrantL1 JuniorL2 Mid-Level
Asked if the grant drives a long path
What if the grant must come from a flop because it drives a long path?
2:30You have two and a half minutes. Speak or type, then press Get Feedback under your answer. No credits needed.
Speech-to-text runs in your browser. Chrome and Edge may send audio to their own speech service.
You can edit your answer before you send it. Feedback uses AI and checks your answer only against our written answer. No credits are used and your answer is not saved.
Reveal the Model Answer
Register the grant, so it is valid one cycle after the request. The requester must then hold its request until it sees the grant. The arbiter must not grant a requester that has already dropped its request. Latency grows by a cycle, which matters for short transfers.
Self-Check
Tick each key point you covered in your answer.
Half-Truth
"A registered grant is the same arbiter, one cycle later."
The request may change during that cycle. The arbiter can then grant a requester that no longer wants it, and a cycle is wasted.
What People Get Wrong
Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.
Misconception
"The low-priority requester still gets a turn when the others finish."
Only if they ever finish. A high-priority requester that asks every cycle wins every cycle. The twin shows requester 3 with zero grants.
Run It
Requesters 0 and 3 both asking every cycle: fixed priority, then round robin.
fixed priority, r0 and r3 always: grants r0=100 r1=0 r2=0 r3=0 FAIL: requester 3 never got a turn; fixed priority starves itSee the Fix
// Round robin with a mask: after a grant, only requesters above the winner may win next.
module rr4 (input logic clk, rst_n, input logic [3:0] req, output logic [3:0] gnt);
logic [3:0] mask, masked;
assign masked = req & mask;
always_comb
if (masked != 0) gnt = masked & (~masked + 4'd1); // lowest requester above the last winner
else gnt = req & (~req + 4'd1); // nobody above: wrap to the lowest requester
always_ff @(posedge clk or negedge rst_n)
if (!rst_n) mask <= 4'b1111;
else if (gnt != 0) mask <= ~((gnt << 1) - 4'd1); // bits above the winner only
endmodule
module tb;
logic clk = 0, rst_n = 0;
logic [3:0] req = 0, gnt;
int n0, n1, n2, n3;
always #5 clk = ~clk;
rr4 dut (.clk(clk), .rst_n(rst_n), .req(req), .gnt(gnt));
task automatic run(input string name, input int which);
n0 = 0; n1 = 0; n2 = 0; n3 = 0;
for (int c = 0; c < 100; c++) begin
@(negedge clk);
if (which == 0) req = 4'b1001;
#1 n0 += gnt[0]; n1 += gnt[1]; n2 += gnt[2]; n3 += gnt[3];
end
$display("%s: grants r0=%0d r1=%0d r2=%0d r3=%0d", name, n0, n1, n2, n3);
endtask
initial begin
#12 rst_n = 1;
run("round robin, r0 and r3 always", 0);
if (n0 == n3) $display("PASS: round robin gave requesters 0 and 3 equal turns");
$finish;
end
endmodule
Prints: round robin, r0 and r3 always: grants r0=50 r1=0 r2=0 r3=50 PASS: round robin gave requesters 0 and 3 equal turns
Half-Truth
"Fixed priority is bad design."
It is the right choice when a requester must always win, such as an interrupt or a refresh. It needs a limit on how often that requester asks.
Source Lesson P1.9, Arbitration, fairness and atomic access (round robin bounds every requester's wait; fixed priority is fair only for the top requester)
Misconception
"An if-else chain synthesizes to a long chain of gates, so a case statement would be faster."
Here the chain is 5 cells and 2 levels. Synthesis keeps the priority only where items can overlap, whatever the keyword.
Source Sutherland, RTL Modeling with SystemVerilog (2017) ch. 7.4 Combinational logic decision priority