Encoders and priority: choose one of several requests

Encoding needs an input contract

A decoder^{idecoder A circuit activating the output corresponding to an input code. An enable can force all outputs inactive. Learn more} maps an address to a one-hot^{ione-hot An encoding with exactly one bit set. If all-zero is also permitted, the condition is one-hot-or-zero. Learn more} selection. An encoder maps an active input back to an address. A simple one-hot encoder assumes at most one active input; multiple requests require an explicit selection policy.

For requests $r_3r_2r_1r_0$, choose the highest index. Use valid=0 and index=00 for no request. Index=00 alone cannot distinguish no request from request r0.

A dash means either binary value gives the same result, not that a simulation X is permitted.

An RTL if/else chain from request[3] down to request[1], with index defaulting to zero, makes priority explicit. Compute valid separately as OR reduction of all requests. Test all 16 combinations: a valid selection must point to an asserted request, with every higher request clear.

Fixed priority is not fairness. A permanently asserted r3 can starve r0. Fair arbitration requires a policy that usually remembers prior grants.

Lab · Observe request, selected address and grant together

With the initial request 1011, r3 wins. Turn it off: r1 wins with index=01 and grant=0010. Toggling r0 must not change that selection while r1 remains asserted.

Compare Clear all with enabling only r0. Both give index=00, but their valid and grant values differ. A consumer that reads index alone could process a nonexistent request.

Decode index together with valid to obtain a one-hot-or-zero grant:

Check three invariants: at most one grant is asserted, every granted position has an active request, and all requests above the selected position are zero. This lab does not consume requests or remember prior grants. A continuously asserted r3 can keep lower requests waiting: that is a property of fixed priority.