In my previous blog, I talked about debugging an FPGA given the capabilities provided by the device manufacturers. This brought quite a lot of comments from you, both from the (many) people who find these capabilities to be useful and from the (just as many) people who consider finding problems after the designs have been placed in the FPGA to be a failure in their verification methodology.
I wonder if design size has anything to do with this divergence of views and/or whether this divergence is due to other factors associated with the design itself? Itís kind of like trying to compile a survey -- it's only after you have had enough people respond to it that you know the questions you should have, or wished you had, asked.
Anyways, I wanted to move on to consider some of the debug capabilities that are not provided for free. Many of these are intended for people using FPGAs to debug ASICs, but I can see several of these as being useful for FPGA-based designs as well. I am also sure that I have missed many of the capabilities that different vendors provide, so perhaps you can add comments about those that I have missed.
There are several classes of suppliers for FPGA verification and debug software. First, there are those that also sell FPGA debug boards, in which case the software is tied to their hardware. An example of this kind of company would be S2C. Then there are companies that provide software independent of the hardware platform. An example of this would be Tektronix.
Finally, there is the hybrid -- companies that have their own hardware and software, but that also make the software available independently (although often with reduced capabilities). An example of this latter case is Synopsys. When it acquired Synplicity several years ago, it acquired some FPGA debug tools. Later, it acquired a couple of FPGA prototyping companies, but it has continued to make the software available to companies that wish to develop their own prototyping boards.
One of the biggest capabilities they all tout is the ability to change the signals that are being captured without having to perform place-and-route all over again. This requires them to use additional resources in the device, but makes the turnaround time much shorter. This could be particularly useful during the early stages of debug when more problems are likely to be found and you donít want to have to wait for an overnight run to change the probe points.
Let me use Tektronix as an example here. Its Certus 2.0 tool claims to be able to provide 100 percent visibility into the device without having to recompile. It selects and routes the instrumentation dynamically, and Brad Quinton -- the creator of the technology -- assures me that there are no restrictions on which signals are selected for any run.
Next up in terms of capabilities is the ability to capture information from multiple FPGAs. This may still involve using a virtual logic analyzer like SignalTap or ChipScope within the individual FPGAs, but it requires an additional layer on top of them to handle multiple devices. In addition to simple monitoring functions, multiple FPGAs present some challenges when it comes to creating triggers across multiple devices. This can be a long path in the debug circuitry and requires special attention. S2C claims to be able to do this for up to four FPGAs.
Yet another ability, with almost endless possibilities, is moving more of the instrumentation on-chip. At the simplest level, this may mean using internal memories to capture the trace data and then reading them out when the run is terminated. This can save pins and provide for a wider trace, but often the depth of the trace is limited. Some of the suppliers provide on-chip data filtering, selection, compression, and optimization, thereby enabling more data to be stored. Instrumentation can also be created that captures statistical information. There is no end to the capabilities that could be added, so long as there are sufficient spare programmable logic blocks lying around to implement them.
Well, I should probably stop here for today. What other capabilities do you use and/or find useful in add-on debug packages -- assuming that any of you think they are worth the extra expense?