Large-Scale Hardware Simulation: Modeling and Verification Strategies
Potential Flaws in Cummings' SNUG2002SJ_FIFO2 Design

Hardware Verification with C++

Back in October, I received a mail from Mike Mintz asking if I'd like to take a look at a book he just wrote with Robert Ekendahl - "Hardware Verification with C++, A Practitioner's Handbook".  It sounded interesting enough, and I knew Mike had been working on a C++ verification library from a brief correspondence we had about a year ago, so I agreed to give it a read.  Around the same time, I read a post by Joel Spolsky (Book Review: Beyond Java) where he reviews a recent book by Bruce Tate (Beyond Java).  As luck would have it, at the same time all of this was going on I also had just upgraded to an unlimited subscription for O'Reilly's Safari Books Online, which meant I could immediately start reading "Beyond Java" (which I did).  Reading these three items got me thinking about the state of the art programming-wise in hardware verification versus state of the art in the software industry as a whole.

In his book, Tate talks about his experiences with Java, and details the development over the years of Object Oriented Programming.  He then goes on to take a look at some of the issues in current languages that impede programmer productivity, and whether there are any new languages coming along that could help address these issues.  Tate describes C++ as a system programming language and feels (as I do) that it is not a productive language for applications development.  According to Tate:

C++ had some obvious warts, like an awkward syntax, multiple inheritance, primitives rather than objects, typing models, poor strings, and awkward libraries.

Also, on pointer arithmetic:

C and C++ compilers often manage memory with a linked list, and the pointers to the next block in the list sit just outside the allocated blocks! These types of errors hurt systems developers, and absolutely murdered applications developers, who didn't have the background to effectively troubleshoot these types of problems. Reliability also suffered.

I'd highly recommend reading the book (especially section 2.2) for a more in depth discussion of the issues. 

I strongly believe that as verification engineers, we are not trying to write highly optimized, high performance code.  It's also true to say that most verification engineers don't have the time or training to really do such a thing, even if they wanted to.  What we're doing is developing, as quickly as possible, an application that successfully verifies the functionality of the hardware we're testing.  Anything that slows us down, even if in the name of performance, should be rejected out of hand. 

Now, back to the topic of this post.  After reading "Beyond Java", I picked up my copy of Mike's book with great interest.  It's obvious from the first part of this post that I don't think C++ is a good choice for use as a verification language.  But, Mike and Robert have provided something that the verification community sorely needs - an open-source implementation of a set of libraries developed outside the ivory towers of the EDA industry.  Actually, it's the only other set of libraries I know about separate from OSCI SystemC that can be used without having to pay a huge licensing fee.  Most large companies probably have just such a C++ library laying around somewhere, but choose to keep the knowledge to themselves. 

In fact, I recognized aspects of the methodology proposed in the book from other C++ environments I've worked on, meaning folks are continuously reinventing the wheel each time they decide to write a new verification environment in C++.  The book itself provides an excellent overview of how such an environment should be structured, and provides the source code to let you go off and try everything out on your own.  The methodology suffers from the fact that it's implemented in C++.  Things such as the way tests are structured and a recommendation not to use smart pointers (if I understand the text on pg. 197 correctly) wouldn't be required if we were thinking of the problem in terms of Python or Ruby, or taking advantage of features in those languages such as metaclass programming and AOP.

The book doesn't propose a methodology for functional coverage.  In fact, they mention  that they feel there are still questions in the industry that would make it difficult to apply.  Questions such as (pg 14):

  • Do you keep the time that the coverage event occurred?
  • How do you fold a large coverage range (such as an integer or real) into coverage bins?
  • ... what is the relationship between the covered events and the constraints that control the randomization?

After this brief discussion, coverage is left out of the rest of the book.  That's too bad because I've seen implementations of functional coverage gathering tools in C++, and I do believe real, robust  solutions exist for collecting and managing coverage.

Random number generation is also short changed, as it is in most C++ environments.  Having a constraint solver available really does make a huge difference.  It allows constraints to be written much more concisely and frees up engineering time for thinking about the higher level verification problem at hand.  In Teal, the library used throughout the book, random number generation is limited to selecting random numbers from a range.  Anyone used to the constraint solvers in Vera or e would find the lack of one in Teal to be a major problem (believe me, I've had to deal with this very issue at companies in the past with large C++ environments).

In the end, the real benefit of this book is the description of the flow of C++ testbenches and an open source library to use as a basis for further development.  What sort of further development?  I'd love to take Teal (the underlying libraries) and Truss (the verification framework) and either wrap them up using SWIG or just reimplement them from scratch in Ruby or Python (After Tate's book, I'm now leaning a bit more in the direction of Ruby).  If I ever have the time to undertake such a project, I'll have a copy of "Hardware Verification with C++" at my side the entire time.  If you're intent on writing environments in C++, you should definitely read it.  But, if you appreciate your sanity, please don't use C++ for verification!

Comments