Earlier I blogged about IC and ASIC functional verification, so today it’s time to round that out with the state of FPGA functional verification. The Wilson Research Group has been compiling an FPGA report every two years since 2018, so this marks the third time they’ve focused on this design segment. At $5.8 billion the FPGA market is sizable, and forecasted to grow to $8.1 billion by 2025. FPGAs started out in 1984 with limited gate capacity, and have now grown to include millions of gates, processors and standardized data protocols.
Low volume applications benefit from the NRE of FPGA devices, and engineers can quickly prototype their designs by verifying and validating at speed. FPGAs now include processors, like: Xilinx Zynq UltraSCALE, Intel Stratix, Microchip SmartFusion. From the 980 participants in the functional verification study, the FPGA and programmable SoC FPGA design styles are the most popular.
As the size of FPGAs has increased recently, the chance of a bug-free production release has dropped to just 17%, which is even worse than the 30% of IC and ASIC projects for correct first silicon. Clearly, we need better functional verification for complex FPGA systems.
The types of bugs found in production fall into several categories:
- 53% – Logic or Functional
- 31% – Firmware
- 29% – Clocking
- 28% – Timing, path too slow
- 21% – Timing, path too fast
- 18% – Mixed-signal interface
- 9% – Safety feature
- 8% – Security feature
Zooming into the largest category of failure, logic or functional, there are five root causes.
FGPA projects mostly didn’t complete on time, once again caused by the larger size of the systems, complexity of the logic and even the verification methods being used.
Engineers on an FPGA team can have distinct titles like design engineer or verification engineer, yet on 22% of projects there were no verification engineers – meaning that the design engineers did double-duty and verified their own IP. Over the past 10 years there’s been a 38% increase in the number of verification engineers on an FPGA project, so that’s progress towards bug-free production.
Verification engineers on FPGA projects spent most of their time on debug tasks at 47%:
- 47% – Debug
- 19% – Creating test and running simulation
- 17% – Testbench development
- 11% – Test Planning
- 6% – Other
The number of embedded processors has steadily grown over time, so 65% of FPGA designs have one or more processor cores now, increasing the amount of verification between hardware, software interfaces; and managing on-chip networks.
The ever-popular RISC-V processor is embedded in 22% of FPGAs, and AI accelerators are used in 23% of projects. There are 3-4 average number of clock domains used on FPGAs, and they require gate-level timing simulations for verification, plus the use of static Clock Domain Crossing (CDC) tools for verification.
Security features are added to 49% of FPGA designs to hold sensitive data, plus 42% of FPGA projects adhere to safety-critical standards or guidelines. On SemiWiki we’ve often blogged about ISO 26262 and DO-254 standards. Functional Safety (FuSa) design efforts take between 25% to 50% of the overall project time.
The top three verification languages are VHDL, SystemVerilog and Verilog; but also notice the recent jumps in Python and C/C++ languages.
The most popular FPGA methodologies and testbench base-case libraries are: Accellera UVM ,OSVVM and UVVM. The Python-based cocotb was even added as a new category for 2022.
Assertion languages are led by SystemVerilog Assertions (SVA) at 45%, followed by Accellera Open Verification Library (OVL) at 13% and PSL at 11%. FPGA designs may combine VHDL for RTL design along with SVA for assertions.
Formal property checking is growing amongst FPGA projects, especially as more automatic formal apps have been introduced by EDA vendors.
Simulation-based verification approaches over the past 10 years shows steady adoption, listed in order of relevance: Code coverage, functional coverage, assertions, constrained random.
Summary
The low 17% bug-free number for FPGA projects in 2022 that made it into production was the most surprising number to me, as the effort to recall or re-program a device in the field is expensive and time consuming to correct. A more robust functional verification approach should lead to fewer bug escapes into production, and dividing the study participants into two groups does show the benefit.
Read the complete 18 page white paper here.
Related Blogs
- Achieving Faster Design Verification Closure
- An Update on HLS and HLV
- Connecting SystemC to SystemVerilog
- Today’s SoC Design Verification and Validation Require Three Types of Hardware-Assisted Engines
- Verifying 10+ Billion-Gate Designs Requires Distinct, Scalable Hardware Emulation Architecture
- UVM Polymorphism is Your Friend
- Coverage Analysis in Questa Visualizer
- EDA in the Cloud with Siemens EDA at #59DAC
Comments
There are no comments yet.
You must register or log in to view/post comments.