Introduction

For today's complex ICs, ASICs, and SoCs, debugging is more costly than verification. Verification, which determines the existence of bugs, can be put in the background as a batch job or accelerated by running many jobs in parallel. In contrast, the interactive nature of debugging-the process of understanding the reasons for the defects-requires the continuous direct involvement of an engineer. Consequently, debugging costs are not limited to software and hardware. The cost of debugging must necessarily include engineering time, and more importantly, the opportunity cost incurred every moment an engineer is tracking down old problems instead of adding new product value.

Many factors work together to drive up the cost of debugging. Underlying most of them is the difficulty of understanding large complex designs. Incredibly complicated protocols and algorithms, the multitude of interactions between design components, design reuse and intellectual property (IP), translation and synthesis of code from higher to lower levels of abstraction, and an extensive battery of verification tools all confound the ability of engineers to grasp how the design is supposed to work, and to make sense of the verification results.

Also contributing to the high cost of debug is the fact that debuggers have typically been tied to particular verification tools. This costs precious time as engineers move between tools. Moreover, these tool-oriented debugging GUIs do not have full knowledge of the design, as they are limited to what they can extract from a verification-specific database. As a consequence, these tools cannot do enough to help engineers locate and isolate defects so they can fully comprehend what's wrong before attempting a fix.

The key to cost-effective debugging is rapid, thorough understanding of complex behavior even in unfamiliar designs. A design-oriented, open system approach facilitates faster, more accurate debugging by automating the tasks required to locate, isolate, and understand the causes of defects uncovered throughout the design process.

Verification vs. Debugging

Verification and debugging are very closely related tasks. However, close coupling between verification tools-notably simulators-and their dedicated debuggers often obscures important distinctions between the two. Verification recognizes the existence of design defects; debugging determines the reasons for them. All verification tools in one way or another answer the question "does the design behave as intended." The goal of debugging is to understand what causes each defect discovered by verification. The debugging process answers the questions "why does the defect exist?" and "where does it originate?" Only by fully understanding these answers can an engineer craft an appropriate repair for each defect. And only by investigating the defect in the context of the design can an engineer come to that full understanding.

Design Understanding

Today's designs are necessarily complex. The whole point is to integrate lots of powerful functions to drive down system cost. To this end, today's designs may comprise processor cores, caches, fifos, and other memories, bus interfaces, communications protocol engines, and algorithms for processing pictures and sound-all on the same chip. It is bad enough that the bewildering number of potential interactions between these components makes them hard to understand. Worse yet, the tactics required to put these chips together compounds the understanding problem.

For a single team to design all the components of a large SoC from the ground up is simply untenable. Instead, these designs are built up by combining new pieces with parts recycled from older designs and components that have been designed for reuse (IP). This "composed" approach to design cuts both ways-it drives down design time and cost, but it increases the difficulty of understanding and fixing problems because so much of the design is unfamiliar. This "understanding gap" threatens to erase the design savings by increasing debug time.

Open Debug System

An open system debugging approach separates debugging tools from verification tools and provides standard interfaces for integrating the debugging system with the verification systems. This allows engineers to use a uniform interface to the design throughout the design and verification process. Open system users debug the results from many verification tools in a common environment for tracing, visualization, and analysis.

A debugging system such as the Debussy system from Novas Software independently compiles the HDL source files to extract not just connectivity and hierarchy, but also the behavioral organization of the design. This compilation process is quite similar to the initial stage of the RTL synthesis process, and recognizes elements such as flip flops, latches, multiplexors, and memories, which are critical to automating the tasks required to locate, isolate, and understand the causes of bugs.

The information extracted from the design sources is stored in a debugging-specific database that makes it immediately available to the system's tracing, visualization, and analysis tools. These tools use the stored design information to automate tasks that engineers perform again and again during debug.

Verilog and VHDL source code is the primary representation of the design for most engineers who design complex ICs. Therefore, the debugging system primarily presents the design through a flexible interactive view of the source code. Other views, such as hierarchical connectivity diagrams, RTL functional block diagrams, FSM bubble diagrams, and gate-level schematics are automatically derived from the information stored in the design database.

An open system facilitates integration with other systems through applications programming interfaces (APIs) and scripting interfaces (such as tcl). The figure below shows the system architecture.

Figure 1: Debugging system architecture

Location and Isolation

The value of design automation systems comes from the ability to automate tasks that are repetitive, time consuming, tedious, or difficult. In debugging, the process of locating and isolating the logic that drives incorrect values under some conditions is repeated again and again, takes a lot of time, is very tedious, and is often quite difficult due to the many source files, hierarchy levels, and signal name changes. The method for tracking incorrect values to their sources goes much like this:

- Start with a signal that the testbench says has the wrong value;
- Find the file and design block where it exists;
- Find each occurrence of the signal in that block;
- Determine which occurrences are drivers;
- Note the signals that are the inputs to those drivers;
- Recursively follow each of these signals to its drivers (through hierarchy, multiple source files, and name changes);
- Understand the values that each drivers should have;
- Determine which drivers appear to be at unexpected values;
- Understand why the wrong values are present.

Needless to say, in a large design this takes too long. If the design is unfamiliar, tracking these relationships can be enormously difficult.

A debugging system automates tracing of these relationships to locate the driving logic and isolate the reason for the problem. Using the connectivity data stored in the design database, the system tracks down the drivers of any selected signal, automatically traversing hierarchy changes, file changes, and name changes. The stopping points for the trace can be the individual RTL statements and netlist elements along the driver chain, or they can be the storage elements recognized during compilation. The trace can be easily extended along any interesting branch by means of hyperlinks. In the source code view, connectivity and hierarchy elements are shown as highlighted links that make it easy to follow parent/child and driver/receiver relationships throughout the design, no matter how convoluted the hierarchy or file structure may be.

