Authoritative Opinion » Hardware

Analog Multiplexer (Update–9/25/09)

Tue, 11 Aug 2009 02:23:24 +0000

After posting about digital multiplexers and decoders, I started thinking about analog multiplexers, which I have not used before, but which can be quite useful, for instance in bypassing an effects pedal on a guitar. In principle, because a CMOS transistor can function as a connected/disconnected switch for digital circuits, I figured that it would work similarly for analog circuits, and threw together this 2:1 analog multiplexer:

V1 and V2 combine to form a single 0-5 V supply, I simply broke the two apart to demonstrate how the signal biasing could work. V3 and V6 represent the output pins on a microcontroller that are used to select between inputs—they must be able to source a few mA when driven high (this shouldn’t be a problem for practically all microcontrollers, on real I/O pins). A simple logic circuit (i.e. decoder) could be used to take an encoded representation of the desired signal and drive these inputs appropriately. V4 and V5 are the input signals, referenced to any other signal, and they are properly biased (a good practice, even if they are supposedly referenced correctly) to ensure they are within the operating region of the rest of the circuit.

I chose 0-5 V rails to make the mux usable on any board that already had similar supplies for, say, a PIC microcontroller. Not using a -5 V rail simplifies the power requirements for simple circuits, but it does require that the signal be biased properly, in order to avoid clipping as it passes through the output buffer. The resistors and capacitors on the biasing circuit were selected to provide a cutoff frequency of ~0.3 Hz on the implicit high-pass filter, in order to avoid attenuating the low frequencies in audio applications and attempt to provide a relatively flat passband in the entire bandwidth of the NMOS transistors, which was approximately 1 MHz in the SPICE simulation I used. For higher frequency usage only, the values of both can be adjusted in order to make the circuit components easier to find, but care must be taken to limit the current that the input will be required to source/sink. If a piezoelectric transducer is used, its current capabilities are rather limited, so high resistances are preferable, as well as low capacitances (1 uF is large in this case, I think). A buffer stage could be introduced on the front end, but it would again require proper biasing to ensure that the signal is not clipped, which is highly likely using only a single +5 V supply.

This circuit is provided for academic/hobbyist purposes. If you really need to use an analog multiplexer, I suggest you sample or purchase one from Analog Devices because it will be more robust and have fewer caveats than this circuit does (for instance, if you drive both inputs high on this circuit, it will gladly add the two signals together, which might be useful instead of using a summing amplifier). Comments and other feedback are welcome, as I’m by no means good at analog design, and I only did SPICE simulations for this circuit—I haven’t had a chance to build it and try it in the real world yet.

[UPDATE]
I was planning on building this circuit recently, both for a separate project and to test it out, when some shopping on Digi-Key led me to find that it is very difficult to purchase MOSFETs with substrate connections. MOSFETS are four terminal devices, but most common applications do not use them this way. Digi-Key has over 16,000 differently listed MOSFETS and no easy way to search for a four-terminal one (many come in larger packages with multiple pins connected to the drain and source) so I abandoned it and spent some time working on an alternative circuit. A combination of MOSFETs and BJTs should be sufficient to emulate the four-terminal device, but it imposes additional restrictions on the signals that can be passed through for a given power supply. The threshold voltages of BJTs gates require that there be a (device specific) gap between the maximum value of the signal and the power rails, but most operational amplifiers have similar restrictions (although not as large in magnitude). To that end, this is the modified circuit that gives the same results in simulation. I’ve also added a pull-down resistor (which can be tied to any of your negative rail 0V, the positive rail +5V, or a constant voltage available) to deal with the input/offset current of the op amp. This resistor should ideally be as big as possible (5 MOhm like the others is fine), but it will, in theory, attenuate all frequencies equally, which means that something as low as 10 or 100 kOhm is acceptable, depending on how wide the voltage margins your op amp requires are and how much current your signal transducers can source.

Unlike

TMP: Master Plan

Fri, 19 Jun 2009 18:07:54 +0000

I spent a lot of time debating which ISA to base this on. MIPS has the advantages of being easy to explain, being a good example of RISC, and I’ve implemented large sections of it before for class. However, that last bit makes me wary, because it means that more students in a similar situation will need to implement a MIPS-like processor. I don’t want to just give away final projects here, so anything resembling MIPS enough to allow people to literally copy large sections of the code I release is undesirable. The other option that comes to mind is something based on ARM’s ISA. ARM is well-established and is a very common platform for embedded systems, but at the same time. So I’ll use a handful of the really interesting features available in ARM’s ISA, such as conditional execution of instructions. Finally, it’s never fun to blindly implement someone else’s ISA, it’s much more interesting to create your own design, so ultimately I will draw on both MIPS and ARM, as well as my own intuition, and create something that incorporates what I think are important features from both, while at the same time lending itself well to explanation of key features.

