CS152 Computer Architecture and Engineering Lecture 3 Testing Processors 2004 09 07 Dave Patterson www cs berkeley edu patterson John Lazzaro www cs berkeley edu lazzaro www inst eecs berkeley edu cs152 CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Last Lecture Clocked Logic Review design description Schematic Diagrams Timing Diagrams Verilog CS 152 L03 Testing Processors Intel XScale ARM Pipeline JSSC 36 11 November 2001 UC Regents Fall 2004 UCB Outline Testing Processors The four types of testing Making a test plan Unit testing techniques CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Lecture Focus Testing 152 Projects testing goal The processor correctly executes programs written in the supported subset of the MIPS ISA CS 152 L03 Testing Processors d e e p s k c o l C I P g n C i om UC Regents Fall 2004 UCB Four Types of Testing CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Big Bang Complete Processor Testing Top down testing complete processor testing Lab 1 how it works Assemble the complete processor Execute test program suite on the processor Bottom up testing Check results Why is this method Whatappealing makes a good test CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Methodical Approach Unit Testing Top down testing how it works complete processor testing Remove a block from the design Test it in isolation against specification unit testing Bottom up testing What if the specification has a bug CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Administrivia Mini Lab 1 a Success Survey due today Mini Lab 2 this Friday 9 10 Remember to do the pre lab Lab 1 due Monday 9 13 Don t wait to get started First homework out soon due 9 15 CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Four Types of Testing continued CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Climbing the Hierarchy Multi unit Testing how it works Top down testing Remove connected blocks from design complete processor testing multi unit testing unit testing Bottom up testing Test in isolation against specification How to choose partition How to create CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Processor Testing with Self Checking Units Top down testing how it works complete processor testing Add self checking to units processor testing with self checks multi unit testing unit testing Perform complete processor testing Bottom up testing Good for Xilinx ModelSim Why not use self checks for all CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Testing Verification vs Diagnostics Top down testing complete processor testing processor testing with self checks multi unit testing unit testing Bottom up testing CS 152 L03 Testing Processors Verification A yes no answer to the question Does the processor have one more bug Diagnostics Clues to help find and fix the bug Which testing types are good for verification For UC Regents Fall 2004 UCB Writing a Test Plan peer instruction CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Test Plan Fill in the testing timeline Top down testing complete processor testing Which testing types are good for each epoch Epoch 1 Epoch 2 Epoch 3 Epoch 4 processor testing with self checks multi unit testing Time unit testing Bottom up testing CS 152 L03 Testing Processors processor assembly complete correctly executes single instructions correctly executes short programs UC Regents Fall 2004 UCB Fill in the testing timeline Answer Top down testing complete processor testing processor testing with self checks multi unit testing Which testing types are good for each epoch Epoch 1 Epoch 2 Epoch 3 Epoch 4 unit testing early processor processor complete testing testing processor with with testing self checks self checks verificati on processor multi multi unit multi unit unit testing testing testing testing with unit testing unit testing self checks later unit testing Bottom up testing CS 152 L03 Testing Processors diagnostidiagnosti diagnosti cs cs cs Time processor assembly complete correctly executes single instructions correctly executes short programs UC Regents Fall 2004 UCB Testing Mechanics Asset Management adder v One directory holds all datapath units Adder unit adder utb v Unit testing test bench for adder adder sc v Self checking wrapper for adder unit Follow a file naming convention Why Instantiate into utb and sc is a multi unit instantiates adder regfile shifter mid dpath not copypaste CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Unit Testing CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Combinational Unit Testing 3 bit adder Cin A B 3 3 Cout CS 152 L03 Testing Processors 3 Sum Number of input bits Total number of possible input 7 2 values 128 7 Just test them all Apply test vectors 0 1 2 127 to inputs 100 input space coverage Exhaustive testing UC Regents Fall 2004 UCB Combinational Unit Testing 32 bit adder Cin A B 32 32 Cout 32 Number of input bits Total number of possible input 65 2 values Sum 3 689e 1 Just test them all 9 65 Exhaustive testing does not scale Combinatorial explosion CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Test Approach 1 Random Vectors Cin A B 32 32 how it works Apply random A B Cin to adder 32 Sum Check Sum Cout Bug curve When to stop testing Bug Cout Rate Time CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Test Approach 2 Directed Vectors Cin e t c ire A B 32 how it works D Hand craft d test vectors m o d n a to cover rSum 32 corner cases 32 A B Cin 0 Cout Black box Corner cases based on functional properties Clear box Corner cases based on unit internal structure Examples Examples CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Testing State Machines Break Feedback Rst Change D Next State Combinational Logic D R G Q D Q Q Y Isolate Next State logic Test as a combinational unit Easier with certain Verilog coding styles CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Testing State Machines Arc Coverage Rst 1 Change 1 RYG 100 RYG 001 Change 1 RYG 010 Change 1 Force machine into each state Test behavior of each arc Is this technique always practical to use CS 152 L03 Testing Processors UC Regents Fall 2004 UCB Final Thought When bugs escape Testing our financial trading system we found a case where our software would get a bad calculation Once a week or so Eventually the problem turned out to be a failure in a CPU cache line refresh This was a hardware design fault in the PC The test suite included running for two weeks at maximum
View Full Document
Unlocking...