Property Specification: the Key to an Assertion-Based Verification Platform
Total Page:16
File Type:pdf, Size:1020Kb
Property Specification: The key to an Assertion-Based Verification Platform C. Michael Chang Harry D. Foster President and CEO Chief Architect Verplex Systems, Inc. Verplex Systems, Inc. [email protected] [email protected] Abstract interface constraints (a form of property Assertion-based verification—that is, user specified specification), properties and automatic property extraction combined 5. exhaustive formal verification and semi-exhaustive with simulation and formal techniques—is likely to be the property checking techniques. next revolution in hardware design verification. This paper explores a verification break-through prompted by This paper discusses the important role of property multi-level specification and assertion verification specification and automatic property extraction techniques. The emerging Accellera formal property techniques in the context of an assertion-based language, as well as the Open Verification Library verification flow. standards and the important roles they will play in future assertion-based verification flows are discussed. 1.1 Standards Furthermore, automatic property extraction techniques are explored—and their important roles in validating One organization that works to support improvements semantic consistency in the context of an RTL signoff in verification methodologies is Accellera (see flow. www.accellera.org). Their mission is to drive worldwide standards that enhance a language-based design 1 Introduction automation process. Recently, the Accellera Formal Verification Technical Committee selected the IBM A change is taking place in the way we design and Sugar language as the basis for its property specification verify our designs that will revolutionize the industry and language (PSL) [Accellera 2002]. This declarative result in the equivalent of a synthesis productivity property language supports top-down (that is, functional breakthrough in verification. This change demands that specification-driven) design methodologies. Declarative we move from natural language forms of specification to property languages are ideal for specifying architectural forms that are mathematically precise and verifiable, and and global properties, as well as defining interface lend themselves to automation. Property specification is specification during block-level partitioning. the key ingredient of this revolution, whose end result is In addition to PSL, the Accellera Assertion Committee improved verification through an intelligent testbench. An has developed a standard for specifying RTL assertion-based verification platform is an integral part of implementation properties directly within the designer’s an intelligent testbench, which consists of the following HDL through the Open Verification Library (OVL) key components: [Bening and Foster 2001] and the new SystemVerilog procedural assertion construct [Foster, et al. 2002]. The 1. verifiable testplans through property specification OVL provides a template for expressing a broad class of (that is, functional coverage models), assertions structurally within the designer’s RTL, while 2. hardware verification languages (HVLs) combined the new assertion construct facilitates expression of with property specification to raise the abstraction assertions procedurally during RTL development. Both level of testbench generation the OVL and the new assertion construct enable bottom- 3. reactive coverage driven testbenches based on up (that is, white-box) verifiable implementation property specification (assertions and functional practices, which improve simulation-based methodologies coverage), while providing a seamless path to formal verification. 4. automated block-level methodologies such as smart Combined, these powerful and expressive formal block-level simulation stimulus generation based on property languages enable engineers to: • specify properties as assertions and constraints for 2 Property specification formal analysis, • specify functional coverage models to measure the Informally, a property is a general behavioral attribute quality of simulation, (that is, collection of logical and timing relationships) • develop tools of the future, such as pseudo-random used to characterize a design. When discussing properties, constraint-driven simulation environments derived it is generally easier to view their composition as three from formal specifications, similar to the research distinct layers: by Yuan, et al. [1999]; and Shinmizu and Dill [2002]. • the Boolean layer, which is comprised of Boolean expressions (for example, Verilog or VHDL 1.2 Monitor-based specification expressions) • the temporal layer, which describes the relationship While standardizing a property language, such as PSL, of Boolean expressions over time is integral to addressing increased verification • the verification layer, which describes how to use a complexity, it is not the entire solution. Equally important property during verification to this revolution in design verification is an effective methodology that unifies traditional and formal Defining (or partitioning) a property in terms of the verification within an assertion-based verification abstract view (that is, layer structure) enables us to dissect framework. Recently, monitor-based methodologies have and discuss various aspects of properties. However, it is emerged as a technique for unifying traditional and formal actually quite simple to express design properties; the verification (for example, FoCs-Automatic Generation of three-layer view is merely a way to explain. Simulation Checkers from Formal Specification A property’s Boolean layer is comprised of Boolean [Abarbanel, et al. 2000]). Other approaches include expressions composed of variables within the design creating a protocol bus-monitor that examines an agent’s model. For example, if we state that “signal en1 and output signals (as the monitor’s input) and then generates signal en2 are mutually exclusive” (that is, a zero-or-one- a Boolean correcti output signal, which is true when agent hot condition in which only one signal can be active high i is compliant to the specification (for example, Monitor- at a time), then the Boolean layer description representing Based Formal Specification of PCI [Shinmizu, et al. this property could be expressed in Verilog as: 2000] and A Specification Methodology by a Collection of Compact Properties as Applied to the Intel Itanium (!(en1 & en2) Processor Bus Protocol [Shimizu, et al. 2001]). An effective unifying methodology includes the Notice that we have not associated any time Accellera Open Verification Library (OVL), which relationship to the statement: “signal en1 and signal en2 provides the systematic elements of the methodology. The are mutually exclusive”. In fact, the statement by itself is OVL incorporates a consistent and systematic means of ambiguous. Is this statement true only at time 0 (as many specifying RT-level implementation properties formal tools infer), or is it true for all time? structurally through a common set of assertion monitors. To remove all time ambiguities, a property’s temporal The OVL monitors act like a template, which enables layer describes the Boolean expressions’ relationships to designers to express a broad class of assertions in a each other over time. For example, if signal en1 and common, familiar RTL format. Furthermore, the OVL signal en2 are always mutually exclusive (that is, for all capitalizes on the various Accellera assertion techniques time), then a temporal operator could be added to the by unifying the PSL declarative form of property Boolean expression to state precisely when the Boolean specification with the new SystemVerilog (and VHDL) expression must hold (that is, evaluate true). This could procedural form of specification within the library. be written in PSL as follows: Finally, these monitors address assertion-based methodology considerations by encapsulating a unified always !(en1 & en2) and systematic method of reporting, that can be customized per project, and a common mechanism for enabling and disabling assertions during the verification There are many temporal operators in PSL (including process. The reporting and enable/disable features use a always, never, next, eventually, until), which permit us to consistent process, which provides uniformity and reason about very complex temporal relationships that predictability within an assertion-based methodology. potentially involve multiple Boolean expressions. The Boolean layer combined with the temporal layer form the basis of the property. While a property’s Boolean and temporal layers system. Similarly, a procedural assertion, such as the new describe general behavior, they do not state how the SystemVerilog assert construct, is convenient for property should be used during verification. In other expressing algorithmic properties that must hold in the words, should the property be asserted, and thus checked? context (and sequential scoping) of procedural code. Or should the property be assumed as a constraint? Or For example, using the Accellera declarative formal should the property be used to specify an event used to property language PSL, the designer could express that gather functional coverage information? Hence, the third the 8-bit bus cntrl[7:0] must possess the property of zero layer of a property, which is the verification layer, states or one-hot as shown in Example 1, below. how the property is to be used. Example 1: PSL declarative assertion Consider the following definitions