FV White Papers
With a Boost from OVM, SuperSpeed USB3.0 MVC BFM Accelerates Verification
The need to deal with verification is spurring a wave of technological experimentation across EDA. Though at best most such experiments result in incremental improvement, collectively the work adds up to an impressive effort to dramatically improve verification. One such advance is the USB3.0 Multi-view Verification Component (MVC). USB3.0 MVC is Open Verification Methodology (OVM)-based verification IP. It implements transaction level modeling-based methodology, which accelerates the verification of complex designs. More precisely, the verification IP bus functional model (BFM) provides users maximum controllability, described in this whitepaper, which makes it easier to create scenarios and hit corner cases.
More White Papers
Using Assertions to Satisfy Elemental Analysis
This paper discusses DO-254 and what it requires for verification (including advanced methods for DAL A/B designs), explains the original intent of Elemental Analysis, the way it is typically satisfied today with code coverage, introduces ABV, and proposes a method for using this technique to not only satisfy Elemental Analysis but also to support a systematic approach to satisfying a claim of Robustness testing.
Virtual Devices for Protocol-Specific Host and Peripheral Interfaces
This paper provides a brief genealogy of virtual devices, describes their characteristics and benefits, and presents two design applications that demonstrate its utility and effectiveness.
Virtualization makes emulation more readily available to all design teams within a company and increases the flexibility, visibility, and capacity of emulation environments. Virtualized solutions add a range of capabilities that promise to redraw the functional verification landscape. These include virtual host and peripheral models (called “virtual devices”) and software debug technologies enabled by transaction-based, co-model channel technology. Virtual devices are an emerging technology, with products beginning to offer the same functionality as traditional In-Circuit (ICE) solutions, but without the need for additional cables and additional hardware units.
Understanding electronic IP: common issues and how to find them
Using IP blocks in designs requiring DO-254 compliance is becoming more popular as a way to reduce costs and schedules. However, the use of IP comes with its own problems and pitfalls. A good methodology to better screen this IP before its usage can significantly reduce unexpected problems and lower risk, especially on safety critical designs. The most important soft IP screening technologies are automatic formal check and clock domain crossing analysis. This paper will provide a background explanation of IP, including: what types exist in the market; caveats to their usage; and suggestions to better analyze IP before it is used in a design, thus lowering risk and improving product safety. (Note: This paper does not address IP compliance issues. For more information on that topic, please refer to the DO-254 User Group paper "Use of Intellectual Property (IP) Cores in Airborne Electronic Hardware".
Using Formal Verification to Check SoC Connectivity Correctness
Formal verification offers a solution that is quick, exhaustive and allows for efficient debug. It’s true that traditionally, chip-level formal verification is impractical. The approach usually targets the block level to keep the size of the state space to an appropriate level. But given that connectivity checking is focused solely on the wiring — which is generally a simple part of the device, compared to the complexity found at the block-level — the state space can with some assumptions be reduced to a manageable size. The nature of this simplification depends on the type of checking that is required. After first outlining several types of connectivity checks, this paper then provides details, including code, of a new semi-automated verification flow used by several Mentor Graphics customers to simplify connectivity checking. The flow is based on a script-based environment, about which sufficient information is provided to begin implementing the new verification approach.
Static Verification for Complex Designs
Traditionally, simulation-based dynamic verification techniques — such as directed tests, constrained-random simulation, and hardware acceleration — have been the work horses of functional verification. As modern day SoC designs become more integrated, the only way to advance significantly beyond dynamic verification is to increase the adoption of static verification. In this article, we will summarize a variety of static verification techniques, including RTL lint, static RTL checks (which include low power structure verification and clock domain crossing verification), sequential formal checks, application-specific formal solutions and assertion-based formal property verification.
Best practice development processes for medical device FPGAs
For FPGA developers working on designs for medical devices, one approach to dealing with regulatory uncertainty is to borrow heavily from design assurance processes in other safety-critical industries, such as avionics, where standards are well established. These well-established standards mandate a development flow that is controlled, auditable and perhaps most important, specific to the requirements of hardware engineering. While following such a flow will not guarantee smooth sailing though every regulatory approval process for FPGA devices bound for medical applications, it is consistent with basic regulatory intent – to demonstrate to auditors that complex devices meet their requirements and perform well under all foreseeable conditions.
Advanced Testbench Configuration with Resources
Building robust, reusable testbenches means the testbench elements must be configurable. At its essence, configuring a testbench is a matter of populating a database with name/value pairs and providing a means for testbench objects to access that database. Simply storing and retrieving name/value pairs does not tell the whole story. There are a number of architectural issues concerning the design of the database and how to effectively populate and use the items in the database to build highly configurable, reusable testbenches. UVM provides a facility called resources that provides the configuration infrastructure and API. We will discuss approaches to common configuration problems in term of resources. We will show how to use resources to implement sophisticated configuration use models.
Parameters and OVM: Can’t They Just Get Along?
This paper discusses the methods that have proven useful for verifying a highly parameterized DUT within an OVM testbench. This includes enhancing the default OVM functionality to create parameterized OVM tests and, consequently, testbenches that still allow the use of +OVM_TESTNAME. Techniques will be discussed for dealing with parameterized virtual interfaces, efficiently passing parameters down through the testbench hierarchy from the OVM test, and determining when to use parameters versus alternative methods. The paper will discuss optimizations for improving simulation throughput when using parameters, including actual numbers illustrating the efficiency improvements. Finally, the paper will describe options for ensuring that a parameterizable DUT is fully verified.
TLM2 in SystemVerilog
Transaction-level modeling (TLM) is a methodology for building models at high levels of abstraction, those above RTL. TLM-2.0 is a library that contains classes that implements a methodology for building transaction-level models and connecting them together. TLM-2.0 was written in SystemC that implements a particular transaction-level methodology. It was developed by OSCI and released in 2009 and is now on its way to becoming an IEEE standard as part of the IEEE-1666-2011. In order to support new use models in SystemVerilog, a translation of TLM-2.0 is now included in UVM. This paper will describe the translation of TLM-2.0 from SystemC to SystemVerilog.