The result of this easy, automated tracing of causal relationships is an exponential improvement in the speed of tracking down where a defect originates in a complex design, and much easier understanding of the way the design actually works-especially if the design is unfamiliar.

A debugging system further helps locate and isolate problems by drawing pictures. The system's visualization tools automatically derive schematic-like drawings from the data stored in the database. For example, finding out which hierarchical blocks drive a particular bus is as simple as selecting that bus in the source and asking the system to draw a block-diagram view that shows only that bus and the blocks that drive it. The user can then manipulate the derived view to traverse the hierarchy or trace the logic behind one particular driver, switching naturally between the integrated source text and diagram views.

Perhaps more important, the system can automatically cut through and "flatten" the hierarchy to draw a diagram that depicts the logic between selected points (a critical path or a cone of logic, for example) without the clutter of unrelated information. The effect is to pull from a massive design a simple view in which the actual logic driving or driven by a signal stands out in sharp relief.

The figure below shows an example of flattening. The schematic in the left window shows how a signal (highlighted in red) connects to blocks in the hierarchy. In the right window, the signal's actual driving logic has been automatically extracted and drawn as a "flattened" schematic.

Figure 2: Generation of flattened schematic

The information extracted from RTL source code and stored in the database allows the system to draw diagrams of RTL behavior as well. This type of visualization shows how state machines, multiplexors, flip-flops, and latches relate to each, revealing behavior that is often hidden in complex or unfamiliar Verilog and VHDL code. Linked to this drawing is a finite state machine (FSM) view that automatically lays out a bubble diagram for any of the FSMs in the code. The views are linked together to allow rapid movement between source text, schematic representations, and bubble diagrams. The figure below shows some examples of these derived drawings.

Figure 3: RTL schematics and FSM diagrams

Simulation Annotation

Integration with Verilog and VHDL simulators allows the debugging system to annotate all of the design views with simulation results, and to show the results in a waveform viewer. It also allows the user to control the simulator by single-stepping and setting breakpoints from within the debugging system itself.

Placing the simulation results in the context of the design by annotating the source, schematic and state machine views is another way that the system approach to debugging helps designers understand the complex behavior of their designs. The simulation results are extracted through a special API interface that minimizes simulator loading, and stored in another specialized database that optimizes the balance between file size and load time. The system can then retrieve the stored results and annotate the source, schematic, and state machine views. These are all linked to the waveform view so the values displayed in all windows can be synchronized to the same simulation time.

In the source view this annotation allows users to see not just the value that is the result of an expression, but also the value of all the inputs to the expression at the same time. This greatly increases the "information density" on the screen and is much faster than having to select and view all of the pertinent values in a waveform window. In the schematic window, the annotation allows users to quickly choose which branches of the logic to expand or collapse depending on the displayed value, instead of having to cross reference signal names between windows. In the FSM view, users can easily watch the state flow as simulation time advances. The system allows users to easily replay the simulation forward or backward to investigate interesting behavior.

Heavy reliance on waveform views by standard simulation debuggers leads designers to take a narrow view of debugging, which limits productivity. The annotations made possible by a debugging system help engineers better understand how the design works because they can see the result in the context of the design itself. This is more powerful than simply viewing the signal value changes over time in a waveform window because multiple relationships are immediately evident, and because the time typically spent correlating a signal's waveform with its drivers is eliminated. The system can even go one step further by isolating the actual driver from among several potential drivers.

Formal and Timing

Beyond simulation are the other essential verification tools in today's advanced design flows. Formal verification is rapidly replacing gate-level simulation because it cuts late-stage functional verification time by orders of magnitude. Static timing analysis is widely used to detect timing violations and identify critical paths.

An open debugging system allows users to locate and isolate defects discovered by these tools as well as simulation. For example, the Debussy system is integrated with the Tuxedo-EC equivalence checker from Verplex Systems, and it reads standard SDF (standard delay file) files produced by static timing analyzers.

To debug differences identified by formal equivalence checking, the system displays schematic drawings of the cone of logic from the reference design and the revised design being verified. Tracing the logic of these cones in isolation, without the distracting clutter of unrelated logic, quickly reveals exactly why the corresponding cones are not logically equivalent.

In a similar manner the system reveals delays along critical paths calculated by static timing analysis. By selecting just the endpoints of a critical path the system automatically extracts the signals and gates between the two points and draws exactly that logic. Annotation of the delays along the path completes the picture to help the engineer understand the reason for the timing bottleneck.

Conclusions

The system approach to debugging removes many barriers to design understanding that slow design and verification. Essential elements of the approach are compilation of the original source code to make verification and debug independent of each other, automated tracing of causal relationships to locate the reasons for defects, flexible derivation of drawings that isolate pertinent logic, annotation of verification results in place the results in the context of the design, and seamless integration of the various views through the shared databases. The openness of the approach is essential, as it means that it the system can unify design information with verification results and give users a consistent view of the design and its behavior throughout design, verification and debug. The flexible design viewing mechanisms described here also provide the means to correlate translated or synthesized code with the original source and to communicate among members of a distributed design team. Programming interfaces further expand the system's capability by allowing it to be integrated with a design team's various other tools, some of which may be unique to the team.

The components of an open debugging system work together to reduce debugging costs for large, complex designs, particularly when parts of the source are unfamiliar to the designers. The debugging approach made possible by such a system allows engineers to work at higher levels of abstraction, where the work is more satisfying and more productive. The time saved can be invested in IC features and performance. Since debugging carries such high manpower and opportunity costs, a system approach to debugging is quickly becoming a key strategy for companies seeking to maximize profits from IC, ASIC, and SoC designs.

		Click here to get your listing up.