DOC PREVIEW
Berkeley COMPSCI 150 - Lab 4 Debugging & Verification

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

EECS150 Spring 2008 Lab 4 UCB 1 2008 UNIVERSITY OF CALIFORNIA AT BERKELEY COLLEGE OF ENGINEERING DEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE ASSIGNED: Week of 9/25 DUE: Week of 10/2, 10 minutes after start (xx:20) of your assigned lab section. Lab 4 Debugging & Verification 1.0 Motivation Many of you will be very familiar with the process of debugging software, and thanks to the circuits which you have had to build over the last few weeks, you’ve all become at least minimally familiar with debugging your own circuits. In this lab you will become acquainted with more formal debugging and verification techniques and tools as we ask you to debug and verify a series of modules. 2.0 Introduction No matter how carefully you plan and enter your circuit design, it should always come as a major surprise if it works the first time you try it. The larger and more complicated the design, the larger the fraction of the engineering time you should expect to spend on debugging and verification. In a professional setting, a design would not be considered finished without a complete testing regimen to prove that it works acceptably under all circumstances, a process which can easily consume more than 50% of the time required to implement a design. In the interest of time, we cut a fair number of corners in this class, for example rather than expecting your design to be fully verified (or even fully debugged), we will expect it to appear to work. This is simply because we do not have time to fully examine your 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 will work and perhaps wasting hours debugging it inefficiently. WE HIGHLY RECOMMEND THAT YOU CONSIDER WRITING AN APPROPRIATE AND COMPLETE TESTBENCH AN INTEGRAL PART OF WRITING A VERILOG MODULE. THIS WILL SAVE YOU MANY SLEEPLESS NIGHTS. 2.1 Verification Procedure There 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 actual debugging. We will discuss debugging in section 2.2 Debugging Procedure below.EECS150 Spring 2008 Lab 4 UCB 2 2008 Because hardware modules are often very much larger and more complex than pieces of software it is often not possible to fully verify a module. For example a 32bit adder accepts 264 possible combinations of inputs, so even if it could be run at 10GHz it would take nearly 60 years to plug in all possible 264 inputs, even assuming that a matching 32bit adder could be built to test it against. To make matters worse, most circuits have some kind of memory requiring exponentially more time to test. Because of this 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 contracts to ensure that the modules which they instantiate work as expected, as do the modules with which they must interact. Over the course of this lab and the remainder 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 Procedure Once you know that something is working properly it is often a relatively trying ordeal to hunt down and fix the actual bug. Below is a formalized algorithm that you can use as a starting point for your forays into debugging. 2.2.1 Hypothesis Before starting to try and debug a design you must have a clear hypothesis of what the problem might be. Even if your hypothesis is very much wrong you should always have something specific that you are looking for when you start a debugging session. “Whatever is wrong” is not a specific enough goal. 2.2.2 Control With a hypothesis of what is broken in mind, the next step in debugging is to develop a set of test inputs which will test for the specific bug you expect. Usually developing the test inputs is one of the most difficult parts of the debugging and verification process. The difference between test inputs for general verification and for debugging is simple: inputs for debugging are meant to aid you in testing your hypothesis, whereas inputs for verification should be designed to elicit as wide a range of bugs as possible. 2.2.3 Expected Output Before actually beginning a test, it is necessary to figure out what the expected result of the test will be. This should be a simple matter of working through the circuit specification by hand using the test inputs, as developed according to section 2.2.2 Control above. 2.2.4 Observe With a hypothesis in mind and test outputs and expected outputs in hand it is now time 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 examining signals in hardware.EECS150 Spring 2008 Lab 4 UCB 3 2008 To make this step easier, a testbench or test harness can be developed to look for the expected output and produce more meaningful reports of the success or failure of the test. For example if the test succeeded, all we need to know is that it succeeded, not the how or why of it. 2.2.5 Handling Test Results Ironically a test which fails is a major success during debugging. If the test succeeds, all that has been proved is that the original hypothesis is false and that there is still a bug in the circuit. However if the test 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, that is to say, we have a better idea of what module or what signal is causing the trouble. Fully specifying the bug and identifying the exact fix may require several iterations of this debugging algorithm and many hours of work beyond the first test. ALWAYS BE SURE THAT YOU KNOW EXACTLY WHAT THE BUG IS AND HAVE A WELL DESIGNED FIX BEFORE MODIFYING YOUR CODE! MAKING RANDOM CHANGES


View Full Document

Berkeley COMPSCI 150 - Lab 4 Debugging & Verification

Documents in this Course
Lab 2

Lab 2

9 pages

Debugging

Debugging

28 pages

Lab 1

Lab 1

15 pages

Memory

Memory

13 pages

Lecture 7

Lecture 7

11 pages

SPDIF

SPDIF

18 pages

Memory

Memory

27 pages

Exam III

Exam III

15 pages

Quiz

Quiz

6 pages

Problem

Problem

3 pages

Memory

Memory

26 pages

Lab 1

Lab 1

9 pages

Memory

Memory

5 pages

Load more
Download Lab 4 Debugging & Verification
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lab 4 Debugging & Verification and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lab 4 Debugging & Verification 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?