S2C Limited.
S2C Limited.

Enhancing FPGA Prototype Debug | SemiWiki

Enhancing FPGA Prototype Debug | SemiWiki Dec 06, 2017

Daniel Nenni   Published on 12-06-2017 06:00 AM

FPGA prototyping is very popular in modeling hardware for early system prove-out, early embedded software development, as a cost-effective and performance-effective platform for software-driven hardware debug and for late-stage software debug, all before silicon is available. It has significant advantages in run-time performance over other hardware simulation methods and can be considerably less expensive than emulation. But as always, every solution comes with its own challenges; one particular challenge for FPGA prototyping is visibility into hardware internals for debug.

When using prototyping for hardware debug, good debug access is obviously critical; you have to be able to place probes / triggers wherever needed and you must be able to store long traces to debug back through sequences that may run for millions of cycles. In simulation-based verification this is easy. Changing observation points and triggers is simple and re-running after making a change to the design is equally simple.

But in FPGA prototyping neither of these steps is so easy. Take first the debug capability. Standard FPGAs, typically from Xilinx or Intel/Altera provide debug support in the form of on-chip logic analyzers (LAs), but these offer limited and potentially expensive debug support. First, they use extra gates, routing and (on-board) memory, more of each being required the more you want to debug. Problems are particularly acute with memory. Storing traces over millions of clock cycles may burn up all your on-board memory, undermining your design needs.

This becomes even more complex when your design spreads across multiple FPGAs, as is common when prototyping designs of any reasonable size. Commercial prototyping systems support large designs by partitioning them across multiple FPGAs on a board, and potentially across multiple boards or even multiple enclosures. In cases like this, native device-based debuggers hit yet another problem. They are effective, as far as they go, in debug at a device level, but each device now represents just a part of your design. Moreover, multi-FPGA prototyping isn't just about partitioning across FPGAs. Logic to pipeline signals through limited package pins and board-level logic to optimize communication between FPGAs, all artefacts of prototyping rather than features of your design, further complicate the debug picture from a whole design point of view.

There's another problem (in case you though you could somehow work your way around the problems I have listed so far). Since probes are logic embedded in your design, if you need to change probes (which you will, given a very limited budget for debug logic when using LAs), you'll need to re-implement the whole design on almost all debug iterations (because you'll almost certainly need to add more probes). And that is going to take a lot of time per iteration: adding the probes to the RTL, resynthesizing, perhaps re-partitioning and re-implementing through FPGA place and route. Think days at least to add a few probes.

This is where dedicated debug solutions become particularly important, by moving most of the debug functionality off the FPGA so that the bulk of device resources remain allocated to your design, by supporting many more probes per device than would be possible in LAs and by letting you interact with a view of your total design (which is what you really want to understand) by transparently handling the details of design to device mapping. I'll illustrate this through the S2C MDM (multi-debug module) solution.

On resources, consider first memory needs. MDM doesn't use FPGA memory. All debug data is output through a DDR3 memory port to external memory on the MDM board. Freed of the highly constrained FPGA memory resources, the solution provides 16GB of memory, supporting up to 16K probes per FPGA and several million cycles of traces. The on-device support logic is also greatly reduced to the very limited circuity, even for 16K probes, needed to capture and stream out this data.

This also largely addresses the design iteration (for debug) problem. With 16K probes per FPGA, you'll need a lot less lengthy design rebuilds to complete debug. Which means that getting to verification closure is going to be a lot faster.

Finally, the MDM solution works with up to 16 FPGAs simultaneously. And through the Prodigy Player Pro cockpit, you can interact with your design in selecting probes, viewing waveforms and tracing back to find root-causes, all without having to worry about the mapping details between the design and the FPGA implementation. Together this provide a debug solution much closer to what you are used to in simulation.

Back to list Back to list
Related S2C Complete Prototyping Solutions
Cloud Service
S2C could service a program providing comprehensive management capabilities for enterprise-wide prototyping environments. Through a flexible browser-based interface, and provides a host of management and control capabilities.
Neuro enables users to quickly access FPGA computing power and CPU cluster resources deployed in data centers or company computer rooms through various terminal devices.
Prodigy S7 Series (Virtex UltraScale+)
The 7th generation SoC/ASIC prototyping solution from S2C, the Prodigy S7 series Logic System, is equipped with AMD's(Xilinx)Virtex UltraScale+™ FPGA. The Prodigy Logic System are supported by S2C'...
What's New at S2C
Request for Quote
What type of chip are you designing
What is the capacity of the ASIC gate included in the design?
5 million-20 million
20 million-50 million
50 million-100 million
100 million-1 billion
More than 1 billion
Which FPGA do you prefer to use?
Xilinx VU440
Xilinx KU115
Xilinx VU19P
Xilinx VU13P
Xilinx VU9P
Intel S10-10M
Intel S10-2800
Not sure, need professional advice
What kind of FPGA configuration do you need?
Single FPGA
Four FPGAs
Eight FPGAs
Not sure, need professional advice
What kind of peripheral interface do you need?
How many prototype verification platforms do you need?
Do you need the following tools?
Segmentation tool
Multiple FPGA debugging tools
Co-modeling tool (allows large amounts of data to interact between FPGA and PC host)
When do you need to use our products?
0-6 months
6-12 months
More than 12 months
Not sure
Any additional comments?