DebuggingToday (1)Today (2)Simulation vs. Hardware (1)Simulation vs. Hardware (2)Simulation vs. Hardware (3)Debugging (1)Debugging (2)Debugging (3)Debugging (4)Debugging (5)Debugging (6)Debugging (7)Administrative InfoLab #4 - DebuggingPart1: Bottom Up Testing (1)Part1: Bottom Up Testing (2)Part1: Bottom Up Testing (3)Part1: Bottom Up Testing (4)Part1: Bottom Up Testing (5)Part1: Bottom Up Testing (6)Part1: Bottom Up Testing (7)Part1: Bottom Up Testing (8)Part2: Test Hardware (1)Part2: Test Hardware (2)Part2: Test Hardware (3)Part3: FSM Testing (1)Part3: FSM Testing (2)01/14/19 EECS150 Lab Lecture #4 1DebuggingEECS150 Fall 2007 – Lab Lecture #4Shah Bawany2/9/2007 EECS150 Lab Lecture #4 2Today (1)Simulation vs. HardwareDebuggingAlgorithmGoalsTipsAdministrative Info2/9/2007 EECS150 Lab Lecture #4 3Today (2)Lab #4Bottom Up Testing (Peak Detector)Designing Test Hardware (Broken Adder)Exhaustive FSM Testing (Broken FSM)2/9/2007 EECS150 Lab Lecture #4 4Simulation vs. Hardware (1)Debugging in SimulationSlow Running TimeFast DebuggingWaveformsText messagesFull VisibilityCan examine any signalEasy to FixA few minutes to compile and resimulateModelsim assumes no gate delay2/9/2007 EECS150 Lab Lecture #4 5Simulation vs. Hardware (2)Debugging in HardwareFast Running TimeFull speed in factSlow DebuggingSynthesis can take hoursLittle or No VisibilityVery hard to probe signals2/9/2007 EECS150 Lab Lecture #4 6Simulation vs. Hardware (3)SimulationFunctional Testing & VerificationTest everything at least minimallyFully Verify what you canThis will save you many sleepless nightsHardwareDebuggingTreat this as a last resortIt is painfulHowever, it will sometimes be necessary (wireless)2/9/2007 EECS150 Lab Lecture #4 7Debugging (1)Debugging AlgorithmHypothesis: What’s broken?Control: Give it controlled test inputsExpected Output: What SHOULD it do?Observe: Did it work right?If it broke: THAT’S GREAT!If we can’t break anything like this then the project must be working…2/9/2007 EECS150 Lab Lecture #4 8Debugging (2)Don’t debug randomlyJust changing things at random often makes things look fixedIt won’t really helpDebug systematicallyYour first design may be the bestWhat can you do?2/9/2007 EECS150 Lab Lecture #4 9Debugging (3)High Level DebuggingLocalize the problemSDRAM? Video?Test PatternsLets you easily isolate the broken componentIf you know exactly what’s going in you can check what’s coming out2/9/2007 EECS150 Lab Lecture #4 10Debugging (4)Simulate the broken component(s)Writing test benches takes less time than sitting around wondering why its brokenEveryone hates writing testbenches(Even me)Get used to it2/9/2007 EECS150 Lab Lecture #4 11Debugging (5)Your best debugging tool is logicIf 3 out of 4 components work, what’s broken?Question all your assumptions!Just because you think its true doesn’t mean it is90% of debugging time is wasted debugging the wrong problem otherwiseGiven solutions and modules may not work the way you expect!2/9/2007 EECS150 Lab Lecture #4 12Debugging (6)Before you change anythingUnderstand exactly what the problem isFind an efficient solutionEvaluate alternative solutionsAfter the changeFixes may make things worse sometimesMay uncover a second bugMay be an incorrect fixRepeat the debugging process2/9/2007 EECS150 Lab Lecture #4 13Debugging (7)Ask aroundSomeone else may have had the same bugThey’ll probably at least know about where the problem isDifferent bugs may produce the same resultsTAsThe TAs know common problemsWe’re here to help, not solve it for you2/9/2007 EECS150 Lab Lecture #4 14Administrative InfoMidterm IThursday 9/27Reviews session is:Tuesday 9/25, 8-10pm, 125 CoryPartnersYou MUST have one for this weekRestrictionsYou can change partners until the project startsYou must be checked off in the same labProject begins in 2 weeks!2/9/2007 EECS150 Lab Lecture #4 15Lab #4 - DebuggingPart 1: Bottom Up TestingPart 2: Hardware TestingPart 3: FSM Testing2/9/2007 EECS150 Lab Lecture #4 16Part1: Bottom Up Testing (1)What if EqualOut = 1’b0 and GreaterOut = 1’b0?Lab4Comp12/9/2007 EECS150 Lab Lecture #4 17Part1: Bottom Up Testing (2)Exhaustive TestingIdeal Testing MethodCircuit is 100% tested!Requires us to test a LOT!Can we do it here? (24 possible inputs)MethodMake a truth tableHave the testbench generate all inputsMake sure outputs match truth table2/9/2007 EECS150 Lab Lecture #4 18Part1: Bottom Up Testing (3)Lab4Comp1 Lab4Comp1 Lab4Comp1 Lab4Comp1Lab4Comp42/9/2007 EECS150 Lab Lecture #4 19Part1: Bottom Up Testing (4)Exhaustive Testing?28 = 256 Possible InputsMethodUse a for loop to generate all inputsLoops allowed only in testbenchesThey will not synthesizeCompare against a “>=“Print a message if they differ2/9/2007 EECS150 Lab Lecture #4 20Part1: Bottom Up Testing (5)Lab4PeakDetector2/9/2007 EECS150 Lab Lecture #4 21Part1: Bottom Up Testing (6)Exhaustive Testing?24 = 16 Possible Inputs24 = 16 Possible States16*16 = 256 combinationsWe could do it in this caseCan’t exhaustively test most FSMsToo many state/input combinationsMust rely on directed testing2/9/2007 EECS150 Lab Lecture #4 22initial beginendPart1: Bottom Up Testing (7)integer i;reg [3:0] TestValues[1:16];$readmemh("TestValues.txt", TestValues);for(i = 1; i <= 16; i = i + 1) begin#(`Cycle);In = TestValues[i]; $display("In = %d, Peak = %d", In, Peak);end2/9/2007 EECS150 Lab Lecture #4 23Part1: Bottom Up Testing (8)Read Test Vectors from a FileDesigning Test VectorsMake sure to cover most casesWe want 95%+ coverageDesigning test vectors is a “black art”“$” ProcessesNot synthesizeableMore information in IEEE Verilog Reference2/9/2007 EECS150 Lab Lecture #4 24Part2: Test Hardware (1)Lab4 Part2Lab4Part2TesterFailModeFailMode2/9/2007 EECS150 Lab Lecture #4 25Part2: Test Hardware (2)Test ProcedureHit Reset (SW1)Hit Go (SW2)Record an errorDD1-8 show {A, B}SW10[1] selects the sum on DD4-8Hit GoRepeat until the tester stops2/9/2007 EECS150 Lab Lecture #4 26Part2: Test Hardware (3)The Broken Adder16bit Adder232 ≈4 Billion Test VectorsCan’t simulate this
View Full Document