Give every waiting requester a turn

An arbiter may grant access to only one requester and still be unfair. A persistent request test exposes starvation in a fixed priority variant.

Open the repository on GitHub

Checks passed

Public demonstration

This is not a client result. The recorded command and check status appear below.

Recorded outcome

The correct arbiter passes all fifteen configurations. The fixed priority variant fails the persistent requester test. The waiting bound is measured in accepted grants, so a stopped receiver does not imply a promise of progress in clock cycles.

What was checked

Problem: Checking that two requesters never win together does not show that every requester eventually gets service. A fixed priority design can keep serving the same requester while another waits.
Scope: An original round robin arbiter with explicit grant and acceptance signals. The matrix tests 1, 2, 3, 4, and 7 requesters with seeds 1, 17, and 2026. The directed fairness scenario keeps all contenders active.
Approach: Tests check grant eligibility, mutual exclusion, rotation after acceptance, stalled priority, and reset. With all requests held active, the last requester must receive a turn within the configured number of accepted grants. A deliberate fixed priority variant fails this requirement.
Evidence: The repository retains the named starvation failure, passing configuration logs, tool versions, source hashes, commands, and process times. Runner tests reject timeouts, unrelated assertions, and misleading result markers. Default RTL synthesis was checked separately.

Scope and limits

What these checks do not establish.

This is original educational RTL and a deliberately unfair comparison, not a client result.
The fairness test holds all contenders active and assumes grants continue to be accepted. It is not a proof over every request pattern.
A stalled receiver can delay service indefinitely in clock cycles. The tested bound counts accepted grants.
This is finite simulation evidence, not formal verification, production sign off, or a performance guarantee.

Reproduce and inspect

Recorded verification status

Rerun from public GitHub revision 049b015 on 15 September 2026 with Python 3.9.6 and Icarus Verilog 13.0. Fifteen correct configurations pass and the fixed priority mutant fails the named starvation test. Eight runner regression tests also pass.

Recorded commandround-robin-verification

git clone https://github.com/Rivoryxa-Technologies/round-robin-verification
cd round-robin-verification
# Install Python 3.9+ and Icarus Verilog first.
make test

Filesrtl/round_robin_arbiter.svrotating priority implementationrtl/fixed_priority_mutant.svdeliberately unfair comparisontb/arbiter_tb.svsafety, rotation, and starvation checkstools/run.pyreproduction and measured resultsrecorded/2026-09-15/reviewed logs and source hashes

Next steps

Service: Bug reproduction and root cause Service: Simulation environments Other examples

Want this method on your design?

Share the problem in a few lines. We will discuss the scope before any confidential project material changes hands.

Discuss a verification problem