Debug will get your attention, sooner or later

One alarming trend that is not necessary is the increasing proportion that debugging consumes in the design cycle. Within functional verification, it is the single largest component at approximately 60 percent and is projected to grow even larger. Broadly speaking, the reason for this trend is that traditional debug practices are not adequate for today’s problems.

Sooner or later, debug will get your attention.

Today, debug gets your full attention when problems occur. More specifically, not much thought is given to debug until it is actually performed. In such cases, according to Murphy’s Law, debug will get your full attention at the worst possible time.

For example, a dreaded bug will be found near the end of the cycle and the problem will be bounced like a ping-pong ball between multiple engineers consuming valuable time. The problem will be elevated to higher levels of management, making it both stressful and embarrassing for the technically savvy engineers. Of course, this leads to a “blame game” across groups since most tough bugs fall through the cracks of responsibility.

Can you avoid this scenario? Not entirely. Can you reduce its likelihood to occur and reduce its impact? Absolutely. The key is to give debug your attention sooner rather than later.

Here is some advice that takes relatively little time to develop, but can provide huge benefits.

Anticipate problems up front
When developing the testbench and checkers, engineers should not only think of checks that can detect problems, but should also anticipate the type of information that can help debug the problem. Some examples:

• When a problem is detected, is it possible to derive an expect/correct value?

• When a problem is detected, is it possible to determine at what time the failure occurred in the DUT (i.e. as opposed to the testbench)?

• If an expected value exists, is it possible to generate the corresponding value at different interesting module boundaries such as the design under test (DUT) pins?

• When a problem is detected, what other signal values or events would be interesting to know at the time of the failure?

• When a problem is detected, can the failure be associated to the stimulus events?