Four Requirements To Improve Chip Design Debug

Debug has always been a painful and unavoidable part of semiconductor design and, despite many technological advances, it remains one of the dominant tasks in chip development. At one time, most bugs were detected and diagnosed on actual devices in the bring-up lab, where both visibility and controllability are severely limited. It is certainly true that debugging the results from pre-silicon testbench simulation, static checks, and formal verification is much easier. However, this gain is partially offset by chips growing ever larger and more complex, requiring more time and effort to track down the source of bugs. Many designs today are system-on-chip (SoC) devices that rely on embedded software as well as hardware, further complicating debug.

Fortunately, the best debug environments provide many ways to reduce the time and effort required. These tools are in a state of continual improvement, adding new functionality with every release to keep ahead of debug complexity. Key features include an intuitive graphical user interface (GUI), multiple views of the design and testbench, easy navigation across the views via cross-links, and the ability to control simulation runs from within the GUI. In recent months, four new required capabilities have come to the forefront. To remain competitive and relevant, any debug solution must add robust support for these four new features.

One major challenge in debug is the size of the design that must be loaded to examine the simulation results and track down the source of test failures. Loading the register-transfer-level (RTL) design is hard enough; loading the results from a gate level simulation (GLS) of a huge netlist is even more difficult. The first new requirement is that the debug tool must not insist on loading complete simulation information for the entire design. Simulation signal values and source code are needed only for the parts of the design related to the failure being debugged, and only “dummy” (skeletal) information is needed for the rest. This “Smart Load” capability typically increases debug capacity by at least five times and decreases debug bring-up time by at least 80%, for a big boost in productivity.

Smart Load has two primary modes of operation. Users can specify that only a specific subset of the design be fully loaded, making an educated guess as to where a design bug is located based on the test failure. The rest of the design is loaded only in dummy form, speeding up debug and conserving both human and compute resources. Alternatively, the users can load the entire design but specify that certain instances be blackboxed and loaded in dummy form. These two modes can be combined so that only a subset of the design is loaded, with some instances within that subset blackboxed. The users must be able to provide a configuration file with this information, fully load dummy instances incrementally and interactively during the debug process and save the current state as a configuration file for use in future debug sessions.

Smart Load does a lot to help with performance when debugging both RTL designs and GLS netlists, but some operations still take significant time. Searching a large netlist is one common example. Users do not want the entire debug process on hold during deep searches, so another requirement is multi-tasking technology in the debug tool. Many views and browsers in the GUI can be used while a search is in progress if they are programmed as independent tasks that can run in parallel. The debug tool must also provide a task manager so that users can monitor and control the parallel activities.

Another challenge that has greatly complicated debug is that SystemVerilog and the Universal Verification Methodology (UVM) rely heavily on object-oriented programming (OOP). With OOP, programmers can set up the testbench to create and destroy objects over the course of a simulation run. The debug tool must provide specialized views for dynamic objects showing how they change over time, making it easier for verification engineers to debug failing tests. The users must be able to control how this information is displayed, including filtering out UVM internal attributes to reduce screen clutter and helps the users focus. Note that the ability to handle OOP in debug may place some requirements on the choice of simulator.

The final new debug feature also places requirements on the simulator to automate the task of diagnosing failing UVM-based simulation tests. To save time and disk space, simulation regression tests are generally run with dumpfile generation, detailed logging and other debug options turned off. Failing tests are usually rerun automatically with these options enabled, but from there debug is largely a manual process. The verification team must examine the failure, identify associated events, add checkpoints around these events and rerun simulation. This process is much easier if the simulator can add a checkpoint and save state at the first UVM error which allows the debug tool to start up at this state. With this capability, which Synopsys calls Instant Recall, users can move forward and backward in time around the failure point to debug more efficiently.

The requirements on debug tools become stronger as design and testbenches continue to grow. Anyone developing advanced chips needs partial design loading, multi-tasking debug, intelligent visualization of dynamic objects and Instant Recall regressions. As the industry leader, the Synopsys Verdi Automated Debug System already has all four features available in full production mode and is in use by many leading-edge users. A white paper with more information is available on demand.