Download
1 / 10
100 likes | 175 Views
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
E N D
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 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 patterns0000…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 generatedor 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 patterns1111…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!
