Writing Testbenches using SystemVerilog ______

Writing Testbenches using SystemVerilog

by Janick Bergeron , Inc.

1 3 Janick Bergeron Verificationguild.com

Writing Testbenches Using SystemVerilog

Library of Congress Control Number: 2005938214

ISBN-10: 0-387-29221-7 ISBN-10: 0-387-31275-7 (e-book) ISBN-13: 9780387292212 ISBN-13: 9780387312750 (e-book)

Printed on acid-free paper.

¤ 2006 Springer Science+Business Media, Inc. All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the publisher (Springer Science+Business Media, Inc., 233 Spring Street, New York, NY 10013, USA), except for brief excerpts in connection with reviews or scholarly analysis. Use in connection with any form of information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed is forbidden. The use in this publication of trade names, trademarks, service marks and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights.

Printed in the United States of America.

9 8 7 6 5 4 3 2 1 springer.com TABLE OF CONTENTS

About the Cover xiii

Preface xv Why This Book Is Important ...... xvi What This Book Is About ...... xvi What Prior Knowledge You Should Have ...... xviii Reading Paths ...... xviii Why SystemVerilog? ...... xix VHDL and ...... xix Hardware Verification Languages ...... xx Code Examples ...... xxi For More Information ...... xxii Acknowledgements ...... xxii

CHAPTER 1 What is Verification? 1 What is a Testbench? ...... 1 The Importance of Verification ...... 2 Reconvergence Model ...... 4 The Human Factor ...... 5 Automation ...... 6 Poka-Yoke ...... 6

Writing Testbenches using SystemVerilog v Table of Contents

Redundancy ...... 7 What Is Being Verified? ...... 7 Equivalence Checking ...... 8 Property Checking ...... 9 ...... 10 Functional Verification Approaches ...... 11 Black-Box Verification ...... 11 White-Box Verification ...... 13 Grey-Box Verification ...... 14 Testing Versus Verification ...... 15 Scan-Based Testing ...... 16 Design for Verification ...... 17 Design and Verification Reuse ...... 18 Reuse Is About Trust ...... 18 Verification for Reuse ...... 19 Verification Reuse ...... 19 The Cost of Verification ...... 20 Summary ...... 22

CHAPTER 2 Verification Technologies 23 Linting ...... 24 The Limitations of Linting Technology ...... 25 Linting SystemVerilog Source Code ...... 27 Code Reviews ...... 29 Simulation ...... 29 Stimulus and Response ...... 30 -Driven Simulation ...... 31 Cycle-Based Simulation ...... 33 Co-Simulators ...... 35 Verification Intellectual Property ...... 38 Waveform Viewers ...... 39 Code Coverage ...... 41 Statement Coverage ...... 43 Path Coverage ...... 44 Expression Coverage ...... 45 FSM Coverage ...... 46 What Does 100 Percent Code Coverage Mean? . . . . . 48 Functional Coverage ...... 49 vi Writing Testbenches using SystemVerilog Coverage Points ...... 51 Cross Coverage ...... 53 Transition Coverage ...... 53 What Does 100 Percent Functional Coverage Mean? . 54 Verification Language Technologies ...... 55 Assertions ...... 57 Simulated Assertions ...... 58 Formal Assertion Proving ...... 59 Revision Control ...... 61 The Software Engineering Experience ...... 62 Configuration Management ...... 63 Working with Releases ...... 65 Issue Tracking ...... 66 What Is an Issue? ...... 67 The Grapevine System ...... 68 The Post-It System ...... 68 The Procedural System ...... 69 Computerized System ...... 69 Metrics ...... 71 Code-Related Metrics ...... 71 Quality-Related Metrics ...... 73 Interpreting Metrics ...... 74 Summary ...... 76

CHAPTER 3 The Verification Plan 77 The Role of the Verification Plan ...... 78 Specifying the Verification ...... 78 Defining First-Time Success ...... 79 Levels of Verification ...... 80 Unit-Level Verification ...... 81 Block and Core Verification ...... 82 ASIC and FPGA Verification ...... 84 System-Level Verification ...... 84 Board-Level Verification ...... 85 Verification Strategies ...... 86 Verifying the Response ...... 86 From Specification to Features ...... 87 Block-Level Features ...... 90 System-Level Features ...... 91

Writing Testbenches using SystemVerilog vii Table of Contents

