Why can't all the information be encoded into just one bus lane?
jkorn
@williamx You have one bit per wire. Logically you can think of this as a "status bus" composed of 3 wires for a shared signal, a dirty signal, and a snoop-pending signal. You need a separate wire for each signal or else they would all get muddled into one single resulting bit - 0 or 1. You can't extract any useful information from that (is it 0 since nothing is dirty, or since all processors have responded to the snoop request?).
googlebleh
@jkorn In this case, that's a good abstraction, but it's worth noting that buses don't have to be just wires that we read off of.
In class, I don't think we did the concept of a "bus" full justice. The abstraction of a bus just allows us to think "oh, this is a communication line that touches several nodes along the way, and they can all communicate along it," but in practice, the bus doesn't have to be implemented as "one wire per signal." For example, CANBus is made up of two wires, and can encode more than 2^2 bits of data.
The notion of "one bit per wire" is usually known as a parallel bus, whereas there exist serial buses that can encode more than one bit per wire, but still maintain the same capability for many nodes to communicate using the same hardware connection.
jkorn
Yep, that makes sense. On a serial bus you can send a different bit per few clock cycles (whatever the propagation delay is). But here, we need a result that indicates the status of all processors at once, which motivates the use of a parallel bus instead of a serial bus.
Why can't all the information be encoded into just one bus lane?
@williamx You have one bit per wire. Logically you can think of this as a "status bus" composed of 3 wires for a shared signal, a dirty signal, and a snoop-pending signal. You need a separate wire for each signal or else they would all get muddled into one single resulting bit - 0 or 1. You can't extract any useful information from that (is it 0 since nothing is dirty, or since all processors have responded to the snoop request?).
@jkorn In this case, that's a good abstraction, but it's worth noting that buses don't have to be just wires that we read off of.
In class, I don't think we did the concept of a "bus" full justice. The abstraction of a bus just allows us to think "oh, this is a communication line that touches several nodes along the way, and they can all communicate along it," but in practice, the bus doesn't have to be implemented as "one wire per signal." For example, CANBus is made up of two wires, and can encode more than 2^2 bits of data.
The notion of "one bit per wire" is usually known as a parallel bus, whereas there exist serial buses that can encode more than one bit per wire, but still maintain the same capability for many nodes to communicate using the same hardware connection.
Yep, that makes sense. On a serial bus you can send a different bit per few clock cycles (whatever the propagation delay is). But here, we need a result that indicates the status of all processors at once, which motivates the use of a parallel bus instead of a serial bus.