Verifying complexity with an all-encompassing methodology

The increased size and complexity of designs continues to push design and verification methodologies to progressively higher levels of abstraction. These upward shifts in abstraction tend to occur about every decade or so, and we are currently experiencing one in the shift from RTL to transaction-level modeling (TLM).

Abstractions must eventually be converted back effectively and efficiently? In its most basic sense, verification is the to detailed designs in order to be implemented. The most interesting aspect of the shift to TLM is that it is the first upward shift in modeling abstraction not accompanied by a corresponding, automated path back to the lower abstraction level. The RTL shift was accompanied by (and was largely caused by) the advent of synthesis. In contrast, as a design moves up to the transaction level, the transition down to RTL is essentially manual — although some tools can automate parts of the process.

The only way to ensure the integrity of the transition is to put together a verification environment that can effectively verify the design at multiple levels of abstraction. To do this, one needs a methodology that is targeted at solving the problem of how to verify designs consistently at those multiple levels. In addition, the methodology must make it easy for users to take advantage of functional coverage, constrained-random stimulus generation, assertions, and other advanced verification techniques.

The verification landscape

Tools and technologies provide the means to gather data. An advanced functional verification methodology helps turn that data into useful information. Therefore, when we talk about ‘methodology’, we mean the application of tools and technologies in proven ways, based on knowing what works and what does not. It is no longer a matter of how fast your simulator runs a particular test case, but more importantly, how quickly you can fully verify the design, including the time to write the test cases in.

This means that verification teams must be able to produce more tests with less redundancy to cover targeted features more quickly. The optimal verification solution helps engineers achieve higher productivity by applying advanced technologies and methodologies to their best advantage.

Over recent years, different aspects of verification have earned their own three-letter acronyms (TLAs). Among these are testbench automation (TBA), transaction-level modeling (TLM), assertion-based verification (ABV), and coverage-driven verification (CDV). The technologies that enable these methodologies are constrained-random simulation, assertions, formal verification, and functional coverage. An overarching methodology that ties all of these together into a single coherent solution is needed.

Figure 1.The basic verification process fosters predictability and design quality

In its most basic sense, verification is the process of comparing a design’s behavior against the designer’s intent. Methodology is all about establishing a highly effective process that ensures verification predictability and design quality (Figure 1).

Beginning with the functional specification, this process follows a bifurcated yet interdependent flow. On the right side is design implementation and debug. This is where ABV comes into play; although assertions are also used in CDV, on the left side of the flow. CDV includes testbench automation and functional coverage. Guided by the verification plan, the testbench is implemented in the simulator to verify that the design intent is fulfilled. The primary job of assertions is to tell you when and where problems happen. They also inform functional coverage. If bugs are found, assertions help you fix them more quickly. If none is found, CDV helps to determine if you have achieved sufficient coverage.

Simulation performs the behavior versus intent comparison dynamically, with the testbench and assertions serving as alternate ways of specifying that intent. TBA simplifies the writing of the testbench. ABV locates bugs when and where they occur, and verifies corner cases by describing sequential coverage points. On the other hand, formal verification statically compares the design to its intent. ABV enables formal analysis to be invoked as a complement to simulation, enhancing CDV and enabling additional technologies like dynamic formal verification. Assertions, simulation, and formal verification help convert functional coverage data into useful information that is fed back, either manually or programmatically, into the TBA engine in order to target new tests at unverified functionality.

The Mentor Graphics Advanced Verification Methodology (AVM) aims to encapsulate this process in a single package. It captures the best practices of experienced users and codifies them for use by all designers and verification engineers, allowing them to apply leading-edge verification technologies to designs at multiple levels of abstraction, using multiple languages.

Essential standards

The more engineers embrace new methodologies, the more powerful they become. To foster widespread acceptance of an advanced verification methodology, tools must support interoperability and automation, accommodate divergent engineering styles and choices, and be easy to adopt in an incremental fashion. Most importantly, they must fully support the leading verification languages and libraries, including SystemVerilog, SystemC, the Property Specification Language (PSL), and the Open Verification Library (OVL).

The most important languages for advanced design and verification are SystemVerilog and SystemC. Their design constructs allow modeling at higher levels of abstraction, enabling the creation and verification of next-generation designs. A full, mixed-language design seat allows advanced testbenches written in SystemVerilog or SystemC to be used with any design language. This has the added benefit of facilitating advanced verification methodologies.

TLM in verification

An advanced verification methodology enables modeling at multiple levels of abstraction by the use of TLM. Transactions are often used to model hardware systems, and the semantics of software systems can be easily represented as high-level transactions. This presents opportunities for system architects, software, verification, and hardware engineers to communicate directly with one another. Higher levels of abstraction and TLM enable a significant amount of software to be used as part of the testbench and allow testbench development to begin before RTL coding is complete. As the RTL design becomes available, verification engineers can insert transactors that translate the transactions to signal-level transitions.

