Techniques for finding faults

• Improve readability of trace
  • Choose a ‘simple’ clock frequency (e.g. ‘1 MHz’) if no real-time considerations
  • Add some artificial delays to signal changes
  • Have test harness signal raised in trace on error
    • Most waveform viewers allow searches for particular signals changing
  • Keep ‘phase’ variable in trace – easy to see what was being tested
• Export diagnostic information
  • Print $time with error reports
  • Print statements as simulation advances
  • Maybe $stop; after^† an error occurs …
  • … or stop reporting certain errors after N occurences of the same thing
• Test the tests
  • Induce failures to make sure the tests find them!

^†Taking another clock cycle or two before $stopping makes a wave trace easier to read.

Debugging

Every engineer has ideas on ‘the best’ way to find faults. We are not here to tell you how to do it. Here are some tips and ideas on some things which might be useful.

The two readily available methods for diagnosing simulations are using a wave-form view of selected signals and printing out diagnostic values.

The first is most useful when first debugging a unit. Errors are expected and the desired diagnostic information is unclear. It gives a more interactive debugging route. The second method is to check and print diagnostics into a log file. This is most useful when tests are run repeatedly (such as checking to see that a fault has not been introduced) and automation is more important than interactivity.

Waveform trace

In small designs all the signals can be traced. In large designs and long simulations keeping all the traces may not be feasible because it slows down the run and can fill the filestore quite quickly.

• Choose some key nodes which will give plenty of information.

These are often near the top level of the hierarchy although the control state of various FSMs can be very useful.

• As far as possible, keep signal names the same throughout the hierarchy.
• Name (major) instances to simplify browsing.

These are points for the design rather than the test phase but can prove big time savers when diagnosing problems. Having a few dozen different buses all called “data” on the display is not conducive to clarity!

• Mark points of failure within the run.

The simplest method is to stop just after a fault is found. Don't stop immediately – it's useful to have a bit more trace to see the faulty values. This makes the fault easy to find.

Alternatively, a signal in the test harness can be switched or pulsed to flag up the position of an error.

Most waveform viewers will allow searches for transitions on selected signals. By creating a test variable which indicates a fault condition it is easy to locate a point of failure in a large trace.

A related technique is to use a test state variable to indicate which phase of a long test is being executed.

$display("Resetting");
test_state = 0;
…
…
$display("Phase 1");
test_state = test_state + 1;
…
…

This is useful as a test file grows to cover a large number of different tests.

• Keep a test state variable to show phases of a long test.

A variable in the test harness which changes according to which test is current is useful for navigating through long traces. This is particularly useful when revisiting a waveform trace after a ‘new’ problem has been found.

Log file

Commands such as $display and $monitor allow progress through a test to be checked.

• A few judicious printed strings help follow progress through a test.
• Including the time can help if returning to a trace to diagnose a fault.
• Printing ‘okay’ at the end (if appropriate!) is reassuring.

At this stage it is likely that you want to know that an error has occurred but little else. The sort of thing to look for may be an expected and an obtained value, and printing both in the case of a mismatch may be useful. A printed heading will indicate which test failed.

• Use experience gained in debugging to set up appropriate tests.

Finally …

As in software, conditional compilation (`ifdef) may be used to embed debugging information in synthesizable blocks yet exclude it from synthesis.

Up to testing.

Back to test ordering.

Forward to test delays.