We provide two sets of open source verification libraries called Truss and Teal available for both C++ and SystemVerilog. Together these two libraries solve many common verification environment structural problems. These pages provide more information about them.

Verification environments are interesting (to us). So interesting that we wrote a book about it. Seen from either an abstract ("framework") or detailed("utilities") enough level they all look pretty much the same. At the framework level you want to initialize, randomize, start and run a simulation. At the utilities level you need solutions for logging, passing in parameters and controlled randomization. This is where we can help.

An ends-in approach

Looking at verification environment it's clear that there are two common and defined layers in most verification environment; one at the highest level of abstraction and one at the lowest. This fits well with a design approach we call ends-in design. Ends in design basically say that you start out defining what you know (i.e. how a top level test looks, and how low layer interfaces looks) and design towards the middle.

To be clear it's the work between these two layers where the real and interesting work happens, and this work is different from chip to chip, field to field, and company to company. These middle layers are also the stuff that is really hard to do and consists of such things as writing data generators/monitors, bus functional models, tests and actual constraints to random variables. This takes real hard work and expertise so it's these middle layers that you as an verification engineer where hired to do. We hope to help by eliminating the need for you (and your team) to reinvent the 'easy' parts over and over again and also provide some good OOP programming ideas

So we provide an open-source solution for the common framework and utility type problems and even describe the methodology for them in a book. There is no reason each company, field and project should use their own solutions as there is nothing magical, secret or that different about these layers. They just have to be discussed and agreed upon. Instead of wasting time inventing these layers time and again it would, in our mind, be more efficient for the industry, as well as more fun for us engineers, if we could agree upon some of these things, solve them and move on. This is what we try to do with the libraries we provide. We started out with C++, because it is a language we prefer, but we've just released SystemVerilog version of our libraries. If time, need and interest arise we could see porting our solution to other languages (like SystemC, Vera or maybe Specman) as well.

Truss: Verification Framework Library

At the most abstract level there is a dance going on, as we describe in our book. The individual dance steps of the dance describe how each major component in your system (from bus functional models, to monitors, generators and tests) can be controlled (i.e. initialized, randomized, started, stopped and checked). The dance steps can get pretty technical and complex in any reasonably sized project, especially if little or no consistency between team members is agreed upon. The good thing is that object oriented programming can help you make sense of it (and enforce an agreed upon consistency). We do not say at any time what should be done in these control points, that's up to you and your team. Also, only at the top level do we enforce what control point is called when (the dance steps).

Truss is an open-source verification framework that describes the topmost level dance. You can find out more about it on the truss product page. It's a methodology described in our book and it was first implemented in C++, though we just released a systemVerilog version. It consists of a set of classes that if used correctly will allow your different tests, bus functional models, generators and checkers to work as expected in parallel in a large environment. If a team can agree and use these classes it will be much easier to reuse components from one configuration to another (and chip to chip). It deals with other features such as parameter setup (through command line or text files) as well.

It is a good starting point if you want to start a new verification environment and probably similar to environments you are used to.

Teal: Verification Utility and Connection Library

At the lowest level you need solutions for a lot of common tasks such as logging, error reporting, controlled randomization, passing argument from text files and command lines etc. And if you, like us, prefer C++ the you need PLI calls to connect your verification code to your simulator of choice.

Teal is an open-source verification utility and connection library that fits at the lowest abstraction level. It deals with such things as simulation logging, error reporting, threading, memory model management. It basically provides all the low level building blocks needed to start a verification environment. You can find our more about teal on it's product page.

Teal was first implemented in C++ as we prefer a none proprietary and powerful languages, but a systemVerilog is available as well. Teal for C++ connects your verification code to your simulator through PLI and work with all major simulators running on Linux or Solaris.
Teal (for C++) is a stand-alone solution and do not use systemC. It allows you to write much simpler verification code (similar in feel to Vera) that compiles and runs fast. You can of-course link it to systemC models if needed. Remember that systemC is a modeling language and provides little for pure verification code.

Teal is a good solution if you want a small verification environment or are using C++ for something very specific (such as driver development).

Summary

As we said before, it's the work in between the two abstraction levels that are hard and unfortunately that work is yours. No outside company can help you (much) here (beyond providing IP or consultant services). Verifying your chip through writing bus functional models, generators, monitors and tests is not only hard work, most of it is probably chip, field and company specific (and secret). Writing this code (along with debugging) is where you should spend your time and what you get paid for.

We provide open source solutions that are simple yet flexible for the upper "framework" layer as well as for the lowest "utilities" layer. These layers have common functionality found in almost any verification environment. Nothing magical or secret about it, simply "stuff" that you need. We provide them as two separate libraries as they deal with different abstraction layers. We call them Truss and Teal. Together they can help create a good verification environment and if enough of us agree on them we can create a community to support it.

Both truss and teal are available open-source, with support through or community and they are documented in our book. If you need more dedicated support then talk to us!