1. Reconfigurable Computing - Verifying Circuits
John Morris
The University of Auckland
Iolanthe II at anchor near the Marsden Cross, Bay of Islands

2. Verification Circuits need to be verified This is completely obvious!
A circuit with an error
Costs money
How much did Intel’s Pentium divide bug cost them?
May endanger lives
Medical systems
Aircraft control
Spacecraft guidance
Spoil your reputation!
Testing is expensive!

3. Verification Circuits need to be verified Testing is expensive!
32-bit adder – inputs a, b, c
Naïve approach - Test all possibilities
a – 4  109 (all possible 32-bit numbers)
b – 4  109 ( do )
c – 2 ( 0 or 1 )
Total 4  4  2  1018 = 1.6 x 1019
4 GHz machine – 109 cases / sec (optimistic!)
1.6  1010 seconds – about 6 months will do it!
What about the rest of the machine?
-, x, /, ^, v, <<, >>, …
We should be finished in about 5 years
Hmmmm … our 4 GHz machine should be about 30 GHz now!
Clearly we need to be more efficient about testing!

4. Case study – Ripple carry adder
Composed of full adder circuits and carry chains
Test the full adders
3 inputs, each with 2 possible values  23 = 8 possible inputs
In this case, exhaustive testing (trying every possible combination of inputs) will work fine!
We can probably work out how to check all the full adders individually at the same time
If there are no carries, then they all operate independently
Input pairs (a=0,b=0) (a=0,b=1) and (a=1,b=0) all generate no carries, so we can test the inputs (a,b,c) = (0,0,0) (0,1,0) (1,0,0) (3 out of 8 cases) for each FA in parallel with the patterns …0000 and 0000… …0000 and 1111… …1111 and 0000… (3 tests)

5. Case study – Ripple carry adder
Composed of full adder circuits and carry chains
Test the full adders
3 inputs, each with 2 possible values  23 = 8 possible inputs
Exhaustive testing …
We can also check the cases where a carry is generated or propagated when there is a carry in
Input pairs (a=1,b=0) (a=0,b=1) and (a=1,b=1) all propagate a carry, so we can test the inputs (a,b,c) = (1,0,1) (0,1,1) (1,0,1) (3 out of 8 cases) for each FA in parallel with the patterns …1111 and 0000… …0000 and 1111… …1111 and 1111… and a carry in set to 1

6. Case study – Ripple carry adder
Composed of full adder circuits and carry chains
Test the full adders
3 inputs, each with 2 possible values  23 = 8 possible inputs
Exhaustive testing …
Finally we have the cases where
a carry in is ‘absorbed’ (ie not propagated) (0,0,1)
a carry is generated when there is no carry in (1,1,0)
We can try to be efficient here and generate alternating patterns that test every second FA for these two cases
4 tests
Total tests so far
= 10

7. Case study – Ripple carry adder
Composed of full adder circuits and carry chains
Test the full adders
3 inputs, each with 2 possible values  23 = 8 possible inputs
Exhaustive testing …
Total tests so far
= 10
Now we’ve checked
Each FA block
Carry links between each block
Carry out (whenever carry is generated, we check the carry out from the whole circuit too!)
Carry in (needed to generate carry input to FA0)
so we could possibly claim that we’ve verified everything!

8. Case study – Ripple carry adder
Composed of full adder circuits and carry chains
Test the full adders
3 inputs, each with 2 possible values  23 = 8 possible inputs
Exhaustive testing …
10 tests adequate?
A formal argument certainly claims it!
A thorough tester would probably want to check
Different carry chain lengths
Testing so far has only checked a carry propagated
Across 1 link
Along the full adder
(there may be some circuit loading or cross-talk patterns that produce glitches)
Different numbers of sum bits
… possibly some more
But we can certainly get away with far less than 1.6 x 1019 tests!

9. Equivalence Classes
We reduced the number of tests by just working out which tests were ‘different’
They processed the inputs in a different way
We avoided tests which – although the inputs differed – were basically similar to other tests
This is formally known as identifying the equivalence classes
An equivalence class contains all the inputs which cause basically the same actions to occur
In the RC adder case, random inputs would just apply the 8 input patterns for each FA block to different parts of the adder
Our tests ensured that
all 8 possible patterns were tried
for each FA in the full circuit

10. Random Testing With automated test generation
For example, use an FPGA to generate test vectors!
Testing can be very fast
~109 tests / second is possible
Programmed generation of random numbers can apply large numbers of tests in reasonable times
However
There’s always a (non-zero) probability that some vital test will be missed
It is sometimes difficult to calculate (or generate) the expected answer
After all, that’s what the circuit you’re testing is supposed to do!!
Random testing sometimes relies on the absence of exceptions rather than checking that the answer is right!