It is a pleasure to write a foreword to Samir's book. It tackles a really important topic: I find functional verification, in its most general sense, to be one of the most challenging and interesting engineering endeavors. It is a tough challenge, and also a critical challenge. Design bugs can kill projects, careers, and even people. In addition to being tough, verification is very creative work, and it can also be fun. I hope this book gives a glimpse of all of these aspects.
As Samir says in his preface, e is only a tool. To be successful at functional verification, you need the right tools and methodologies. You also need a lot of imagination and flexibility. Every verification project is different, because every design is different.
Much of functional verification is about knowledge representation. It is about taking the knowledge embedded in the various specifications (and in the implementation, and in people's heads), and representing it in a way that will be conducive to creating the four main components of verification: input generation, checking, coverage, and debugging.
While verification deals with highly abstract concepts, it also needs low-level operations such as Perl-style file and regular-expression handling. Thus, readers of this book may notice that e has borrowed freely from many domains to create one unified language. For instance, it contains:
Constructs for knowledge representation (e.g., constraints and when inheritance)
Support for Aspect Oriented Programming (AOP), for combining distinct specification aspects
The capability to use both declarative and procedural code, including the capability to define new declarative constructs
Low-level file and string constructs
Constructs for describing timing, interfacing to hardware description languages (HDLs), and much more
I hope readers will find the resulting language to be coherent and natural. It has existed (in more or less its current form) for more than 10 years, and people have found more and more uses for it, from the block level to the full system level.
Lately, we at Verisity (working with many of our customers) have concentrated even more on methodology, trying to distill best-of-class methodology for reuse (culminating in the e Reuse Methodology, or eRM), and for coverage-based verification.
I would like to give special thanks to Amos Noy, Yaron Kashai, Guy Mosenson, and Ziv Binyamini, and to the many other people from Verisity who contributed to the evolution of e. Also, the language would not be what it is today without the deep involvement, helpful comments and criticism from our customers.
Finally, I'd like to thank Samir Palnitkar for writing this book. I hope he is as successful in teaching the e language via this book as he has been in teaching e in training classes.
Yoav Hollander
Founder and CTO, Verisity Design, Inc.
April 2003