Time TableMotivationIntroductionVerification ProcedureDebugging ProcedureHypothesisControlExpected OutputObserveHandling Test ResultsTypes of Debugging (Parts of this Lab)PrelabLab ProcedureBottom Up TestingLab4Comp1Lab4Comp4Lab4PeakDetectorDesigning Test HardwareExhaustive FSM TestingReferencesLab 4 CheckoffFail Mode Tables:Bubble-and-Arc Diagram:EECS150: Lab 4, Debugging & VerificationUC Berkeley College of EngineeringDepartment of Electrical Engineering and Computer ScienceSeptember 19, 20081 Time TableASSIGNED Friday, September 19thDUE Week 5: September 28st− October 4th, 10 minutes after your lab section starts2 MotivationMany of you will be very familiar with the process of debugging software, and thanks to the circuitswhich you have had to build over the last few weeks, you’ve all become at least minimally familiar withdebugging your own circuits. In this lab you will become acquainted with more formal debugging andverification techniques and tools as we ask you to debug and verify a series of modules.3 IntroductionNo matter how carefully you plan and enter your circuit design, it should always come as a major surpriseif it works the first time you try it. The larger and more complicated the design, the larger the fractionof the engineering time you should expect to spend on debugging and verification. In a professionalsetting, a design would not be considered finished without a complete testing regimen to prove that itworks acceptably under all circumstances, a process which can easily consume more than 50% of thetime required to implement a design.In the interest of time, we cut a fair number of corners in this class, for example rather than expectingyour design to be fully verified (or even fully debugged), we will expect it to appear to work. This issimply because we do not have time to fully examine your testing regimen. However it is in yourbest interest to fully verify your modules. Most students will simply write a piece of Verilog andsynthesize it, hopping that it will work and perhaps wasting hours debugging it inefficiently.We highly recommend that you consider writing an appropriate and complete testbenchan integral part of writing a Verilog module. This will save you many sleepless nights.3.1 Verification ProcedureThere are roughly two steps in the verification process:1. Perform a test.2. If the test fails, debug the module being tested.As such there are two very different parts to the verification process, designing tests and actualdebugging. We will discuss debugging in Section 3.2.Because hardware modules are often very much larger and more complex than pieces of software it isoften not possible to fully verify a module. For example a 32 bit adder accepts 264possible combinations1of inputs, so even if it could be run at 10 GHz it would take nearly 60 years to plug in all possible 264inputs, even assuming that a matching 32 bit adder could be built to test it against. To make mattersworse, most circuits have some kind of memory requiring exponentially more time to test. Because ofthis exhaustive testing only suffices for the most basic of modules, where it can be run easily.For more complicated modules, hardware engineers rely on bottom up testing and interface contractsto ensure that the modules which they instantiate work as expected, as do the modules with which theymust interact. Over the course of this lab and the remainder of the semester you will become intimatelyfamiliar with this style of testing, as it is the only way to produce a fully working design.3.2 Debugging ProcedureOnce you know that something is working properly it is often a relatively trying ordeal to hunt downand fix the actual bug. Below is a formalized algorithm that you can use as a starting point for yourforays into debugging.3.2.1 HypothesisBefore starting to try and debug a design you must have a clear hypothesis of what the problem mightbe. Even if your hypothesis is very much wrong you should always have something specific that you arelooking for when you start a debugging session. “Whatever is wrong” is not a specific enough goal.3.2.2 ControlWith a hypothesis of what is broken in mind, the next step in debugging is to develop a set of test inputswhich will test for the specific bug you expect. Usually developing the test inputs is one of the mostdifficult parts of the debugging and verification process.The difference between test inputs for general verification and for debugging is simple: inputs fordebugging are meant to aid you in testing your hypothesis, whereas inputs for verification should bedesigned to elicit as wide a range of bugs as possible.3.2.3 Expected OutputBefore actually beginning a test, it is necessary to figure out what the expected result of the test willbe. This should be a simple matter of working through the circuit specification by hand using the testinputs, as developed according to Section 3.2.2.3.2.4 ObserveWith a hypothesis in mind and test outputs and expected outputs in hand it is now time to actually runthe test. Unfortunately this is usually a very complicated process, made worse by slow simulation times,complex circuits and the difficulty of examining signals in hardware.To make this step easier, a testbench or test harness can be developed to look for the expectedoutput and produce more meaningful reports of the success or failure of the test. For example if the testsucceeded, all we need to know is that it succeeded, not the how or why of it.3.2.5 Handling Test ResultsIronically a test which fails is a major success during debugging. If the test succeeds, all that has beenproved is that the original hypothesis is false and that there is still a bug in the circuit. However if thetest fails, that means that the hypothesis has been proven true and the bug has been found.When we say that “the bug has been found” we simply mean that it has been further localized, thatis to say, we have a better idea of what module or what signal is causing the trouble. Fully specifying thebug and identifying the exact fix may require several iterations of this debugging algorithm and manyhours of work beyond the first test.Always be sure that you know exactly what the bug is and have a well designed fix beforemodifying your code! Making random changes until the problem disappears will simplyprolong the problem and frustrate you!23.3 Types of Debugging (Parts of this Lab)In this lab, we will introduce you to four specific types of debugging, all of
View Full Document
Unlocking...