Verification Grows Up

Semiconductor Engineering sat down with a group of verification experts to see how much progress has been made in solving issues associated with the profession. Panelists included Mike Baird, president of Willamette HDL; Jin Zhang, VP marketing and customer relations for Oski Technology, and Lauro Rizzatti, a marketing consultant and previously the general manager of EVE-USA. What follows are excerpts of that conversation.

SE: It was not that long ago that you became a verification engineer if you were not good enough to be on the design team. We have made a lot of progress, but still nobody grows up wanting to do verification. How much progress have we made?

Zhang: From the formal space, we see a lot of designers and verification engineers wanting to use formal methods. There is, in general, a lack of expertise in this area and so people who have this knowledge are well paid and well regarded within the industry. So, this is one part of verification that is given high regard within the industry. It is considered to be a good career choice, and people are being offered huge compensation packages to move between companies.

Rizzatti: When you look at the design community, they can design most types of chip and mostly use the same tools. When it comes down to verification, you have formal, , new languages – it is highly specialized. For one designer, you may need three or four verification engineers with different specialties. Salaries for verification engineers are quite high.

Baird: It depends upon the industry. On one end of the scale you have defense contractors, and there we have designer engineers who are being dragged kicking and screaming into doing verification work. They view it as being a bad career move. So here the stigma has remained. Many of them are older engineers and they were also probably dragged kicking and screaming into simulation.

Rizzatti: But military is not leading edge.

Baird: Exactly. At the other end of the scale, we have companies where the relative time spent in verification has changed and it is now the dominant function. Here we have seen that stigma go away because verification is such a key component in these companies. Even though it has become more sophisticated, the design engineer is using Verilog, which hasn’t changed much. Whereas in verification, they are now dealing with object-oriented testbenches, UVM and emulation. It is much more complex and requires a skill set that is actually higher than the designer in terms of programming abilities.

SE: Where are the majority of verification engineers coming from—hardware or software backgrounds?

Baird: I am seeing both. There are still a lot of companies that are migrating their hardware people, and many people in those companies end up doing both. Depending upon the size of the company, the larger ones have dedicated groups and they may get them with more verification background or could have come from the software world. We have been doing this long enough now that we are starting to see verification people move between companies with 10 years under their belts. Smaller companies and those doing FPGAs are more likely to have hardware guys wearing all of the hats, and perhaps just a single verification person putting together the framework,

Zhang: Because formal is primarily white-box testing, you have to be able to understand the design, so we see more coming from the hardware space. That is an easier transition. People with a lot of simulation background may have a harder time switching because the concepts are very different. But it is not that you have to have a lot of design experience. We have had a lot of success hiring fresh graduates, many of them with a EE degree, and we can provide them with the skills they need.

Rizzatti: A hardware background is a big plus for working in verification. I recently attended an event at Portland State University and they showed me an entire class on the subject of functional verification. They teach you everything required for functional verification. This did not exist 10 years ago.

Baird: A career choice coming out of university with the right background.

SE: Design and verification is moving from being a single tool focus to being flows. At the crudest level there are blocks, and there is the system, and they require different techniques, different approaches to solving the problem. In verification, we are seeing more complex flows being needed. The recent work in means that verification will start even earlier in the flow and will become a flow that progresses through all stages of the design process.

Zhang: We are hearing a lot about Shift Left, and that is also true for formal verification. The best time to engage with customers is when they are just starting RTL. By the time you have finished your RTL you are done with block-level verification, instead of doing the RTL and then thinking about verification. We can verify a particular feature even before the whole RTL has been written.

Rizzatti: In all three EDA companies they are building a verification continuum. They have flows with several verification engines such as simulation, emulation, virtual platforms and formal, sharing a common database and a common user interface. This is new even though they have been thinking about it for quite a while. Today it has been implemented. To have a verification engineer who can cover all of these spaces, and perhaps add in FPGA prototyping, would be a unique individual.

Zhang: An engineer has to be dedicated to what they are doing, and specialization is necessary in order to become good at it. Nobody is going to be that good if they are doing part-time simulation and part-time formal. Special skill development will become important for anyone going into a verification career.

Baird: Most of our focus is in simulation and emulation, and I see people floundering around because they don’t have all of the necessary skill sets. They may have the desire to do a Left Shift, but there are hurdles caused by the existing engineers they have. The first time anyone uses emulation, they struggle and it requires the EDA company to come in and do a lot of hand-holding until they have the necessary skill set.

SE: Not long ago, verification was done wherever there was the cheapest labor, but today it seems as if the industry values closeness between the design and verification teams.

Zhang: In the software industry there is the concept of paired programming where two people are working on the same problem, and they find that this is more productive than working individually. We have a vision where we pair a design and formal verification engineer. As the designer is implementing something, the formal person will be verifying it. This requires them to be side-by-side physically. It may work if they are in the same time zone, but not if they separated around the world.

Rizzatti: To add another dimension. So far we have been talking about hardware verification, but today there is even more effort being spent on the software. Coming from emulation, it is a tool that can be used for both and the integration of both. Formal cannot handle software. So the team is getting even more complicated.

SE: Verification is no longer just about functionality. Verification now involves power, performance and security, and many of these cannot be verified at the block level. How well are we doing developing methodologies for these?

Rizzatti: The emulation engine has more versatility than any other verification engine. You are talking about system-level verification on systems that are over three quarters of a billion gates. Simulation cannot handle this even if we just stick to hardware.

Baird: You cannot put enough software through the hardware to do much. I don’t see anyone really getting their arms around it today.

Zhang: Formal is not meant for system-level tasks. It is a block-level tool. Even there, if I implement something, there is a clear spec and well defined functionality. That holds a lot of value. Debugging at the higher-level is difficult and can require vast numbers of cycles to track down where the bug is, whereas with formal you are looking at 10 or 20 cycles. And here the designer can quickly pinpoint where the problem is. The more bugs you can get out at the block level the more benefit you will see later on.

Rizzatti: Is it conceivable that a formal tool could be put together that could handle a system?

Zhang: No, just because of the complexity. Consider the state space that a formal tool has to explore. If there are 3 flops, formal has to traverse 8 states. It is exponential. With 10 flops, it is 1,000; 100 is 1 million; and 1,000 is 1 billion. So there is just no way that formal can be used at the higher levels. There are additional problems with things like power because there are no formal definitions of the problem.

SE: (CDC) is a system-level problem and can be solved because there is a functional partitioning of the problem. Simulation and emulation cannot tackle this problem. It is made solvable by the way the problem is defined. We may find other domains in which this can be done.

Zhang: Yes, there are certain aspects that you can pull out, but it is not clear yet how to pull out what is necessary for some of these problems. There are times when you just have to do all of the dirty work.