1.0 Motivation2.0 Introduction2.1 Verification Procedure2.2 Debugging Procedure2.2.1 Hypothesis2.2.2 Control2.2.3 Expected Output2.2.4 Observe2.2.5 Handling Test Results2.3 Types of Debugging (Parts of this Lab)3.0 Prelab4.0 Lab Procedure4.1 Bottom Up Testing4.1.1 Lab4Comp14.1.2 Lab4Comp44.1.3 Lab4PeakDetector4.2 Designing Test Hardware4.3 Exhaustive FSM Testing5.0 Lab 4 Check-offEECS150 Spring 2008 Lab 4UNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCEASSIGNED: Week of 9/25DUE: Week of 10/2, 10 minutes after start (xx:20) of your assigned lab section.Lab 4Debugging & Verification1.0 MotivationMany of you will be very familiar with the process of debugging software, andthanks to the circuits which you have had to build over the last few weeks, you’ve allbecome at least minimally familiar with debugging your own circuits. In this lab you willbecome acquainted with more formal debugging and verification techniques and tools aswe ask you to debug and verify a series of modules.2.0 IntroductionNo matter how carefully you plan and enter your circuit design, it should alwayscome as a major surprise if it works the first time you try it. The larger and morecomplicated the design, the larger the fraction of the engineering time you should expectto spend on debugging and verification. In a professional setting, a design would not beconsidered finished without a complete testing regimen to prove that it works acceptablyunder all circumstances, a process which can easily consume more than 50% of the timerequired to implement a design.In the interest of time, we cut a fair number of corners in this class, for examplerather than expecting your design to be fully verified (or even fully debugged), we willexpect it to appear to work. This is simply because we do not have time to fully examineyour testing regimen. However it is in your best interest to fully verify your modules.Most students will simply write a piece of Verilog and synthesize it, hopping that it willwork and perhaps wasting hours debugging it inefficiently.WE HIGHLY RECOMMEND THAT YOU CONSIDER WRITING AN APPROPRIATE ANDCOMPLETE TESTBENCH AN INTEGRAL PART OF WRITING A VERILOG MODULE. THIS WILLSAVE YOU MANY SLEEPLESS NIGHTS.2.1 Verification ProcedureThere are roughly two steps in the verification process:1. Perform a test2. If the test fails, debug the module being testedAs such there are two very different parts to the verification process, designingtests and actual debugging. We will discuss debugging in section 2.2 DebuggingProcedure below.UCB 1 2008EECS150 Spring 2008 Lab 4Because hardware modules are often very much larger and more complex thanpieces of software it is often not possible to fully verify a module. For example a 32bitadder accepts 264 possible combinations of inputs, so even if it could be run at 10GHz itwould take nearly 60 years to plug in all possible 264 inputs, even assuming that amatching 32bit adder could be built to test it against. To make matters worse, mostcircuits 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 runeasily.For more complicated modules, hardware engineers rely on bottom up testing andinterface contracts to ensure that the modules which they instantiate work as expected, asdo the modules with which they must interact. Over the course of this lab and theremainder of the semester you will become intimately familiar with this style of testing,as it is the only way to produce a fully working design.2.2 Debugging ProcedureOnce you know that something is working properly it is often a relatively tryingordeal to hunt down and fix the actual bug. Below is a formalized algorithm that you canuse as a starting point for your forays into debugging.2.2.1 HypothesisBefore starting to try and debug a design you must have a clear hypothesis ofwhat the problem might be. Even if your hypothesis is very much wrong you shouldalways have something specific that you are looking for when you start a debuggingsession. “Whatever is wrong” is not a specific enough goal.2.2.2 ControlWith a hypothesis of what is broken in mind, the next step in debugging is todevelop a set of test inputs which will test for the specific bug you expect. Usuallydeveloping the test inputs is one of the most difficult parts of the debugging andverification process.The difference between test inputs for general verification and for debugging issimple: inputs for debugging are meant to aid you in testing your hypothesis, whereasinputs for verification should be designed to elicit as wide a range of bugs as possible.2.2.3 Expected OutputBefore actually beginning a test, it is necessary to figure out what the expectedresult of the test will be. This should be a simple matter of working through the circuitspecification by hand using the test inputs, as developed according to section 2.2.2Control above.2.2.4 ObserveWith a hypothesis in mind and test outputs and expected outputs in hand it is nowtime to actually run the test. Unfortunately this is usually a very complicated process,made worse by slow simulation times, complex circuits and the difficulty of examiningsignals in hardware.UCB 2 2008EECS150 Spring 2008 Lab 4To make this step easier, a testbench or test harness can be developed to look forthe expected output and produce more meaningful reports of the success or failure of thetest. For example if the test succeeded, all we need to know is that it succeeded, not thehow or why of it.2.2.5 Handling Test ResultsIronically a test which fails is a major success during debugging. If the testsucceeds, all that has been proved is that the original hypothesis is false and that there isstill a bug in the circuit. However if the test fails, that means that the hypothesis has beenproven true and the bug has been found.When we say that “the bug has been found” we simply mean that it has beenfurther localized, that is to say, we have a better idea of what module or what signal iscausing the trouble. Fully specifying the bug and identifying the exact fix may requireseveral iterations of this debugging algorithm and many hours of work beyond the firsttest.ALWAYS BE SURE THAT YOU KNOW EXACTLY WHAT THE BUG IS AND HAVE A WELLDESIGNED FIX
View Full Document
Unlocking...