WWW.TESTBENCH.IN

Tutorials

Specman E
Interview Questions

PSYCHOLOGY OF VERIFICATION ENGINEER

Broadly speaking, we can view Verification Engineer as having two kinds of skills: one set used to perform basic duties at work, and another set of skills used to approach work. The former can be categorized as technical skills and the latter as soft skills.

While the technical skills are absolutely important for a Verification Engineer, there are certain soft skills that should complement the technical abilities. A comprehensive Verification engineer should have a blend of the technical and soft skills.

To elaborate more on soft skills, these are the ones that define one's approach towards work, life, problems, etc. Soft skills are people skills. The best part about mastering them is that the application of these skills is not limited to one's profession, but their scope reaches all aspects of life. Technical skills may teach one how to meet the expectations of the job, but soft skills teach one to succeed, and to exceed expectations. There are many situations that we come across on the day-to-day work life as a Verification engineer in which one person perform better than the others just on the basis of Soft skills- be it winning an argument with RTL designer on the basis of his/her communication or finding handling multiple tasks effectively because if superior organizational abilities etc.

Soft skills are extremely important for the people in Verification and this is something that is often found to be neglected by the upcoming Verification engineers. It is surprising that we spend our time educating almost exclusively in technical skills.

Human beings reaction in this complex world of happenings varies widely with respect to situations, surroundings, emotions, need, requirements, time frame, money, visualization, belief, education, knowledge, expertise, intuition and so on. Such complex is the nature of human being and certainly there's no exception at work place too. Therefore it's cynical to say that the job being done by a Verification Engineer is simple & complete.

The quality of the job done by the verification engineer is directly proportional to his or her psychological maturity and profoundness acquired, adopted and developed with age and experience.

Let's examine the psychology of the verification engineer by describing the definition of Verification under three circumstances.

"Functional Verification is the process to prove that the RTL works as per the specification"

"Functional verification is the process to find all the bugs present in the RTL design"

"Functional Verification is the process to detect the defects and minimize the risks associated with the residual defects"

Above three definitions are upside-down. Understanding the true definition of Functional verification can make a profound difference in the success of your efforts.

1)

"Functional Verification is the process to prove that the RTL works as per the specification"

Generally this definition is given by the RTL designers or the new verification engineers with prior RTL design experience. The above definition sounds good if the RTL designer itself is trying to verify his implementation .  RTL designer intentions would mostly revolve around the point to prove that the RTL meets the specification. RTL designer will exercise only those inputs for which the correct results are obtained and are specified in the specification and the DUT can still contain bugs which will not be visible.

2)

"Functional verification is the process to find all the bugs present in the RTL design"

This definition sounds good epically if the main aim of the verification engineer is to prove that the RTL work for what it's supposed to do and not what is not supposed to do. This type of psychology would bring out the most of the bugs in the RTL.  This goal is impossible to achieve.

3)

"Functional Verification is the process to detect the defects and minimize the risks associated with the residual defects"

This definition appears to sound realistic. Practically, if at any point, the RTL development starts, the verification should start and keep in track the number of bugs being detected while correcting.

At some stage of a planned verification, there would be a stage where no bugs are identified after many days or weeks or sometimes months of verification which statistically allows you to conclude that the RTL is "good enough" to be released to next step. i.e. there may still exist some bugs undetected, but the risk associated with the residual defects is not very high or are tolerable.

From the above three definitions, we can understand that the psychology of a verification engineer plays a vital role throughout the ASIC development cycle.

Role And Characteristics Of A Verification Engineer

Verification Engineer requires technical skills similar to RTL designers, but Verification engineers need to acquire other skills, as well.

Most engineers that I've talked to over the years believe that the mind-set and personality of a good Verification engineer are different from those of a good RTL designers. For example Verification engineer are more experimental then RTL designers.

Keen Observation
Detective Skills
Deduction skills
Destructive Creativity and Negative Thinking
Understanding the DUT as an integration of its parts
Cynical but Affable Attitude
Organized, Flexible and Patience at Job
Objective and Neutral Attitude
Discipline and Perseverance
Communication Skills
Learning from Past
Eagerness to embrace new technologies, methods and flows

