The pitfalls – and the promise – of functional verification
Matt Hilbert, Editor
You’ve probably been there. The RTL is complete, the testbench implemented, both are compiled into a verified simulation build, and the cursor is hovering over “run”. One click is all it takes. Initial vectors are applied, the first assertions fire…
…and then the problems start. The log reports failures due to uninitialized signals, or protocol handshake violations, or incorrect reset sequencing, or coverage gaps, or other factors you weren’t expecting. You’re not alone. Far from it. The 2024 Wilson Research Group Functional Verification Study revealed that only 13 percent of FPGA projects see no non-trivial bugs escaping into production. The same study showed that it actually decreased from 17 percent in 2020, and 22 percent in 2016.
Importantly, it’s often not one bug that’s the issue in the 87 percent (yes, 87 percent) of projects that introduce bugs. In nearly two thirds of cases, it’s two or three or even more. That’s a lot of time, effort and money in a lot of places being spent on debugging, revalidation and remediation.
When measured in terms of how it affects project completion schedules, it becomes a lot clearer. Only just over a third of design projects are completed on schedule, another third are up to 20 percent behind schedule, and there’s then a slow descent of doom to the 9 percent of projects which are 50 percent or more behind schedule. Not a good place to be.
The design flaws contributing to those bugs are varied, with logic or functional flaws leading the pack at 48 percent followed by clocking at 32 percent. Most of the rest hover around the 15 percent mark (multiple bugs means the total exceeds 100 percent), the major ones being issues with crosstalk, power consumption, mixed-signal interfaces, timing paths being too fast or too slow, and firmware.
Given that logic or functional flaws contribute to nearly half of bugs, either alone or in combination with other flaws, it’s worth looking a little closer. Here, the major cause in 60 percent of cases is design error. As you might expect, however, it’s followed closely by incorrect specifications at 59 percent and changes in specification at 42 percent, with flaws in internal or external IP playing a much smaller role.
What’s going on?
There’s a puzzling paradox in all of this. The FPGA industry as a whole is healthy and it’s growing in size as well as scope with the advent of AI. There’s a pressing need for more FPGA engineers. And FPGAs aren’t exactly new. At the first FPGA Horizons Conference in October 2025, a session from AMD, 40 Years of FPGA Innovations, talked about how Ross Freeman the co-founder of Xilinx introduced the world’s first commercially viable FPGA, the XC2064 in 1985. Since then the successor to Xilinx, AMD, has shipped over three billion FPGAs and adaptive SoCs. So why the issues? Why the problems?
The rise and rise of SoC FPGAs
Firstly, there’s the number of embedded processor cores FPGA engineers are now working with, thanks to the rise in System-on-Chip (SoC) FPGAs. A surprising 80 percent of FPGA projects now use embedded processors, with 27 percent using one, 18 percent using two, and 35 percent using three or more.
All of which changes the game. While SoC FPGAs offer huge flexibility with hardware acceleration right next to software control, it also means FPGA engineers have to think like system architects. They need to partition functionality between the FPGA fabric and the on-chip processor subsystem, consider integration and verification challenges from boot sequences to mixed domain timing, and ensure even tighter constraints on resource usage, power budgets, and thermal hotspots.
The increase in asynchronous clock usage
This same shift toward highly-integrated, system-level architectures has also seen an increase in asynchronous clock domains, which now average between five and ten per device. This growth stems from the convergence of diverse subsystems we’re now seeing on a single chip, each optimized for its own clock domain. While this enables performance tuning and efficient resource use, it also multiplies the boundaries where signals cross between unrelated timing domains. These clock domain crossings (CDCs) introduce the risk of metastability and subtle, non-deterministic failures that may evade standard simulation and functional and system-level verification.
Security and safety concerns
Many companies and organizations are now making security and safety a key priority. Nearly two-thirds of FPGA projects expect security controllers, for example, to protect sensitive data, which adds complexity to functional verification. Two thirds of FPGA projects also now have to follow one or more safety standards, like DO-254 in avionics, a structured and certifiable process for developing airborne electronic hardware so that it performs safely and reliably throughout its operational life.
As a result, 75 percent of FPGA engineers spend one day or more per week analyzing, identifying, quantifying, and mitigating risks, considering safety architecture and design, and conducting safety verification to demonstrate their designs can handle abnormal conditions without creating unsafe behavior. All of which is important work, but it also brings additional challenges to verification.
What can you do about it?
There’s already a shift underway, with more designs drawing on pre-verified IP cores and vendor-supplied IP libraries. These can significantly reduce development time and costs, and minimize verification effort, although integrating them into your specific project still requires thorough checking. They’re a strong fit for many projects, but not all.
When they’re not, consider adding formal techniques to your simulation-based techniques if you don’t already do so. You’ll already have a testbench and test environment set up, for example, to simulate your design, apply stimuli, monitor the outputs and check them against the results you expect. You’ll be looking at code coverage, functional coverage, assertions and constrained-random simulation.
Instead of relying on simulation to sample behavior, formal verification uses mathematical proofs to show that specified properties or behaviors hold for all possible input sequences and states, within the depth or state space limits you define. When a proof completes without finding a counterexample, you have assurance within those bounds.
Because it uses mathematical proofs to exhaustively explore reachable states, it’s good for finding issues that simulation might miss like rare timing alignments. You can also apply it to individual RTL blocks as soon as they’re written, letting you test and prove elements like protocol compliance and safety properties before integration. If your design needs to be safety- or security-critical, it can prove the unsafe behavior mentioned earlier won’t happen by demonstrating, for example, that a secure state machine never transitions to an unprivileged state without the correct key sequence. Many formal verification tools also now integrate static CDC analysis, exhaustively checking every signal crossing against structural synchronization rules, so potential metastability issues are caught without depending on handwritten test vectors.
Where should you go next?
A good place to start is right here, in this journal, where many of the issues I’ve talked about have been covered. CDC, for example, has been highlighted as an issue FPGA engineers should now be conversant with. Dave Wallace from Blue Pearl Solutions has written a great article, From chaos to clarity: CDC methodologies for success. Go to page 18 and you’ll see how it gives FPGA engineers a clear, practical framework for identifying, analyzing, and fixing CDC issues before they cause costly respins.
Flaws relating to power consumption and mixed-signal interfaces were also seen to be a cause of 25 percent of bugs. Fortunately, Dan Binnun from E3 Designers has written another engaging and informative article, Why you really should be thinking about power and signal integrity. Go to page 40 and find out how to identify, simulate, and mitigate power and signal integrity issues early, improving reliability, and reducing problems.
Many FPGA engineers are turning to verification methodologies to help reduce verification time and resolve the issues this article talks about. Espen Tallaksen from EmLogic talks about his favored methodology in his article, Why UVVM can result in faster and better FPGA verification, Turn to page 30 and discover how the Universal VHDL Verification Methodology (UVVM) enables teams to boost coverage, reduce debug time, and improve the overall quality of FPGA designs without adding cost.
Finally, this article is based on a fascinating report from Siemens, The 2024 Wilson Research Group Functional Verification Study. If you’d like to know a lot more about the challenges – and the opportunities – of functional verification, I’d recommend downloading it from: https://resources.sw.siemens.com/en-US/white-paper-2024-wilson-research-group-ic-asic-functional-verification-trend-report/
