Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Solving SoC and FPGA prototyping debug issues

Posted: 06 Feb 2013 ?? ?Print Version ?Bookmark and Share

Keywords:ASICs? FPGA? Debugging?

When designing complex ASICs such as a highly-integrated system-on-chip (SoC), engineers are highly motivated to perform comprehensive verification under as real-world operating conditions as possible to ensure that bugs can be identified and corrected before final tape-out. The source of the motivation, of course, is the high-cost and time required to re-spin an ASIC.

While discovering and tracking down the root cause of bugs can be challenging in the best of circumstances, inherent limitations in the various technologies available to ASIC designers for verification testing make the job much harder as each involves a variety of trade-offs. Now, however, new technologies are emerging that offer the promise of much more efficient and less time intensive debug processes using FPGA prototypes.

Debugging requirements
A SoC consists of both hardware and software controlling the microcontroller, microprocessor or DSP cores, peripherals and interfaces. The design flow for a SoC aims to develop the hardware and software in parallel. Most SoCs are developed from pre-qualified hardware blocks for the hardware elements, together with software drivers that control their operation. Also important are protocol stacks that drive industry-standard interfaces like USB or PCI Express. The hardware blocks are put together using EDA tools while the software modules are integrated using a software development environment.

In order to debug the SoC, all these various pieces need to be pulled together into a functional unit and tested extensively. When this functional verification turns up bugs, the root causes need to be tracked down and either fixed, or a work around needs to be developed. Further, if time permits, it can be useful to conduct optimisation testing to identify and correct performance bottlenecks in the design. Core requirements for optimal SoC debugging include:

???Full RTL-level visibility with minimal dependence on FPGA CAD flows
???Fast, efficient identification of the root cause of bugs
???Run at full speed to enable verification with real-world signals
???Time-correlated signals across different clock domains
???Scale seamlessly to support large, complex designs
???Enable efficient debugging of firmware and application-level software
???Verify hardware and software interactions at the system-level

ASIC prototyping approaches and trade-offs
The three main approaches traditionally used to verify and debug both hardware and software for SoC designs are simulation acceleration, emulation and FPGA-based prototyping technology. To date, all three fail to meet all the requirements outlined above for ASIC debugging.

With high capacity and fast compilation time, acceleration and emulation are powerful technologies that provide wide visibility into systems. Both technologies, however, operate slowly, on the order of MHz, which may be significantly slower C up to 100X slower C than the ASIC's operating frequency. As a result, emulators and accelerators cannot use real-world stimulus for testing without creating specialised interface circuits. Nor are they feasible for developing a system's software. For instance, at the rate of 100X slower, emulating a system running for 15 minutes of real-time would take more than 24 hours. Acceleration and emulation boxes are also very large and expensive ($1M+) and thus beyond the means of many chip manufacturers.

FPGA-based prototyping platforms use FPGAs directly to enable engineers to validate and test at, or close to, a system's full operating frequency with real-world stimulus. FPGA-based prototypes are small enough to be portable and used at an engineer's desk. They are also much less expensive than emulators or accelerators, on the order of $75K. Given these advantages, it's no wonder that about 80 per cent of all ASICs and SoCs are prototyped in FPGAs.

But that doesn't mean that FPGAs are the ideal platform either. Some teams use an emulator in addition to building up an FPGA prototype. That may be changing.

FPGA prototyping debug challenges
An FPGA-based prototype is a hardware-based implementation of an ASIC design that operates at high clock frequencies that closely represent the final ASIC while enabling non-intrusive monitoring of internal signals. Figure 1 shows the process for instrumenting and observing an FPGA-based prototype. Depending upon the size of the ASIC, the design may span multiple FPGAs. To test the system, engineers partition their RTL design among the FPGAs. Probes are added directly to the RTL to make specific signals available for observation. This instrumented design is then synthesised and downloaded to the FPGA prototype platform.

Figure 1: To monitor internal signals, probes are added directly to the RTL.

When the system is run, the RTL-based probe connected to each of the instrumented signals collects the signal's value at each clock cycle. To enable the system to run at its full operating frequency and collect signal data in real-time, the data is stored in a trace buffer in FPGA block RAM. An analyser connected to the prototype then downloads the information collected from each of the instrumented signals from block RAM, giving engineers offline visibility into the system.

The chief limitation to date of this approach is that instrumenting signals requires the use of significant amounts of block RAM and LUTs within the FPGA. Both of these resources are constrained by fixed availability on the FPGA, as well as by the fact that the majority of these resources are required by the ASIC or SoC design itself. For example, while an FPGA may have 96 block RAM, the ASIC design may require 86 of them, leaving only 10 for use in debugging.

1???2???3?Next Page?Last Page

Article Comments - Solving SoC and FPGA prototyping deb...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top