|
When entering numeric values in the answer fields, you can use
integers (1000), floating-point numbers (1000.0), scientific notation
(1e3), or JSim numeric scale factors (1K).
Problem
1. lab4checkoff.jsim tests your ALU circuitry by applying 169 different
sets of input values. These questions explore how those values were chosen.
No designer I know thinks testing is fun -- designing the circuit seems
so much more interesting than making sure it works. But a buggy design
isn't much fun either! Remember that a good engineer not only knows
how to build good designs but also actually builds good designs, and
that means testing the design to make sure it does what you say it does.
An obvious way to test a combinational circuit is to try all possible
combinations of inputs, checking for the correct output values after
applying each input combination. This type of exhaustive test proves
correct operation by enumerating the truth table of the combinational
device. This is a workable strategy for circuits with a few inputs but
quickly becomes impractical for circuits with many inputs. By taking
advantage of information about how the circuit is constructed we can
greatly reduce the number input combinations needed to test the circuit.
The ripple-carry adder architecture suggested in Lab 4 uses 32 copies of
the full adder module to create a 32-bit adder. Each full adder has
3 inputs (A, B, CI) and two outputs (S, CO):
A single test vector for the full adder consists of 3 input values
(one each for A, B and CI) and 2 output values (S and CO). To run a test
the input values from the current test vector are applied to the device
under test and then the actual output values are compared against the
expected values listed by the test vector. This process is repeated until
all the test vectors have been used. Assuming we know nothing about the
internal circuitry of the full adder, how many test vectors would we need
to exhaustively test its functionality?
- Consider a 32-bit
adder with 64 inputs (two 32-bit input operands, assume CIN is tied to
ground as shown in the diagram below) and 32 outputs (the 32-bit
result). Assume we don't know anything about the internal circuitry
and so can't rule out the possibility that it might get the wrong
answer for any particular combination of inputs. In other words, just
because the adder got the correct answer for 2 + 3 doesn't allow us to
draw any conclusions about what answer it would get for 2 + 7. If we
could apply one test vector every 100ns, how long would it take to
exhaustively test the adder?
- Shown below is a
schematic for a 32-bit ripple-carry adder.
Except for the carry-in from the bit to the
right, each bit of the adder operates independently. We can use this
observation to test the adder bit-by-bit and with a bit of thought we can
actually run many of these tests in parallel. In this case the fact that
the adder got the correct answer for 2 + 3 actually tells us a lot about
the answer it will get for 2 + 7. Since the computation done by adder bits
0 and 1 is same in both cases, if the answer for 2 + 3 is ocorrect, the
low-order two bits of the answer for 2 + 7 will also be correct.
So our plan for testing the ripple-carry adder
is to test each full adder independently. When testing bit N we can set
A[N] and B[N] directly from the test vector. It takes a bit more work to
set CI[N] to a particular value, but we can do it with the correct choices
for A[N-1] and B[N-1].
If we want to set CI[N] to 0, what values
should A[N-1] and B[N-1] be set to? If we want to set CI[N] to 1? Assume
that we can't assume anything about the value of CI[N-1].
|
:
|
|
|
:
|
|
- Here's a proposed
set of 10 test vectors which we'd like to use as an exhaustive test of
the 32-bit ripple carry adder.
|
Test Vector
#
|
A[31:0]
|
B[31:0]
|
|
1
|
0x00000000
|
0x00000000
|
|
2
|
0x55555555 (even bits)
|
0x00000000
|
|
3
|
0x00000000
|
0x55555555 (even bits)
|
|
4
|
0x55555555 (even bits)
|
0x55555555 (even bits)
|
|
5
|
0xAAAAAAAA (odd bits)
|
0x00000000
|
|
6
|
0x00000000
|
0xAAAAAAAA (odd bits)
|
|
7
|
0xAAAAAAAA (odd bits)
|
0xAAAAAAAA (odd bitts)
|
|
8
|
0xFFFFFFFF
|
0xFFFFFFFF
|
|
9
|
0x00000001
|
0xFFFFFFFF
|
|
10
|
0xFFFFFFFF
|
0x00000001
|
E.
To see if the tests are exhaustive, fill in the following
table, indicating which test vectors tested which combinations of input
values. There are separate tables below for even adder bits (bits 2, 4, 6,
...) and odd adder bits (1, 3, 5, ...). Ignore adder bit 0 when filling in
the "Even adder bits" entries since it is a special case with its
CIN tied to ground.
|
Even adder
bits
|
Odd adder
bits
|
|
A
|
B
|
CIN
|
Tested?
|
A
|
B
|
CIN
|
Tested?
|
|
0
|
0
|
0
|
Yes, by A = 0x00000000 and B=0x00000000
|
0
|
0
|
0
|
Yes, by A = 0x00000000 and B=0x00000000
|
|
0
|
0
|
1
|
Yes, by A=0xAAAAAAAA and B=0xAAAAAAAA
|
0
|
0
|
1
|
Yes, by A=0x55555555 and B=0x55555555
|
|
0
|
1
|
0
|
|
0
|
1
|
0
|
|
|
0
|
1
|
1
|
|
0
|
1
|
1
|
|
|
1
|
0
|
0
|
|
1
|
0
|
0
|
|
|
1
|
0
|
1
|
|
1
|
0
|
1
|
|
|
1
|
1
|
0
|
|
1
|
1
|
0
|
|
|
1
|
1
|
1
|
|
1
|
1
|
1
|
|
- Three of compare
unit's inputs (Z, V and N) come from the adder/subtractor running in
subtract mode. To test the compare unit, we'll need to pick operands
for the adder/subtractor that generate all possible combinations of Z,
V and N. It's easy to see that any combination with Z = 1 and N = 1 is
not possible (the output of the adder cannot be negative and zero at
the same time!). It also turns out that combinations with Z = 1 and V
= 1 cannot be produced by a subtract operation.
For each of the combinations of Z, V and N
shown below, choose the subtraction operation that will produce the
specified combination of condition codes.
|
:
|
|
|
:
|
|
|
:
|
|
|
:
|
|
|
:
|
|
|