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



To start the verification program, Jane had to start building a verification team. Most of the people working on parts of the THX1000 verification had migrated to different teams or left the company, and her current group; Jane, Tom and Bill wouldn't cut it for the level of verification required for achieving a successful job on such a big project. Offers of multiple interns for short spans of time during key parts of the project were not appealing.

She decided to talk to Josh about the type of group he was working with. He was happy to help her. He emphasized the importance of choosing the right people and then discussed the different people in his team. As Josh described each team member, she charted the different traits that the team had. He explained that while everybody had modules they were working on, each verification-designer also had one or more unofficial roles which he described in detail.

His description started with Sam. "Sam is team's script master. Sam swims in Perl and knows all of the debug features including the undocumented ones in the HVL. He knows all the little configuration tricks and optimization flags for six simulators. He is able to make everybody be able to run/reproduce every version of the environment with every version of RTL and every seed. He consistently drives the team to work on the most recent tools and spends time on reducing simulation time and tool overhead. Recently he found a shareware utility that integrates the Simulator and HVL GUIs into one simpler window. Sam is on-line hacking away on his laptop when most people are snoring."

Meltz is the team's pseudo-architect, his position has evolved since he worked on a series of projects that were cancelled just after he had produced an HVL infrastructure for the complete environment. He is the most experienced at looking at the pre-silicon environment and defining the level of abstraction of the environment best suited for dealing with the DUT. He does a great job partitioning the environment design into smaller pieces that have fewer cross-effects and can be developed in parallel. He is the team's re-use champion, frequently finding things in older code or done by other groups in the corporation which suit our project needs. He also loves playing cubicle hockey.

Shmeekimanavaransky, or Shmeek as he is lovingly called, is the team's debugger. He has vast (3 whole years) experience in Verilog and is quite adept at finding root-cause of bugs. When integration gets stuck and the blame game begins, it is always Shmeek to the rescue. He has a calm, serene quality about him that enables him to get to the bottom of things methodically. Shmeek loves soft classical music and functions as the group's DJ.

Shirley is the team's bulldozer. If you need a task completed she just gets it done- and thoroughly. She is able to get into the middle of a project quickly and get results fast. She normally gets the big features with lots of little configuration bits. She will plow through any problem in the most unique ways. She has a special gift for comprehending specifications. She also helps with the team's schedule, she seems to have a knack at knowing exactly how much time tasks will take, despite the long list of unknowns. If you come to work sick, she'll be sure to give you a speech about how to stay home when you're sick.

Jane asked Josh what he does. "I don't do much of anything..", he said.

"Oh... a manager", she replied, and they both laughed.

Josh added that his role is divided into a few different tasks. "First, I run a lot of interference with management, so that the team's job can gets the resources they need and can proceed smoothly despite frequent whims and changes in priorities. Second I mentor, mostly from a distance. I do this by reviewing, encouraging and discussing some of the failures and successes on projects I've done. And third I fill in as a buffer when the schedule gets tight. So I end up doing a wide variety of engineering tasks from creating block level environments, writing features as well as debug and documentation."

"What about managing people? Doesn't that take a lot of your time?" Jane

"Oh, I don't do much of that; the trick is to hire a small team of people who are pretty much self-managed."

After speaking with Josh about the team he was working with, she noticed a few common themes and a few divergent traits in his descriptions.

The common themes were highly motivated people, friendly personalities, high service orientation, and skilled verification professionals. This had her worried; "How could I possibly find people like that?" she asked him, almost completely dismayed... "You don't find them... you create them!" was his response, which had her even more confused.

The differences had her even more curious.. some of the team was software oriented, while some were hardware. Some were conservative in their approach while some radical. As he described them, she could see how the team's different qualities were needed for a successful project execution, and how without team-players committed to the project success these same differences could make working most difficult.

She questioned him about the Software and Hardware, since her company had used exclusively Hardware engineers in the past. He said a lot of that is historical, and with the advent of HVLs you actually need people who understand both. In Josh's view the ideal team should be between 60%-80% software engineers, since most of the environment development is done at a higher level of abstraction, while the RTL debugging can be partitioned in large part to the RTL or a debug team.

"How do you keep these types of engineers?" She asked.
"The key is successful execution of challenging projects in a friendly and fun atmosphere".

"And what about when you get to the high-pressure parts of the project?", she continued.

"That's when you get to see who you can really count on, so far those times have only proven to make the team stronger."

"But you must have difficulties?"

"Tons of them. Some we can control others we can't. The important thing is that the team is completely open and aware of all the difficulties and comes together to resolve them. We work on two to three projects at a time so we frequently juggle people to make sure all projects are happy."

She saw that setting out to build her own team would be quite a challenge. Josh encouraged her, "The more diverse the more difficult, but that's where you really get to use your noodle." She saw the Chinese food was getting to him, so she called it a night.

The next day Jane spoke to Spike. Spike was on the firmware team, but his job had recently been replaced by a team in Micronesia who were supposed to provide a generic firmware package. Management had decided to commit to this package, since it was a recent acquisition and they were afraid to disappoint upper management's push to integrate the new group.

Spike had been heavily involved in the THX1000 initial debug, he had worked with Jane and had consistently crossed boundaries to ensure overall project success. He was one of the friendliest people she knew, and it was clear that working with him on a team would be a good experience. Before graduating college he had worked in support in one of the computer-labs, and was known for giving people complete solutions.

Spike listened intently to Jane's verification plan, and it sounded interesting to him. He had heard rumors that she was planning a different approach and that sounded exciting, however, he had some concerns.

"Jane, your plan includes working on a proprietary HVL language, if I stay in Verification, that would be an asset, however if I choose to leave verification where does that leave me?",

"Good question", she replied, "I agree that the most added value is if you stay in verification, however, you will have an healthy opportunity to develop many other skills. First of all, you will gain a much deeper knowledge of how Hardware is built. The people who know both fields well are much more apt to develop both hardware and software, and as such are consistently in high demand. Second, you will get a unique opportunity to understand the whole system, this will develop your abilities if you decide to go on to architecture or system design. Third, even though we will be reusing components, the environment that we build here will require a great deal of software development. I can assure you that each engineer on this team will do far more development than engineers of either the software or hardware teams. She added that she would be building the team with people who she would be happy to see each morning; "So even if the project fails, at least we'll all have a good time", she added jokingly.

Jane finished with a commitment that she had acted upon twice before in her career to the satisfaction of the engineers. "If you decide that you don't want to be on the team, let me know; I will actively seek an alternative team for you join. It may take me a few months, but I'll find you a place where you will be happy."

Spike looked at her, he knew she was true to her word. "Ok, I'd be happy to
join our team."

With the new team starting to take form, Jane felt confident about her success. Relying on over-simplification of traits of 5 mythical people gave her an odd sense of security in knowing how a verification team should be built.

Next Chapter >>


Design right. Verify right. Ace Verification


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