Before a chip or system goes into manufacturing, a development team wants to ensure that the design has as few bugs as possible given the constraints of time and money. That is the act of verification and the level of confidence in measured using coverage. When a problem is found, the debug process starts and it has been reported that this may consume between 35% and 50% of total project time. This figure includes finding and fixing bugs in the design and those that exist within the verification environment. What is more alarming to many teams is that after a bug has been found, the time to a fix is unpredictable. Much of the debug process is unpredictable and developing the right fix can be problematic, possibly introducing new bugs in the process.
There are two fundamental approaches to debug. The first is to discover a problem, usually through the execution of a model of the design using a testcase, and then attempt to find the root cause of the problem and determine a solution. The second method is to do analysis on a system, usually through static analysis tools that attempt to discover a class of problems using broad analysis techniques.
In the first case, once a problem has been identified, the developer creates an hypothesis as to what might be wrong. This may involve multiple simulation runs on designs that have been instrumented so that they provide additional information. If the hypothesis does not get to the root cause of the problem, the specific bug may be fixed and yet latent bugs related to the true problem remain in the design to be found at a later date. Debug often involves visualization tools that aid the developer in understanding what is happening within the design.
The second class of debug can start much earlier in the development process and usually does not require any kind of testbench. Analysis is performed on the whole design looking for a class of problems that are known to get created. An example is clock domain crossing where it is easy to miss problems when blocks running at a different frequency need to share data. Most of these tools are considered to be 'lint' tools of based on formal analysis techniques.
While most debug is associated with finding and fixing functional problems in the design, problems in other domains are becoming increasingly important. As an example, power and performance bugs may exist in a design. They do not affect its primary operation, but may cause the design to miss the power budget or a task may take longer than expected. Another domain that is becoming increasingly important is security.