IEEE 1850 PSL: The Next Generation Harry Foster
Erich Marschner
Yaron Wolfsthal
Jasper Design Automation, Inc. Mountain View, CA, USA
[email protected]
Cadence Design Systems, Inc. Ellicott City, MD, USA
[email protected]
IBM Haifa Research Lab Haifa, Israel
[email protected]
Abstract The Accellera Property Specification Language (PSL) was developed to provide a standard assertion language for use in both simulation and formal verification tools and in the context of a variety of hardware description languages. After four years of development in Accellera, PSL has now been transferred to the IEEE for standardization. This paper presents an overview of the IEEE 1850 PSL activity to create an IEEE standard version of PSL. The paper also summarizes efforts to coordinate with other IEEE standards, such as the incorporation of PSL into IEEE VHDL 200x, as well as research into future applications of PSL.
Introduction An industry-wide effort has been underway for the past four years to develop a formal specification language. The fruit of that labor is the Accellera Property Specification Language (PSL), which is now being further extended and standardized within the IEEE. In this paper, we present the IEEE 1850 working group standardization effort for PSL. We begin by giving a brief overview of PSL and its value in specification and verification of designs. We continue with a summary of the history of PSL development in Accellera, followed by an overview of the current standardization process within the IEEE 1850 working group, including coordination with the various other HDL standards. Finally, we discuss the schedule and future plans for PSL. What is PSL? PSL is a language for the formal specification of concurrent systems. The language is particularly applicable for the description of hardware designs; and
as such, PSL is believed to have become the most popular property specification language across the electronics industry [1]. PSL is typically used to describe properties, or assertions, that are required to hold (that is, evaluate to true) on the design under verification. To this end, PSL was designed to have several important advantageous characteristics that make it highly useful for both documentation and engineering applications (for example, primarily verification, but also property-based synthesis). A few key characteristics of PSL include: • • • •
PSL is mathematically precise and has a rigorous, well-defined formal syntax and semantics. PSL is sufficiently expressive, allowing the specification of a large class of “real world” design behaviors. There are known efficient underlying algorithms for verifying designs against PSL properties—whether in simulation or using formal verification. PSL is intuitive, and easy to learn, read, and write.
While all the above characteristics are important, the first one is critical, and it is the rigorous PSL formal semantics that give PSL the ability to be a high-quality specification language. PSL is defined in layers. The Boolean layer is the foundation; it supports the temporal layer, which uses Boolean expressions to specify behavior over time. The verification layer consists of directives that specify how tools should use temporal layer specifications to verify functionality of a design. Finally, the modeling layer defines the environment within which verification is to occur. To demonstrate the interplay of the layers, consider the following assertion:
The Value of PSL One of the key features of PSL is the ability to specify formal properties as assertions that can be verified in either a static or dynamic verification environment. In addition, PSL properties provide a convenient means to specify functional coverage models that can be used to measure the quality of a simulation testbench. This PSL assertion specifies that the signals A and B always have mutually exclusive values. The PSL constructs assert and always belong to the verification and temporal layers, respectively, and the expression (!(A&B)) belongs to the Boolean layer. This example does not involve the modeling layer (which is typically required only in more complex applications). PSL is also defined in various flavors. Each flavor corresponds to a particular underlying hardware description language. Currently defined flavors include VHDL, Verilog, SystemVerilog, and a generic definition language, GDL. In addition, a SystemC flavor is under development. In all flavors, the temporal layer and the verification layer are nearly identical. The flavor determines the syntax of the Boolean and modeling layers, and allows easy, interoperable use of PSL across languages and design flows. The most common application of PSL is assertion-based verification (ABV), which is a generic name for a verification methodology that is based on the use of properties and is increasingly gaining momentum across the engineering community. ABV involves the exploitation of properties for checking the design against its specification. Most commonly, this involves the development of PSL properties and automatically generating from them Verilog or VHDL checker modules. These checker modules, in turn, are integrated into the simulation environment and monitor the design on a cycle-by-cycle basis, identifying violations of the assertions as they happen. Another approach for ABV, which is highly acclaimed for its ability to provide high quality verification, is formal verification. With this approach (also known as model checking) an exhaustive analysis of the design state-space is performed to determine, across all possible scenarios, whether the design obeys its PSL specification. For a complete review of PSL, which is beyond the scope of this paper, we refer the reader to the language reference manual [2].
So why is this important? The act of specification is fundamental to the process of functional verification. Historically, the process of specification has consisted of creating a natural language description for a set of design requirements. Unfortunately, this form of specification is both ambiguous and, in many cases, unverifiable (due to the lack of a standard machineexecutable representation). For example, consider a requirement on an imaginary design, where an event of type A would always follow an event of type B. This simple statement actually gives rise to multiple questions about the design intent: How are events A and B defined in terms of signals, and what is their duration? How many time units after B should A occur? Is it required that for every event of type A, a unique event of type B should follow? And so forth. Clearly, avoiding multiple interpretations of design intent is essential in this case. PSL supports the unambiguous formulation of such specifications in a clear and mathematically precise way, which makes it an important tool for both architects and engineers. PSL also reduces the time spent in verification. With the advent of PSL, engineers are now able to adopt an assertion-based verification methodology based upon verifiable forms of specification [3]. Consider the benefits a formal specification provides to both IP producers and IP consumers. For the IP producer, developing an assertion-based specification for IP has a collateral benefit—the formal specification process often uncovers misconceptions about the implementer’s original intent. Thus, the time invested in developing the specification is time well spent. And generally, the benefits are realized early in the design and verification cycle, before the IP producer applies any form of verification to the IP. With an assertion-based specification in hand, the IP producer is positioned to verify IP compliance and interoperability. For the IP consumer, an assertion-based specification reduces integration time by unambiguously
clarifying proper IP behavior under various configurations, while providing a way to verify the SoC’s interoperability with the IP. But perhaps most notably, assertion-based specification benefits both producers and consumers by unifying the verification process with a single form of specification that can be automatically leveraged across a diverse set of verification tools, such as formal verification, simulation, emulation, and even synthesis.
Background PSL has its roots in the Sugar language from IBM. Researchers at the IBM Haifa Research Laboratory developed Sugar gradually over a period of many years, starting in 1994. The language originated as syntactic sugaring of the temporal logic CTL [4], which is a branching-time temporal logic. The developers of Sugar, building on lessons learned from hands-on experience, added an extensive set of operators that allow complicated properties to be expressed more succintly than in the basic language. Later, they added regular expressions in order to allow easy formulation of sequences of events .
completed shortly thereafter, and was approved by the Accellera FVTC on February 2003. The Accellera Board of Directors ratified PSL 1.01 in May 2003. Between May 2003 and January 2004, an FVTC subcommittee worked on alignment between PSL and the assertion subset of SystemVerilog, called SVA. This effort led to changes in both languages to ensure that they would be semantically consistent and syntactically as similar as possible. The alignment effort completed in January 2004, and the results were included in PSL v1.1. In June 2004, during the 41st Design Automation Conference in San Diego, the Accellera Board approved PSL v1.1 as an Accellera standard and voted for its transfer to IEEE for further standardization.
Current Work In this section, we describe the IEEE 1850 working group and the current work, specifically related to LRM issues, proposed extensions, and the coordination effort with other standardization efforts. IEEE 1850 Working Group
In late 1998, the Accellera Formal Verification Technical Committee (FVTC) started working towards the definition of a standard property language that would support assertion-based verification. In March 2001, IBM donated Sugar 1.0 to Accellera as a candidate language for that standard. Three other languages were also donated to Accellera: CBV from Motorola, “e” from Verisity, and ForSpec from Intel. Faced with several syntactically and semantically incompatible formal property languages, the FVTC initiated a process to select a single language, based on a set of criteria that was developed by the committee. After a lengthy process of discussion and voting, the candidate languages were narrowed down to two languages: Sugar and CBV.
The charter of the IEEE 1850 working group is to continue the work begun in Accellera, by further refining and enhancing PSL to provide a well-defined language for formal specification of electronic system behavior. The goal is to produce an IEEE standard that is compatible with multiple electronic system design languages, including IEEE 1076 VHDL, IEEE 1364 Verilog, IEEE 1800 System Verilog, and IEEE 1666 SystemC—and to facilitate a common specification and verification flow for multi-language and mixed-language designs.
Responding to the FVTC’s apparent preference for linear-time semantics, IBM repackaged the Sugar language, giving birth to Sugar 2.0. The new formulation of the language included two components: the foundation language (FL), which has LTL semantics [5], and an optional branching extension (OBE), which retained the branching semantics of CTL. Sugar 2.0 was presented to the FVTC in October 2001, and in April 2002 the committee selected it as the finalist of the four candidate languages, thus making Sugar 2.0 the basis for the Accellera standard. The LRM for the property language (which was renamed from Sugar to PSL) was
Issues Subcommittee: This subcommittee is responsible for reviewing the PSL v1.1 issues list and proposing priorities and disposition for each item to either the LRM or Extensions subcommittee.
To ensure productivity and efficiency, the actual technical work is conducted within three subcommittees. These subcommittees are:
LRM Subcommittee: This subcommittee is responsible for creating the IEEE 1850 PSL LRM, based on the Accellera PSL v1.1 LRM. This involves applying all corrections and clarifications, as well as any new extensions developed by the Extensions Subcommittee.
Extensions Subcommittee: This subcommittee is responsible for defining language extensions in response to requests submitted to the working group. To ensure that we can achieve the short term goal of delivering an IEEE 1850 PSL standard by June 2005, features requiring a longer time to implement and validate are targeted for the June 2006 release. This timeframe allows the Extensions subcommittee to work on short term and longer term feature requests in parallel, thus assuring that the working group’s delivery goals are not compromised.
2. Initial values of built-in functions. PSL defines function prev(), which returns the previous value of a variable, and functions rose(), fell(), and stable(), which are defined in terms of prev(). PSL v1.1 does not clearly specify what value prev() returns at the beginning of simulation, and this in turn means that the initial values of rose(), fell(), and stable() are not clearly defined in PSL v1.1. Furthermore, the addition of a clock parameter to these functions raises the issue of their definition at the time of the first tick of that clock. These questions will be answered in the IEEE 1850 PSL LRM.
PSL v1.1 Issues
3. Type of endpoints and return types of built-in functions used in the context of VHDL. The PSL v1.1 LRM states that certain VHDL types are interpreted as equivalent PSL type classes Boolean and Numeric. However, the PSL v1.1 LRM does not state how PSL Boolean and Numeric expressions are mapped back to VHDL data types when endpoints (Boolean) and built-in functions (Boolean and Numeric) are referenced in a VHDL expression or directly in modeling layer VHDL code. This will be clarified.
As of early January 2005, approximately fifty specific issues have been collected for consideration in the IEEE 1850 PSL working group. These include a small set of minor corrections to the existing Accellera PSL v1.1 LRM, a number of requests for clarification, and a number of requests for new features and extension of existing features. Corrections: Minor corrections are being handled directly by the LRM subcommittee. For the most part, these involve modifications to ensure consistent use of terminology, completeness of summary tables, and accuracy of notes about equivalent forms. Two changes in the grammar are also involved, one to remove a redundant production, and another to correct an error in the production for the old form of suffix implication. Clarifications: Clarifications are being addressed first by the Extensions subcommittee, because they may involve minor extensions to the language definition, or perhaps even to the language. So far, the following clarification issues have been discussed and are expected to result in LRM and language changes: 1. Inheritance of clock context. In general, sequences and properties inherit the clock context of the construct in which they are nested, and the clock context is ultimately defined by either the @ operator or by a default clock declaration. However, the modeling layer has no such clock context, and therefore it is not clear in PSL v1.1 what clock context should be used for unclocked endpoints and built-in functions used in the modeling layer. This will be clarified in the IEEE 1850 PSL LRM, and as part of that clarification, the language will be extended to allow specification of the clock context as an optional parameter to certain built-in functions.
4. Simple Subset restrictions. The Simple Subset, which is defined by a short list of restrictions that ensure that a straightforward implementation is possible, will be modified slightly to add restrictions on two operators, and relax restrictions on two others. The Simple Subset restrictions will be extended to require Boolean operands for the operators next_e and next_event_e. At the same time, the Simple Subset restrictions will be relaxed to allow non-Boolean operands of the logical ‘and’ operator, and to allow one non-Boolean operand of the logical ‘or’ operator. 5. PSL’s support for multiple HDLs. PSL v1.1 supports various languages, including VHDL, Verilog, and SystemVerilog (and PSL will be extended to support SystemC). In each case, PSL adopts certain syntactic conventions of the HDL language context, which allow PSL specifications to be syntactically consistent with the language in which the corresponding design is expressed. Although this allows PSL to be used with each of the HDLs, PSL v1.1 does not explicitly define how verification units in one ‘flavor’ of HDL can be used with designs expressed in a different HDL. Clarifying this will improve the language’s ability to support assertion and coverage specifications that are portable across multiple versions of the same design, where each version is expressed in a different HDL.
Extensions: A number of requests for extensions are also being considered. At this point, the following extensions have been discussed and approved in the Extensions subcommittee: 1. Addition of new parameterized and/or operators. These operators will both subsume the capabilities of the current ‘forall’ construct as well as add new capabilities. Among other things, the new capabilities will help enable more flexible use of the cover directive to specify data and transaction coverage. A new ‘for’ construct will be added that will allow ‘forall’-like replication of properties. However, unlike ‘forall’, which cannot be nested anywhere except within another ‘forall’ property, the new ‘for’ construct will be nestable without restriction. Furthermore, while ‘forall’ implicitly involves conjunction, the ‘for’ construct allows the user to specify whether conjunction (the logical ‘and’ operator) or disjunction (the logical ‘or’ operator) is to be used. Finally, the ‘for’ construct will also apply to sequences, in which case any of the sequence operators &&, &, or | can be specified. For example, the assertion assert always for i in {1:3}: || (a[i] -> next b[i]); would be equivalent to assert always ( (a[1] -> next b[1]) || (a[2] -> next b[2]) || (s[3] -> next b[3]) ); and similarly the assertion assert always (for i in {0:3}: && {a[i] == b[i]} |=> sync);
the parameterized or operator will effectively allow definition of coverage ‘bins’ containing a range or a subset of values. For example, the following cover directives define several different bins corresponding to values of ‘data’, including a final bin that overlaps the first two. D0_9: cover for i in {0:9}: | {data==i}; D10_99: cover for i in {10:99}: | {data==i}; D100_999: cover for i in {100:999}: | {data==i}; Dprime: cover for i in {2,3,5,7,11,13,17,19}: | {data==i}; Similarly, the following cover directive would detect any transaction involving a request from one of 16 components, followed by a grant for the same component within the specified maximum delay. cover for i in {0:15}: {request(i); {grant(i) within [*max_delay]}};
2. Extensions to simplify creation of reusable verification IP. These extensions amount to providing for more flexible parameterization of properties and sequences. In particular, the language will be extended to allow PSL declarations to have parameters of any PSL type class, or of any HDL-specific data type. Specifically, parameter declarations will be extended to allow PSL type classes bit, bitvector, numeric, and string to be used in the declaration of formal parameters (extending the existing set of const, boolean, sequence, and property). In addition, type names from the corresponding HDL flavor will be allowed as type qualifiers. In the latter case, the HDL type name will be preceded by a keyword (“hdltype” is currently proposed) indicating that the name is an HDL type name rather than a PSL type class. For example, the following declarations in the VHDL flavor of PSL will be possible with these extensions:
would be equivalent to assert always ( {{a[0]==b[0]} && {a[1]==b[1]} && {a[2]==b[2]} && {a[3]==b[3]}} |=> sync); The addition of the parameterized or operator on sequences will have the additional benefit of enabling cover directives to be more easily written for data and transaction coverage applications. For data coverage,
sequence color_is_red (hdltype COLOR_ENUM c) is {c = "RED"}; sequence slope_is_1 (hdltype COORDINATE_RECORD c) is {(c.x / c.y) = 1}; The following additional enhancements are also being considered, but at the time of this writing they are still under discussion:
1. Definition of additional built-in functions to support various forms of non-deterministic value selection. 2. The possibility of defining a built-in function to refer to the end of a sequence (as an alternative to the current method of declaring an endpoint). 3. The possibility of defining a default abort expression, in addition to the default clock expression. Coordination with Other Standards Efforts Another goal of the IEEE 1850 PSL working group is to coordinate with other IEEE groups to ensure that PSL works well in various language contexts. This is being accomplished through a designated liaison for each of the other IEEE working groups that define a language with which PSL is intended to work. VHDL 200x: The IEEE 1076 VHDL working group has recently decided to include the VHDL flavor of PSL into the next generation of the VHDL standard. A proposal for such inclusion has already been delivered to the VHDL working group. SystemVerilog/Verilog: The IEEE 1800 SystemVerilog working group and the IEEE 1364 Verilog working group are now working together to coordinate the two languages. PSL has both a Verilog flavor and a SystemVerilog flavor, so it works with both; furthermore, SystemVerilog’s assertion capability (SVA) and PSL v1.1 are semantically aligned, and it is desirable to try to maintain that alignment if possible. To that end, the IEEE 1850 PSL working group is tracking changes made to SVA within the IEEE 1800 effort. SystemC: The IEEE 1666 SystemC working group, which has been formed recently to create an IEEE standard based on OSCI SystemC. PSL users have been requesting support for PSL in SystemC for more than a year, and therefore one of the extension requests being considered by the Extensions Subcommittee is for the definition of a SystemC ‘flavor’ of PSL. As part of proposing such a PSL extension, the PSL working group is coordinating with the SystemC working group to ensure that the PSL extension meets the requirements of SystemC users.
Future PSL Applications Increasing application of PSL within the design process will drive new language features and enhancements. For example, current interest in assertion-based verification
primarily focuses on using assertions in simulation. Assertions are usually added after the fact, to increase observability of events within the design so that bugs can be detected closer to their source. However, this approach is only beginning to take advantage of the power of PSL. Over time, we can expect to see an increase in the use of the coverage capabilities of PSL to enable coverage-driven verification. At the same time, by taking advantage of the formal semantics of PSL, formal verification of designs is becoming more common. Eventually, we can expect to see PSL used to thoroughly specify the behavior of design IP blocks and their interfaces [6], with such specifications developed before, rather than after, the design is done. This may even lead to using PSL as a vehicle for design as appropriate methods for assertion-based design synthesis or component selection are developed. Examples of current research into future PSL-based applications include the Property-Based System Design (PROSYD) project[7], which has been funded by a generous grant from the European Commission Information Society Technologies. The goal of the PROSYD project, which consists of multiple research partners from both industry and academia, is to significantly increase the competitiveness and efficiency of the European IT industry by establishing a standard, integrated, property-based paradigm for the design of electronic systems. This paradigm will integrate and unify the many phases of system development, including requirement definition, design, implementation, and verification, into one coherent design flow, building on the emerging standard property specification language PSL. The new paradigm will enable development of electronic systems of higher quality in shorter design cycles and with lower costs. The prime deliverable of the PROSYD project will be a reference methodology and a set of coherent PSL-based tools for property-based system design. Using these tools, the aim is to demonstrate an improvement of at least 30% in design productivity. In addition, an increase in the quality of the finished product, resulting in a significant decrease in the number of design flaws that make it through the verification phase is expected. In parallel with increasing application of property-based system design, PSL development will continue to increase the language’s capabilities and applicability within a variety of design languages and environments. Much of this development will occur within IEEE standards activities.
Summary Through an extremely efficient community effort, building on the work of many volunteers, PSL has evolved to become the most widely-used property language across the electronics industry. Underlying the popularity of PSL are its true interoperability across multiple languages and design flows, its power of expressiveness, and its ease-of-use. To date, the vast majority of EDA vendors support the PSL language in their EDA offerings, and the list is growing steadily [8]. This is only the beginning for PSL. With the forthcoming completion of the IEEE standardization of PSL, we believe the language will gain new ground and become the standard specification language of choice for engineers worldwide.
Acknowledgement The authors would like to thank Cindy Eisner of IBM Haifa Research Lab for her careful and detailed reviews of this paper.
References 1. 2. 3.
4.
5.
6.
7. 8.
DeepChip survey on assertions, June 2004, http://www.deepchip.com/items/dvcon04-06.html The Accellera PSL Language Reference Manual, www.eda.org/vfv/docs/PSL-v1.1.pdf H. Foster, A. Krolnik, D. Lacey. Assertion-Based Design, Second Edition, Kluwer Academic Press, 2004. E. Clarke and E. Emerson. “Design and synthesis of synchronization skeletons using branching time temporal logic”. In Proc. Workshop on Logics of Programs, LNCS 131, pages 52{71. Springer-Verlag, 1981. A. Pnueli. The Temporal Logic of Programs, Proc. 18 IEEE Symp. on Foundations of Computer Science, pp. 46-57, 1977 E. Marschner, B. Deadman, G. Martin, "IP Reuse Hardening via Embedded Sugar Assertions", in Proceedings of the IP-Based System-on-Chip Design Workshop, Grenoble, France, October 30-31, 2002. www.prosyd.org http://www.haifa.il.ibm.com/projects/verification/ sugar/tools.html
