Four request lines in, a 2-bit index out — the highest-priority one wins. A ready-made fun circuit you can open in the TorchAnvil simulator.
Four sources all want attention at the same time. You can only deal
with one. Which do you pick? A priority encoder answers that
question in hardware: it takes a bunch of request lines, decides which
is the most important one that's currently active, and reports its
index as a binary number. Here we've got inputs I0 through I3 —
with I3 the loudest, I0 the quietest — and two output bits Y1 Y0
that spell out the winner's number.
For a 4-input encoder the priority logic simplifies to a surprisingly small expression:
I1 or I0), Y1 stays
at 0.I3 and
for I1, but only if I2 isn't stealing the show. The
AND !I2 part is what makes this an honest priority encoder instead
of a plain encoder; it's how we force I1 to shut up when I2 is
loud.| I3 | I2 | I1 | I0 | Y1 | Y0 | winner |
|---|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 | 0 | (none) |
| 0 | 0 | 0 | 1 | 0 | 0 | I0 |
| 0 | 0 | 1 | x | 0 | 1 | I1 |
| 0 | 1 | x | x | 1 | 0 | I2 |
| 1 | x | x | x | 1 | 1 | I3 |
(The x marks really do mean "don't care" — once a higher input is
on, the lower ones are ignored.)
Note that Y1 Y0 = 00 collides with "I0 active" and "no input active."
Real encoders add a valid output line to tell them apart; we've
left that off to keep the gate count small.
Operating-system interrupt controllers work exactly like this. When a dozen devices are all shouting for the CPU's attention, a priority encoder picks the most important request and tells the processor its number — so the CPU can jump to the right handler without polling anyone. Bus arbiters, elevator-call panels, game-show buzzers with a ranking of contestants — wherever "whichever is most important, name it in binary" is the job, this is the shape of the answer.
Y1 Y0 = 00, meaning "I0."01 —
I1 outranks I0, so I0 is ignored.10. Now flip I1 too; nothing
changes, because I2 is already drowning it out.11 no matter what else is on.