Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCB2004-09-07 Dave Patterson(www.cs.berkeley.edu/~patterson)John Lazzaro (www.cs.berkeley.edu/~lazzaro)www-inst.eecs.berkeley.edu/~cs152/CS152 – Computer Architecture andEngineeringLecture 3 – Testing ProcessorsCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBLast Lecture: Clocked Logic ReviewIntel XScale ARM Pipeline, JSSC 36:11, November 2001Schematic DiagramsTiming DiagramsVerilogdesign descriptionCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBOutline - Testing ProcessorsThe four types of testing.Making a test plan.Unit testing techniques.CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBLecture Focus: Testing 152 Projectstesting goalThe processor correctly executes programs written in the supported subset of the MIPS ISAClock speed? CPI? Upcoming lectures ...UC Regents Fall 2004 © UCBCS 152 L03 Testing Processors ()Four Types of TestingCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBBig Bang: Complete Processor Testinghow it worksAssemble the complete processor.Execute test program suite on theprocessor.Check results.Top-downtestingBottom-uptestingcomplete processor testing(Lab 1)Why is this method appealing?What makes a good test program suite?CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBMethodical Approach: Unit Testinghow it worksRemove a block from the design.Test it in isolation against specification.complete processor testingTop-downtestingBottom-uptestingWhat if the specification has a bug?unit testingCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBAdministrivia - Mini-Lab 1 a Success!Survey due today! First homework out soon --due 9/15.Lab 1 due Monday 9/13. Don’t wait to get started!Mini-Lab 2 this Friday (9/10).Remember to do the pre-lab!UC Regents Fall 2004 © UCBCS 152 L03 Testing Processors ()Four Types of Testing(continued)CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBClimbing the Hierarchy: Multi-unit Testinghow it worksRemove connected blocksfrom design.Test in isolation againstspecification.complete processor testingTop-downtestingBottom-uptestingHow to choose partition?unit testingHow to create specification?multi-unit testingCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBProcessor Testing with Self-Checking Unitshow it worksAdd self-checking to unitsPerform complete processor testingcomplete processor testingTop-downtestingBottom-uptestingunit testingmulti-unit testingprocessortestingwithself-checksGood for Xilinx? ModelSim?Why not use self-checks for all tests?CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTesting: Verification vs. Diagnosticscomplete processor testingTop-downtestingBottom-uptestingunit testingmulti-unit testingprocessortestingwithself-checksWhich testing types are good for verification? For diagnostics?Verification:A yes/no answer to the question “Does the processor have one more bug?”Diagnostics:Clues to help find and fix the bug.UC Regents Fall 2004 © UCBCS 152 L03 Testing Processors ()Writing a Test Plan(peer instruction)CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTest Plan: Fill in the testing timelinecomplete processor testingTop-downtestingBottom-uptestingunit testingmulti-unit testingprocessortestingwithself-checksWhich testing types are good for each epoch?processorassemblycompletecorrectlyexecutes singleinstructionscorrectlyexecutes shortprogramsTimeEpoch 1 Epoch 2Epoch 3 Epoch 4CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBFill in the testing timeline: Answer:complete processor testingTop-downtestingBottom-uptestingunit testingprocessortestingwithself-checksWhich testing types are good for each epoch?processorassemblycompletecorrectlyexecutes singleinstructionscorrectlyexecutes shortprogramsTimeEpoch 1 Epoch 2Epoch 3 Epoch 4unit testingearlymultiunit testinglatermulti-unit testingprocessortestingwithself-checksmulti-unit testingunit testingdiagnosticscomplete processor testingverificationprocessortestingwithself-checksdiagnosticsprocessortestingwithself-checksmulti-unit testingunit testingdiagnosticsCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTesting Mechanics: Asset ManagementOne directory holds all datapath units.mid_dpath is a multi-unit: instantiates adder, regfile, shifter.adder.vAdder unit. adder_utb.vUnit testingtest bench for adder.adder_sc.vSelf-checking wrapper for adder unit.Follow a file naming convention! Why?Instantiate into_utb and _sc,not copy-paste! Why?UC Regents Fall 2004 © UCBCS 152 L03 Testing Processors ()Unit TestingCS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBCombinational Unit Testing: 3-bit adder3A3B3SumCoutCin+Number of input bits ?7Total number of possible input values?27= 128Just test them all ...Apply “test vectors”0,1,2 ... 127 to inputs.100% input space “coverage”“Exhaustive testing”CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBCombinational Unit Testing: 32-bit adder32A32B32SumCoutCin+Number of input bits ?65Total number of possible input values?3.689e+19Just test them all?Exhaustive testing does not “scale”.“Combinatorial explosion!”265=CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTest Approach 1: Random Vectors 32A32B32SumCoutCin+how it worksApply randomA, B, Cin to adder.Check Sum, Cout.Bug curve.TimeBug RateWhen to stop testing?CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTest Approach 2: Directed Vectors 32A32B32SumCoutCin+how it worksHand-craft test vectorsto cover“corner cases” A == B == Cin == 0“Black-box”: Corner cases based on functional properties.“Clear-box”: Corner cases based on unit internal structure.Examples ?Examples ?Directed random?CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTesting State Machines: Break Feedback Next State Combinational LogicChangeRstYGD QD QD QRIsolate “Next State” logic. Test as a combinational unit.Easier with certain Verilog coding styles?CS 152 L03 Testing Processors () UC Regents Fall 2004 © UCBTesting State Machines: Arc Coverage Change == 1Change == 1 Change == 1R Y G1 0 0 R Y G0 0 1 R Y G0 1 0 Rst == 1Force machine into each state. Test behavior of each arc.Is this technique always practical
View Full Document
Unlocking...