Ace Verification Homepage



Reference Materials

Ch 1 - Plan from Hell
Ch 2 - Recovery 101
Ch 3 - Building a Plan
Ch 4 - Verification Team
Ch 5 - The Tool
Ch 6 - Setting Goals



Jane spent the rest of the day in front of a PowerPoint presentation. Her first slides stated the goals of pre-silicon verification for the THX2000. In the following slides she laid out the basics of the Verification System. She placed slides on the cost of finding bugs later in the project and how the "system" works to find bugs in the optimal place. She outlined how each of the major changes they would be making in their verification plan worked with the others to make an integrated system for verification.

For example, in her slide on block-level testing she placed the benefits of being able to test components of the FullChip test-bench prior to integration and on the ability to use this phase of the testing as an opportunity to code assertions, assumptions, and coverage points needed for other parts of the system to succeed.

She concluded the presentation with a foil on how using the system, they would be able to find bugs in the easiest way, build the right skill-set of verification engineers, and ensure completion of the verification plan in quality beyond their previous executions with less people.

She called Josh back (the friend who was enjoying verification at his company) again, and discussed her presentation with him. After some discussion, she decided she needed to review the presentation with him for her to feel confident it would convince her department that this was the way to go. He had mentioned something about "the elementary rat-hole argument in hardware projects" but left it a little open to lure her into more discussion.

Over an exquisite dinner of Chinese take-out, Josh and Jane discussed her presentation. He was impressed with how fast she had been able to assimilate the information from their last discussion and start seeing verification as a whole system of interconnected needs. To simulate the audience she would be facing, he asked her the typical HW questions and saw that she had good data on the subjects he asked about. She quoted different successful projects in her company using advanced methods, as well as data from the few articles she was able to find. One of the questions he kept getting back to was how many tests would the team end up writing if random testing was not able to produce the desired coverage. She kept giving unsatisfactory speculative answers until something clicked and she answered (with Akiva's 5th law of verification) "The worst-case of coverage driven verification is that you have to write all of the tests directed, That's the best case in directed testing!".

Jane continued telling him about how they would set realistic goals, use linting tools and bring the right people for the project while Josh continued simulating the hardware team. She was feeling quite confident until he threw her the "we-can't-change-anything-because-it's-a-stupid-idea" argument. He told her it goes like this: A person sitting in back who has been sleeping most of the meeting suddenly looks up and comments "Shucks, this looks like a stupid idea"...A few people who have been wary of change give an understanding nod, and then your meeting is functionally over, along with the whole plan goes with it.. Josh added there is only one way out of such a situation.

Try as she might Josh was able to show her that facts no longer worked once the "Stupid argument" was used. He explained that graphs, charts, and journal articles are ineffective, since RTL designers are trained to be paranoid of change. Josh wasn't helping her out too much when suddenly it dawned on her, the only way to retort the "stupid argument" is to say "but it's your idea!".

Jane went back to work with new energy the following day. She set up meetings with each of decision makers of the company. She had specific goals for what she wanted to catch them saying. With the design manager she had the longest discussion, she aimed him right to the targets and he hit perfectly. As they discussed things she wrote down his comments and paraphrased them for him to assure he was committed to them:

So what you are saying is: "If the engineers on your team were able to find these bugs in block level tests debug and fix would be 2-10 times faster."

"If we were using in code assertion checks many of the bugs could be root-caused instantly."

"As we improve our linting we could save a lot of the easy bugs much earlier"

"If we were to work methodically and go through the THX2000 specification and the protocols it complies to we can build a more complete coverage list"

"Having a ready specification of the THX2000 will reduce design and verification time"

Her next stop was a few of the senior designers

So what you are saying is: "If the environment that you are using to test your design is higher quality, your team will have less false errors"

"Testing the environment components on the interface components prior to full chip integration will save time on integration"

"Anything that can reduce the amount of tests you team needs to write is a positive change"

She followed that by a brief discussion with the software guys:

"You are saying that most of your work is gated by not having a complete specification"

"'HowTos' - Writing examples of how to configure the DUT for each of the features could save you a bundle of time"

She spoke to the former verification lead:

"If we have the driver in the test-bench environment instead of distributed across over 2000 tests the upkeep would be easier"

"If we had more people with a software skill-set we could build a higher level environment and catch many of the bugs that got through on the THX1000"

"If we work with Random we can get to many of the corners in the design we could never thought of or had resources to develop tests for"

She spoke to the project architect who gave her a few good ones:

"If we could just gage what the random was doing we'd be able to rely on it"

"If we could get people with a better view of the system in the verification team then a lot of the trivial bugs could be eliminated"

Then she spoke to the project manager

"So what you’re saying is that predictability is the key, we need to be able to gage what is the extent of our coverage at any given time."

During the information gathering process, Jane also learned a lot about her company. There were intelligent people with good ideas, as she gave them a feeling of being involved and having built the plan with them it started to appear to all, a lot more realistic.

Jane set a meeting for the next day with all of the key people she had spoken to, and updated her foils to give credit to everybody who had contributed. When she went over the slides again Josh had to confirm, she was quite convincing.

Next Chapter >>


Design right. Verify right. Ace Verification


About Us | Careers | Contact Us
Copyright © 2006 Ace Verification Corp. All rights reserved.