Making Hardware Block Diagrams

If I were forced to give a limited amount of advice about making good hardware block diagrams, I would say
these things in this order:

 “The three most important considerations when making a block diagram are consistency, clarity and
specificity.”
 “If your block diagram is especially clear, then it doesn’t always have to be entirely consistent.”
 “You should still strive for consistency even if you believe that you have achieved a high degree of clarity.”
 “The more specific your block diagram is, the less you will struggle when implementing it.”

Fortunately, you don’t have to limit yourself to these particular statements if you desire to learn a little more
about what I mean by clarity, consistency, and specificity.

What makes a hardware block diagram consistent?

Even though making hardware models is an inherently technical process, making diagrams is at least as much
an artistic process. It is a process that involves the creation and use of symbols. I am not a good artist by any
stretch of the imagination, but I am very much at home creating symbolic representations for devices.

So when I talk about consistency, I am really talking about maintaining a particular symbolic representation
across illustrations of the same device.

To give an example that illustrates a lack of consistency: Eventually, we are going to produce block diagrams
that represent implementations of register transfer language statements. Without going into too much detail,
imagine a situation where the contents of one register (call it Register A) are being transferred to a second
(call it Register B) while the contents of the second register are simultaneously being transferred to the first.

Some students have a tendency to do these problems in a rush, and part of being in a rush involves not taking
care to develop a consistent symbolic representation. I have tended to get a lot of diagrams that look like this:

Figure 1: Actually, your guess is as good as mine…

There are many things wrong with and missing from this diagram, but let’s focus on what is here. Even though
we have not studied or designed registers, you might take away from this diagram that transferring the
contents of one register into another involves connecting the outputs of one register to the inputs of another.
The arrows might help make this connection – information is “clearly” going from Register A to Register B, and
from Register B to Register A. At least, it’s clear until you ask yourself – as I do frequently – “Why are Register
A’s inputs and outputs on the bottom side of its block, while Register B’s inputs and outputs are on the top of
its block?”
If a device’s inputs and outputs can be anywhere on the symbol for that device, then it calls into question the
ease of interpreting what a diagram containing those symbols is supposed to say.

Hardware block diagrams are supposed to make it easy to interpret the “flow” of information. The best
examples we have seen of how information flows in a system are digital circuit diagrams containing logic
gates.

(a) Organized to proceed from left to right

(b) Organized (generally) to proceed from top to bottom

Figure 2: Gate-level multi-output functions