Keen Observation

The Verification engineer must possess the qualities of an 'eye for detail'. A keen observation is the prime quality any Verification engineer must possess. Not all bugs are visible clearly to the naked eye. With keen observation, the Verification engineer can easily identify or detect many critical bugs. Verification engineer should learn how to look for details, how to analyze the things from different possible dimensions. The more observant a verification engineer is, the more likely he is detecting more bugs.

Without observation, it is impossible to tell the outcome of a test or an experiment. Although this makes sense, it is tempting to design tests and experiments that are difficult if not impossible to observe. We may want to prove or test something, but real-world constraints prevent constructing an accurate experiment. That's why you can't verify everything and not everything is verifiable.

Detective Skills

Ideally the Design under development would be documented before, after and throughout the development process. Unfortunately, there is every chance of not updating the documentation (specification, defect reports etc) due to time and resource constraints.

The Verification engineer should therefore apply his knowledge of rationalization in knowing about the DUT from formal system like system specifications, design & functional specifications, review notes etc. From this information, the Verification engineer should look for researching more analytical information through other sources called non-formal sources of information like RTL designers, previous version test plans, bugs and related product documents, reviews of related and (seemingly) unrelated documents.

A Verification engineer should therefore possess the quality of a 'detective' to explore the product under test, more rationally

Deduction Skills

A Verification engineer with deduction skills is also likely to be good at issue solving. Deduction skill is an ability to analyze the meanings of the signs and deriving of a conclusion by reasoning. It's a logical thinking, which helps a Verification engineer to differentiate a bug from a false one. Deduction skills may come from practice of cognitive information processing, power of interpretation and can help a Verification engineer in differencing and decision making.
Deduction skills play major role while debugging. Not all the verification engineers can debug an issue at same speed. Looking at some waveform signals, log messages, he has to isolate or locate it. In Verification life cycle, everything can be planned and can meet the schedule in time except debugging. Time spent in debugging is unpredictable and cannot be planned ahead.

Destructive Creativity Or Negative Thinking

Most human beings are constructive in nature rather than destructive.
The Verification engineer need to develop destructive skills ,means skills to perturb and crash RTL functionality. In other words, the Verification engineer should 'not hesitate to break the RTL functionality. In the world of functional verification, boundaries are meant to be crossed not obeyed.

A creative oriented but destructive approach is necessary while verifying a RTL by the Verification engineer to make the RTL Design evolve more robustly and reliably.

Negative Thinking is a art. While mentioning the risks involved in the project, a Verification engineer has to consider all the things that can go wrong. Training the mind to think negatively in required situations helps Verification engineer develop an efficient contingency plan.

A word of caution here; distractive skills are useful only for specific situations. A Verification engineer has to be smart enough to identify such situations and wear an appropriate thinking hat to deal with the situation.

Understanding The Dut As An Integration Of Its Parts

The RTL design is a culmination of lines of code interacting with data through user interfaces. It is an integration of separate group of code interacting with other groups assembled together to function as a whole chip. The developers might be working on a respective piece of code module focusing more on those modules under work, at a time.

It is no wonder if the developer sometimes may not even know the complete workflow of the RTL and not necessary too. Whereas, in the case of a Verification engineer, being the rider of the DUT, should understand and know about the complete specifications of the DUT.

The Verification engineer may not be the best expert on any one module of the RTL but definitely he/she should gain expertise on the overall operation of the RTL Design. In fact, the Verification engineer should possess a 'Systems' view of the RTL design because they are the only people to see and verify the complete functionality of interdependent modules and compatibility.

Cynical But Affable Attitude

Irrespective of the nature of the RTL design, the Verification engineer need to be tenacious in questioning even the smallest ambiguity until it is proved.

There may arise some situations during the course of verification , a large number of bugs might be encountered unusually which might compel to further delay in RTL freezing. This may lead to heat up the relation between the Verification engineer and RTL design teams. The Verification engineer should balance this relationship not at the cost of the bugs but by convincing and upholding their intentions to "assault the RTL design but not the RTL developers".

Organized, Flexible And Patience At Job

