ASSERTION-BASED DESIGN

SECOND EDITION

ASSERTION-BASED DESIGN

SECOND EDITION

Harry FosterJasper Design Automation, Inc.

Adam KrolnikLSI Logic Corporation.

David LaceyHewlett-Packard Company

KLUWER ACADEMIC PUBLISHERSNEW YORK, BOSTON, DORDRECHT, LONDON, MOSCOW

eBook ISBN: 1-4020-8028-XPrint ISBN: 1-4020-8027-1

Print ©2004 Kluwer Academic Publishers

All rights reserved

No part of this eBook may be reproduced or transmitted in any form or by any means, electronic,mechanical, recording, or otherwise, without written consent from the Publisher

Created in the United States of America

Boston

©2005 Springer Science + Business Media, Inc.

Visit Springer's eBookstore at: http://ebooks.kluweronline.comand the Springer Global Website Online at: http://www.springeronline.com

Dedicated to:

Jeanne—the most wonderful person in my life.And to my children—Elliott, Lance, and Hannah.Always remember, when I was your age I used to

have to walk across the room to change the channel.

-Harry

Cindy, Seth, Nicholas, Sarah and Jesus the Christ.

-Adam

To my loving wife, Deborah, for her patience andsupport while this book was written.

-David

TABLE OF CONTENTS

Chapter 1 Introduction 11.11.21.3

Property checkingVerification techniquesWhat is an assertion?

1.3.11.3.21.3.31.3.4

A historical perspectiveDo assertions really work?What are the benefits of assertions?Why are assertions not used?

1.4 Phases of the design process1.4.11.4.21.4.3

Ensuring requirements are satisfiedTechniques for ensuring consistencyRoles and ownership

1.5 Summary

123467

111416181920

Chapter 2 Assertion Methodology 212.1 Design methodology

2.1.12.1.22.1.32.1.42.1.5

Project planningDesign requirementsDesign documentsDesign reviewsDesign validation

212227282930

2.2 Assertion methodology for new designs2.2.12.2.22.2.32.2.42.2.5

Key learningsBest practicesAssertion densityProcess for adding assertionsWhen not to add assertions

303133373939

2.32.42.5

Assertion methodology for existing designsAssertions and simulationAssertions and formal verification

2.5.12.5.22.5.32.5.4

Formal verification frameworkFormal methodologyECC exampleGradual exhaustive formal verification

40424444485356

T a b l e o f C o n t e n t s vii

2.6 Summary 59

Chapter 3 Specifying RTL Properties 613.1 Definitions and concepts

3.1.13.1.2

PropertyEvents

3.2 Property classification3.2.13.2.23.2.3

Safety versus livenessConstraint versus assertionDeclarative versus procedural

3.3 RTL assertion specification techniques3.3.13.3.23.3.33.3.43.3.53.3.63.3.7

RTL invariant assertionsDeclaring properties with PSLRTL cycle related assertionsPSL and default clock declarationSpecifying sequencesSpecifying eventualitiesPSL built-in functions

3.43.5

Pragma-based assertionsSystemVerilog assertions

3.5.13.5.23.5.3

Immediate assertionsConcurrent assertionsSystem functions

3.6 PCI property specification example3.6.1 PCI overview

3.7 Summary

Chapter 4 PLI-Based Assertions4.1 Procedural assertions

4.1.14.1.24.1.34.1.4

A simple PLI assertionAssertions within a simulation time slotAssertions across simulation time slotsFalse firing across multiple time slots

4.2 PLI-based assertion library4.2.1 Assert quiescent state

4.3 Summary

Chapter 5 Functional Coverage5.15.2

Verification approachesUnderstanding coverage5.2.15.2.25.2.35.2.45.2.5

Controllability versus observabilityTypes of traditional coverage metricsWhat is functional coverage?Building functional coverage modelsSources of functional coverage

62626565666767686972737475808282848486959696

102

103104105108111116118119123

125126127128128130132133

v i i i A s s e r t i o n - B a s e d D e s i g n

5.3 Does functional coverage really work?5.3.15.3.25.3.3

Benefits of functional coverageSuccess storiesWhy is functional coverage not used

5.4 Functional coverage methodology5.4.15.4.25.4.35.4.45.4.55.4.6

