As noted earlier, the data gathered from ILAs is usually associated with the gate-level view of the FPGA. To understand what’s happening in such gate-level logic, one must be able to correlate the gate-level data back to the RTL representation of the design, or even to a system-level description.
Due to synthesis and optimization, however, not every signal in the gate-level representation will have a corresponding signal in the RTL representation. To address this issue, the visibility-enhancement environment must somehow localize signal correspondence. One technique is to automatically generate structural dependency graphs and employ approximate graph-matching algorithms. This approach imitates the process employed by humans, whereby one often locates corresponding areas by looking at registers in the fan-in and fan-out cones.
Perhaps the most significant aspect of visibility enhancement is its on-the-fly data expansion capability (see the figure). This capability, however, relies on all of the previous points, especially visibility-enhanced signal selection. The signals to be observed are selected specifically to facilitate automatic data expansion.
Here’s the idea behind data expansion. Often, the designer may wish to display and analyze signals that weren’t in the captured set. Rather than modify the design and perform a new verification run, it’s preferable to interpolate the missing data. Consequently, the visibility-enhancement environment will use data expansion to fill in the missing gaps in the captured data.
In particular, such data expansion can populate the signals internal to blocks of combinational logic that sit between registers whose signals were captured. To maximize performance, the expansion is done on-the-fly or dynamically only for the logic under investigation rather than statically for all design logic. A comparison of a traditional design environment compared to its visibility-enhanced counterpart is illustrated in the table.
Visibility-enhancement technology can dramatically speed the process of locating, isolating, and understanding the causes of error symptoms in FPGA-based prototypes (similar techniques can be applied to FPGA-based emulation and software simulation).
In a typical design, registers account for approximately 20% of the signals. Using visibility-enhancement technology allows designers to use these signals as the basis for determining the values on the remaining 80% of the signals, which equates to an approximate fivefold increase in visibility. In turn, users of this technology report a fourfold reduction in debugging times. In other words, every hour spent debugging without visibility-enhancement technology can be reduced to only 15 minutes with this technology.
As for the future, the data-expansion capabilities provided by a visibility-enhanced environment provide the basis for using internal FPGA signal data in conjunction with advanced debugging techniques that are typically considered only in the context of software simulation. If the device contains sophisticated internal buses, for example, the expanded data could be viewed at the transaction level, thereby making it easier to understand the device’s operation. Careful integration of the data-expansion technique in the context of the debugger could provide reductions in both verification run time and the resulting captured data file sizes. Such an environment would empower automated guided debug along with advanced analysis and tracing capabilities.
Conclusion
One of the most significant challenges facing design and verification teams employing FPGA-based prototypes is to understand the internal behavior of the system when it fails to perform as expected. A visibility-enhanced verification and debug environment addresses this by:
• aiding in the selection of the signals to be observed
• working with (and negotiating with) the other tools to modify the design to capture the selected signals
• capturing all of the required data and attributes necessary to drive downstream tools
• using advanced techniques to automatically map between the system, RTL, and gate-level views
• performing data expansion to interpolate values for signals that weren’t captured