In addition, this high-performance bridge between disciplines improves cooperation between the design and verification teams. It does this by allowing software engineers and system architects to share data directly with verification and hardware engineers. This cross-discipline communication helps to uncover and fix issues early in the design cycle.

The AVM in detail

The AVM is an open, non-proprietary verification methodology for a true system-level-through-RTL design and verification flow. The AVM provides libraries of base classes (in SystemC and SystemVerilog) and modules (in SystemVerilog) in open-source form. These form the basis of an advanced testbench environment that combines transaction technology with RTL verification in a complete verification platform applicable at any level of abstraction.

These libraries have been implemented to solve many infrastructure-level problems encountered in setting up such environments, improving productivity by yielding functional, reliable testbenches much faster than would be otherwise possible.

The communication mechanism between verification components in the AVM is based on the use of TLM interfaces, as defined by the OSCI TLM1.0 standard, implemented in both SystemC and SystemVerilog. By standardizing communication between components, users are free to focus on the component behavior to support constrained-random stimulus generation, functional coverage, scoreboarding, and more.

Since all components use the same interfaces, they are highly reusable within and across projects – another large productivity gain. Productivity is further enhanced since the focus on TLM interfaces makes it easier to develop verification components at higher levels.

By relying on standard TLM interfaces, it is now possible to begin assembling a testbench around an early, transaction-level system-model of a design. This testbench can be reused throughout the design refinement process simply by adding new components or adapters to convert the high-level transactions in the testbench to RTL behaviors connected to the device under test (DUT).

Figure 2.TLM and advanced verification allow disciplines to come together earlier and more often

The AVM includes working examples, in both SystemVerilog and SystemC, that progress incrementally from the basics of modularity and reusability up to realistic, domain-specific examples that illustrate how to assemble advanced coverage-driven testbenches.

These examples and supporting libraries are delivered in open-source form, so the libraries and models provided can be used freely to help users get up and running on the next project. The AVM then comes with extensive, book-form documentation: the Verification Cookbook. This discusses the different concepts in a series of examples.

The AVM’s package of libraries, examples, and documentation provides an easy-to-use kit to get even the verification beginner up and running quickly, while providing the features, modularity, and reusability that advanced verification engineers have come to expect. The AVM makes verification teams more efficient by enabling them to write less code and find bugs faster. Engineers can use constrained-random testing and assertions to broaden the bug search, they can call available libraries for common tasks and use examples as templates; and they can write reusable code in object-oriented SystemVerilog and SystemC.

All of the AVM libraries and examples are provided in open-source form, so users are free to use these to get up and running quickly. They can even add their own modifications. The extensive set of examples, coupled with the Verification Cookbook, allows us to share the accumulated knowledge of our verification experts, customers, and consulting partners to show what works for advanced functional verification of large, complex designs.

AVM and leading languages

The AVM supports the creation of modular reusable testbenches. By freely mixing classes and modules in SystemVerilog, it has the advantage of being easy to connect directly to an RTL DUT, while retaining all the needed flexibility and configurability that HVL users have come to expect and demand.

In addition to simplifying the DUT connections, the use of modules allows AVM-compliant components to contain assertions to check behaviors and collect coverage information. This can be communicated to the rest of the testbench via TLM.

Figure 3. Reusing a transaction-level testbench withan RTL design

The use of TLM, implemented in both SystemVerilog and SystemC, allows the exact same concepts to be applied to system-level architectural models written in SystemC as to RTL and gate-level models in SystemVerilog, Verilog, and VHDL.

Regardless of the testbench or design language, the AVM makes it much easier for users to define the topology of the test environment, leaving the verification engineers free to focus on the functionality of the specific components, such as stimulus generators, drivers, monitors, and scoreboards.

Implementations of TLM in SystemVerilog and SystemC are provided so that the concepts addressed by the AVM apply to the development of testbenches and verification environments, regardless of the underlying implementation language.

Each language has its strengths and weaknesses, but the AVM includes libraries and other infrastructure that take advantage of those languages’ respective strengths while supplying additional functionality to address their weaknesses. For example, SystemVerilog includes assertions and functional coverage directly in the language. In SystemC, a library of functional coverage components provides functionality similar to that of the SystemVerilog covergroupconstruct, affording SystemC users the same kinds of coverage capabilities. In SystemC, all components are themselves classes, so class/module duality is not an issue. SystemVerilog handles this issue deftly through its flexible use of either classes or modules for verification components.

The AVM is also neutral with respect to the design language used. Through the single-kernel, mixed-language environment provided by Questa, the AVM testbench can be connected to designs in Verilog, VHDL, SystemVerilog, SystemC or any combination thereof. In fact, the ability of the AVM to connect to VHDL designs means that VHDL users now have a standard, object-oriented testbench environment that they can use to apply all of the advanced verification features mentioned in this article.

Mentor Graphics
Corporate office
8005 SW Boeckman Rd
Wilsonville OR
97070
USA

T: +1 800 547 3000
www.mentor.com