Steps to functional coverageCorrect coverage densityIncorrect coverage densityCoverage analysisCoverage best practicesCoverage-driven test generation

5.5 Specifying functional coverage5.5.15.5.25.5.35.5.45.5.55.5.6

Embedded in the RTLFunctional coverage librariesAssertion-based methodsPost processingPLI logging and reportingSimulation control

5.65.75.8

Functional coverage examplesAHB exampleSummary

Chapter 6 Assertion Patterns6.1 Introduction to patterns

6.1.16.1.2

What are assertion patterns?Elements of an assertion pattern

6.2 Signal patterns6.2.16.2.26.2.36.2.4

X detection patternValid range patternOne-hot patternGray-code pattern

6.3 Set patterns6.3.16.3.26.3.3

Valid opcode patternValid signal combination patternInvalid signal combination pattern

6.4 Conditional patterns6.4.16.4.2

Conditional expression patternSequence implication pattern

6.5 Past and future event patterns6.5.16.5.2

Past event patternFuture event pattern

6.6 Window patterns6.6.16.6.2

Time-bounded window patternsEvent-bounded window patterns

6.7 Sequence patterns6.7.16.7.2

Forbidden sequence patternsBuffered data validity pattern

134135135136137138139141142145149150150151152154154155156158160

161161162163164164167169172173173175177179179181185185187189189192194194195

T a b l e o f C o n t e n t s ix

6.7.3 Tagged transaction pattern6.7.4 Pipelined protocol pattern

6.8 Applying patterns to a real example6.8.16.8.2

Intra-interface assertionsInter-interface assertions

6.9 Summary

196199202204208210

Chapter 7 Assertion Cookbook7.17.27.37.47.57.67.77.8

Queue—FIFOFixed depth pipeline registerStack—LIFOCaches—direct mappedCache—set associativeFSMCountersMultiplexers

7.8.17.8.27.8.37.8.4

Encoded multiplexerDecoded one-hot multiplexerPriority multiplexerComplex multiplexer

7.9 Encoder7.107.117.127.137.147.157.16

Priority encoderSimple single request protocolIn-order multiple request protocolOut-of-order request protocolMemoriesArbiterSummary

211213219222225231236240244244245246248249251252254257259262266

Chapter 8 Specifying Correct Behavior 2678.1 Natural language interpretation

8.1.18.1.28.1.38.1.48.1.58.1.6

Temporal ambiguityActive ambiguityBoundary ambiguityToo strong interpretationImplicit assumptionPartial specification

8.2 Property specification guidelines8.2.2 Syntax ambiguity

8.3 Clarity in higher-level specification8.3.18.3.28.3.3

Implementation assertionsHigher-level requirementsModeling high-level requirements

8.4 Summary

267268271273274276277278280281283285287288

x A s s e r t i o n - B a s e d D e s i g n

Appendix A Open Verification Library 291A.1A.2

OVL methodology advantagesOVL standard definition

A.2.1 OVL runtime macro controlsA.2.2 Customizing OVL messages

A.3A.4A.5

Firing OVL monitorsUsing OVL assertion monitorsChecking invariant properties

A.5.1A.5.2A.5.3A.5.4

assert_alwaysassert_neverassert_zero_one_hotassert_range

A.6 Checking cycle relationshipsA.6.1A.6.2A.6.3

assert_nextassert_frameassert_cycle_sequence

A.7 Checking event bounded windowsA.7.1 assert_win_changeA.7.2 assert_win_unchange

A.8 Checking time bounded windowsA.8.1A.8.2

assert_changeassert_unchange

A.9 Checking state transitionsA.9.1A.9.2

assert_no_transitionassert_transition

291292293294296297298298300302303305305307309311311313314315316318318319

Appendix B PSL Property Specification Language 321B.1B.2B.3B.4

Introduction to PSLOperators and keywordsPSL Boolean layerPSL Temporal Layer

B.4.1B.4.2B.4.3B.4.4B.4.5B.4.6B.4.7B.4.8B.4.9

SERESequenceBraced SERESERE concatenation ( ; ) operatorConsecutive repetition ([* ]) operatorNonconsecutive repetition ([= ]) operatorGoto repetition ([-> ]) operatorSequence fusion (: ) operatorSequence non-length-matching (& ) operator

