Reconfigurable Computing -Verifying Circuits

John MorrisChung-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!

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 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 …

2. 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 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 …

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