Debugging Commandments

Anything that can go wrong will go wrong. Which means that you need to follow this checklist every time you want to debug.

1. Visually Inspect the Board
   A quick check to verify that chips are still plugged in, no wires have broken, or pins bent, is worth a minute, before you start, but is unlikely to find most bugs.
2. Check Software Functionality
   Is the computer system and network functioning? Are your files missing pieces or corrupted? (You do have floppy backups, right?) Verify that the software tools are working as expected. Compile a known working schematic; do the tools still work, such as ViewSim and EDIF?
   (Please send mail to cs150@po and cs150support@deepthought if software tools malfunction).
3. Check Hardware Functionality
   Are all cables, oscilloscope and logic probes working? (You can check the oscilloscope probes by using the Calib output on the front of the oscilloscope. You should see a nice square wave). Is test equipment set up for desired sweep rate, volts-per-division, etc. (Please notify your TA about bad cables so other students won't have to find them the hard way). Do you really have +5V on your Xilinx board? Verify that download cable, Xilinx board, RAM, camera, camera software, A/D and serial output are still working by running the TA project file on your board.
4. Verify that you are using the correct version of your design. Did you run check -p design-name to make sure you updated all the .WIR files?
5. Check System Essentials
   Is the clock running at the expected frequency? Do voltage levels seem reasonable (using oscilloscope to measure)? Are your state machines running?
6. Divide and Conquer
   ``Complex systems usually present designers with complex problems to solve during system debugging. At times overwhelming, may of these problems are easily solved when addressed in an orderly manner. A divide and conquer technique is commonly used to debug complex systems.
   First, concentrate on problem identification. Next, isolate the questionable circuitry from the rest of the system. Isolation allows you to observe output-signal integrity.''

   The three keys to efficient divide and conquer debugging are:

   1. Model Expected Behavior. What do you expect to see? ViewSim tells you what you have (with unrealistic unit delay model). It can NOT tell you what you need to see.
   2. Measure the real system's behavior using oscilloscope and/or logic analyzer. Where are the differences from your model significant?
   3. Hypothesize possible errors.
   4. Controllability and Observability. Force module inputs to verify hypotheses, and observe outputs. Are outputs consistent with your model, or is something not functioning as expected? One of the best ways to force the system to a known state is using the Xchecker tools and single stepping your design.
7. Understand Component Devices
   Are you sure you understood the data sheet correctly on that part?
8. Know your Software
   Is the serial protocol what you expect? Also, logic without loads or sources may be eliminated, and routing is non-deterministic -- are you expecting that? Look at warning messages in the log file. Sometimes they matter. Make life easier for yourself by labelling every component such as U5-1 for component 5 on page 1.
9. Know Your Test Equipment
   The digital scope will give nonsense if the sweep rate is too high or too low. The logic analyzer can not tell you that a signal which appears to be random is actually just floating at 1.5V, and not connected to any output. When in doubt about a signal, verify that you have proper logic levels using the oscilloscope. For example, the oscilloscope can find a short between two outputs pretty easily since there can be an intermediate voltage level, neither zero nor one. The logic analyzer can't tell you this.
10. Take a Break/Get a New Perspective
    Debugging is mentally taxing, and we tend to focus in narrowly on particular suspect areas. Taking a break opens the mind to a wider range of possibilities and can get you out of a rut.