Course Related

Tools & Style


Hints for Logisim Design

Updated: September 26, 2006

Overall the Project 1 submissions were very good. But in grading the projects, we noticed the same problems cropping up over and over. Below is a list of common errors and bad designs that you should not make in the remaining Logisim projects.

Bad design #1: Improper use of "controlled buffers"

Most groups used controlled buffers in one place or another. And most groups used them wrong. Learn to use multiplexors instead. Controlled buffers work a lot like a real "switch", where one wire connects or disconnect a second wire. We have not taught you how to design a circuit when some of the wires are actually disconnected, rather than simply carrying zeros. Most of you tried to use controllecd buffers to do one of two things:
Bad idea: Controlled buffers to disable parts of circuits you don't want computing things.


The only reason to do this is to save electricity, and that is a whole 'nother game. Instead, just ignore the output from parts of circuits by using a multiplexor to select just the thing you wanted to compute.

Bad idea: Controlled buffers instead of a multiplexor.


This is called a "wired-or". We won't use it in class, and you should not use it in your designs. Just use a multiplexor instead. Note: putting the OR gate in this case is actually wrong -- Logisim doesn't complain, but real hardware would not work correctly.

Bad design #2: Not using n-way multiplexors

Multiplexors are great things. Use them please. And there is no need to build your own, or combine multiple 2-input muxes to get a larger mux. Logisim multiplexors are all you should ever need. No they can't be rotated, but at least they are pretty.
Bad idea: Build your own 8-way mux


The Logisim version will lead to a cleaner, more easily understood circuit.

Bad design #3: Improper use of constants

The only exceptons are for (a) providing inputs to a sub-circuit that has more inputs than you need, or (b) making your circuit look slightly simpler in certain cases. Any time you feel like putting down a constant, just ask "can I just optimize this away by using a different gate?"
Bad idea: Use a multiplexor with constants as inputs.


These almost always reduce to just an AND gate, without the constant. Or in the worst case, a no-op. The circuits on the left and right are equivalent.

Bad design #4: Not using logisim primitives

There is no need to build your own NOR, XOR, AND, multiplexor, and other gates. Logisim's built-in gates work just as well as your own, and can work with any size inputs. And they look nice too.

Bad design #4: Invisible splitters

They are very hard to see on the circuit. Instead, just use a fan-out of 2 or more, and leave all but one of the wires unconnected.
Bad design: invisible splitters



Bad design #5: Useless sub-circuits

Instead, just use the component itself. An exception to this rule is the "bit reverser" circuit that many of you built (with no components, just spliters and wires), since it takes up so much screen space.
Annoyance: unnecessary and distracting sub-circuits


also wrong
These sub-circuits are just re-packaging and re-naming already existing Logisim primitives. Just use the primitive instead.

Bad design #6: Not testing completely

At minimum, do positive+positive, postive+negative, negative+negative, and negative+positive. And try a couple of each combination, too.

Logisim quirk: data flow

This is a minor point. But you have probably noticed that logisim likes data to flow left-to-right on the screen. For example, the default orientation of primitives are all left-to-right, and multiplexors can't be rotated at all. Many of you displayed an amazing stubornness by having your circuits go in other directions.


Don't fight it.


  1. MIPS Volume 1: Basic MIPS Architecture
  2. MIPS Volume 2: Instruction Set Reference
  3. MIPS Volume 3: Privileged Resources and Systems Programming


  1. ALU Implementation
  2. Basic Execution
  3. MIPS Processor
  4. MIPS Disassembler
  5. MIPS Simulator
  6. Cache Simulation and Measurement
  7. Multicore Simulator
  8. Final Project