Error Types to Look For ...... 91 Prioritize ...... 92 Design for Verification ...... 93 Directed Testbenches Approach ...... 96 Group into Testcases ...... 96 From Testcases to Testbenches ...... 98 Verifying Testbenches ...... 99 Measuring Progress ...... 100 Coverage-Driven Random-Based Approach ...... 101 Measuring Progress ...... 101 From Features to Functional Coverage ...... 103 From Features to Testbench ...... 105 From Features to Generators ...... 107 Directed Testcases ...... 109 Summary ...... 111

CHAPTER 4 High-Level Modeling 113 High-Level versus RTL Thinking ...... 113 Contrasting the Approaches ...... 115 You Gotta Have Style! ...... 117 A Question of Discipline ...... 117 Optimize the Right Thing ...... 118 Good Comments Improve Maintainability ...... 121 Structure of High-Level Code ...... 122 Encapsulation Hides Implementation Details ...... 122 Encapsulating Useful Subprograms ...... 125 Encapsulating Bus-Functional Models ...... 127 Data Abstraction ...... 130 2-state Data Types ...... 131 Struct, Class ...... 131 Union ...... 134 Arrays ...... 139 Queues ...... 141 Associative Arrays ...... 143 Files ...... 145 From High-Level to Physical-Level ...... 146 Object-Oriented Programming ...... 147 Classes ...... 147 Inheritance ...... 153 viii Writing Testbenches using SystemVerilog Polymorphism ...... 156 The Parallel Simulation Engine ...... 159 Connectivity, Time and Concurrency ...... 160 The Problems with Concurrency ...... 160 Emulating Parallelism on a Sequential Processor . . . 162 The Simulation Cycle ...... 163 Parallel vs. Sequential ...... 169 Fork/Join Statement ...... 170 The Difference Between Driving and Assigning . . . . . 173 Race Conditions ...... 176 Read/Write Race Conditions ...... 177 Write/Write Race Conditions ...... 180 Initialization Races ...... 182 Guidelines for Avoiding Race Conditions ...... 183 Semaphores ...... 184 Portability Issues ...... 186 Events from Overwritten Scheduled Values ...... 186 Disabled Scheduled Values ...... 187 Output Arguments on Disabled Tasks ...... 188 Non-Re-Entrant Tasks ...... 188 Static vs. Automatic Variables ...... 193 Summary ...... 196

CHAPTER 5 Stimulus and Response 197 Reference Signals ...... 198 Time Resolution Issues ...... 199 Aligning Signals in Delta-Time ...... 201 Clock Multipliers ...... 203 Asynchronous Reference Signals ...... 205 Random Generation of Reference Signal Parameters 206 Applying Reset ...... 208 Simple Stimulus ...... 212 Applying Synchronous Data Values ...... 212 Abstracting Waveform Generation ...... 214 Simple Output ...... 216 Visual Inspection of Response ...... 217 Producing Simulation Results ...... 217 Minimizing Sampling ...... 219 Visual Inspection of Waveforms ...... 220

Writing Testbenches using SystemVerilog ix Table of Contents

Self-Checking Testbenches ...... 221 Input and Output Vectors ...... 221 Golden Vectors ...... 222 Self-Checking Operations ...... 224 Complex Stimulus ...... 227 Feedback Between Stimulus and Design ...... 228 Recovering from Deadlocks ...... 228 Asynchronous Interfaces ...... 231 Bus-Functional Models ...... 234 CPU Transactions ...... 234 From Bus-Functional Tasks to Bus-Functional Model 236 Physical Interfaces ...... 238 Configurable Bus-Functional Models ...... 243 Response Monitors ...... 246 Autonomous Monitors ...... 249 Slave Generators ...... 253 Multiple Possible Transactions ...... 255 Transaction-Level ...... 258 Procedural Interface vs Dataflow Interface ...... 259 What is a Transaction? ...... 263 Blocking Transactions ...... 265 Nonblocking Transactions ...... 265 Split Transactions ...... 267 Exceptions ...... 270 Summary ...... 278

CHAPTER 6 Architecting Testbenches 279 Verification Harness ...... 280 Design Configuration ...... 284 Abstracting Design Configuration ...... 285 Configuring the Design ...... 288 Random Design Configuration ...... 290 Self-Checking Testbenches ...... 292 Hard Coded Response ...... 294 Data Tagging ...... 295 Reference Models ...... 297 Transfer Function ...... 299 Scoreboarding ...... 300 Integration with the Transaction Layer ...... 302 x Writing Testbenches using SystemVerilog Directed Stimulus ...... 304 Random Stimulus ...... 307 Atomic Generation ...... 307 Adding Constraints ...... 312 Constraining Sequences ...... 316 Defining Random Scenarios ...... 320 Defining Procedural Scenarios ...... 322 System-Level Verification Harnesses ...... 327 Layered Bus-Functional Models ...... 328 Summary ...... 331

