Testbench logging is front end of debug. Primary objective for logging is to provide clues into failure and help root cause the issue for failure. Logging objectives should be aligned to three phases of debug. This should be achieved with the help of verbosity.

Logging messages are of two types.

• Error messages from checks and assertions
• Debug messages from verification components

Error messages objectives

Failure of checks should be logged with the meaningful error message. Writing cryptic error messages is like sentencing “debug” to hang till death.

Error messages provide vital clues and insights into nature of failure and set direction for debug. If they are not clear, already heavy activity like debug becomes even heavier.

A high quality error messages makes two things very clear:

• What was expected by the check
• What has actually happened

Along with this including any additional information to trace to cause of problem is extremely valuable.

Debug messages objectives

Debug messages are meant to serve the purpose of helping confirming the root cause of failure. Debugging is a process to reach the root cause of the failure. This requires insights into stimulus generated, how it has been translated, responses received, various events taking place, state changes etc.

From debug logging point of messages can be classified into three different categories. They are based on the phases in which debug progresses.

These can be mapped to three levels of verbosity in logging utility. Based on the requirement appropriate verbosity can be enabled.

Throughout this discussion USBx will used as example to make some points. Just defining few key terms to make it easier for understanding. USB3x is a layered protocol, the protocol data unit(PDU)s at application level is called transfer, PDUs at protocol layer are called transactions and PDUs at link layer are called symbols and symbols are converted to bits are driven out the on USB wires. Application level stimulus is communicated to USB3x host controller using the XHCI protocol.

Step 1: RTL vs. Testbench isolation debug

The first level of debug verbosity should contain the messages that should help isolate the cause of failure between the RTL or Testbench or both. In the “RTL vs. Testbench” debug verbosity mode, the stimulus generated and response received should be logged. This information should correlate to the specification.

The messages of this verbosity should be such that it can be understood by anyone who understands the requirements specifications. For example if its USB3x host controller DUT, the messages should be in format that is easy to correlate to XHCI and USB3x specifications. Anyone who understands the XHCI and USB3x specifications should be able to understand what is happening from the log files. Both verification and design engineers use this verbosity.

If the issue is classified as RTL issues it takes deviation from this point. It does not rely on log files for further debug. It relies on the waveforms to isolate and root cause the issue to a specific block within the design.

If the issue is classified as testbench issue, debug continues to rely on the logging and uses the next two levels of verbosity to root cause the issue to a specific verification component within the testbench.

Step 2: Testbench component isolation debug

This verbosity should be able to help isolate the issue so a specific component among various components of the testbench. The messages of this verbosity should be easy to understand for anyone who understands the testbench architecture.

One should be able to find out if the transaction has left a particular block, has it reached next block, what is being awaited etc. If it can help root cause the issue as well it’s a bonus. The verification team uses this verbosity.

Step 3: Verification component root cause debug

This verbosity should help root cause the issue within a component. Anyone who is familiar with the component should be able to understand the messages and be able to get to task, function or thread that might be causing the issue.

This verbosity level provides the freedom to component developer to structure it the way it fits his needs. Its least restricted phase of verbosity used only by the verification component developers to debug the functionality within their block.