Increasing visibility in FPGA prototypes and emulators
By Robert Ruiz and Becky Leiser Capezza, Novas Software
March 07, 2006 -- pldesignline.com
With the rise in design complexity and corresponding verification, many ASIC design teams are using FPGAs for prototyping and emulation. These hardware-based verification methods overcome performance shortcomings associated with software-based simulation, thereby allowing a greater number of test scenarios to be verified. However, with these advantages come several major issues that must be addressed when moving from software-based to hardware-assisted verification. Among these issues is the challenge to understand the internal behavior of the design prototype when the system does not perform as expected. FPGA prototyping and emulation can only be adopted if they provide sufficient visibility for efficient debugging. Furthermore, the visibility must be achieved with little overhead otherwise the benefit of performance gains will be erased by lengthened run times.
Inherent in silicon is the extremely limited signal access and visibility into the device. As a result, finding and analyzing the problems in FPGAs is dreadfully tedious and time consuming. Many approaches for improving FPGA debug focus on increasing visibility, such as multiplexing internal signals to output pins. However, these methods utilize significant resources to gain even the smallest insight into the silicon. Alternate methods – such as internal logic analyzers (ILAs) – are structured, but are more suitable for understanding the values of a few architectural registers rather than combinational logic values. These and other related methods often require a "trial and error" approach since the engineer may not initially know what part of the design needs to be examined. Each iteration is time-consuming because of the time it takes to insert observation points and recompile the design into the FPGA. And once the relevant signal values are accessed, the next step is analysis. Because extracting the data and analyzing it are so tightly integrated, the arduous task of debugging the FPGA has become a major bottleneck in adopting prototyping and emulation techniques for verification.
March 07, 2006 -- pldesignline.com
With the rise in design complexity and corresponding verification, many ASIC design teams are using FPGAs for prototyping and emulation. These hardware-based verification methods overcome performance shortcomings associated with software-based simulation, thereby allowing a greater number of test scenarios to be verified. However, with these advantages come several major issues that must be addressed when moving from software-based to hardware-assisted verification. Among these issues is the challenge to understand the internal behavior of the design prototype when the system does not perform as expected. FPGA prototyping and emulation can only be adopted if they provide sufficient visibility for efficient debugging. Furthermore, the visibility must be achieved with little overhead otherwise the benefit of performance gains will be erased by lengthened run times.
Inherent in silicon is the extremely limited signal access and visibility into the device. As a result, finding and analyzing the problems in FPGAs is dreadfully tedious and time consuming. Many approaches for improving FPGA debug focus on increasing visibility, such as multiplexing internal signals to output pins. However, these methods utilize significant resources to gain even the smallest insight into the silicon. Alternate methods – such as internal logic analyzers (ILAs) – are structured, but are more suitable for understanding the values of a few architectural registers rather than combinational logic values. These and other related methods often require a "trial and error" approach since the engineer may not initially know what part of the design needs to be examined. Each iteration is time-consuming because of the time it takes to insert observation points and recompile the design into the FPGA. And once the relevant signal values are accessed, the next step is analysis. Because extracting the data and analyzing it are so tightly integrated, the arduous task of debugging the FPGA has become a major bottleneck in adopting prototyping and emulation techniques for verification.
To read the full article, click here
Related Semiconductor IP
- Zigbee Transceiver PHY
- Data Flow Architecture IP
- AMBA SPI Controller MRAM Controller
- Ethernet MAC
- Protocol Bridges
Related Articles
- Increasing bandwidth in industrial applications with FPGA co-processors
- The rise of FPGA technology in High-Performance Computing
- Advanced Topics in FinFET Back-End Layout, Analog Techniques, and Design Tools
- How silicon and circuit optimizations help FPGAs offer lower size, power and cost in video bridging applications
Latest Articles
- A Low-Latency ASIC Architecture for Real-Time Line Segment Detection
- BitFair: A 12nm Bit-Serial CNN Accelerator with Learnable Early Termination and Adaptive Bit Ordering for Ultra-Low-Power XR Vision
- A Flexible Sparsity-Aware FPGA Accelerator with Column-Wise Compression for Efficient CNN Inference
- Reducing Instruction-Fetch Energy in RISC-V for Embedded AI Processing via Dynamic and Static Loop Caching
- SPARC: Automated Root-Cause Analysis of Pre-Silicon Power Side-Channel Leakage in the Processor Design Flow