Infineon innovates in firmware verification by combining OVM and SystemVerilog
The No. 1 chip supplier to the automotive industry, Infineon worked with Mentor Graphics to pilot a new verification methodology. The result: a better, more structured approach to hardware/software co-verification.
“We were the first guys to adopt this methodology at Infineon, and to show that it works at a relatively complex SoC level. I see a good future for this combined use of OVM and SystemVerilog in the company.”
Ranga Kadambi, Infineon senior staff engineer
The Problem: Finding verification footing on a shifting foundation
For those writing the firmware, the challenge is a bit like building a plane while flying it. Namely, they are writing software for early-stage hardware that is nowhere near stable. How do you verify something when everything from the individual IP blocks to the overall design is still a work-in-progress? That was the challenge in a recent pilot project to design and verify a power train microcontroller at Infineon in Singapore.
The Solution: Layered approach helps hide lion's share of complexity
The solution was a layered methodology. The first layer is a standard Open Verification Methdology (OVM) testbench that is used to drive input interfaces using constrained-random pattern generation. The layer also observes outputs, measures functional coverage, and compares the results against expected values, a process known as scoreboarding. A second layer implements a well-defined structure for observing (using the SystemVerilog bind construct) and driving internal nodes in the VHDL design (using SignalSpy™, a technology within the Mentor Graphics Questa® simulator). Key to the second layer: Open Verification Components (OVCs), which help deal with large numbers of IP blocks and interact in such a way as to hide the lion's share of the complexity.
The Results: Success measured by the metrics that matter most
Verification methodologies must prove their mettle by finding bugs, and Infineon's from-scratch approach did just that. The team found 12 firmware bugs and five hardware bugs using the OVM for firmware verification. Common firmware bugs were the result of the implementation not meeting specification (these were detected by assertions) or implementations that did not cover all possible scenarios in the firmware (detected by random stimulus generation and coverage). Most significantly, the team hit verification targets related to functional coverage and code branch coverage. The latter is a methodology that executes both trunk and branch blocks of code, a technique that helps to deal with multiple revisions, a fact of life in all software development.
“Verifying all this functionality at the design stage is difficult, especially with unverified underlying hardware.”
Eric Eu, Infineon senior verification engineer