S2C Limited.
S2C Limited.

Prototype-Based Debug for Cloud Design | SemiWiki

Prototype-Based Debug for Cloud Design | SemiWiki Mar 14, 2017

Bernard Murphy   Published on 03-14-2017 05:00 AM

Unless you've been in hibernation for a while, you probably know that a lot more chip design is happening in system companies these days. This isn’t just for science experiments; many of these designs are already being used in high-value applications. This development is captive - systems companies generally don’t want to get into selling chips – but there is enough value in their own needs for them to justify the design and manufacture of these parts.The Growth of Cloud Computing

An important motivation is for differentiated enhancements in cloud hardware. Cloud services are a very hot and competitive area; one estimate puts Amazon Web Services, considered standalone, as the 6th largest business in the US. Which is good news for cloud services providers and for those who sell hardware and software solutions to those providers. Climbing fast on this list is a Chinese company called Inspur. I’m guessing you’ve never heard of them. That may change; they’re a vertically integrated company, with offerings all the way from cloud services down to building and selling servers. In server sales, they rank 5th worldwide and top in China. Which makes them very interested in anything that can improve QoS for cloud applications.

Networking between servers is an especially hot domain for differentiation. Microsoft recently announced their work with Intel/Altera to optimize networking for Azure through software-defined networking on reconfigurable platforms. Inspur is working on their own routing control chip (details not available) and unsurprisingly they want to prototype it, presumably in-system, before they commit to silicon.


Inspur chose S2C for their prototyping solution because they wanted to be able to inspect and validate correct behavior in operation, while making high volume/throughput packet transmissions. In particular, S2C's Prodigy MDM (Multi-Debug Module) is being used to set trigger conditions and capture related packets for chip debug. Deep sampling depth supported by Prodigy MDM allows Inspur to grab as many packets as possible to then be analyzed for correctness.

Inspur cited especially the strength and ease of debugging across a multi-FPGA prototype in the Prodigy solution. Large designs (and routing controllers tend to be large) are unlikely to fit on a single FPGA and may have to span to multiple boards. But from the designer’s point of view, that’s an implementation detail; they still want to observe and debug across the whole design, unimpeded by FPGA partition boundaries. Using traditional FPGA tools, you would have to debug each FPGA in isolation; problems spanning more than one FPGA become painful to trace to a root-cause. Fixes are even more challenging – a fix on one FPGA, made without a clear perspective on behavior in the rest of the design, may create a new problem on another FPGA.

The Prodigy MDM solution addresses this fundamental problem in multi-FPGA debug by presenting a unified design view across 4 Prodigy logic modules (boards) simultaneously. When you setup probes and trigger conditions, they are based on the design and indifferent to partitioning. When you view waveforms, the same applies. The designer sees the design as a whole and can monitor and debug it as a whole – the FPGA implementation is transparent.

Inspur also mentioned that deep tracing support was very important to speeding up their debug process. They needed to grab as many packets as possible when looking for potential problems and this can only be accomplished at reasonable speed if trace data can be buffered into sizeable on-board memory. To get at the details of those packets, Prodigy MDM supports many more probes on each FPGA than you are likely to need (and you can precompile up to 16k probes per FPGA, from which you can select and change candidates for tracing without needing to recompile). MDM can then store up to 16GB of probe traces on the MDM hardware, again a significant differentiator from traditional FPGA debug tools which offer limited internal memory to capture traces. Tracing supports speeds up to 40MHz and transfer to a host computer is accomplished through a high-speed Gigabit Ethernet interface.

Compile, probe setup, run-time control and debug are all steered though the Prodigy Player Pro cockpit, so you have one unified interface for ease of use. You can learn more about Prodigy MDM HERE, the complete Prodigy line (including support for logic boards based on a variety of FPGA options) HERE and you can read the joint S2C/Inspur press release HERE.

Back to list Back to list
Related S2C Complete Prototyping Solutions
Prodigy Logic Module
S2C's FPGA Prototyping system has been in the market since 2004 and has since been widely adopted by many leading SoC/ASIC design companies. The Prodigy Logic Module series are specially designed ...
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.
Virtex UltraScale Series
S2C's Virtex UltraScale (VU) Prodigy Logic Systems are built on the Virtex UltraScale XCVU440 FPGA from Xilinx.
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?