B.4.10B.4.11B.4.12B.4.13B.4.14B.4.15B.4.16

Sequence length-matching (&&) operatorSequence or ( | ) operatoruntil* sequence operatorswithin sequence operatorsnext operatoreventually! operatorbefore* operators

321322323324324325325325325327328329329329329330330330331331

T a b l e o f C o n t e n t s xi

B.4.17B.4.18B.4.19B.4.20B.4.21B.4.22

abort operatorEndpoint declarationSuffix implication operatorsLogical implication operatoralways temporal operatornever temporal operator

B.5 PSL propertiesB.5.1B.5.2B.5.3B.5.4

Property declarationNamed propertiesProperty clockingforall property replication

B.6 The verification layerB.6.1B.6.2B.6.3

assert directiveassume directivecover directive

B.7 The modeling layerB.7.1 prev()B.7.2 next()B.7.3 stable()B.7.4B.7.5B.7.6B.7.7B.7.8

rose()fell()isunknown()countones()onehot(), onehot0()

B.8 BNF

Appendix C SystemVerilog Assertions 353C.1 . Introduction to SystemVerilogC.2 Operator and keywordsC.3 Sequence and property operations

C.3.1C.3.2C.3.3C.3.4C.3.5C.3.6C.3.7C.3.8C.3.9

Temporal delayConsecutive repetitionGoto repetitionNonconsecutive repetitionSequence and Property ANDSequence intersectionSequence and Property ORBoolean until (throughout)Within sequence

C.3.10C.3.11C.3.12C.3.13C.3.14

EndedMatchedFirst matchProperty ImplicationConditional property selection

C.4 Property declarationsC.4.1 Sequence composition

332332332333333334334334334334335336336336336337337337338338339339339340340

353353355356357357358359360360361362362363363364365366368

x i i A s s e r t i o n - B a s e d D e s i g n

C.5C.6C.7

Assert, Assume and Cover statementsDynamic data within sequencesSystem Functions

C.7.1 New operatorsC.8C.9

SystemTasksBNF

369370371372373374

T a b l e o f C o n t e n t s xiii

FOREWORDThere is much excitement in the design and verificationcommunity about assertion-based design. The question is, whoshould study assertion-based design? The emphatic answer is,both design and verification engineers.

What may be unintuitive to many design engineers is that addingassertions to RTL code will actually reduce design time, whilebetter documenting design intent.

Every design engineer should read this book! Design engineersthat add assertions to their design will not only reduce the timeneeded to complete a design, they will also reduce the number ofinterruptions from verification engineers to answer questionsabout design intent and to address verification suite mistakes.With design assertions in place, the majority of the interruptionsfrom verification engineers will be related to actual designproblems and the error feedback provided will be more useful tohelp identify design flaws. A design engineer who does not addassertions to the RTL code will spend more time with verificationengineers explaining the design functionality and intendedinterface requirements, knowledge that is needed by theverification engineer to complete the job of testing the design.

Every verification engineer should read this book! The smartverification engineer will assist the design engineer to addassertions to the RTL-design code because the sooner a designengineer understands the usage and benefits of inserting assertionsinto the design, the more valuable that design engineer will be tothe verification effort. A smart verification engineer is someonewho can help a designer to catch the vision and understand theease and value of assertion-based design. This is the first book tocomprehensively address and explain HDL assertion-baseddesign.

My colleague Harry Foster is the best-known name in the Verilogverification and assertion-based methodology community. Alongwith Lionel Bening, Harry pioneered the Verilog OpenVerification Library (OVL), a freely available set of verification-focused Verilog modules that have been used in advanced designand verification environments ever since they were introduced.

My colleague Adam Krolnik was the verification champion of theVerilog-2001 Standards Group. I counted on Adam to promote

F o r e w o r d xv

and propose verification enhancements to the IEEE Veriloglanguage.

David Lacey, Harry and Adam are key participants on theAccellera SystemVerilog Standards Group. Their practicalverification experience has contributed to the value of theassertion enhancements added to the SystemVerilog standard.

These three verification specialists have written a book that willendow the reader with an understanding of the fundamental andimportant topics needed to comprehend and implement assertion-based design.