The Master Plan, then, loosely resembles the following, with many stages happening in parallel:

Design Instruction Set Architecture (ISA)
- Should be Load-Store and adhere to basic RISC principles.
- Should make it easy to explain and demonstrate basic design principles, while allowing for powerful features and extensibility.
Create a Simulator
- Written in C
- Will require an additional, simple assembler to convert instruction mnemonics to a binary execution image
- Initially command line based (or ncurses frontend), with the possibility of adding a GUI if it seems worthwhile
Design ALU
- This part, and everything leading up to the actual processor implementation connecting everything together, can happen in parallel with simulator programming
Create Register File
Miscellaneous Processor Structures
- Memory interface (initially, an ideal memory, so this will just decode/translate requests)
- Forwarding/Hazard Detection and Handling
- Pipeline Registers
Assemble the Microprocessor
- This includes pipelining
- Support for multiply and divide instructions
  - Requires significant pipeline extensions and an additional parallel processing unit
- Support for interrupts
  - This is necessary for implementing any reasonable, albeit basic, operating system
  - Also necessary for I/O, which is quite reasonable for anyone using integrated FPGA development boards (which often have a lot of I/O and the necessary support circuitry already implemented)
  - Not covered/explained often in microprocessor courses, yet integral to the functionality of all modern computers (interrupts are used to make system calls in both Windows and Linux).
- A basic OS
  - Flat memory model, without memory protection (dangerous, but simple)
  - Cooperative Multithreading (because it’s easy to implement)
  - Implements basic system calls to provide common sets of functionality for user programs
With this list of central goals complete, a few additional features seem quite reasonable and would serve to be important in understanding the functionality of a much more advanced processor. Therefore, these are secondary targets, to be completed once the basic design is done:
- Instruction and Data Cache
- Branch Predictor
I’ve even got some genuinely crazy ideas, but I’ll keep them to myself for now (most fall into the realm of “not existent on 99% of available commercial microprocessors/microcontrollers”). If this can be established as a platform on which I can test less mainstream concepts and designs, then this will be a success for me.

All that said, I may have missed a few features that won’t be apparent until the time comes, but I think this is a good starting point. Next time, the ISA will be unveiled (hopefully a week), or at least the first revision of it. Design flaws will always become apparent through actually working with it (something a lot of software library designers haven’t realized, but I digress), and so things will be amended as time goes on.

Like
Unlike

The Microprocessor Project: Overview

Fri, 12 Jun 2009 19:45:02 +0000

This summer, I need something to do. I’ve got a few ideas, but in particular, one desire I’ve had since I was a young teenager was to design my own computer, which I’ve now learned enough to understand means “to design my own microprocessor.” Software for it can come later, if I still like the idea after designing the hardware (or, if I’m really clever, I can try to port Linux to it, and not have to write my own software at all). However, I see now that the reason I didn’t do this sooner, and my new reason for doing this project, is that there are virtually no in-depth, beginner-level resources available on the Internet (if anyone wants to try to look at OpenSPARC and without any understanding of what it’s based on, deduce how to build a basic microprocessor, please, be my guest). To that end, today I begin my next big project: designing, simulating, testing, and maybe putting on an FPGA a real, functional, 32-bit microprocessor. Then, explaining it in detail, putting my results on the Internet, and releasing it under the GNU GPL, so that there exists a simple platform for people to play around with microprocessors, extending it with additional features or modules as they see fit. I don’t intend to create something remotely commercially viable, because I will, initialy, purposely not include features found even in the early 90s on Intel chips, in order to simplify the design process, and help explain the basic concepts. If I like what I’ve done, when the time comes, maybe I’ll add more realistic features, such as multiple pipelines (superscalar) and out-of-order execution, or I’ll design support for more esoteric features (like barrel processing), to see how readily (if at all) they are implemented and to provide some context about where microprocessors can go from the basic 5-stage pipeline.

The real goal here is educational in nature. Microprocessors are incredibly complicated devices, and so most online descriptions are terse at best. Despite that, I think people should be able to learn, for free, exactly how a microprocessor works. However, I can’t explain how an x86 chip works, for a number of reasons. First, I don’t actually know. I have a pretty good understanding of the elements from which it is built, but I’ve spent almost no time studying the ISA or reading papers on how Intel has actually implemented things. Second, I’d hate to speculate and be totally wrong, and then have people read it and think that was how it works. In contrast, I do understand the principles upon which RISC microprocessors (like MIPS and ARM) are based, so I can readily make up an instruction set that it is similar to MIPS, implement it, and then talk at great length about how it works. Hopefully, then, a younger version of me can find this online, look through it, and then be able to answer all those questions I had until college about how computers actually do things. If software and programming can be well documented and available for free to learn from, then hardware should be too.

