Is Your Verification Manager Obsolete?

Tom West, Tempe AZ.

This was a hot topic about a year ago when I wrote this but felt it was to political at the time to publish. Now that a year has passed, and my previous Verification Manager is off in India contributing to the exportation of jobs out of the USA, my conscience is telling me it is now acceptable.

Obviously I expect a rebuttal.

Over the past dozen or so years the typical approach to functional verification was to set up separate compartmentalized verification teams to tackle overwhelming verification tasks. Because this is/was such a cumbersome task, the balance of power within development organizations shifted heavily towards the functional verification efforts. Vendors rushed in to deliver point solutions to solve verification tasks, often filling the needs of verification engineers at the expense of the rest of the product development team.

The question is whether a separate team focused solely on design verification still best serves the goals and interests of the product development team as a whole, or should this function be integrated into the product development flow to be accomplished by team members reporting to the architecture managers, design managers, and software managers? My answer to this is clearly the later and here is why.

I have seen it to often that Verification Managers do not always focus on the end goals of the business unit. The goal of a business unit is typically "Product Development" as efficiently and accurately as it can be done. This larger business unit goal often conflicts with the goals of a compartmentalized verification team. Architecture design, software design, hardware design, and marketing all must be tightly integrated. Every decision maker needs not only to decide how to accomplish the task at hand, but how that decision affects other aspects of the product development team. Is this true for typical verification teams? I think not and here are some supporting reasons.

Verification Managers often select point tools that are the best tools to accomplish the specific verification task, while the overall product development team suffers. My biggest examples are proprietary verification languages. These languages are often foreign to other product development team members, and languages with limited licenses might not be accessible to other team members. How many software developers do you know that have a good knowledge of Specman or Vera?

What about reuse? Who is looking out for reuse of models among design, software, and architecture teams? Is this the verification manager’s function? These decisions clearly should be made at the Engineering Director level. Is the verification manager interested in how the needs of the business are served by sharing the environment with other business units within the organization, or with customers? Often the answer is no, yet the choices are made by verification managers both in methodology and proprietary tools, and these choices can result in a major disservice to the greater good of the organization.

Verification managers and the compartmentalized verification teams under them often form walls between themselves and the rest of the product development groups. Often the justification is that this sheltered group will think independently and provide a unbiased interpretation of the design specification. But wouldn't you agree that the associated reduced communication with the rest of the product team formed by these compartmentalized "walls" is often to blame for missed bugs Clearly since the focus and goals between the compartmentalized verification team is slightly skewed from the rest of the product development team, communication gaps will always exist.

Compartmentalized verification engineers often do not know intricate details about weak areas of the design under verification. Only the designers know these troublesome areas that need detailed attention. Often the designer working closely with the verification environment will be the only way to attack the problem. The only way to achieve this is if the designer is intimately familiar with the verification environment, without walls, and communication barriers.

Often an issue gets kicked back and forth between a verification environment problem and design problem. We have all seen this happen and it can waste days on each issue. More often than not, this is a result of a designer who does not understand the verification environment because the environment was developed with verification specific proprietary tools by a compartmentalized verification group. It’s normally not the designer’s job to understand the verification environment. Typically the environment is built to serve the specific interests of the verification group and it might be too hard to understand outside this group. This scenario does not serve the best interests of the overall product development team.

Segregated verification teams often develop an adversarial relationship with designers. It’s the verification engineer’s job to identify faults with the designer’s work. Could this be one of the causes to the breakdown in communication? I think so. On the other hand, designers may tend to avoid double-checking their work because they expect the verification engineer to catch errors. Clearly this is an unhealthy scenario.

On the positive side, we have never had solution to this problem like we have today. In today’s product development environment, integration of the verification tasks is imperative and it is now easier than ever to do this. While we still need verification engineers focusing on building verification environments, a larger focus can now be and must now be placed on full product verification and more importantly, the superset development effort. Successful development teams will have director level management making decisions on methodologies and non-proprietary tools that affect the greater good of the entire organization well into the future. Successful development teams will see that verification is far more than “logic verification” – it is architecture verification, software verification, and design verification. Verification is “product verification.” This cannot be accomplished with a compartmentalized team and certainly cannot be accomplished with many of the verification point tools and methodologies chosen by these teams. Verification needs to be an integrated approach with decisions made at the highest of levels. Hopefully the decision maker will see beyond the verification point tool products that most vendors are peddling. Every tool decision needs to be made with a positive answer to the question, “How will this help integrate my entire team and get my product out faster?” Its an approach in which open common languages, common models, and a methodology that supports reuse across teams, over time, across the development cycle, across business units and customers prevails. There is no room for proprietary point tool languages. My message to business unit managers is short. Take control of the situation, Every team member is responsible for verification. Focus heavily on choosing the best tools and methodologies that support reuse and communication across your entire team.

Tom West Tempe AZ

Visit my odd outdated fun pages at www.openverificationfoundation.org