Bus Arbitration Calculator

Inputs

Use realistic bursts and overhead from your platform.

Bus frequency (MHz)

Clock rate used for bus transfers.

Bus width (bits)

Effective data width per cycle.

Number of masters

Agents requesting bus ownership.

Arbitration scheme

Choose a common arbitration policy.

Arbitration overhead (cycles)

Grant decision + control handshakes.

Turnaround (cycles)

Bus idle or direction change cost.

Average burst size (bytes)

Average payload per grant.

Request rate per master (req/ms)

Approximate request arrivals per millisecond.

Priority skew (0–100)

Used only for fixed priority modeling.

Reset

Formula used

Cycle time (ns) = 1000 / f(MHz)
Bytes/cycle = bus_width_bits / 8
Capacity (B/s) = f(Hz) × bytes/cycle
Data cycles = ceil(burst_bytes / bytes/cycle)
Service cycles = overhead + turnaround + data
Offered load (B/s) ≈ masters × req/s × burst_bytes
Utilization ≈ offered / capacity
Avg wait ≈ (N−1)/2 × (guard+1) × g(util)
Grant latency (ns) = wait_cycles × cycle_time
Jain fairness = (Σx)² / (n·Σx²)

The wait model is a practical approximation for early sizing.

How to use

Enter bus frequency and effective data width.
Set masters that can request ownership.
Choose your arbitration policy.
Provide overhead and turnaround from your timing.
Enter an average burst size from traces.
Estimate request rate per master for load.
Press Calculate to see latency and fairness.
Export CSV or PDF for reviews and tracking.

Example data table

Scenario	Masters	Scheme	Bus (MHz / bits)	Burst (bytes)	Overhead+Turn (cycles)	Utilization (%)	Avg grant (ns)
Balanced traffic	4	Round-robin	200 / 64	64	3	55	~30
Priority favored	6	Fixed priority	150 / 32	128	4	78	~120
Noisy contenders	8	Lottery	100 / 128	256	2	62	~95

Example values are illustrative and depend on platform timing.

Arbitration goals in shared buses

Bus arbitration converts many simultaneous requests into one safe transfer stream. Designers target three outcomes: predictable latency, high usable bandwidth, and fair access. The calculator estimates grant delay from masters, overhead, and turnaround, then relates that delay to clock period so teams can compare architectures on a common time scale. It reports per master share during sizing.

Relating burst size to service time

Service time is dominated by payload cycles when bursts are large, but control costs dominate small bursts. Data cycles equal ceil(burst bytes divided by bytes per cycle). Total service cycles add arbitration overhead and turnaround. Increasing bus width reduces data cycles, while increasing frequency reduces cycle time, improving both throughput and latency. If your protocol inserts wait states, fold them into overhead so the estimate tracks measured transactions.

Load, utilization, and saturation signals

Offered load is approximated as masters × request rate × burst size. Dividing by bus capacity yields utilization. When utilization approaches 100%, small changes in request rate can create large queueing delays, even if average throughput remains close to capacity. The utilization panel helps spot risky operating points early. For healthy headroom, many teams target sustained utilization below about 70% and reserve the rest for bursts and interrupts.

Policy tradeoffs: fairness versus priority

Round-robin and lottery policies tend to equalize long run bandwidth shares. Fixed priority improves response for urgent masters but can starve low priority agents during heavy contention. The modeled Jain fairness index summarizes equality, while the starvation risk flag highlights configurations where skew and high load combine to create repeated deferrals. If you must use priority, consider adding aging or maximum grant streaks to keep tail latency bounded.

Using results to guide design reviews

Start with measured overhead and turnaround from your bus protocol, then sweep burst sizes from trace statistics. Compare average and worst grant latency across schemes, and verify that throughput at expected load meets margin. Export CSV for spreadsheet plots and PDF for review packets, keeping assumptions visible for every stakeholder. Finally, rerun with peak request rates from stress tests to validate that low priority paths still meet functional progress and watchdog limits.

FAQs

What does “grant latency” represent?

Grant latency is the time from a request becoming eligible until the master receives ownership. It is modeled in cycles and converted to nanoseconds using the bus clock period.

Why do overhead and turnaround matter so much?

They consume cycles without moving payload data. When bursts are small, these fixed costs can dominate service time, reducing effective bandwidth and increasing per-transaction delay.

How accurate are the wait and worst-case estimates?

They are sizing approximations meant for early trade studies. Actual latency depends on traffic correlations, protocol rules, and buffering; validate final numbers with simulation or hardware measurements.

When should I use fixed priority arbitration?

Use it when a specific master must meet tight deadlines and can preempt others. Add safeguards such as aging, quotas, or maximum consecutive grants to reduce starvation under load.

What does a Jain index near 1.0 mean?

It indicates bandwidth shares are nearly equal across masters over the measured window. Lower values suggest some masters receive consistently more service than others.

How should I choose a realistic request rate?

Derive it from workload traces or bus monitors. Convert observed transactions per second into requests per millisecond per master, and include peak phases rather than only long-run averages.