Given that we know how the inputs and outputs of a logic gate are represented, the diagrams shown above
should be clear as to how the information flows through them. In the top diagram, the inputs are on the left
and the outputs are on the right; the gates are organized accordingly. In the bottom diagram, the inputs are
on the top and the outputs are on the bottom; by and large, the gates are again organized accordingly. (There
are always exceptions – note that in the bottom diagram, the inverters are placed in a way that allows us to
show parallel wires to represent the signal complements in the same space as the uncomplemented signals. In
a slightly-different context of the word, we might think of the wires carrying the signals and their
complements to be a “bus” of wires that allow for easy connection of all literal forms of the input set to the
logic circuits below.

With that in mind, one key aspect of determining a consistent symbol set is making your first big artistic
decision: Which way is information going to flow in my diagram?

If you decide that information will generally flow from top to bottom, then it makes sense to draw symbols
whose inputs are generally on top and whose outputs are generally on the bottom.

If you decide that information will generally flow from left to right, then it stands to reason that you should
draw symbols whose inputs are generally on the left and whose outputs are generally on the right.

Let’s return to our register transfer block diagram. But before we try to diagram a pair of registers, let’s make
a symbol for one. A rectangle is a convenient shape for the body of the register. Let’s say that information
flows from top to bottom, so we’ll put the inputs on top and the outputs on the bottom. Even though we’ve
chosen a direction for information flow, it seldom hurts to put arrows on the inputs and outputs to emphasize
the direction. (But this is situational; I wouldn’t do it, say, on a logic gate.)

Figure 3: A register-to-be

If this is what every register looks like, then it becomes easier to imagine how we should connect them
together to achieve particular register transfers:

Figure 4: Two such registers connected output-to-input

It even becomes easy to standardize the appearance of other control signals:

CLK A
LOAD

B
LOAD

Figure 5: Two registers with clock and control inputs

Don’t worry about what those signals are or what they are doing. Just take note of how the “pins” they control
are placed in a consistent fashion on the registers that use them. Once you learn about what a “clock” is or
how a “load control line” exercises control over a register, you’ll see why it is a good idea to place these
important control signals in a way that makes them easy to identify on each device.

As a second example of symbol-making, here are a number of symbols that I have used before to represent
multiplexers:

S1 0
S0 1
S1 S0 0 1 2 3 S1 0 1 2 3 0 2
S0 1 3
2 S1 S0
3

(a) (b) (c) (d)

Figure 6: Four 4-to-1 multiplexer blocks

I will discuss what makes it reasonably clear that these are 4-to-1 multiplexers in the next section. However,
it’s also important to discuss symbols like these in the context of consistency. In the context of our discussion
of the flow information, it’s probably clear that (generally speaking) symbols (a) and (b) have their inputs on
the top and their outputs on the bottom, while symbols (c) and (d) have their inputs on the left and their
outputs on the right. But past that, if I were making a block diagram where information flowed from top to
bottom, I would not use symbols (a) and (b) interchangeably in the same diagram. Once you determine a
symbol for a device, use it consistently unless you find an extremely compelling reason to vary it within the
diagram.
What makes a block diagram clear?

Labels.

I don’t think it really gets any simpler than that. Anyone can draw a box that has six or seven lines attached to
it. But the best way to identify a device is to know what its inputs and outputs are.

Here’s such a box.

Figure 7: Once again, I have no idea.

Is this the symbol for a 2-to-4 decoder with enable?

A1 D0
A0 D1
EN D2
D3

Figure 8: I guess it could be this…

Is it the world’s worst symbol for a 4-to-1 multiplexer, with its inputs on the right and its select inputs and
outputs on the left?

S1 A0
S0 A1
D A2
A3

Figure 9: I actually hope it isn’t this…

Is it something else entirely, like a specific three-input, four output circuit containing its own logic?

A F1
B F2
C F3
F4

Figure 10: This could be anything, so I guess so?

As you can hopefully see, labels can make all of the difference in interpreting what it is that a device is or what
it does. And as you might imagine, knowing a device’s function and purpose go a long way in making the block
diagram clear.
In my experience, students tend towards under-labeling their block diagrams – sometimes, vastly. I suspect
this is because they know what it is that their block diagrams are supposed to represent, and just don’t
imagine that a block diagram exists just as much to tell others about your design as it is for them to organize
their own designs. It’s possible that over-labeling happens to the detriment of clarity, but (1) I don’t remember
the last time I saw a student over-label a block diagram, and (2) if I had to choose between being cursed either
to always under-label or always over-label, I would choose the latter one hundred percent of the time.

But we’re not here trying to under-label or over-label, so it’s worth asking: What’s a good guide for doing the
right amount of labeling? I think the answer to that question is “Label each pin of a device, and label the signal
that is driving each pin in the design.” To illustrate this, let’s look at a 1-bit full adder:

X Y
Cout Cin
S

Figure 11: A 1-bit full adder block.

Taking information to flow (broadly) from top to bottom, this full-adder uses addend bits X and Y with carry-in
Cin to produce sum S and carry-out Cout. We might imagine this to be the symbol for every 1-bit full adder in the
whole world. This is a powerful concept as it applies to modeling hardware using Verilog, because once we
write a module to describe every 1-bit full adder in the world just one time, we can instantiate that module
into as many designs as we might like.

To illustrate this using a diagram, let’s use this 1-bit full adder to make a 4-bit ripple carry adder, as we’ve
done in class before.

X Y X Y X Y X Y
Cout Cin Cout Cin Cout Cin Cout Cin
S S S S

Figure 12: A 4-bit adder made of full adders, hanging out in space.

What are the two 4-bit quantities that this adder is adding? Well, isn’t it obvious?

No, I guess it isn’t. Okay. Let’s suppose we are adding together the four bit numbers A – represented by the
bits A3 A2 A1 A0 – and B – represented by the bits B3 B2 B1 B0. Let’s further suppose that the carry-in to the
least significant bit is C0. We’ll use S to designate the sum of A and B, where S is represented by the bits S3 S2
S1 S0. Finally, let’s call the most significant carry-out C4. While we’re at it, we’ll call the internal carry bits C1,
C2, and C3.
With these names in mind, your temptation might be to change the labels on the adders:

A3 B3 A2 B2 A1 B1 A0 B0
C4 C3 C3 C2 C2 C1 C1 C0
S3 S2 S1 S0

Figure 13: Hey! Don’t do this to label your inputs!

But the problem that I see with this approach is that it destroys the consistency of the device labeling. Instead
of doing this, we should approach this by thinking as follows: “Having labeled the pins of the device, let’s now
label the signals that are on the pins.” So it might look as follows:

A3 B3 A2 B2 A1 B1 A0 B0

X Y X Y X Y X Y
C3 C2 C1
C4 Cout Cin Cout Cin Cout Cin Cout Cin C0
S S S S

S3 S2 S1 S0

Figure 14: Label your inputs on the pins separately from what the pins represent

This is important because it might be the case that the inputs of the adder are the outputs of other devices, as
happens in arithmetic units. If we want to use multiplexers as buses to govern which of a number of possible
input values the adder uses, we can simply label the signals at their source.

P2 P1 B3 B3´ 0 1 P2 P1 B2 B2´ 0 1 P2 P1 B1 B1´ 0 1 P2 P1 B0 B0´ 0 1

S1 S0 0 1 2 3 S1 S0 0 1 2 3 S1 S0 0 1 2 3 S1 S0 0 1 2 3

A3 A2 A1 A0

X Y X Y X Y X Y
C3 C2 C1
C4 Cout Cin Cout Cin Cout Cin Cout Cin P0
S S S S

S3 S2 S1 S0

Figure 15: A budding arithmetic unit: Note how the inputs and pins are labeled separately.
Notice how the pattern of labeling pins and naming signals continues on the multiplexers. All four 4-to-1
multiplexers have pins with consistent labels, and each multiplexer has its pins labeled to show which signals
are driving those pins. In this particular instance, there are certain places corresponding pins of different
multiplexers have different signals driving them, while in other places the same signal drives those
corresponding pins. This is on purpose: all four multiplexers use the same select signals (P2 and P1), but each
one buses a distinct set of signals to the adders. (We could have used wires to connect all of the select inputs
commonly to P2 and P1, but this is a personal choice.)

The takeaway from all of this is that a 3-bit opcode P (P2 P1 P0) determines which of eight possible operations
the arithmetic unit performs on the 4-bit operands A and B. (Review the arithmetic unit in the lecture slides
for specific details.)
What makes a block diagram specific?

It could be said cynically that a block diagram’s purpose is to obscure certain implementation details. By using
blocks for multiplexers, we save ourselves the effort of drawing the logic circuit that we know to be inside of
every multiplexer. But it’s to be understood that we are only doing this because we know the nature of that
logic circuit and understand how it causes the multiplexer to function properly.

But just because we are purposefully abstracting (a much better word than “obscure”) certain details of the
design doesn’t mean that we are abstracting all of them away. The arithmetic unit above is an example of
this. Not drawing the logic circuits for the multiplexers doesn’t prevent us from actually showing multiplexer
blocks as the means by which values are bused to the adder.

Speaking generally, a block diagram is specific when it shows the implementation details of a system at the
level represented by the block diagram. If the diagram doesn’t accomplish that goal, then it is not specific
enough.

Consider a 2-function circuit that performs general left shift and right shift operations on a 4-bit operand. The
presumption is that sometimes the 4-bit output of the shift unit will be the input operand shifted left by one
bit, and that other times the output will be the input operand shifted right by one bit. (I’m being purposefully
vague about many of the implementation details because eventually you will have to solve a problem very
much like this one.)

Many first efforts at making block diagrams subscribe to the “then a miracle happened” method of design that
students apply when they don’t know any better. We might suppose that the block diagram for this system
has four inputs and four outputs. As far as everything else, your guess is as good as mine:

Then a miracle happens…

Figure 16: Hopefully this is the last time we have no idea what’s happening

We can do much better. In fact, we can start by deciding that the block diagram has pins that represent the
bits of a 4-bit input (In3 In2 In1 In0) and the bits of a 4-bit output (Out3 Out2 Out1 Out0). The homework
problem that corresponds to this example suggests that an operand called B is the one that we will be shifting.
We’ll take B to be represented by the bits B3 B2 B1 B0. It doesn’t specify the name of the specific result, so
let’s call it Shift, and represent it as Shift3 Shift2 Shift1 Shift0. (This will allow us to distinguish its output from
the outputs of other units.)
Our block diagram is beginning to take shape:

B3 B2 B1 B0

In3 In2 In1 In0

Then a miracle happens…

Out3 Out2 Out1 Out0

Shift3 Shift2 Shift1 Shift0

Figure 17: Oh! It’s a shift unit.

Now we can begin asking important implementation questions:

 How many operations is the logic circuit supposed to perform?
 How many bits of control do I need to distinguish from among that number of operations?
 What kinds of devices will I need to make selections and perform the operations, and how will I use the
control bits to make the devices work properly?

Let’s consider this shift unit:

 How many operations is the shift unit supposed to perform? This shift unit performs two operations.
 How many bits of control do I need to distinguish two operations? I’m not going to say here, but it follows
that we’ve actually left out the input or inputs that represent this control capability. Let’s refine our block
diagram:

B3 B2 B1 B0

In3 In2 In1 In0

? Control
Then a miracle happens…

Out3 Out2 Out1 Out0

Shift3 Shift2 Shift1 Shift0

Figure 18: Block diagrams can evolve as we figure out more about them

 What kinds of devices will I need to make selections and perform the operations, and how will I use the
control bits to make the devices work properly? I’m not going to answer that directly either, but if you think
about how the shift unit has to work, then that question also becomes easy to answer.
 Consider the output Shift2: For a left shift, it should be equal to B1, but for a right shift, it should be equal
to B3. It should go without saying, but we can’t connect two signals to the same point in the circuit. What
we need is a circuit that can select between input values B1 and B3 and direct the correct signal to Shift2.
At this point, the miracle starts to go away, and is replaced by hardware that we can describe and diagram:

B3 B2 B1 B0

In3 In2 In1 In0

? Control
?

Out3 Out2 Out1 Out0

Shift3 Shift2 Shift1 Shift0

Figure 19: We don’t need miracles when we can elaborate behavior

More importantly, it becomes hardware that we can describe hierarchically in a hardware description
language like Verilog. And that goal – to make what you are trying to implement seem less and less like magic,
so that you can implement it in an HDL using the approaches that we will continue to develop in this course.