# Why do we use a MUX rather than tristate buffers to implement a bus?

Consider a small digital system consisting of registers connected to a bus interconnection network. It is well-known that the output to the bus can (functionally) be implemented either with tristate buffers at each register output (first picture below), or with MUXes to choose what drives the bus at any given instant (second picture below).

The pictures above are from Chapter 7.1 of my digital logic textbook, Fundamentals of Digital Logic by Brown and Vranesic.

My textbook (Weste and Harris's CMOS VLSI Design) gives the following discussion of why MUXes (presumably) is now preferred to tristate buffers in order to implement such a bus:

Tristates were once commonly used to allow multiple units to drive a common bus, as long as exactly one unit is enabled at a time. (1) If multiple units drive the bus, contention occurs and power is wasted.

(2) If no units drive the bus, it can float to an invalid logic level that causes the receivers to waste power.

(3)Moreover, it can be difficult to switch enable signals at exactly the same time when they are distributed across a large chip. Delay between different enables switching can cause contention.

Given these problems, multiplexers are now preferred over tristate busses.

I have inserted the bracketed numbers in the above, and my question is about understanding each of the claims. In each case I ask a question about the issue with the tristate implementation as well as a question about how the MUX implementation avoids said issue.

(1) Tristate: Why would multiple signals ever be driving the bus? Surely the control circuit is always such that only one of the $$\Rj_{out}\$$ signals is asserted at a time?

MUX: I guess the idea is that with a MUX implementation one only spends the dynamic power associated with switching?

(2) Tristate: I am not sure I follow what's meant by "causes the receivers to waste power". Why would this be the case? Surely the registers are "gated" as per the L (Load) inputs in the images such that no data is clocked into the registers when these signals are low. Do you think Weste and Harris are assuming there is no such gating and that this floating somehow means that if the bus floats to a value far enough to be recognized as a different logic value on the D inputs than is currently on the Q inputs of the given flip-flop, that we would have an incorrect overwrite? I don't think this is what they mean though because they talk about power and not about logic values being overwritten, so perhaps I am missing something and there is an issue even with this L gating.

MUX: Why is there no issue with the MUX implementation here? I guess the implementation I have given always has some fixed output from one of the Rj on the bus so that it's never floating, so we can therefore never affect the registers if we have gating? Is there any issue with always having some fixed output on the bus rather than letting it float?

(3) Tristate: Is the idea here basically analogous to (1) in that if an enable signal $$\Rj_{out}\$$ which is being shut off remains on long enough due to delay that the next enable signal $$\Ri_{out}\$$ has already been asserted, then if the data to be driven onto the given bus wire is different between the two register's outputs $$\Qi,Qj\$$ (I think we must assume this because if they're trying to drive the same signal onto the bus then there is no contention?) then we have contention and a continuous path from the supply to ground?

MUX: I suppose I can see how the MUX virtually switches the data on the wires without possibility of persistent contention because it is a complementary (static) CMOS gate itself. Are there any drawbacks then in this case?

EDIT:

Below I have attached the Load structure of the registers in the images above.

• You need to treat these two cases separately. Inside an ASIC/FPGA, gates are cheap and fast, so MUXes are almost always used. At the PWB level, MUXing can require a lot of components so tri-stating is still often used. Commented Dec 13, 2023 at 1:53
• Aren't buffers made of gates too? Why would they be any more expensive in an ASIC if so? In the PCB case I have very little background, but I take it that buffers are easier to implement? @Mattman944
– EE18
Commented Dec 13, 2023 at 2:12
• Many ICs, RAMs, EEPROMs, etc, have built-in tri-state buffers. Commented Dec 13, 2023 at 2:19

## 2 Answers

I might not have found all the questions you asked in your post, but I'll address a couple of the bigger ones:

Why would multiple signals ever be driving the bus? Surely the control circuit is always such that only one of the Rjout signals is asserted at a time?

Ideally, sure. But in larger systems (think an ISA bus or even a VME frame rather than a single chip) not all the drivers on the bus are designed by the same engineer. Even at chip level, some of the drivers might be purchased IP or designed by a different team member.

If there's bus contention that's a bug in the system design, but it's not always trivial to design a bug-free system, and the system should be robust to bugs if they do occur.

I am not sure I follow what's meant by "causes the receivers to waste power".

In a tri-state system, if all of the drivers are in tri-state then the inputs to the loads are floating. Logic with a floating input can potentially drift back and forth randomly between high and low input or even oscillate if there is some parasitic feedback between output and input. This causes undesired logic switching which is where the power is wasted.

