Digital Logic – Why Use MUX Instead of Tristate Buffers for Bus Implementation?

busdigital-logicmultiplexertri-statevlsi

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.

Best Answer

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.

Related Solutions

Bidirectional bus in vhdl

Take the following VHDL design description:

library ieee;
use ieee.std_logic_1164.all;

entity bidir is
    port (
        Z  : inout std_logic;
        Y  : out   std_logic;
        OE : in    std_logic;
        A  : in    std_logic
        );
end;

architecture behave of bidir is
begin

    Z <= A when OE = '1' else
         'Z' when OE = '0' else
         'X';

    Z <= 'H';                           -- pullup

    Y <= TO_X01(Z);

end behave;

There are potentially three or more drivers for the net connected to the mode inout port Z. There are two local drivers - the two concurrent signal assigments one driving from port A depending on the output enable OE (and propagating unknowns), the other a pullup.

There can be some some number of external drivers on the net Z is connected to, potentially none. The value of that signal net is determined by a resolution function.

This introduces the distinction between the driven value from a driver and the effective value of signal net. The value of the signal net in an expression is the output of the resolution function, and not the nearest driver.

In a timed simulation, or in the case of the output enables of two of these buffers with the output enable being delivered on different delta cycles (a second signal for one of the output enables derived from the other by a signal assignment), there can be overlap between active drivers. You typically logically AND a chip select with the output enable to prevent overlapped enables on multiple drivers. If the driven values of the multiple drivers are different (e.g. one '1', the other '0') you'll see a resolution of 'X' during VHDL simulation for the overlap.

The pullup implies that the default value of the signal net is 'H' when there are no 'active' drivers providing strong values ('1' or '0'). You'd typically 'filter' the 'H' to a '1' by using a conversion function (e.g. TO_XO1) on the signal being used internally on the theory that un-driven signals floating in the switching region for an input buffer is a bad thing, potentially causing high transient current loads and potential latch up.

With std_logic there are two ways to insure a driver doesn't interfere with another driver. std_logic is a resolved type, using a resolution table to determine the effective value, taking two signals at a time (a result value and each driver in turn, the result initialized to 'Z.

  constant resolution_table : stdlogic_table := (
    --      ---------------------------------------------------------
    --      |  U    X    0    1    Z    W    L    H    -        |   |  
    --      ---------------------------------------------------------
             ('U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U'),  -- | U |
             ('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X'),  -- | X |
             ('U', 'X', '0', 'X', '0', '0', '0', '0', 'X'),  -- | 0 |
             ('U', 'X', 'X', '1', '1', '1', '1', '1', 'X'),  -- | 1 |
             ('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X'),  -- | Z |
             ('U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X'),  -- | W |
             ('U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X'),  -- | L |
             ('U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X'),  -- | H |
             ('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X')   -- | - |
             );

The two axis of the resolution table are the two inputs. You might note that every intersection of 'Z' on one input results in the unchanged value of the other input. 'Z' is a safe value.

Specifying a 'Z' output for an 'inactive' driver is the correct thing to do for a pure behavioral model.

A structural model can use a disconnection specification on a guarded signal, specifying how long after an event a signal is driven. When it's not driven (disconnected) it's not involved in resolution.

Without disconnecting a driver the only way to have a driver uninvolved in the resolution value for a multi driver net is to drive it to 'Z'.

Tristate logic equivalent in NMOS logic

This is an example of a classic Open Collector bus architecture using MOSFETS to achieve the open drain equivalent.

This technique was very common before the days of 3 state logic (TriState is a registered trademark incidentally) in discrete computing, where each processor register was in fact an octal D type latch.

The setup you have should work fine for what you want to achieve. Note that this is inherently safe, as the worst that can occur if more than one output is active at the same time is incorrect data.

The drawback is one of speed; driving a low onto the output will take a short amount of time, but the bus will have to charge back up before you could output a high (which would not change the state of the common bus line).

To say this is tried and tested is an understatement.

Edit: responded to number of collectors / drains

The number of devices on the bus does indeed affect the timing as they act as a capacitive load. The time taken to change the state of the line is proportional to R*C. The C term is constant and determined by the number of devices and the length of the actual common line. The R term is different depending on whether the line is being pulled low, or being released to go high.

When a single device pulls the line low (and this is affected by the number of devices as the single device turning on must discharge the bus from the high state which is proportional to the number of devices present) it is acting as a current sink with the drain to source resistance as the R term.

When it switches off, the R term becomes the pull-up resistor which is very much larger. This is why active pull-ups in 3 state logic was such a breakthrough.

Best Answer

Related Solutions

Bidirectional bus in vhdl

Tristate logic equivalent in NMOS logic

Related Topic