Included in Chapter 7 of this book is a valuable set of commonlyused assertion examples to help the reader become familiar withthe capabilities of assertion-based design. This book is a must forall design and verification engineers.

Clifford E. Cummings

Verilog Guru & President, Sunburst Design, Inc.Member IEEE 1364-1995 Verilog Standards GroupMember IEEE 1364-2001 Verilog Standards GroupMember IEEE 1364-2002 Verilog RTL Synthesis Standards GroupMember Accellera SystemVerilog 3.0 Standards GroupMember Accellera SystemVerilog 3.1 Standards Group

x v i A s s e r t i o n - B a s e d D e s i g n

PREFACEYou may have heard that this is a book about verification and nowyou’re wondering why it’s called Assertion-Based Design, and notAssertion-Based Verification. The answer to that is one of thedriving forces in this book: Verification doesn’t happen in avacuum. Specification has to occur before any form ofverification, and as you know, specification occurs very early inthe design cycle. Thus, our contention is that assertionspecification is one of the integral pieces of a contemporarydesign cycle.

Within that context then, the focus of this book is three-fold:

How to specify assertions

How to create and adopt a methodology that supportsassertion-based design (predominately for RTL design)

What to do with the assertions and methodology once you havethem

To support these three over-arching goals, we showcase multipleforms of assertion specification: Accellera Open VerificationLibrary (OVL), Accellera Property Specification Langauge (PSL),and Accellera SystemVerilog.

The recommendations and claims we make in this book are basedon our combined actual experiences in applying anassertion-based methodology to real design and verification aswell as our work in developing industry assertion standards.

Real-world experience. In Assertion-Based Design, wehave pooled our combined experiences to share our understandingand provide a reality-based picture of our chosen topic. Thefollowing is a summary of our background related to this topic:

Harry Foster—Chairs the Accellera Formal VerificationTechnical Committee; which is developing the PSL standard;created the Open Verification Library; member of theSystemVerilog Assertion Committee; and previouslydeveloped assertion-based methodologies at Hewlett-PackardCompany.

P r e f a c e xvii

Adam Krolnik—Accellera SystemVerilog AssertionCommittee committee member and major contributor in thedevelopment of the System Verilog assertion constructs;created assertion-based methodologies at Cyrix and LSI LogicCorporation.David Lacey—Chairs the Accellera Open Verification Librarycommittee; member of the System Verilog AssertionCommittee; created functional coverage and assertion-basedmethodologies at Hewlett-Packard Company.

Fundamentals. Property specification is fundamental to anassertion-based verification platform (that is, assertions,constraints, and functional coverage). Once specified, propertiesenable the following components, which may be included in yourassertion-based verification platform:

verifiable testplans through property specification (forexample, executable functional coverage models, whichhelp answer the question “what functionality has not beenexercised?”)

exhaustive and semi-exhaustive formal property checkingtechnology (for example, model checking andbounded-model checking)

dynamic property checking technology (for example,monitoring assertions in simulation) for improvedobservability to reduce the time involved in debug

hardware verification languages (HVLs) for testbenchgeneration that leverage property specification to defineexpected input (constraints) and output (assertions) behavior

constraint-driven stimulus generation based on interfaceproperties targeting block-level designs

assertion property synthesis to address silicon observabilitychallenges during chip bring-up in the lab, as well asoperational error detection required for high availability(HA) class systems

In this book, we discuss the important role that propertyspecification plays in an assertion-based verification flow.

Evolution in levels of abstraction. The following figureshows an evolution in levels of design notation and specificationabstraction. Each time we move up a level of abstraction, weexpand possibilities, increase productivity, and improvecommunication of design intent. Perhaps most importantly, is thegrowth our field has experienced in conceptualizing new forms ofspecification, developing new technologies based on these newforms of specification, and then developing standards, which inturn opens new markets. For example, the development ofRegister Transfer Languages in the mid-1960’s lead to thedevelopment of synthesis. However, it was the standardization of

xviii A s s e r t i o n - B a s e d D e s i g n

VHDL/Verilog in the early 1990’s that opened new markets andhelped drive synthesis adoption.

