Q&A: Todd Westerhoff

As a high-speed-design manager for Cisco Systems Inc and a former product manager for Cadence Design Systems, Todd Westerhoff feels the pain of EDA customers he used to sell to and advise. He has 25 years of experience in modeling and analyzing electronics systems. Currently, he and his team of 10 focus on signal integrity and support other design groups at Cisco. Westerhoff earned a bachelor's degree in electrical engineering from the Stevens Institute of Technology (Hoboken, NJ). He vented his frustrations about EDA tools in an interview after a recent vendor panel sponsored by the EDA Consortium.

What do you do at Cisco?

We use simulation tools to model the behavior of chips and the way we interconnect them at the board level. The limiting factor is that the speed of light is too slow. Circuits are switching so fast that the way a signal propagates is like a wave front. We can no longer consider circuits as lumped elements but rather as distributed structures like a wave.

Where does EDA come into the picture?

In the past, you'd put these boards onto an oscilloscope or analyzer, but we use off-the-shelf simulation tools to increase the chance of first-pass success. The cost of mistakes in board design is prohibitive. The problems we face are so complex, you can't fix them simply by trial and error. We have to use simulation tools before we "fab" out the board.

Why do EDA tools fall short?

The things we are trying to do, such as determine how an ASIC works with other chips, is a fantastically complex problem. It requires multiple tools to predict the board's behavior. Even the vendors that say, "We have a full solution" don't cover the myriad details associated with modeling and manufacturing the board. The problem of building something and bringing it into manufacturing has a million angles.

Why does this problem evoke so much emotion?

I don't know if I'd [sound off strongly in a public forum] again. But sometimes you have to shake people up to get them to do things differently. I've been saying [EDA companies should use their products in actual design] for seven or eight years, and, obviously, not a lot of people are listening. We spend a lot of time and money on getting these tools to work correctly. I don't know anybody who says their relationship with the EDA industry is a walk in the park. But we'd be a lot better off if these tools were tested in a real-world situation.

How did your transition from vendor to customer influence your thinking?

When I got out of college, I spent 10 to 12 years as the guy marketing analog and digital simulators. Then I went out as a consultant using EDA tools, and it was a real eye opener. Instead of selling tools, I went to make a living using the tools. Many users never develop the comprehensive understanding of the tool that the vendors expect. User understanding of the tool is uneven, so everybody's perception of what needs improvement is different. The tool becomes difficult and complex to manage. They are big and complicated with many options. The user is saying "I just want to solve this problem." What grows out of that is you have tools that don't work or solve problems.

When I got into EDA around 1983, the paradigm was that, if you could get a computer to do what you wanted, you would be thankful. That [mindset] has never gone away with [EDA]. People tend to look at the problem from their own perspectives. It all changes when you turn around and try to use it, but if you don't use these things, you're not going to be able to perfect them. They're like race cars. You have to go to the track and beat them to death, or you're not going to win. It's also kind of like being in battle where everything is changing and going on around you. The last thing you need is to be in battle with tools that are unpredictable.

How do you cope?

It's a constant problem and one we've learned to live with. The fascinating thing is that some of the things we thought were trivial are big deals, and the things we thought were simple rough edges turn out to be big factors.

Please give an example.

When I was a vendor, this schematic editor had all these fancy functions. Users came back and said that to put a component down and rotate it took seven mouse clicks, whereas our competitor's product required two. Vendors need to get things done repetitively right—not close, but right. You need to nail it. If it's something a user is going to do several hundred times a day, it is going to drive him crazy. And, if you're going to nail it, you've got to use it.

We can ask [a vendor] to add another bell or whistle to a simulator. [They say], "Here's this collection of capabilities. If we change it all around, maybe we can give them that feature." They might say, "We can't quite do this, but we can do something like it." That could be in 12 to 18 months, and compromises get made along the way. In the meantime, the technology moves on.

Don’t they get customer feedback?

Then, you’re in the loop where an EDA vendor has a product that it’s launching. They show it to a customer and ask, “What do you think?” We go back and forth, coding it for six months, but it’s an open-ended problem and nonconvergent process. We constantly say, “We need this, this, and this.” The requests never stop. When you take a problem and develop requirements to solve it—I don’t care what it is—if you go by only those specifications and requirements, some of the essence of what you want to get done gets lost, and the problem magnifies.

Is this problem unique to the EDA industry?

There’s the rub. The problem I am expressing is not limited to EDA. People who design complex systems share this phenomenon. I see the same problem when I go to semiconductor companies. They design this component but often lack the background to understand what this semiconductor will encounter when they use it in a system environment. They don’t share the experience of designing a system around it. And “one size fits all” can become a crutch.

The problem is bigger in EDA industry. A lot of the semiconductor companies do reference designs. The EDA companies offer tools and training but often lack the depth to go much beyond that and into design. EDA companies say, “We are not in the design business. We’re in the tools business.” EDA companies have design services to create a tool, but the problem is they have to make profit. When that happens, they don’t have the freedom to take software and tune it. They’re under the gun to make a profit.

What should EDA companies do?

I’d like to see them engage in really using their tools in actual design problems. They should get involved in real work of design before delivering their tools to market. It’s fairly easy to do. How much money are EDA vendors losing because EDA products don’t quite work? How much needless churn do we have going through bug reports because we are releasing software not quite ready for prime time?

How can the EDA industry do better?

It’s a question you can put back to them. We think a tool is functioning, but it is not done until we bring it into real situations. A couple of aspects prove fairly vexing.

One is beta testing. Customers are going to expect it to work, even though it’s beta. If it does not work, they are not going to play with it. If you tell them it’s almost running, none of your customers have enough time to test it. It’s hard enough to get the software to work well enough for design and find the customer who can devote the time to it and be flexible enough to do something with the feedback. We’ve all got 9 to 5 jobs.

How do you stay current?

You’ve got to take things into battle and keep sharpening those swords. Before I went to Cadence, I had been practicing signal integrity. Within two years [at Cadence], I felt dated. You have to come up with special ways to do simulations with different conditions and adapt the tool on the fly. The minute you stop practicing these things, you get stale.

Editor's note: The above is an expanded version of the article that appears in the print edition. The PDF below reproduces the printed version.