Infineon Combines OVM and Systemverilog
Total Page：16
File Type：pdf, Size：1020Kb
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. onsider embedded microcon - many as 70 distinct IP blocks that must trollers. They rarely receive the be integrated and verified. And the hard - aCttention paid to the latest chips that ware challenges are only the half of it. "We were the first guys to adopt power desktops, servers, game consoles Like all microcontrollers, those this methodology at Infineon, and the like. However, when it comes designed by Infineon rely heavily on and to show that it works at a to ubiquity, microcontrollers can't be firmware. The firmware is critical, and relatively complex SoC level. I beat. These blocks of processing capa - not just the higher-level code that is see a good future for this bility, memory and programmable closest to the application itself and that combined use of OVM and peripherals are found in a range of usually resides in flash memory. The SystemVerilog in the company." products, from power tools to toys. lower level boot read only memory Their reach is in part due to the (ROM) code executes an increasing RANGA KADAMBI SENIOR STAFF ENGINEER metronome of Moore's Law, which of number of background processing INFINEON TECHNOLOGIES course for decades has steadily pushed tasks, including bootstrap loading, prices down across the semiconductor memory checking and so on. industry. Today 8-bit microcontrollers, As is true of the hardware, the which account for the majority of all firmware itself is increasingly complex. CPUs sold in the world, sell for as little Just a few years back the firmware for as $0.25 each. Consider that in the early Infineon's automotive chips – the 1970s Intel's 8008, the world's first 8- Munich, Germany-based company is bit processor, sold for $120, an amount the No. 1 chip supplier to the automo - roughly equal to $520 today. Microcontrollers are niche devices, usually built to execute a small handful of tasks. For example, an engine micro - controller might take input from various sensors and adjust fuel mix and spark plug timing. However, the speci - ficity of these chips does not equate to design simplicity. High-end 32-bit Infineon microcontrollers that drive Ranga Kadambi (left) and Eric Eu (right), engineers at Infineon many automotive applications have as Technologies in Singapore, combined OVM and SystemVerilog in a firmware verification pilot project. www.mentor.com tive industry – amounted to just a few neers in Infineon’s automotive, micro - would not be easy to migrate from e to hundred lines of code. Today the controller division in Singapore. OVM because of fundamental language firmware file is 16 kilobytes, and differences. This also gave the team the Starting from scratch: time inten - growing larger with each release. opportunity to make all of the OVM sive but ultimately worth it For those writing the firmware, the verification components (OVC) more Kadambi and his colleagues work on challenge is a bit like building a plane structured, a contrast to the former e Infineon's TriCore architecture, the first while flying it. Namely, they are environment. single-core 32-bit microcontroller-DSP writing software for early-stage hard - Building an OVM testbench from architecture optimized for real-time ware that is nowhere near stable. How scratch certainly takes a bit of effort. embedded systems. TriCore unifies the do you verify something when every - There's no getting around the work to best of three worlds - real-time capabil - thing from the individual IP blocks to understand the OVM technology and its ities of microcontrollers, computational the overall design is still a work-in- guidelines, and then make its firmware prowess of DSPs, and highest perform - progress? That was the challenge in a verification methodology fit accord - recent pilot project to design and verify ingly. However, as the project a power train microcontroller at progressed, Kadambi and his collabo - Infineon in Singapore. rators became convinced that the OVM The solution was a layered method - “Verifying all this functionality at methodology and technology were ology. The first layer is a standard the design stage is difficult, worth the initial ramp up. The main Open Verification Methdology (OVM) especially with unverified benefit: OVM enables a structured testbench that is used to drive input underlying hardware.” approach that lends itself to reuse. interfaces using constrained-random This effort to learn OVM took place ERIC EU pattern generation. The layer also against a backdrop of increasing time SENIOR VERIFICATION ENGINEER observes outputs, measures functional and resources required to verify INFINEON TECHNOLOGIES coverage, and compares the results firmware in general. Five years ago, against expected values, a process verification of automotive Infineon known as scoreboarding. A second microcontrollers took no more than ance/price implementations of RISC layer implements a well-defined struc - four man-months. Today, Infineon loadstore architectures. ture for observing (using the spends twice as long, largely due to When building the new testbenches SystemVerilog bind construct) and rising complexity. with OVM, the goal was to use the driving internal nodes in the VHDL Even seemingly simple tasks can be same firmware verification method - design (using SignalSpy™, a tech - confounding. Take, as a hypothetical ology the team used in e, a verification nology within the Mentor Graphics case, firmware written to toggle a language developed by Cadence and Questa® simulator). particular port. It should be straightfor - approved in IEEE Standard 1647. "We believe this combined approach ward enough to verify the code and Kadambi and his colleagues chose to will be more widely used in the future," check the ports that are toggled. But start from scratch rather than migrate says Ranga Kadambi, Infineon senior what happen when there are additional portions of the e testbench to staff engineer. Kadambi, who has been conditions, as is inevitably the case? SystemVerilog because it did not have with the company for 12 years, is "Perhaps the firmware reads the an e Reuse Methodology (eRM) currently, leading a team of functional counter value from another address and compliant testbench. Additionally, it verification and design-for-test engi - is coded to toggle every set number of SystemVerilog/OVM top-level is rates a new or replacement block, the instantiated under this VHDL top-level. team simply needs to add or swap out The first layer of the OVM test one OVC. Given the modular nature of environment consists of an interface OVC and of SystemVerilog in general, layer for observing and driving signals the rest of the stitched-together design into the DUT. Firmware verification can be left mostly as is, a boon to the differs from the conventional bus func - design team. Modularity is also a bit tional model (BFM) because Kadambi unusual in an era in which complexity and Eu are mostly interested in often hides interdependence and tugging whitebox testing. Instead of a BFM on one loose thread too often causes an model, the team used a signal map, a entire digital fabric to unravel. collection of internal signals of interest Finding bugs while laying foun - during verification. The signal map dation for future implements methods for observing and Verification methodologies must driving internal signals. In this project, prove their mettle by finding bugs, and the used the SystemVerilog bind Infineon's from-scratch approach did construct to observe the internal VHDL just that. The team found 12 firmware signals and the Mentor Graphics bugs and five hardware bugs using the Questa SignalSpy technology for OVM for firmware verification. Infineon Automotive TriCore driving them. Common firmware bugs were the result Family AUDO MAX, which target The second layer consists of the powertrain and chassis applica - of the implementation not meeting Open Verification Components tions. Infineon worked with Mentor specification (these were detected by Graphics in a pilot project to verify (OVCs), encapsulated and reusable assertions) or implementations that did firmware for AUDO MAX chips. components that follow consistent not cover all possible scenarios in the architecture and communication chan - cycles," says Eric Eu, Infineon senior firmware (detected by random stimulus nels. The team uses TLM analysis ports verification engineer who focuses on generation and coverage). Firmware and TLM analysis fifos for the OVC firmware verification for the company’s verification quite often also detects interconnections. TLM analysis ports 32-bit TriCore microcontrollers. "And hardware bugs (through assertions) provide simple and powerful transac - maybe there's input from another pin caused by registers that are not writable tion-based communication because of that tells the code whether the counter or readable because either their protec - their ease of implementation, support of should be reset or just stopped with each tions are not set correctly in the RTL or multiple connections, and execution in toggle. Verifying all this functionality at their top-level connections are incor - the delta cycle. the design stage is difficult, especially rect. Most significantly, the team hit OVCs are critical in helping the with unverified underlying hardware." verification targets related to functional team to deal with large numbers of IP coverage and code branch coverage. Layered approach blocks. Each such block more or less The latter is a methodology that The design under test (DUT) is maps to a corresponding OVC, and executes both trunk and branch blocks mainly coded in VHDL with some IP together these OVCs interact and cross of code, a technique that helps to deal blocks coded in Verilog. The DUT is check at a high level in such a way as to with multiple revisions, a fact of life in instantiated by a VHDL top-level test - hide the lion's share of the complexity.