Verification engineer must remember the fact that not all the tests planned are performed completely and some tests dependent on other tests has to be blocked for later testing. We manage ourselves, our tasks, so that we make the most of our time. Verification engineer have to juggle a lot of tasks.

This needs an organized approach by the Verification engineer in attempting to phase out the bugs. Sometimes, significant tests has to be rerun which would change the fundamental functionality of the RTL design. The Verification engineer should therefore have patience to retest the planned bugs and any new bugs that may arise.

It is even more important to the Verification engineer to be patient and keep prepared in the event of a dynamic development and test model. Development keeps changing continuously as requirements and technology keeps changing rapidly and so should Verification. The Verification engineer must take these changes into account and plan to perform tests while maintaining the control of Verification environment to ensure valid test results.

Objective And Neutral Attitude

Nobody would like to hear and believe bad news, right? Well, Verification engineer are sometimes viewed as messengers of bad news in a team. No wonder, how good the Verification engineer is (meaning very negative) and brilliant in doing his job (identifying bugs-no one likes to do it but most human beings are taken for granted to be naturally very good at it, at least from childhood), he/she might always be a messenger of communicating the bad part, which, the creators (developers) doesn't like it.

The Verification engineer must be able to deal with the situation where he/she is blamed for doing his/her job (detecting bugs) too good. The Verification engineer's jobs must be appreciated and the bugs should be welcomed by the RTL design team because every potential bug found by the Verification engineer would mean a reduction of one bug that would potentially might have been encountered in later stage.

Irrespective of the negative aspects of doing such a highly skillful job, the role of a Verification engineer is to report honestly every known bug encountered in the product with always an objective and a neutral attitude.

Discipline And Perseverance

One obvious aspect of verification is that it can be extremely repetitive and may require a lot of manual effort. Consider the following situations:

A Verification engineer is struck with a bug that is not reproducible at all the instances. In order to reproduce the bug he goes through the whole series of steps again and again.

As part of a daily routine, a Verification engineer has been asked to collect data about test cases executed, bugs reported, etc.

There can be numerous examples that prove the reiterative nature of the job.
A very predictable reaction to this repetition is to simply get tired of the job. But soft skills include the psychological tools to persevere, and to find ways to make effort more productive and interesting. This attitude difference helps a Verification engineer maintain focus and higher levels of quality work. It brings the ability to carry out task at hand in spite of difficulty.

Communication Skills

Communication skills form the necessary ingredients for success in any profession. Communication is something that we always do in our personal lives as well as professional life. Communication is a very basic human skill and one cannot go very far without it. Communication in this context does not involve any body language; so it's the pure word power, which rules the situation. Though most of us agree that these skills are important, very few of us give these skills a high enough priority. For a VE, both verbal and written communication is crucial.

If your written communication is bad, you'll miss the salient points - the audience won't know the important stuff - or you'll put the audience to sleep. This means your bug reports will bounce back as "invalid" / "unable to reproduce" / "won't fix."

Many instances can be thought of in the day-to-day work of Verification engineer, where a Verification engineer can make a difference to the situations with effective communications skills.

Learn From Past

Keep learning from past experience and try not getting caught in any mistakes that have been made earlier. A common saying is "Never repeat the same mistake again". A verification engineer should know not only his mistakes, but also the RTL Designers mistakes. If RTL designers does the same mistake, Verification engineer past experience on catching the same mistake increases the possibility of the finding the mistake easily.

Mistakes can be categorizes into 4 categories:

Stupid:
Absurdly dumb things that just happen.

Simple:
Mistakes that are avoidable but your sequence of decisions made inevitable.

Involved:
Mistakes that are understood but require effort to prevent.

Complex:
Mistakes that have complicated causes and no obvious way to avoid next time.

Eagerness To Embrace New Technologies, Methods And Flows

A Verification engineer should have enthusiasm to learn new technologies, methods and flows and eagerness to progress further. Today's functional verification is still in research stage. Even most of the terminology is not stable across the industry. As the research is going on, companies are adopting new technologies and the Verification engineers should be able to learn them.

About the author:

Gopi Krishna He is the Author of testbench.in.

Report a Bug or Comment on This section - Your input is what keeps Testbench.in improving with time!