To prevent that, you might put a pull-down or pull-up on the bus lines...but then the pull-up or pull-down consumes power whenever the line is actually driven to the opposite state. So again, there's wasted power.

That can all be managed, or avoided by never putting all the drivers in tri-state...but then you've effectively created a MUX'ed system instead of a tri-state one anyway.

If you design your MUX using pass-gate logic (common in VLSI but not in FPGA designs) you are using tri-state drivers under the hood ... but by designating the bus access as a MUX in your HDL you're at the same time also telling the synthesis tool to make sure there's never a state that leaves the bus undriven.

• Thank you so much for these very helpful comments! You write "To prevent that, you might put a pull-down or pull-up on the bus lines...but then the pull-up or pull-down consumes power whenever the line is actually driven to the opposite state. So again, there's wasted power." Can you elaborate on this a bit more? Where is the wasted power (current) coming from a supply (I think similar comment to a comment I left on other answer)? Or are you saying that if the line floats down to 0 from 1 when the bus is floating, and then in the next state in which it must be a 1 we...
– EE18
Commented Dec 13, 2023 at 2:20
• ...waste some power coming back up to 1? But isn't this completely random, in that it's possible that the next state would be a 0 on that line and so we save power? Perhaps I am misunderstanding.
– EE18
Commented Dec 13, 2023 at 2:20
• Your last two paragraphs were amazingly insightful and useful for me. I don't think I fully appreciated that a MUX is fundamentally such that there is always some output asserted. One of my questions was about understanding why we would want that, and if you're able to comment on that it would be greatly appreciated. Is there any disadvantage to always asserting something on the bus, even if it's not being clocked into a register? Obviously in a tristate system we can let it float, and I guess you've pointed out some issues which I still don't understand. Does asserting hurt too though?
– EE18
Commented Dec 13, 2023 at 2:27
• @EE18, say I put a 100 kohm pull-down on a bus line, then my logic drives it to 3.3 V. Then $V^2/R$ tells me the pull-down resistor will consume ~0.1 mW. If it's a 32-bit bus, and (statistically) half the lines are high and half are low at any time, that's 1.6 mW. That's more for one bus than many small microprocessors expect to consume for the whole device. Commented Dec 13, 2023 at 2:29
• Sorry for perseverating on this but I still don't follow. Why would there be a 100 kohm pull-down on the bus line? Isn't the bus connected to various gate capacitances (of the input MUXes in the register structure I've pointed out above)? I think I'm failing to picture whatever situation it is that you're talking about. I'm imagining the charge on these capacitances drifting as the bus nodes float, but I don't see any consistent path from the supply to ground while this is happening as you seem to describe?
– EE18
Commented Dec 13, 2023 at 4:02

Regarding (1)

Sure, your logic will be designed in such a way, that this does not happen. However, you have to insert a idle clock to make sure. This wastes bandwith.

You need to insert this idle cycle (switch off, wait one clock, switch on) as the logic controlling the switching has propagation delays and the signal must be routed within the IC - so run-time for the signal is added.

This means, even if your switch-over is perfectly synchronized in e.g. VHDL simulation, it wont be in real-world.

Regarding (2)

Even if the input data is latched, the register input and the line capacitance gets driven. When the signal picks up crosstalk within the chip, this power is wasted.

There is a "lesser issue" with the MUX. A MUX has "one input" and the output can driven "multiple slaves" on the bus. So only the MUX-Input is affected - in contrary to the "multiple slaves" on a tri-stated bus.

Regarding (3)

Correct.

• Thank you so much for this very nice answer. If it's OK, I have a few misunderstandings which I'd appreciate help with: (A) Isn't your comment regarding (1) really a comment about timing and thus about (3)? That is, if there were no propagation delay then there would be no contention. Perhaps I am misunderstanding. Either way, there is propagation delay and uncertainty thereabouts, so there would be contention (I think this was (3)). (B) I am not sure I follow your answer to (2). I have attached the structure of the register to describe the Load mechanism. Why does the bus floating Z mean...
– EE18
Commented Dec 13, 2023 at 2:08
• ...that there is power draw? Is the bus connected to a supply somewhere? I understand that the bus floating and changing can change the charge on the input capacitance to each input gate, but where is the current draw from a supply? Likewise for crosstalk, where is the current from the supply? I also do not understand the comment with the MUX and perhaps it's because I don't know what "one input" you are referring to. Any help would be greatly appreciated!
– EE18
Commented Dec 13, 2023 at 2:11