Often the verification engineer has the impression that the job is to “find bugs”. While that’s true, its only part of the story. I believe the correct description of a verification engineering job is
designing a system that helps the RTL designer successfully develop a device to meet a specification.
There are important things to note from that description that will help you be successful:
- Designing a System: Verification Engineer IS a design job. You are designing a complex test environment. Often engineers feel its less glamorous than an RTL design job, but its usually more important and more difficult to do well.
- You should never design a complex system without a plan! Have a read of our guide to writing a good verification test plan.
- Help the RTL Designer: Your immediate customer is the RTL designer. You need to help him or her create a good design.
- Don’t forget the RTL designer’s needs. In a contract position its often the RTL designer(s) that will decide your long term position. Design and Verification form a team and you will only succeed if the team succeeds.
- The designer needs a tool to see certain situations to add new features. While it may be easier to just randomize everything, its better to know what the designer needs to control and when he needs it. The design schedule is required to create a verification schedule!
- First, assume that any bug you find is in the testbench. Once you have put at some effort into ruling that out, then let the designer know about it. Its just good etiquette.
- ALWAYS automate checks, don’t ever rely on visual checking except for a very short term need. Having said that… its also good to visually check (the first time) to confirm that your automated tests are working.
- Don’t be afraid of making suggestions once you feel you have a reasonable understanding of what the device does and how it does it.
- If a particular feature (design or verification) continues to have problem after problem, its worth suggesting that it be re-designed/re-evaluated.
- Don’t be afraid to suggest that changes be made with verification in mind. A good design is a design that can easily be verified.
- Successfully develop a device: Success is difficult to define, at its very core is developing a device, that works, within a set schedule.
- Schedule is almost always the most defining factor. All of the other factors end up being a trade-off with schedule.
- Depending in the life-cycle of the product and/or the company, factors like future re-use, future enhancements, scalablity, variations in end-products and even sales will have some effect on what success means with respect to your testbench design.
- Meeting the specification: Don’t forget to read the specifications that the designer is trying to meet.
- Don’t EVER trust that the designer(s) knows what they are doing and/or have documented the device properly, even if you have the utmost respect for that person/team and their capabilities. Read the specifications yourself to make sure that the end product will work as expected by customers of the physical device.
- Often it will help you understand why things were done a certain way, as the designers documentation is rarely as thorough as a standard specification.
- Don’t forgot to ask for product specifications. Make sure the design meets management’s expectations.