The way design and verification has traditionally been performedis changing. In the future, we predict that design and verificationwill become property-based. Through the standardization ofassertion and property languages that are occurring at the time ofthis publication, we foresee new and exciting EDA marketsemerge, once again opening the door for improved productivity.All made possible through assertion-based design practices.

Design notation and specification levels of abstraction

Book organizationAssertion-Based Design is organized into chapters that can be readsequentially for a full understanding of our topic. Or you maywish to focus on a particular area of interest and visit theremaining chapters to supplement your understanding. We haveallowed repetitions to support the readers who prefer to browse forinformation as well as readers who intend to read cover-to-coverand then revisit sections of particular personal relevance.Highlights of the contents follow.

Chapter 1,“Introduction”

Chapter 1 introduces property checking and modern verificationtechniques. It then introduces assertions and their use in industry,and statistics of their effectiveness. It discusses the benefits ofassertion-based verification methodologies and dispels commonmisconceptions about assertion use within an RTL design flow.

P r e f a c e xix

Chapter 2,“Assertion

Methodology”

Chapter 2 discusses details for effectively creating and managingan assertion-based methodology, which includes validatingassertions using simulation and formal verification. It shows howto best apply assertion-based methodologies to both new andexisting designs. It explores how an assertion-based methodologyworks together with, not separate from, a general designmethodology. Finally, it introduces several key learnings thatmust be accepted by the project team in order to be successfulwith an assertion-based methodology.

Chapter 3,“Specifying RTL

Properties”

Chapter 3 discusses basic property and assertion specificationconcepts and definitions. It introduces various forms of RTLassertion specifications, which include: the Accellera OpenVerification Library (OVL), Accellera PSL formal propertylanguage, and Accellera SystemVerilog assertion constructs.Examples are given throughout the chapter to demonstrate howeach property concept is used in concert with one of the assertionspecification forms to create assertions. Many of these assertionexamples can be used today, as they utilize the OVL. Otherexamples can be used as the EDA vendors move to support PSLand SystemVerilog. Finally, the chapter closes with a PCIproperty specification example.

Chapter 4,“PLI-BasedAssertions”

Chapter 5,“FunctionalCoverage”

Chapter 4 discusses PLI-based assertion and procedural assertiontechniques. It provides actual code that can be used as an assertionspecification form with today's Verilog simulators that support thePLI. It also addresses ways to prevent false firing of proceduralassertions.

Chapter 5 introduces the verification coverage models and howthis topic fits in a book about assertions. It discusses the conceptsof black-box and white-box testing, as well as assertiontechniques that improve functional coverage. It explores the ideasof controllability and observability and their role in verification.The chapter focuses primarily on functional coverage models, butintroduces other traditional coverage metrics (such asprogramming code coverage) and their role in the overallcoverage efforts. Real world examples of successes usingfunctional coverage is provides in this chapter as well as adiscussion of the benefits of using functional coverage in yourverification efforts. It provides an outline for an effectivefunctional coverage methodology, including guidelines forachieving correct functional coverage density within your design.Finally, it provides a description of several forms of functionalcoverage specification before concluding with examples of bothlow-level RTL implementation and high-level architecturalfunctional coverage specification.

Chapter 6,“AssertionPatterns”

Chapter 6 introduces the concept of assertion patterns as aconvenient method to document and communicate commonlyoccurring assertions that are found in today's RTL designs. Thisprovides an easy reference for broad classes of assertions that

xx A s s e r t i o n - B a s e d D e s i g n

allows the reader to more easily apply the concepts to theirspecific designs. A number of different assertion patterns arepresented, including signal, set, conditional, past and future event,window, and sequence. Each assertion pattern is described in greatdetail and provides examples of applicable assertions anddescriptive waveforms for additional clarity, as needed.

Chapter 7,“Assertion

Cookbook”

Chapter 7 provides concrete examples of the common assertionsand functional coverage points for components, interfaces, andgeneral logic, including queues, stacks, finite state machines,encoders, decoders, multiplexers, state table structures, memory,and arbiters. It includes examples that use each form described inChapter 2 (OVL, SystemVerilog, and PSL). While the list ofcomponents is not exhaustive, the chapter gives a broad coverageof components that enables readers to extend the concepts to theirspecific applications.

Chapter 8,“Specifying

CorrectBehavior”

