FPGA prototyping: Difference between revisions

Revision as of 18:17, 15 August 2023

Revision as of 12:21, 27 September 2023

Line 44:

==Debugging==

One of the most difficult and time-consuming tasks in FPGA prototyping is debugging system designs. The term coined for this is "FPGA hell".<ref>{{Cite web|url=https://zipcpu.com/blog/2017/05/19/fpga-hell.html|title=FPGA Hell|website=zipcpu.com|access-date=2019-11-05}}</ref><ref>{{Cite web|url=http://www.rocketmanrc.com/downloads/MakerFaire2019FPGAsPresentation.pdf|title=Getting Started with FPGAs|last=|first=|date=|website=|url-status=live|archive-url=|archive-date=|access-date=}}</ref> Debugging has become more difficult and time-consuming with the emergence of large, complex ASICs and SoC designs. To debug an FPGA prototype, probes are added directly to the RTL design to make specific signals available for observation, synthesized and downloaded to the FPGA prototype platform.

A number of standard debugging tools are offered by FPGA vendors including ChipScope and SignalTAP. These tools can probe a maximum of 1024 signals and require extensive LUT and memory resources. For SoC and other designs, efficient debugging often requires concurrent access to 10,000 or more signals. If a bug is not able to be captured by the original set of probes, gaining access to additional signals results in a “go home for the day” situation. This is due to long and complex CAD flows for synthesis and place and route that can require from 8 to 18 hours to complete.