| 2 min read

What ARE the Root Causes of Functional Flaws?

By Louie de Luna, Agnisys Director of North American Sales and Marketing

Functional flaws in our everyday electronics are annoying. Internet routers can suddenly stop working, or our smart phones can suddenly freeze. For safety-critical systems such as the airplane engine control system, functional flaws can be catastrophic, and can lead to fatalities of all passengers. For both consumer-type and safety-critical systems, ASIC/FPGA teams strive to minimize functional flaws to the best of their abilities using their verification prowess with the help of EDA tools.  The more the budget the better the resource they have for minimizing functional flaws.

I just attended the webinar about the results of the Wilson Research Group & Mentor’s 2018 Functional Verification Study, and I can say that I’m not surprised with the results regarding root causes of functional flaws – this is what my team and I come across with frequently when we talk to our prospective customers and verification community.

Confirmed by the 2018 study, the three major causes in ASICs are categorized by Design Error, Changes in Specification and Incorrect/Incomplete Specification.  When you combine the two categories related to specification, you can see that the functional flaws caused by issues related to specification is higher than issues related to design error.

ASIC Root cause of functional flaws


For FPGAs, the results are the same – the specification is the main culprit.

FPGA Root Cause of Functional Flaws

Again, I’m not surprised. The specification is the main source of all the design and verification activities. Any errors in the specification often lead to higher costs for fixing them and can even be the make or break of a given project.

The Hardware/Software Interface (HSI) data is a major component of the specification because it controls the configuration of peripherals and their communication with the software. The HSI:

  • includes the definition of addressable registers, interrupts, device drivers and low-level C-header files
  • is often manually captured and maintained in Word™ or Excel™, and used in conjunction with various files such as IP-XACT, SystemRDL, XML, Verilog and C/C++ header files
  • is used by multiple isolated teams including system architects, designers, verification engineers, firmware developers, lab testers and SW developers
  • registers need to be designed in Verilog or VHDL, and the corresponding UVM models need to be created for verification

With the amount of data and various teams who create and rely on it, the HSI can easily get chaotic without a process in place – this is the main reason why the specification is the main culprit of functional flaws.

If you don’t have a process for controlling the HSI data, you should definitely take a look at IDesignSpec. The tool’s main goals are to eliminate the HSI errors and inefficiencies, and to synchronize various teams so that they are all working from the same specification – which is the golden reference. The tool is an add-in to Word or Excel, and it can take in various input text files like SystemRDL and generate various output formats (see picture below). More importantly, you don’t have to design the RTL for the registers and UVM models manually, the tool will generate that for you.  The generated RTL supports standard buses such as AXI, AHB, APB or Avalon. The UVM register model covers all verification elements including sequences, covergroups, coverpoints, coverbins and illegal bins. The tool supports various complex registers including interrupt registers, shadow registers, alias registers, trigger buffer (write-combined), lock registers, virtual and multi-dimensional registers.

IDesignSpec Suite


In the future versions of the Wilson Research Group & Mentor Functional Verification Study (maybe 2028 😊), my dream is to see that the specification is no longer a major root cause of functional flaws – we already have a tool for it after all. With the help of IDesignSpec, FPGA/ASIC experts such as yourself can finally ensure that our internet routers and smart phones will work without any annoying bugs, and more importantly ensure that our safety-critical systems would always function as intended in order to prevent any disasters.

The road ahead would be narrow and rough – we have more ground to cover, more meetings to conduct, more leaders to educate, more verification problems to solve and more technology to invent.

As always, we invite you to contact us for a free evaluation or to learn more about our high-performance ASIC, FPGA, and SoC Software to solve complex design and verification problems for system development.

ic designer's guide to automating design through implementation of semiconductors