CHAPTER 7 Simulation Management 333 Transaction-Level Models ...... 333 Transaction-Level versus Synthesizable Models . . . . 334 Example of Transaction-Level Modeling ...... 335 Characteristics of a Transaction-Level Model ...... 337 Modeling Reset ...... 341 Writing Good Transaction-Level Models ...... 342 Transaction-Level Models Are Faster ...... 347 The Cost of Transaction-Level Models ...... 348 The Benefits of Transaction-Level Models ...... 349 Demonstrating Equivalence ...... 351 Pass or Fail? ...... 352 Managing Simulations ...... 355 Configuration Management ...... 355 Avoiding Recompilation or SDF Re-Annotation . . . . . 358 Output File Management ...... 361 Seed Management ...... 364 Regression ...... 365 Running Regressions ...... 366 Regression Management ...... 367 Summary ...... 370

APPENDIX A Coding Guidelines 371 File Structure ...... 372 Filenames ...... 375 Style Guidelines ...... 376

Writing Testbenches using SystemVerilog xi Table of Contents

Comments ...... 376 Layout ...... 378 Structure ...... 380 Debugging ...... 383 Naming Guidelines ...... 384 Capitalization ...... 384 Identifiers ...... 386 Constants ...... 389 Portability Guidelines ...... 391

APPENDIX B Glossary 397

Index 401

xii Writing Testbenches using SystemVerilog ABOUT THE COVER

The cover of the first edition of Writing Testbenches featured a pho- tograph of the collapse of the Quebec bridge (the cantilever steel bridge on the left1) in 1907. The ultimate cause of the collapse was a major change in the design specification that was not verified. To save on construction cost, the engineer in charge of the project increased the span of the bridge from 1600 to 1800 feet, turning the project into the longest bridge in the world, without recalculating weights and stresses.

In those days, engineers felt they could span any distances, as ever longer bridges were being successfully built. But each technology eventually reaches its limits. Almost 100 years after its completion in 1918 (after a complete re-design and a second collapse!), the Quebec bridge is still the longest cantilever bridge in the world. Even with all of the advances in civil engineering and composite material, cantilever bridging technology had reached its limits.

You cannot realistically hope to keep applying the same solution to ever increasing problems. Even an evolving technology has its limit. Eventually, you will have to face and survive a revolution that will provide a solution that is faster and cheaper.

1. Photo: © Rock Santerre, Centre de Recherche en Géomatique, Univer- sité Laval, Québec City, Québec, Canada

Writing Testbenches using SystemVerilog xiii About the Cover

Replacing the Quebec bridge with another cantilever structure is estimated to cost over $600 million today. When it was decided to span the St-Lawrence river once more in 1970, the high cost of a cantilever structure caused a different technology to be used: a sus- pension bridge. The Pierre Laporte Bridge, visible on the right, has a span of 2,200 feet and was built at a cost of $45 million. It pro- vides more lanes of traffic over a longer span at a lower cost and weight. It is better, faster and cheaper. The suspension bridge tech- nology has replaced cantilever structures in all but the shortest spans.

Directed testcases, as described in the first edition, were the cantile- ver bridges of verification. Coverage-driven constrained-random transaction-level self-checking testbenches are the suspension bridges. This methodology revolution, introduced by hardware ver- ification languages such as e and OpenVera and as described in the second edition of Writing Testbenches, make verifying a design bet- ter, faster and cheaper. Hardwave verification languages have dem- onstrated their productivity in verifying today’s multi-million gate designs.

SystemVerilog brings the HVL technology to the masses, as a true industry standard, with consistent syntax and simulation and built in the simulators you already own. It is no longer neces- sary to acquire additional tools nor integrate different languages. Like the Pierre Laporte Bridge, which today carries almost all the traffic across the river, you should use these productive methods for writing the majority of your testbenches.

I’m hoping, with this new book, to facilitate your transition from ad-hoc, directed testcase verification to a state-of-the-art verifica- tion methodology using a language you probably have at your fin- gertip.

xiv Writing Testbenches using SystemVerilog PREFACE

