Preface

Unlike synthesizable coding, there is no particular coding style nor language required for verification. The freedom of using any language 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, coupled 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 subset of the intended functionality, to a delayed product shipment.

Why This Book Is Important

In 2003, the second edition presented the latest verification techniques 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 functional verification: coverage-driven constrained-random verification using proprietary hardware verification languages.

This book is not really a new edition of the previous Writing Testbenches 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 implementation 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

It will be necessary to cover some SystemVerilog language semantics that are often overlooked in textbooks focused on describing the synthesizable subset or unfamiliar to traditional Verilog users. These unfamiliar semantics become important in understanding what makes a well-implemented and robust testbench and in providing 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 transactions into high-level procedures using bus-functional models. The architecture of testbenches built around these bus-functional models is important to create a layer of abstraction relevant to the function 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 $random 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. Random 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 verification 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 performance over the RTL model. Striking the correct level of accuracy is key to achieving that performance improvement.

This book has one large omission: assertions and formal verification. It is not that they are not important. SystemVerilog includes constructs and semantics for writing assertions and coverage properties 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 assertions¹ or formal verification. This book focuses on the bread-and-butter of verification for the foreseeable future: dynamic functional verification using testbenches

What Prior Knowledge You Should Have

I also expect that you have a basic understanding of digital hardware design. This book uses several hypothetical designs from various application domains (video, datacom, computing, etc.). How these designs are actually specified, architected and then implemented 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 SystemVerilog (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 powerful 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

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 verification project, you probably want to concentrate on Chapter 3, Chapter 6 and Chapter 7.

Why SystemVerilog?

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. SystemVerilog, being a superset of Verilog, benefits from the same smooth initial learning curve. However--like VHDL--Verilog and SystemVerilog provide similar concepts: sequential statements, parallel 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 structures 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 learning 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 available in SystemVerilog not available in VHDL, there are no longer any technical reasons to use VHDL³. 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 continue 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 business decision.

Making use of the verification features of SystemVerilog involves more than simply learning a new syntax. Although one can continue to use a Verilog-like directed methodology with SystemVerilog, using it appropriately requires a shift in the way verification is approached and testbenches are implemented. The directed verification strategy used with Verilog is the schematic capture of verification. 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 proprietary 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 marketplace 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 percent 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

For More Information

In the resources area, you will find links to publicly available utilities, 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 the book⁴.

Acknowledgements

I continue to thank the numerous reviewers from the previous two editions and readers who have reported errors in the published versions, 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^TM.

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

¹ Cohen, Venkataramanan and Kumari, "SystemVerilog Assertion Handbook", VhdlCohen Publishing, 2005

² Janick Bergeron, Eduard Cerny, Alan Hunter and Andrew Nightingale, "Verification Methodology Manual for SystemVerilog", Springer 2006,
ISBN 0-387-25538-9

³ 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.

⁴ If you know of a verification-related resource or an error in this book that is not mentionned in the website, please let me know via email at janick@bergeron.com. I thank you in advance.