Visibility
Enhancement Technology for
Simulation
Introduction
Although new tools, improved methodologies and higher levels of abstraction are shortening design and verification times, the time required to (and difficulty associated with) determining the root cause of problems found in large, long simulations is growing.
A key factor stretching debug times for full-chip verification applications is the impact of observing signal values. Effective debug requires the engineer to observe and record signal values over time so that the causes of design behavior can be investigated and understood. But observing signal values impacts design and verification. It takes time to dump and record the signal values that must be observed. As a result, simulation run-times stretch. For large chips, the sheer quantity of data limits what can be observed, leading to methodologies that require multiple simulation runs to isolate the cause of a given problem if "the right signals" aren't captured the first time around.
Visibility enhancement provides the engineer a way to optimize visibility by making tradeoffs between impact and observability. With lots of impact, it is easy to see everything. With no impact, nothing can be observed. The trick is to find a way to minimize impact while achieving full visibility - or at least enough visibility to debug the problem.
Visibility Enhancement
Research by Novas Software has revealed two steps for optimizing the ability to debug a chip with minimal observation impact:
-
Analyze the design to determine which signals are essential for full visibility; and
-
Expand the limited data of the essential signals to obtain values for the rest of the design's signals.
Formal analysis of an RTL description or netlist provides the engineer with a list of observable signals. Observation of the values of these signals over time enables full visibility within a designated portion of the design. Once the essential signals are dumped, additional analysis can fill in the blanks for the signals that were not dumped, making a full set of values over time available for debugging.
For large RTL simulations, essential signal analysis and data expansion may be adequate. For those involved in the debug of gate-level simulations, much of the challenge lies in understanding the workings of the detailed netlist - something that to most engineers is unfamiliar. This challenge can be alleviated by a third step:
-
Map the gate-level signals up to the RTL to enable expansion and debug of netlist-level activity on the familiar design description.
<click here to download complete paper>