You've seen round-robin arbiters that give every requester an equal turn, and priority arbiters that always favor the lowest-numbered port. Real chips need something in between: an arbiter that gives Port A 50% of the bandwidth, Port B 30%, and Port C 20%, even though all three are hammering requests at 100% duty cycle. This is what weighted arbitration solves.

Fixed-priority is the trivial baseline: a priority encoder picks the lowest-index active request every cycle. Cheap (log-depth OR tree), zero state, but Port N starves whenever Port 0 stays busy. Only usable when high-priority traffic is bursty and provably bounded — think NMI handlers or refresh requests to a memory controller.

Weighted Round-Robin (WRR) extends round-robin by giving each port a credit counter. When Port i wins a grant, its counter decrements. When all active ports hit zero, the counters reload to their programmed weights. If Port A's weight is 5 and Port B's is 2, Port A gets 5 consecutive grants, then B gets 2, then reload. Simple, but bursty — B waits 5 cycles before seeing service, which trashes latency-sensitive traffic.

Deficit Round-Robin (DRR) is the fix. Each cycle, add a quantum to every active port's deficit counter. Grant the port whose deficit exceeds the packet size (or just 1 for single-cycle grants). Traffic gets interleaved — A, B, A, A, B, A, A — instead of clumped. DRR is work-conserving (never idles the shared resource if any port has a request) and provides bounded fairness within O(quantum) cycles.

Real example: Cisco's Nexus switch line cards use DRR on their VOQ (Virtual Output Queue) schedulers. Each ingress port has 8 traffic classes (voice, video, control, best-effort, etc.), and DRR weights are set per class so voice gets ~40% of egress bandwidth even under congestion, while best-effort gets whatever's left. AMD's Infinity Fabric arbiters between CCX-to-memory-controller traffic use a similar weighted scheme so GPU traffic doesn't starve CPU cache-line fills.

Rule of thumb for weight sizing: the maximum service latency for port i is roughly (sum of all other weights) / weight_i grant cycles. So a port with weight 1 in a system where other weights sum to 15 waits up to 15 cycles between grants. If that violates your latency SLA, either bump the weight or add a strict-priority tier on top for the latency-critical traffic and DRR for the rest — the standard "hierarchical scheduler" pattern.

Cost: DRR needs one adder + one comparator + one counter per port, plus a priority encoder to pick the winner among ports whose deficit exceeded threshold. Typically 100–200 gates per port at reasonable weight resolution (8 bits).