If you survey hardware design groups, you will learn that between 60% and 80% of their effort is dedicated to verification. This may seem unusually large, but I include in "verification" all debugging and correctness checking activities, not just writing and running testbenches. Every time a hardware designer pulls up a waveform viewer, he or she performs a verification task. With today’s ASIC and FPGA sizes and geometries, getting a design to fit and run at speed is no longer the main challenge. It is to get the right design, working as intended, at the right time.

Unlike synthesizable coding, there is no particular coding style nor language required for verification. The freedom of using any lan- guage that can be interfaced to a simulator and of using any features of that language has produced a wide array of techniques and approaches to verification. The continued absence of constraints and historical shortage of available expertise in verification, cou- pled with an apparent under-appreciation of and under-investment in the verification function, has resulted in several different ad hoc approaches. The consequences of an informal, ill-equipped and understaffed verification process can range from a non-functional design requiring several re-spins, through a design with only a sub- set of the intended functionality, to a delayed product shipment.

Writing Testbenches using SystemVerilog xv Preface

WHY THIS BOOK IS IMPORTANT In 2000, the first edition of Writing Testbenches was the first book specifically devoted to functional verification techniques for hard- ware models. Since then, several other verification-only books have appeared. Major conferences include verification tracks. Universi- ties, in collaboration with industry, are offering verification courses in their engineering curriculum. Pure verification EDA companies are offering tools to improve productivity and the overall design quality. Some of these pure verification EDA companies have gone public or have been acquired, demonstrating that there is significant value in verification tools and IP. All of these contribute to create a formal body of knowledge in design verification. Such a body of knowledge is an essential foundation to creating a science of verifi- cation and fueling progress in methodology and productivity.

In 2003, the second edition presented the latest verification tech- niques that were successfully being used to produce fully functional first-silicon ASICs, systems-on-a-chip (SoC), boards and entire systems. It built on the content of the first edition—transaction- level self-checking testbenches—to introduce a revolution in func- tional verification: coverage-driven constrained-random verifica- tion using proprietary hardware verification languages.

This book is not really a new edition of the previous Writing Test- benches books. Nor is it a completely new book. I like to think of it as the 2½ edition. This book presents the same concepts as the second edition. It simply uses SystemVerilog as the sole implemen- tation vehicle. The languages used in the second edition are still available. Therefore it is still a useful book on its own.

WHAT THIS BOOK IS ABOUT I will first introduce the necessary concepts and tools of verifica- tion, then I’ll describe a process for planning and carrying out an effective functional verification of a design. I will also introduce the concept of coverage models that can be used in a coverage- driven verification process.

It will be necessary to cover some SystemVerilog language seman- tics that are often overlooked in textbooks focused on describing the synthesizable subset or unfamiliar to traditional Verilog users. xvi Writing Testbenches using SystemVerilog What This Book Is About

These unfamiliar semantics become important in understanding what makes a well-implemented and robust testbench and in pro- viding the necessary control and monitor features.

I will also present techniques for applying stimulus and monitoring the response of a design, by abstracting the physical-level transac- tions into high-level procedures using bus-functional models. The architecture of testbenches built around these bus-functional mod- els is important to create a layer of abstraction relevant to the func- tion being verified and to minimize development and maintenance effort. I also show some strategies for making testbenches self- checking.

Creating random testbenches involves more than calling the $ran- dom system task. I will show how random stimulus generators, built on top of bus-functional models, can be architected and designed to be able to produce the desired stimulus patterns. Ran- dom generators must be easily externally constrained to increase the likelihood that a set of interesting patterns will be generated.

Transaction-level modeling is another important concept presented in this book. It is used to parallelize the implementation and verifi- cation of a design and to perform more efficient simulations. A transaction-level model must adequately emulate the functionality of a design while offering orders of magnitudes in simulation per- formance over the RTL model. Striking the correct level of accu- racy is key to achieving that performance improvement.

This book has one large omission: assertions and formal verifica- tion. It is not that they are not important. SystemVerilog includes constructs and semantics for writing assertions and coverage prop- erties using temporal expressions. Formal verification is already an effective methodology for verifying certain classes of designs. It is simply a matter of drawing a line somewhere. There are already books on assertions1 or formal verification. This book focuses on the bread-and-butter of verification for the foreseeable future: dynamic functional verification using testbenches

1. Cohen, Venkataramanan and Kumari, "SystemVerilog Assertion Hand- book", VhdlCohen Publishing, 2005

Writing Testbenches using SystemVerilog xvii Preface

