CEO and Professor Spotlight: Andreas Veneris

10/11/2012 12:53 PM EDT

Andreas Veneris is the CEO of Venssa Technologies and a Professor of Electrical and Computer Engineering and Computer Science at the University of Toronto. Both his company and his research are in the areas debugging and verification of VLSI circuits and systems.

I was doing some research into your background and I see that you were doing some interesting stuff related to the Internet. Tell me about that.

Veneris: When I moved to the University of Illinois for my PhD, Netscape was being developed. It was the senior level project of a 4^th year student named Marc Andreessen under the direction of Simon Kaplan. I was TAing for Simon and got involved with NCSA and Netscape because there was such a unique vision. Soon after, I started doing journalism on the web. In 1995, the Grammy awards called a company we started to cover the event and this was the first time that video and audio were put on the web. We called it a “web cast”. Before that, in the spring of 1994, the Rolling Stones broadcasted their concert but that was only audio, so working for the Grammy Awards, we created such a unique piece of history.

So, how did you end up in EDA?

Veneris: This was in parallel to my PhD work which was on the subject of debugging. These were the very early days of debugging, back in 1994. But it wasn’t in the current context of RTL debug but in fault diagnosis. When silicon fails, how do you find the reason for the failure? My master’s degree was in algorithm development and so I came at it from a theoretical standpoint. You know the kind of things, theorems and lemmas, that you can spent several years on and never get a job! I realized that and so I moved to VLSI debug. In the 90’s I was publishing in the fault diagnosis field and it was difficult because the industry and academic community didn’t want to see theory, they wanted heuristics that helped them get to answers quicker. When I moved to Toronto as faculty, I decided that I might be better off publishing in the verification domain. People tried to dissuade me saying that in verification, reviewers can be really brutal!  But this is not true; verification is such a lovely community. So I stopped working on fault diagnosis and started work on RTL verification and RTL debug.

Twenty years after, I think we are still a long way away from silicon debug because the problem is huge. An example is a customer who once said to me “I am doing an emulation of an MPEG block and after two days there are some bad pixels. Can you help me debug it?” Well, no and good luck! With RTL debug there are at least some things that everyone does, a common platform. They do simulation, they use assertions and things are contained both in size and in terms of the environment. In silicon, they are just too large to handle.

There is very little research that goes on in universities related to verification. It is not only because it is not sexy as design, but contrary to popular opinion, I believe that it is because verification is too difficult for most universities to handle. Design is simpler in that it can be broken down into small issues where it is possible to show results fairly easily.

Veneris: You are right. Verification falls between the cracks. The engineering departments see it as a practical problem. How are you going to verify something? You are probably working on a design problem for Intel or someone like that and you just have to verify what you have done.  But in this manner, you are not developing a cultural infrastructure that others can follow. To create contrast, you go to a computer science department and they all see verification as a collection of theorems and lemmas. Software guys see it this way because this is what it actually is, so hardware verification has stayed the same for about 30 years.

Why is hardware different?

Veneris: There are simplifications. In software you have pointers and loops. The complexity of a software program compared to hardware is different by orders of magnitude. Verilog is simplified and a constrained version of software. But today, the level of abstraction is being raised in our field to that closer to general programming. Also, in hardware, I assume that my spec is correct and I am trying to verify against that. In software, I have my program and the specification is described in an English language document so you are trying to verify two entities that are fundamentally different. I tried working with the CS department at Toronto 6 or 7 years ago, but realized that it would not be a good use of my time. Software verification is a very interesting problem, but it is still intractable, way beyond our reach.

Going back to the question about universities and verification. Why is there so little verification research?

Veneris: I think a big issue is with the industrial funding.  It is common for a company to go to a professor who has years of experience in design, a large pool of great students, and access to tools and all that stuff, and they can get a project done at 1/10 of the cost of a large company. Now this doesn’t happen with verification. A company has to give me funds and I have to develop a tool which may work in the laboratory but working in an industrial environment, it is wishful thinking. But this is the way it has to be! Doing EDA, I push the frontiers, I create new models, I build theory and prototypes. Without this theory, no CAD tool can be developed in the industry. Many of the CAD groups in universities are shrinking and so they don’t have money to spend on research or CAD tool development. So the industry has a problem and it needs to change its thinking with regards to verification. It has to fund it and promote it to build the fundamentals.

There have been few successful transfers of technology from universities to the EDA industry. What are the unique challenges?

Veneris: At the end of the day, we are engineers. We have to be building tools that will help solve some problem and there are two avenues if you want to make your research practical. First is to get a grant from someone like the SRC and then you do your research and it gets assigned to one of the funding companies. This path has not been particularly successful in deploying large commercial tools but mainly custom solutions. The second path is to create a startup that takes the research forward. This path has traditionally been successful in EDA and remember, many companies, including Synopsys and Cadence both came out of academic beginnings.

The way research happens needs to be different. If you give me money and go away for a few years, I am just going to produce a number of papers, but if you closely supervise my work and show how the tool is going to be applied, then there is a much higher chance of success. Much of the funding in Canada is done this way with funds being given for meeting milestones and objectives for actual project deliverables with a strong commercialization aspect behind them.

So what you are saying is the university funding has to be treated more like venture capital.

Veneris: Yes and no. Universities have a mandate to educate highly qualified people. Now funding sources can provide resources and help provide direction and guidance and in addition, outside people can help professors to use this money to create real value.

What message do you want people to hear about Vennsa?

Veneris: I am glad the community has come to a level of understanding and awareness that debugging is the big issue in verification today. In the past decade, they knew they had a problem but they didn’t know what this problem was and how to solve it. Now they know, in the heart of verification there is an inherently manual debugging task. We have seen a steady increase in the understanding for the need of automated debugging technology, which is what we do at Vennsa, and for the great value that it provides.