Tektronix has come up with an interesting and potentially disruptive way of providing visibility into up to 100,000 signals on each FPGA on a prototyping board in its Certus 2.0 release. Standard FPGA debug tools instrument about 1,024 signals at a time.
The wisest thing is to make sure that your RTL is mature before going to FPGA prototyping. But that entails significant acceleration, simulation and - where you have access to a box - emulation. Even then you are limited in addressing problems that might arise when your design connects to the real world. This is the biggest selling point for FPGA prototyping as all end-products become more and more connected: It provides the best external interface.
However, FPGA debug can be a pain. Limited visibility means you check for one bug (or cluster) based on limited test instrumentation capacity, possibly find it, but then have to go back through the recompile-instrument-test-review cycle again. Tektronix argues that these are "go home" events: Each can take 8-18 hours, so you leave the system grinding away and head for dinner. Until recently, you also couldn't simply stop and restart your prototyping run (although Synopsys addressed that in a recent release of Synplify).
Certus compression and automation
Tektronix' answer with Certus is a mixture of compression (to up the signals addressed per run) and automation (to identify the signals of interest and reduce guesswork). It claims this can bring run-time down so that root bug causes are identified in hours or days rather than weeks of months of iteration. Reconfigurations are possible in minutes, the company says.
Compression is important because of likely restrictions on LUTs and then on block RAM on the target FPGA. For block RAM, it may have 96, but 86 are needed for the design, leaving 10 for debug. Then there's trace depth. More trace depth means, again, more block RAM. You can use a crossbar MUX, but this has issues as signals need to be carefully grouped and you cannot observe signals from different groups within the same run.
In an article on Certus 2.0, Tektronix summarizes its approach (minus secret sauce obviously), as follows:
"A highly efficient multi-stage concentrator is the basis for its observation network that reduces the number of look up tables (LUT) required per signal to increase the number of signals Certus can probe in a given space. Its efficient architecture, coupled with advanced routing algorithms that keep the size of the concentrator to a minimum, enables Certus to provide effectively the same flexibility of a full crossbar mux while requiring no more die area than a standard simple mux requires. In practical terms, Certus enables engineers to instrument tens of thousands of signals using fewer FPGA resources than a standard FPGA-based debug tool requires to instrument 1,024 signals."
The consequences are summarized thus:
"The flexibility of the multi- stage concentrator makes the entire instrumentation process transparent. As a result, engineers no longer need to spend hours identifying signals of interest because they can observe them all.
"In addition, Tektronix has greatly simplified instrumentation by enabling multiple probes with a single selection. For example, engineers can select all flip flops, all interfaces, all inputs or outputs, and all state registers with the knowledge that they can view any of them as required without needing to recompile the system. In fact, as a matter of routine, all interfaces and registers can be probed by Certus to ensure that engineers have complete access to all of the key signals in a design."
You can read Tektronix' fuller description of the new Certus strategy here. However, the real meat is all about how this works in practice. This Tektronix case study with The Dini Group, one of FPGA prototyping's doyens, provides some of that.