Verification effectiveness!!!

“Functional verification takes 70% of the chip design cycle”. Writing test plans, Writing reusable verification environment, writing assertions for the design, debugging RTL failures, attaining code coverage and functional coverage goals & gate level simulation and debug are some of the common activities a functional verification engineer goes through in project life cycle before tape out. The work of verification engineer exponentially increases if the design under test has more number of bugs, which involves lot of RTL debug effort. Metrics on which a verification engineer is evaluated is on “How many bugs where hit during functional verification” Vs “bugs hit during emulation/post silicon validation” Even a single post silicon functional bug indicates the ineffectiveness in the functional verification.

If you are verification engineer and you feel that you have hard time in meeting your schedules and you work for more hours in office (say more than 8 hours) to meet the dead lines. Following are some effective ways i used to meet the dead lines without compromising on work quality or the compromise on working hours.

1) Micro schedule your tasks with effort estimates and get an approval on the time line from your manager.

2) Whenever scope of the work is increased / decreased re-schedule the effort estimates and keep your manager updated about this.

3) Prioritize your tasks and complete one after the other.

4) Whenever you are writing a test bench make sure your test bench is reusable. This can help you to minimize your work at a later point of time.

5) Always try to use module level verification environment at the system level. Maximum effort you need to put is the integration effort from module level to system level.

6) Always write random verification environment to test your design, most of the bugs are easily captured by random verification environment. Write a directed test case only if it is absolutely required to hit a functional coverage / code coverage hole.

7) Always move with the market, try learning and using new technology which will overall reduce the verification effort. Example adoption to tested methodology like VMM or OVM might be initially tough but on a longer run it will reduce your time to verification.

8) Always file a bug when you hit design issue, this is very important because this is the only metrics on which a verification engineer gets evaluated. Also top level management will know the effectiveness of the verification and schedule slips due to design issues.

9) Always keep your manager updated with status of your task so that he will be in position to evaluate your bandwidth for future tasks.

10) Never compromise on testing a DUT feature due to lack of test bench support, this may lead to emulation/post-silicon bugs.

11) Always keep the code coverage analysis towards the end of the project after your function coverage goals are met.

12) When you are stuck with a problem, do not work continuously to fix the issue this will increase the stress level and you will end up spending more time hitting on the areas around the issue. Take a break from the issue and come back with a fresh mind.

13) Try to understand the code base relevant for the enhancement or the modification, spending time on understanding overall code base has diminishing returns.


Does the functional verification engineer get rewarded for his verification efforts is really a question mark and largely dependent on the company you work for.