A priority encoder produces a binary code for the highest-priority asserted input. It differs from a plain encoder because several inputs may be 1 at the same time; the priority rule decides which one controls the output. That rule must be built into the truth table before using a K-map. If the table treats lower-priority inputs as independent requests, the minimized equations may encode the wrong input.
This guide designs a 4-to-2 encoder with D3 as the highest priority and D0 as the lowest. We derive the two output bits and a valid signal, show how the 16 input combinations collapse into four meaningful priority cases, and minimize each Boolean output. The result is a compact set of equations that can be checked directly against the priority behavior.
Define the priority rule
Let the inputs be D3,D2,D1,D0, where D3 has the highest priority. The encoder output is a two-bit code Y1Y0. If D3=1, output 11 regardless of the other inputs. Otherwise, if D2=1, output 10. Otherwise, if D1=1, output 01. If none of those is active and D0=1, output 00. Add a valid output V that is 1 whenever at least one request is active.
Writing the priority cases in words is useful, but the hardware needs an explicit truth table. Each higher-priority condition masks the lower inputs. For example, when D3=0 and D2=1, the output must be 10 even if D1 and D0 are also 1. When D3=D2=0 and D1=1, D0 no longer matters. Only when D3,D2,D1 are all 0 does D0 determine whether a request is valid.
| Winning condition | Y1Y0 | V | Inputs that do not affect the result |
|---|---|---|---|
| D3=1 | 11 | 1 | D2,D1,D0 |
| D3=0, D2=1 | 10 | 1 | D1,D0 |
| D3=0, D2=0, D1=1 | 01 | 1 | D0 |
| D3=D2=D1=0, D0=1 | 00 | 1 | None |
| D3=D2=D1=D0=0 | 00 | 0 | None |
The last two rows both show code 00, but V distinguishes them. Without a valid output, a downstream circuit cannot tell whether D0 was selected or no request existed. If the interface specification says that code 00 means D0 even when V=0, that is still a well-defined electrical value; the valid bit communicates whether the code should be consumed.
Build a priority-aware truth table
For a four-variable K-map, use variable order D3,D2,D1,D0, with D3 as the most significant bit. The output functions are 1 on these minterm sets:
| Function | On-set minterms | Reason |
|---|---|---|
| Y1 | 4 through 15 | The winning input is D2 or D3 |
| Y0 | 2, 3, and 8 through 15 | D1 wins when D3=D2=0; D3 forces the low code bit high |
| V | 1 through 15 | At least one request is asserted |
Y1 is 0 only when D3=0 and D2=0, independent of lower inputs. Y0 is 1 when D3 is 1, or when D3=0,D2=0,D1=1. The expression may be written without the explicit D3=0 condition in the second case because D3 already forces Y0=1; the term D3 absorbs the overlap. The valid output is simply the OR of all requests.
Derive the valid output
V is 0 only for input 0000 and 1 for every other input combination. On the four-variable K-map, the fifteen 1-cells form the standard OR function. The minimized equation is:
If the gate library limits fan-in to two, implement this four-input OR as a tree, for example T0=D3+D2, T1=D1+D0, and V=T0+T1. A device may provide a four-input gate or absorb the function into a larger cell. The Boolean equation and the physical gate decomposition are related but distinct design decisions.
Sometimes an interface uses a separate `valid` or `enable` input and expects the encoder to ignore requests while disabled. In that case, V and the code outputs must incorporate that enable condition according to the interface timing. Do not simply AND the final V if the code bits must also be forced to a known value while disabled; define those rows in the truth table.
Minimize the encoded outputs
Y1 is true whenever either D3 or D2 is 1. On the K-map, the cells with D3=1 form an eight-cell group, and the cells with D2=1 form another eight-cell group. Their union is the on-set, giving:
Y0 is true across all rows where D3=1, regardless of the other inputs. That is an eight-cell group giving D3. It is also true for D3=0,D2=0,D1=1, regardless of D0; those two cells form a pair giving D1D2′ when the D3=0 part is considered. The expression D3+D1D2′ includes the intended rows. It also includes the rows D3=1,D2=1, which are already in the D3 group and require Y0=1. The minimized equation is:
There is no need to include D3′ in the second product term. By absorption, D3 + D3′D1D2′ = D3 + D1D2′. This is a useful example of an expression that includes overlapping coverage without changing the output. The priority condition is preserved because when D2=1 and D3=0, D2 prevents the D1 term from asserting the low code bit.
Combine the results: Y1=D3+D2, Y0=D3+D1D2′, V=D3+D2+D1+D0. Check the four winning cases: D3 yields 11; D2 with D3=0 yields 10; D1 with D3=D2=0 yields 01; D0 alone yields 00. The equations encode the selected input index, not a one-hot output.
Check simultaneous requests
Testing only one-hot input rows is not enough for a priority encoder. Check combinations with multiple active inputs. For D3D2D1D0=0111, D3=0 and D2=1, so the output is 10, V=1. The equations give Y1=0+1=1 and Y0=0+1·0=0. For 1010, D3=1, so the output is 11; both equations produce 1. For 0011, D1 wins over D0, so output 01; Y1=0 and Y0=1·1′=1.
Also check the no-request condition 0000. All three equations produce 0, including V. The code 00 is electrically present, but V=0 marks it invalid. If a consumer ignores V, it may mistakenly treat no request as D0. The downstream contract should require checking V before acting on Y1Y0.
An exhaustive truth-table script or a truth-table solver can compare the equations against all 16 combinations. Keep the variable order explicit. With D3 as the most significant bit, minterm 8 is 1000, where D3 alone is active; a reversed order would place that case at a different index even though the physical input names have not changed.
Variants and don’t-cares
Some encoders define output bits as don't-cares when V=0 because the consumer is required to ignore them. That is an interface-level permission, not a universal property. In this design, the equations already give 00 when all inputs are zero. If an implementation uses the invalid row as an X, it may choose other values that reduce logic, but the valid bit must be observed downstream.
Priority may be reversed or assigned in a custom order. If D0 has highest priority, rewrite the winning conditions and derive new on-sets; do not merely swap the output bits. For an eight-input encoder, the output width grows to three bits and each bit represents a different partition of the winning index. A hierarchical encoder can combine smaller blocks, but block-valid signals must themselves be prioritized correctly.
Active-low request inputs need explicit polarity conversion. If a pin is low when asserted, define logical request variables after inversion or use a truth table whose 0 values mean active. Mixing active-low pins with active-high equations is a common integration error. Likewise, a registered encoder adds clocked behavior and changes when the output code becomes available.
Implementation and verification
The equations can be implemented with AND/OR/NOT gates, NAND gates, a small ROM, or a programmable logic block. A synthesis tool may factor the output logic or share intermediate terms. Check the mapped design for timing and fan-in limits if the encoder is on a critical path. A priority chain written as nested conditions may synthesize differently from the parallel Boolean equations, so inspect the actual result when speed matters.
If the encoder feeds an arbiter or bus grant, the priority order is part of system policy. A permanently highest-priority request can starve lower-priority requests. Round-robin arbitration requires state that changes the priority order; it is a sequential design, not a fixed combinational priority encoder. K-maps simplify one fixed priority decision but do not solve fairness by themselves.
Design checklist
- State the priority direction. Identify the highest and lowest request explicitly.
- Define output behavior for no request. Include a valid signal if needed.
- Expand priority conditions into a truth table. Higher inputs mask lower ones.
- Map each output separately. Keep the input variable order consistent.
- Use don't-cares only when the interface allows them. Document how V is consumed.
- Verify multiple active requests. These rows are what distinguish priority encoding from ordinary encoding.
- Check polarity, reset, and timing. Consider the surrounding interface.
The four-to-two example reduces to three clear equations. The key work is defining the behavior before simplifying: the K-map can only preserve the priority truth table it receives. Once simultaneous requests, invalid output codes, and input polarity are explicit, minimization becomes a straightforward Boolean task.
Priority is different from arbitration
A combinational priority encoder always chooses according to a fixed order. If D3 remains asserted, it continues to win on every evaluation, so a lower input may wait indefinitely. A bus arbiter that promises fairness needs changing priority state, such as a rotating pointer, and therefore has sequential behavior. The fixed equations in this guide are only the combinational encoding stage after the policy has selected a winner.
If the encoder feeds a grant generator, keep request and grant meanings separate. The encoder output identifies a winning index; the grant logic may need to produce a one-hot enable or acknowledge only after the resource is available. Verify the complete interface under simultaneous requests, including whether requests are held until accepted and whether the winner can change during a transaction.