Part of the  

Chip Design Magazine


About  |  Contact

The Verification Walk and Talk

I may be biased coming from a metric driven verification background, but 2013 seems to have been the year of the reusable metric driven verification environment.  We saw Jasper and Duolog team up to produce not only a re-usable specification, but associated assertions that could travel with it, and the IP from project to project. ARM is shipping these verification environments along with its IP blocks.  Apache touted the benefits of metric driven power verification.  The big three, Cadence, Synopsys, and Mentor, are all headed down variously similar metric driven verification process paths.  Gary Smith called for more reusable system verification that spanned the entire gamut between block level IP and user level apps.  Even physical design is moving to automated, metric driven verification as companies like Sage advance the technique.  Will we soon see packaging and board design tools from companies like Dassault be included in a metric driven flow?

With all the advances in tools, there’s still one personal aspect of the verification project to keep in mind, the true point of origin of all these tracked metrics: communications.  While metrics can and should be codified and tracked by automated tools, they are most effective when they are codified correctly based on a shared understanding of what a design is intended to do and how it is likely to be used.  This knowledge is contained in the minds of various members of the product design and production team.  Here are a few guidelines about what each part of the team might be able to contribute in the metric definition process.  They are by no means complete and additions based on your experience would be greatly appreciated.

Fellow Verification Team Members
Your fellow verification team members may have previously worked with the block you are tasked  to verify and have a historical knowledge of its ins and outs.  In addition to that, your blocks may be adjacent, or share common resources.  Hopefully, you’re both in good contact with your design engineers, (see the next section).  You should also be in good contact with each other.  Often hammering out metric details about inter-block communications identifies bugs without a single testcase being run.

Design Engineers
If you don’t know who your block’s design engineer is, you should find out.  This may not be as simple a task as it seems.  In some boutique semiconductor companies, they may only be a few cubes away.  In large international firms, they might be on the other side of the globe.  In either event, it’s worth the effort to get to know them.  These folks are putting their understanding of the specification into physical realization.  You’ll want to make sure that you’re checking the design vs. what they think it should do as well as what the specification says it should do.  Here as in the section above, good communications can lead to bugs being found without executing any testcases.
Firmware Engineers
These people will use the device utilizing its exposed interfaces.  They can tell you how they’ll use the device.  This usage model defines known sequences of transactions that the device will  be expected to perform.  They can also tell you which portions of the device’s functionality have the highest priority.
Architects specify how the system is to be stitched together and share resources.  They can help identify stress tests to run the system through its paces.  They can also be invaluable in helping you get a big picture of the device you’re testing from the top down.
Despite all the two-drink minimum jokes about marketing, they often have the deepest knowledge of how the device’s customers want to use it.   This knowledge can help in defining must-be-run test sequences and in prioritizing verification tasks.
Production Test
Even though its well after the fact, verification sequences run in production test sometimes expose use case relations between blocks you didn’t know existed.  Test engineers are privy to this sort of thing.  They should especially be engaged for verification planning of derivative products, and let’s face it, what’s not a derivative product these days?

Hopefully I’ve made a good case for communicating early and often with your project team.  In case I haven’t, you might want to think about one extra aspect: the fringe benefits.  Talking to these folks makes you a known quantity around the company and with the fluidity of our industry, over a few years can gain you exposure across multiple companies.  As you get ready to move into other areas of project execution, or to move into positions with more responsibility, being known as a communicator that makes a positive impact can only help.


Leave a Reply