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

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  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!

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…0000 and 0000…0000 0000…0000 and 1111…1111 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  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…1111 and 0000…0000 0000…0000 and 1111…1111 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  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 3 + 3 + 4 = 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  23 = 8 possible inputs Exhaustive testing … Total tests so far 3 + 3 + 4 = 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!

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!

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 ~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!