0
\$\begingroup\$

For a university project, I have to design and construct a very simple CPU including the ALU. In order to select between different data lines that go into the ALU(32-bit data line), I have thought of two different approaches.

Basically, the first method is using a multiplexer, For example, it takes in input from register file and instruction register and gives out the output. This was the method recommended to me by the professor, however this method seems to get very complex very quickly based on the size of the data buses, and the number of operations needed to be performed.

The second method I found was to use tri-state buffers along with a decoder. Rather than use a huge multiplexer, it only requires a decoder large enough for the number of operations. However, with this solution, I was warned that there could be timing issues, where during the transition of the decoder, two tri-state buffers could be simultaneously activated, which would cause a short-circuit. Is there any truth to this, and can it be avoided? This was the method that I thought was used inside most modern architectures, but I could be incorrect.

Also, how is there no timing violation in case of multiplexers

\$\endgroup\$
7
  • 1
    \$\begingroup\$ Are you implementing this in an FPGA, or with discrete components? \$\endgroup\$
    – Mattman944
    Jun 2, 2019 at 16:43
  • \$\begingroup\$ I will be implementing it in an FPGA using verilog. I know it is easy to synthesize the mux based approach in verilog easily but is it efficient? \$\endgroup\$ Jun 2, 2019 at 16:47
  • 3
    \$\begingroup\$ No muxes aren't efficient, but modern FPGAs have lots of gates. It is better to be inefficient than deal with the issues of tri-state buses (oscillating floating buses, etc). Some FPGAs don't even have internal tri-state capability. \$\endgroup\$
    – Mattman944
    Jun 2, 2019 at 16:53
  • \$\begingroup\$ So even in actual manufacturing of chips Mux is preferred due to its reliability, Is that correct? \$\endgroup\$ Jun 2, 2019 at 16:58
  • 1
    \$\begingroup\$ Inside an FPGA, you would normally use multiplexers. Dave confirmed my belief that most FPGAs don't allow tri-state circuits internally. Tri-state is often used to allow multiple devices to be on the same bus, especially when the devices are bi-directional. Most devices designed to be used on a parallel bus will have built-in tri-state capability. \$\endgroup\$
    – Mattman944
    Jun 2, 2019 at 23:24

2 Answers 2

0
\$\begingroup\$

A tristate bus IS a multiplexer, so there really isn't much difference.

A multiplexer is basically a layer of AND gates followed by a layer of OR gates.

With a tristate bus, you're eliminating the OR gates, but you're replacing the AND gates with the arguably more complex tristate buffers.

In most FPGAs, you can't actually have internal tristate buses. If you attempt to use them, the synthesis tool will either throw an error, or convert them to the corresponding multiplexer logic.

\$\endgroup\$
1
  • \$\begingroup\$ So what kind of approach is followed in industry where ASIC is done in which tristate buffers are possible. If tristate buffers can be used, can we go for it instead of multiplexers \$\endgroup\$ Jun 2, 2019 at 18:45
0
\$\begingroup\$

A tri-state buffer is an idea, not a hardware resource. It lets you reason about your design, but whether the idea survives all the way to the hardware depends on who is doing the translation. FPGAs aren’t collections it 74xx logic gates – even old PLDs weren’t. This gap between what you core up in HDL and what ends up in hardware takes some getting used to, but it’s what makes modern FPGA and ASIC tools so powerful: they let humans express intent, and allow tools to worry about much of the implementation details.

For FPGA you let the tooling take care of translating your ideas into the available resources. In many flows, tristate internal buffers are not synthesized at all, the muxes replace them. It’s a very mechanical transformation.

The dualism between muxes and tri-state buffers comes up all the time in various technologies. With double throw relays - and yes, people do actually make computers out of those – a 3-state buffer and a 2:1 mux have the same cost: one relay per bit. Muxes are, up to a certain tree depth, “free” with relays. But not only relays.

For simulation, you let the tools worry about getting the design simulate efficiently. Verilator and the C++ compiler can go a long way in that respect.

I don’t understand how you measure complexity and why you even worry about it: obviously at the higher design level, you’ll be using primitives whose size “comes for free”, eg. putting down a 32-bit mux on a data flow diagram or in VHDL is no different from a 4-bit mux. If you worry about fitting the design into an FPGA, synthesize and place it repeatedly as you develop your design. You’ll have a good idea of how fast you’re going towards resource exhaustion – if at all.

At the lower level you will have to worry only if you choose to physically assemble the stuff from “loose parts”. Most people will simulate or stick it into an FPGA and call it a day.

And finally: all those things you claim about complexity are objectively verifiable. Build some simple design that uses muxes into your target FPGA. Then rewrite it using 3-state buffers and do the same. Compare timing results and resource use from the tool reports. You may find there’s no substantial difference.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.