Switching from AOP to OOP - Strategy and Factory Patterns
From China? You Can't Read This...

Verification Unleashed

Here's a question for all you verification engineers out there.  How many times have you been sitting around, minding your own business, when the project manager appears and says something like "Hey, we've made great progress on our new chip's architecture and micro-architecture, and we've already started coding the design... How long will it take you to verify everything?"  It's not uncommon for designers and architects to ignore the verification team until they well along in the design process.  Then, they complain loudly, wondering why the verification team is spending so much time developing test environments instead of writing tests, or about how all the verification team seems to do is pester them for more documentation.  What if there was another way?  As it turns out, there is, and it has the potential to dramatically improve the quality of first pass silicon.

What's the trick?  Project managers need to Involve the verification team early in the development cycle as an equal partner.  Designers and architects have an overarching desire to prove to themselves that they have identified the correct approach to solve the problem at hand.  Verification engineers have no such restrictions.  Our job is to prove that the designers and architects have NOT come up with the correct solution.  It's also in our best interest to ensure that any design module is as easy to test as possible.  By involving us early in the design cycle, we can provide feedback on how long it will take to verify the 10 unique interfaces to a shared memory vs. the time it will take if all 10 interfaces share some common characteristics.  We're going to ask tough questions to identify why salient information has been left out of design and architecture documentation, and then be the thorn in the side of the rest of the team members until that information is added.  We'll stress the importance of uniform naming conventions for signals, and in general help build the framework necessary to treat the design process as what it truly is - a major software project.  Unfortunately, when the verification team is brought in after the framework for the design has already been created, we're in catch-up mode.  We'll ask for clarification on issues and be told that designers are too busy to provide that sort of information... besides, just look at the RTL, it will explain everything.

In short, the earlier the verification team is pulled into the development process, the better the end result -- despite the potential for some growing pains in the process.

Comments