Designing your own ILAs takes time and effort. In fact, it can be difficult to determine whether you’re debugging the design itself or the ILA. Even when using robust and proven ILAs from the FPGA vendor, the design still needs to be recompiled every time a new set of signals is selected for monitoring. Recompilation can take hours, so it’s desirable to minimize the number of times this task needs to be performed.
Following design modification and the recompilation of the design, a verification run is performed and data from the internal signals is captured. In order for this data to be usable by downstream debug tools, it must contain specific attributes. In addition to the logic values themselves, the data must include the full hierarchical instance name of the signal, along with the relative operational time (time stamps) of each data transition. Also, the dumped data’s file format should be an industry standard, such as VCD or FSDB.
In the case of proprietary solutions, it may be necessary to add these attributes into the signal data stream and/or to translate in-house formats into their industry-standard counterparts. Fortunately, ILAs supplied by the FPGA vendors and specialist vendors typically capture the required data and use industry-standard formats.
The data gathered from ILAs is usually associated with the gate-level view of the FPGA. Designers, however, are more familiar with the design’s RTL representation. Thus, to facilitate the debug process, it’s necessary to map the gate-level instances into the RTL view. This isn’t as simple as it sounds, because in many cases there isn’t a one-to-one correspondence between the gate-level instances and the RTL view. Many conventional and in-house solutions fail to provide this capability.
Following a verification run, it’s invariably necessary to access and analyze additional signals in order to track the problem down. When using a conventional design flow, designers must return to the first of the five steps enumerated earlier. That is, they have to select a new set of signals, modify the design and recompile it, perform a new verification run, map the new data to the RTL, and then analyze the results. This is a process that must be repeated many times.
A Visibility Enhancement Approach
To address the limitations of traditional FPGA prototype debug environments, an approach has emerged that provides enhanced visibility into the design’s inner workings. To be fully effective, visibility-enhancement tools and techniques must be applied to every step in the flow.
As before, the first step in the process is to decide which signals need to be observed. Based on the erroneous outputs being exhibited by the system, designers usually have a “feel” for one or more functional blocks of interest. For example, the memory controller and/or bus-arbiter blocks.
As a rule of thumb, one needs to be able to observe approximately 15% of the signals internal to a block (usually registers, internal memory locations, and primary inputs/outputs to the block). This will provide 95% to 100% visibility in the context of the automatic data-expansion techniques discussed later in this section.
Unfortunately, resource limitations may not permit capture of all of these signals. In this case, it’s obviously preferable to select those signals that provide the best bang for the buck. As a result, visibility-enhanced signal selection includes the concept of “influence-ability” or, the amount of downstream logic each signal influences. To determine the minimum lineup of essential signals required to debug the selected blocks, you will have to analyze the assertions, RTL, or gate-level netlist code—sometimes all three will require attention to assess influence-ability. To debug assertion failures, for example, visibility-enhanced signal selection will analyze the design and the selected assertions to extract the minimal set of signals required to debug each assertion.
Furthermore, if the designers explicitly define a set of signals they wish to observe (where such selection can be made in the RTL and/or gate-level netlist), the visibility-enhanced signal selection tool will automatically identify any registers, memory elements, and primary I/Os that must be captured in order to observe the specified internal signals.
Once a set of signals to monitor is selected, the visibility-enhancement environment will automatically communicate with the FPGA and/or third-party tool vendors to modify the design by adding the appropriate ILAs. In the event that there aren’t sufficient resources to capture all of the desired signals, the environment will base its selection on those signals deemed to have more influence as discussed above.
When a verification run is performed, the visibility-enhanced environment will automatically record and/or provide any information required by downstream analysis and debug environments; this information will include logic values, the full hierarchical instance name of the signal, and the relative operational times of any data transitions. Also, the dumped data file will be in an industry-standard format, such as VCD or FSDB.
Reprints