WHAT PRIOR KNOWLEDGE YOU SHOULD HAVE This book focuses on the functional verification of hardware designs using SystemVerilog. I expect the reader to have at least a basic knowledge of VHDL, Verilog, OpenVera or e. Ideally, you should have experience in writing models and be familiar with run- ning a simulation using any of the available VHDL or Verilog sim- ulators. There will be no detailed description of language syntax or grammar. It may be a good idea to have a copy of a language- focused textbook or the SystemVerilog Language Reference Manual as a reference along with this book. I do not describe a synthesiz- able subset, nor limit the implementation of the verification tech- niques to using that subset. Verification is a complex task: The power of the SystemVerilog language will be used to its fullest.

I also expect that you have a basic understanding of digital hard- ware design. This book uses several hypothetical designs from var- ious application domains (video, datacom, computing, etc.). How these designs are actually specified, architected and then imple- mented is beyond the scope of this book. The content focuses on the specification, architecture, then implementation of the verification of these same designs.

Once you are satisfied with the content of this book and wish to put it in practice, I recommend you pick up a copy of the Verification Methodology Manual for SystemVerilog1 (VMM). It is a book I co- authored and wrote as a series of very specific guidelines on how to implement testbenches using SystemVerilog. It uses all of the pow- erful concepts introduced here. It also includes a set of base classes that implements generic functionality that every testbench needs. Why re-invent the wheel? I will refer to the first edition of the VMM at relevant points in this book where further techniques, guidelines or support can be found.

READING PATHS You should really read this book from cover to cover. However, if you are pressed for time, here are a few suggested paths.

1. Janick Bergeron, Eduard Cerny, Alan Hunter and Andrew Nightingale, "Verification Methodology Manual for SystemVerilog", Springer 2005, ISBN 0-387-25538-9 xviii Writing Testbenches using SystemVerilog Why SystemVerilog?

If you are using this book as a university or college textbook, you should focus on Chapter 4 through 6 and Appendix A. If you are a junior engineer who has only recently joined a hardware design group, you may skip Chapters 3 and 7. But do not forget to read them once you have gained some experience.

Chapters 3 and 6, as well as Appendix A, will be of interest to a senior engineer in charge of defining the verification strategy for a project. If you are an experienced designer, you may wish to skip ahead to Chapter 3.

If you have a software background, Chapter 4 and Appendix A may seem somewhat obvious. If you have a hardware design and RTL coding mindset, Chapters 4 and 7 are probably your best friends.

If your responsibilities are limited to managing a hardware verifica- tion project, you probably want to concentrate on Chapter 3, Chap- ter 6 and Chapter 7.

WHY SYSTEMVERILOG? SystemVerilog is the first truly industry-standard language to cover design, assertions, transaction-level modeling and coverage-driven constrained random verification.

VHDL and Verilog VHDL and Verilog have shown to be inadequate for verification. Their lack of—or poor—support for high-level data types, object oriented programming, assertions, functional coverage and declara- tive constraints has prompted the creation of specialized languages for each or all of these areas. Using separate languages creates inte- gration challenges: they may use a different syntax for the same concepts, have different semantics, introduce race conditions and render the simulation less efficient. SystemVerilog unifies all of these areas under a consistent syntax, coherent semantics, with minimal race conditions and with global optimization opportuni- ties.

In my experience, Verilog is a much abused language. It has the reputation for being easier to learn than VHDL, and to the extent that the initial learning curve is not as steep, it is true. SystemVer-

Writing Testbenches using SystemVerilog xix Preface

ilog, being a superset of Verilog, benefits from the same smooth ini- tial learning curve. However—like VHDL—Verilog and SystemVerilog provide similar concepts: sequential statements, par- allel constructs, structural constructs and the illusion of parallelism.

These concepts must be learned. Because of its lax requirements, Verilog lulls the user into a false sense of security. The user believes that he or she knows the language because there are no syntax errors or because the simulation results appear to be correct. Over time, and as a design grows, race conditions and fragile code struc- tures become apparent, forcing the user to learn these important concepts. Languages have the same area under the learning curve. VHDL’s is steeper but Verilog’s goes on for much longer. Some sections in this book take the reader farther down the Verilog learn- ing curve.

