Open Verification Methodology Cookbook
Mark Glasser
Open Verification Methodology
Cookbook
Mark Glasser
Mentor Graphics Corporation
8005 SW Boeckman Road
Wilsonville, OR 97070
USA
mark_glasser@mentor.com
ISBN 978-1-4419-0967-1 e-ISBN 978-1-4419-0968-8
DOI 10.1007/978-1-4419-0968-8
Springer Dordrecht Heidelberg London New York
Library of Congress Control Number: 2009930147
© Mentor Graphics Corporation, 2009
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, LLC, 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. The author and publisher have
taken care in the preparation of this book, but make no expressed or implied warranty of any
kind and assume no responsibility for errors or omissions. No liability is assumed for incidental
or consequential damages in connection with or arising out of the use of the information or
programs contained herein.
Go to http://www.mentor.com/cookbook for more information about the Open Verification
Methodology and to obtain the OVM Cookbook kit of examples.
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)
To Janice
To all verification engineers, the unsung heros of the design
world, who toil over their testbenches so systems will work,
and who receive satisfaction from a job well done.
Preface
When I need to learn a new piece of software I invent a little problem for
myself that is within the domain of the application and then set out to solve it
using the new tool. When the software package is a word processor, I’ll use it
to write a paper or article I’m working on; when the software is a drawing
tool, I’ll use it to draw some block diagrams of my latest creation. In the
course of solving the problem, I learn how to use the tool and gain a practical
perspective on which features of the tool are useful and which are not.
When the new software is a programming environment or a new
programming language, the problem is a little different. I can’t just apply the
new language or environment to an existing problem. Unless I’m already
familiar with the language, I don’t want to commit to using it in a new
development project. On the other hand, I may have an inkling that it would
be best to use the new language. Otherwise, why would I be interested in it in
the first place? I need a small program to help me understand the
fundamental features and get a feel for how the language works. The
program must be small and succinct, something I can write quickly and
debug easily. Yet, it must use interesting language features I wish to learn.
Brian Kernighan and Dennis Ritchie solved this problem for all of us when
they wrote the famous “Hello World” program. In their classic book The C
Programming Language, they started off with a program that is arguably the
most trivial program you could write in C that still does something. The
beauty of Hello World is in its combination of simplicity and completeness.
The program quoted here in its entirety, is not only simple, it also contains all
of the constructs of a complete C program.
#include
main()
{
printf(“hello, world\n”);
}
All those years ago, I typed the program into my text editor, ran cc and ld,
and a few seconds later saw my green CRT screen flicker with:
hello, world
viii
Getting that simple program working gave me confidence that C was
something I could conquer. I haven’t counted how much C/C++ code I’ve
written since, but it’s probably many hundreds of thousands of lines. I’ve
written all manner of software, from mundane database programs to exotic
multi-threaded programs. It all started with Hello World.
The Open Verification Methodology (OVM) is a programming environment
built upon SystemVerilog. It is designed to enable the development of
complex testbenches. Like C (or SystemVerilog or SystemC), it will take some
time and effort to study the OVM and understand how to apply all the
concepts effectively. The goal of this book is to give you the confidence that
running Hello World gave me all those years ago. If I, the author of this book,
have done my job reasonably well, then somewhere along the way, as you
read this book and exercise the examples, you should experience an aha! The
metaphorical light bulb in your brain will turn on, and you will grasp the
overall structure of the OVM and see how to apply it.
The premise of this book is that most engineers, like me, want to jump right
into a new technology. They want to put their hands on it, try it out and see
how it feels, learn the boundaries of what kinds of problems it addresses, and
develop some practical experience. This is why quickstart guides and online
help systems are popular. Generally, we do not want to read a lengthy manual
and study the theory of operation first. We would rather plunge in, and later,
refer to the manual only when and if we get stuck. In the meantime, as we
experiment, we develop a general understanding of what the technology is
and how to perform basic operations. Later, when we do crack open the
manual, the details become much more meaningful.
This book takes a practical approach to learning about testbench construction.
It provides a series of examples, each of which solves a particular verification
problem. The examples are thoroughly documented and complete and
delivered with build and run scripts that allow you to execute them in a
simulator and observe their behavior. The examples are small and focused so
you don’t have to wade through a lot of ancillary material to get to the heart
of an example.
This book presents the examples in a linear progression—from the most basic
testbench, with just a pin-level stimulus generator, monitor, and DUT, to
fairly sophisticated uses that involve stacked protocols, coverage, and
automated testbench control. Each example in the progression introduces
new concepts and shows you how to implement those concepts in a
straightforward manner. Start by examining the first example. When you feel
comfortable with it, move on to the second one. Continue in this manner,
mastering each example and moving to the next.