If you would like to contribute descriptions, Verilog, or simulation code (which will mostly be written in C), please let me know by posting in the comments.

Coming soon: The Master Plan. I’ll lay out precisely what the objectives are and give an overview of how the project will progress as a whole.

Unlike

Multiplexers and Decoders

Mon, 25 May 2009 22:05:22 +0000

Here’s something that wasn’t emphasized in my digital design courses, which every amateur digital designer should be aware of: decoders and three-state buffers use fewer logic gates than large multiplexers. Obviously when one uses commercial devices with an output enable, the decoder functionality is implicit, but whenever it comes to incorporating selection logic into our own designs acting on our own data, the more natural choice is a conventional multiplexer. Both approaches have benefits and drawbacks, but which is “better?” First, a quick look at the differences between the two: a multiplexer uses a combination of AND and OR gates to select between a number of inputs and always drives the output accordingly. A decoder/three-state selection device (which is really also called a multiplexer, but I’ll try to avoid some confusion) uses only AND gates and single transistors to drive the output with just one of the inputs when it is selected. The key aspect here is that there is not always an output of 0 or 1—a third option, high impedance (or Hi-Z), is available, corresponding to “no value.” This happens because each of the combination of select pins controls whether each input drives the output or not, rather than all inputs driving something regardless of utility. The differences between the two can be seen by implementing generic multiplexer functionality for a 1-bit, 8:1 multiplexer. Without three-stated buses, this requires 24 two-input AND gates and 7 two-input OR gates. The schematic shows that there are six logic gates between the input and the output of the multiplexer:

8 to 1 mux

By comparison, the same functionality can be realized using only 16 two-input AND gates and 8 three-state output buffer elements. The schematic is also much simpler:

8 to 1 decoder

This reduces the gate delay between input and output to two gates plus a transistor. This would make it seem like three-state buffers and decoders are the obvious choice for every situation, because they have a shorter gate delay and use fewer transistors, which has many benefits. However, there are hidden problems associated with this design, making it unsuitable for some situations.

First, if the design is being developed for an FPGA, the AND/OR approach is more versatile. Why? Because FPGAs do not implement traditional combinational circuits. Often, combinational blocks are instead broken into units that can be implemented by 4-input Look-Up Tables (LUTs), which means that any function that can be described by such a lookup table has the same speed cost, regardless of the number of gates that would be required to implement it otherwise. Next, three-state elements are not readily available within most of the logic blocks (although an FPGA could be built to not have this restriction), meaning that more interconnect must be used to route signals through three-state elements, although it is more common for the compiler to simply recognize the situations and convert it into a multiplexer that can be implemented easily with the LUTs.

Second, when working with CMOS, each transistor has an capacitive property. Therefore, as more transistors are tied to the same bus, even in a Hi-Z mode, the capacitance will cause the rise and fall times to increase, in a manner similar to having an increased fanout. This can create problems with setup time in very high speed situations, whereas the rise and fall time of an AND/OR multiplexer output will not vary with the number of inputs (although the total propagation delay will—the two must be balanced, so it is possible that the longer rise time is shorter than the longer propagation delay).

Third, although this isn’t really a big problem, is that during transients when switching, it’s possible for two three-state elements to have their enables asserted at the same time, potentially causing the bus to be driven both low and high at the same time. This is going to happen for an extremely short period of time, as the switching time is usually less than the delay of a single inverter, so I think the additional power dissipation caused by this situation is negligible compared to the sum of leakage current and normal switching power consumption

But, these three considerations aside, if you’re designing an ASIC or wiring together something with discrete components (a rarity in itself), it’s possible that replacing AND/OR multiplexers with decoders and a three-state buffer could increase the throughput of the digital circuit you’re designing, or just make it easier for you to wire, with fewer things to keep track of. It’s hard to say which approach is better, but it’s certainly important to understand how to use both effectively, because many situations will call for one or the other for optimal performance.

Finally, a quick Verilog reference (because the Internet is thoroughly lacking in this department), I find the easiest way to implement a three-state bus is with structural Verilog, defining a module to handle the three-state output (although sometimes it can be incorporated into a larger module). In this case, the module has a parameterized width, and it is used to build a mux of parameterized width as well:

// sel = 0: A => C
// sel = 1: B => C
module mux2x1(A, B, C, sel);
	parameter width = 32;

	input [width-1:0] A;
	input [width-1:0] B;
	input sel;

	output [width-1:0] C;

	en_buffer #(.width(width)) selected (.A(B), .C(C), .EN(sel));
	en_buffer #(.width(width)) not_selected (.A(A), .C(C), .EN(~sel));

endmodule

module en_buffer(A, C, EN);
	parameter width = 32;

	input [width-1:0] A;
	input EN;

	output [width-1:0] C;

	assign C = (EN ? A : {(width){1'bz}});

endmodule