SystemVerilog continues in Verilog’s footstep. Does that mean that VHDL is dead? Technically, all VHDL capabilities are directly available in SystemVerilog. And with the many capabilities avail- able in SystemVerilog not available in VHDL, there are no longer any technical reasons to use VHDL1. However, that decision is never a purely technical one. There will be VHDL legacy code for years to come. And companies with large VHDL legacies will con- tinue to use it, if only in a co-simulation capacity. There is also an effort by the VHDL IEEE Working Group to add these missing capabilities to VHDL, known as VHDL-200x. Whether or not you wish—or can afford—to wait for a me too language is again a busi- ness decision.

Hardware Verification Languages Hardware verification languages (HVLs) are languages that were specifically designed to implement testbenches efficiently and pro- ductively. Commercial solutions include OpenVera from Synopsys and e from Cadence. Open-source solutions include the SystemC Verification Library (SCV) from Cadence and Jeda from Juniper Networks. There are also a plethora of home-grown solutions based on Perl, SystemC, ++ or . SystemVerilog includes all of the

1. Before anyone paints me as a Verilog bigot, I wish to inform my readers that I learned VHDL first and have always had a slight preference toward VHDL over Verilog. xx Writing Testbenches using SystemVerilog Code Examples

features of a hardware verification language. When using System- Verilog, it is no longer necessary to use a separate language for ver- ification.

Making use of the verification features of SystemVerilog involves more than simply learning a new syntax. Although one can con- tinue to use a Verilog-like directed methodology with SystemVer- ilog, using it appropriately requires a shift in the way verification is approached and testbenches are implemented. The directed verifi- cation strategy used with Verilog is the schematic capture of verifi- cation. Using SystemVerilog with a constraint-driven random verification strategy is the synthesis of verification. When used properly, it is an incredible productivity boost (see Figure 2-16 on page 56).

Does SystemVerilog mean that OpenVera, e and the other propri- etary verification and assertion languages are going to die? The answer is a definite no. SystemVerilog was created by merging donated features and technologies from proprietary languages. It did not invent nor create anything new other than integrating these features and technologies under a consistent syntax and semantics. The objectives of SystemVerilog are to lower the adoption and ownership cost of verification tools and to create a broader market- place through industry-wide support.

SystemVerilog accomplishes these objectives by being an industry standard. But the problem with industry standards is that they remain static while the semiconductor technologies continue to advance. SystemVerilog will more than meet the needs of 90 per- cent of the users for years to come. But leading edge users, who have adopted HVLs years ago and are already pushing their limits, will not be satisfied by SystemVerilog for very long. Proprietary tools and languages will continue to evolve with those leading edge projects. Hopefully, their trail-blazing efforts will be folded back into a future version of SystemVerilog, where their art can become science.

CODE EXAMPLES

A common complaint I received about the first edition was the lack of complete examples. You’ll notice that in this book, like the first two, code samples are still provided only as excerpts. I fundamen-

Writing Testbenches using SystemVerilog xxi Preface

tally believe that this is a better way to focus the reader’s attention on the important point I’m trying to convey. I do not want to bury you under pages and pages of complete but dry (and ultimately mostly irrelevant) source code.

FOR MORE INFORMATION If you want more information on topics mentioned in this book, you will find links to relevant resources in the book-companion Web site at the following URL:

http://janick.bergeron.com/wtb

In the resources area, you will find links to publicly available utili- ties, documents and tools that make the verification task easier. You will also find an errata section listing and correcting the errors that inadvertently made their way in this edition.1

ACKNOWLEDGEMENTS My wife, Danielle, continued to give this book energy against its constant drain. Kyle Smith, my editor, once more gave it form from its initial chaos. Hans van der Schoot, Sean Smith and Chris Spear, my technical reviewers, gave it light from its stubborn darkness. The Wilson Beach, on the shore of Lac St-Jean, made me forget that I had just completed another book. And FrameMaker, my word pro- cessing software, once more reliably went where no Word had gone before!

I continue to thank the numerous reviewers from the previous two editions and readers who have reported errors in the published ver- sions, without whom this edition would not have been as good.

I also thank my employer, Synopsys Inc., for supporting this book- writing hobby of mine and for supplying licenses for their VCS™ simulator.

1. If you know of a verification-related resource or an error in this book that is not mentioned in the Web site, please let me know via email at [email protected]. I thank you in advance. xxii Writing Testbenches using SystemVerilog Acknowledgements

VCS and Vera are trademarks of Synopsys Inc. All other trade- marks are the property of their respective owners.

Writing Testbenches using SystemVerilog xxiii “Everyone knows debugging is twice as hard as writing a program in the first place” - Brian Kernighan “Elements of Programming Style” 1974

Writing Testbenches: Functional Verification of HDL Models xxv