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

Overcome challenges of ASIC/SoC prototyping with FPGAs

Posted: 24 Oct 2011 ?? ?Print Version ?Bookmark and Share

Keywords:SoC? ASIC? ASSP? FPGA? prototype?

In order to compare the performance of the various approaches, let us consider the time required to decode a video stream using the H.264 standard for the baseline profile (used for video phone, conferencing etc.).

We will assume a compressed high definition (HD) video with a resolution up to 1280x720p, an operating frequency of 88MHz, and real-time decoding at up to 30 frames per second. The baseline profile includes I (Intra-coded) and P (Predictive coded) slice, CAVLC (Context-based Adaptive Variable Length Coding) entropy encoding, FMO (Flexible Macro block Ordering), ASO (Arbitrary Slice Ordering), and Redundant Slice.

Prototyping challenges
FPGA-based prototyping systems do have certain limitations. For example, although debug tools have been significantly improving, debugging a design is not as intuitive as in a simulator. Also, the process of mapping the RTL design into the board and verifying is not completely automated and needs user intervention. However, the overall benefits of FPGA-based prototyping significantly outweigh these minor limitations.

Some of the key challenges in a prototyping system are:
? Debug visibility and RTL co-relation with debug probes
? The ability to debug any portion of a design mapped over multiple FPGAs
? High-speed data transfer between the verification and design environments using high-level languages such as C and SCE-MI
? The availability of reference designs for quick validation, and wide choice of daughter boards to interface with different protocols such as PCIe, USB 3.0, GbE and other emerging standards
? Availability of comprehensive self-tests that quickly isolate prototyping board issues from design issues.

In the following sections we will consider how these challenges affect overall productivity and the approach that S2C has taken to overcome these challenges.

FPGA-based prototyping challenges
S2C Inc. is currently offering fourth-generation FPGA-based hardware prototyping platforms. The FPGAs on the prototyping system could be from Altera or Xilinx. The boards are available in various device implementations to meet different design sizes such as a single FPGA, dual FPGA, and quad FPGA configurations. The design can be configured into the prototyping system boards via JTAG, standard USB, or SD card.

Debug visibility: In a typical design flow, the design is represented in a Hardware Description Language (HDL) C such as Verilog, SystemVerilog, or VHDL C and simulated in a RTL simulator. Most design errors are discovered and fixed in a simulation environment. In simulation, the visibility and controllability of debug signals is much greater and hence can be fixed easily. The designer can observe and fix the incorrect design behavior at the RTL level while debugging the design on a prototype means working at a gate level synthesized net-list. The synthesis process (RTL to gate level transformation) often renames the signals and sometimes completely optimizes the signals away making it difficult to correlate signals at two different abstract levels.

This year, S2C introduced its Verification Module (VM) (patent pending) to address many of these verification challenges.

First, this solution allows the designer to set debug probes at the RTL level. The setting is intuitive and is performed using S2C's TAI Player Pro Software GUI or it can be scripted into a tcl command file. Another important capability offered by the VM debug solution is that of RTL visibility. The gate-level debug signals names listed in the debug tool after synthesis are very similar to the original RTL names.

This makes it very easy to traverse from gate-level signals to the corresponding RTL so that an error detected during a gate-level debug session is easily identified in the RTL. This significantly simplifies the debugging process.

Secondly, it allows you to use standard vendor debug tools, such as SignalTap (for Altera FPGAs) and ChipScope (for Xilinx FPGAs). For example, for a Stratix 4 based Quad S4 prototyping system, S2C TAI Pro Player software allows you to define 1,920 signals. At any given time of the debug session, you can observe up to 480 signals of the 1,920 defined above. If the debug point of interest doesn't lie within the selected 480 signals, then you can simply select another set of 480 signals.

Third, it drastically reduces the debug iteration time. For instance when a new set of signals is selected for observation in a standard waveform viewer, the design need not be compiled C this means the design doesn't go through synthesis and place and route which form the "long pole" of the design cycle.

Multi-FPGA debug: Most designs don't fit into a single FPGA. Often it is necessary to partition the design and map it over multiple FPGAs. When debugging a design on the prototype it is not always known in advance as to which portion of the design, and therefore which FPGA, might contain a potential design error. And sometimes even if you knew precisely the design block that has potential errors, it is quite possible that the design block of interest has been partitioned and mapped over multiple FPGAs. Most debug tools currently available are capable of debugging only a single FPGA at any given time. This limits the simultaneous visibility into more than one FPGA.

Verification Module

Figure: The Verification Module allows multiFPGA debug and high-speed data transfer.

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Overcome challenges of ASIC/SoC prot...
*? 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