Chapter 8 present a set of clarifying ideas that we have foundeffective when attempting to specify various aspects of a design,at multiple levels of abstraction. We first present a set of commonambiguities that arise when interpreting a natural languagespecification. We then discuss the limitation of temporal propertylanguages, and the need for additional modeling to overcomethese limitations when attempting to specify higher levelrequirements. Finally, we conclude by presenting a constructionguide we have found useful in our own work with assertion andfunctional coverage specification.

Appendix A,“Open

VerificationLibrary”

Appendix B,“PSL Property

SpecificationLanguage”

Appendix C,“SystemVerilog

Assertions”

This appendix provides a detailed discussion of the mostcommonly used monitors in the Open Verification Library.

This appendix provides a detailed discussion of the mostcommonly used keywords and operators in the PSL propertyspecification language.

This appendix provides a detailed discussion of the mostcommonly used keywords and operators in the proposedSystemVerilog standard.

P r e f a c e xxi

New in Second EditionDifferences between the first edition and the second editioninclude:

Updates to the manuscript based on newer versions ofstandards

Corrections to errata identified during reviewer feedback

New material that presents techniques on how to avoidcommon ambiguity errors

New material that discusses high-level requirements modelingfor specification

Since the first edition was published, subtle changes occurred in afew of the standards we originally presented. In this edition, wehave updated the manuscript to be in line with the AccelleraSystemVerilog 3.1a and the Accellera PSL 1.1 proposedstandards.

In addition, we have compiled feedback from multiple reviewers,and made the appropriate corrections. And we simplified thecoding of a number of the examples and fixed known errors.

Finally, we added new material, Chapter 8, “Specifying CorrectBehavior”. This chapter presents a set of clarifying ideas (that is,tips) about a set of common ambiguities that arise wheninterpreting a natural language specification andsuggest techniques to avoid these common errors. In addition, thischapter discusses the limitations of temporal property languagesand the need for additional modeling to overcome theselimitations when attempting to specify higher-level requirements.

AcknowledgementsThe authors wish to thank the following people who participatedin discussions, made suggestions and other contributions to ourAssertion-Based Design project:

Salim Ahmed, Johan Alfredsson, Tom Anderson, Yann Antonioli,Roy Armoni, Brian Bailey, Lionel Bening, Janick Bergeron, DinoCaporossi, Michael Chang, KC Chen, Carina Chiang, AshwiniChoudhary, Edmond Clarke, Claudionor Coelho, Ben Cohen,Cliff Cummings, Bernard Deadman, Kashyap Doerah, SurrendraDudani, Cindy Eisner, Jeffrey Elbert, E. Allen Emerson, LimorFix, Tom Fitzpatrick, Dana Fisman, Peter Flake, Jeanne Foster,Gary Gostin, Faisal Haque, John Havlicek, Bert Hill, Richard Ho,

xxii A s s e r t i o n - B a s e d D e s i g n

Ramin Hojati, Alan Hu, Alan Hunter, C. Norris Ip, Tony Jones,Yaron Kashai, Kathryn Kranen, Avner Landver, James Lee, AmirLehavot, Andy Lin, Lawrence Loh, Joseph Lu, Adriana Maggiore,Erich Marschner, Johan Mårtensson, David Matt, AnthonyMcIsaac, Steve Meier, Hillel Miller, Prakash Narain, AvigailOrni, Doug Perry, Gary Pimentel, Carl Pixley, Andy Piziali,David Price, Jeff Quigley, Bahman Rabii, Rajeev Ranjan, JoeRichards, Sitvanit Ruah, Vigyan Singhal, Sean Smith, MichalSiwinski, Sandeep Shukla, Bassam Tabbara, Sean Torsney, AndyTsay, Mike Turpin, David Van Campenhout, Gal Vardi, MosheVardi, Paul Vogel, Tony Wilcox, Yaron Wolfsthal, HowardWong-Toi.

Special thanks to Cliff Cummings, Lionel Bening, AvnerLandver, Erich Marschner, Gary Pimentel, Andy Piziali, JoeRichards, Paul Vogel, Tony Wilcox.

Finally, a very special thanks to Jeanne Foster for providing highquality editing advice and services throughout this project.

P r e f a c e xxiii