Reconfigurable Computing - Verifying Circuits John Morris Chung-Ang University The University of Auckland ‘Iolanthe’ at 13 knots on Cockburn Sound, Western Australia

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!

Verification  Circuits need to be verified  Testing is expensive!  32-bit adder – inputs a, b, c  Naïve approach - Test all possibilities a – 4  10 9 ( all possible 32-bit numbers ) b – 4  10 9 ( do ) c – 2 ( 0 or 1 ) Total 4  4  2  = 1.6 x GHz machine – 10 9 cases / sec (optimistic!) 1.6  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!

Case study – Ripple carry adder  Composed of full adder circuits and carry chains  Test the full adders  3 inputs, each with 2 possible values  2 3 = 8 possible inputs  In this case, exhaustive testing (trying every possible combination of inputs) will work fine! 1.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…0000 and 0000… …0000 and 1111… …1111 and 0000…0000 (3 tests)

Case study – Ripple carry adder  Composed of full adder circuits and carry chains  Test the full adders  3 inputs, each with 2 possible values  2 3 = 8 possible inputs  Exhaustive testing … 2.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 generate 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…1111 and 0000… …0000 and 1111… …1111 and 1111…1111 and a carry in set to 1

Case study – Ripple carry adder  Composed of full adder circuits and carry chains  Test the full adders  3 inputs, each with 2 possible values  2 3 = 8 possible inputs  Exhaustive testing … 3.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

Case study – Ripple carry adder  Composed of full adder circuits and carry chains  Test the full adders  3 inputs, each with 2 possible values  2 3 = 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 FA 0 ) so we could possibly claim that we’ve verified everything!

Case study – Ripple carry adder  Composed of full adder circuits and carry chains  Test the full adders  3 inputs, each with 2 possible values  2 3 = 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 tests!

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

Random Testing  With automated test generation  For example, use an FPGA to generate test vectors!  Testing can be very fast  ~10 9 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!