Interview with Chuck Alpert

Featured Engineer

Chuck Alpert

Chuck Alpert - Manager, Design Productivity Group, IBM Austin Research Laboratory

What got you hooked on this field?

After my first few computer science classes in college, I realized I had a passion for algorithms. Computer-Aided Design happened to be the first course I took in graduate school and I quickly discovered that it was a terrific forum for large-scale optimization and heuristics. While I have been in the field now for 20 years, I consider myself a Computer Scientist impersonating an Electrical Engineer.

What are your favorite hardware tools that you use?

I don’t really use hardware tools as I mostly develop design automation software to make hardware designers more productive.

What are your favorite software tools that you use?

I’m a big fan of data visualization. When analyzing complex algorithms, I don’t want to see the only the beginning and end result, I want to understand how the algorithms are changing the design as a function of incremental time stamps. Visualization enables one to see trends and find disruptive behavior within the system. I find this much more effective than the trial and error approach many engineers use for algorithmic tuning. I like tools that help with visualization like Matlab and gnuplot. My team writes a lot of perl scripts to help us automate the visualization process.

Do you think the way that engineers interface with physical design tools will change over time and how?

Not in any significant way. The interfaces will improve as will the visualization tools. Certain tasks will move to the cloud. Others can be migrated to portable devices. But I do not see major change here.

What is on your bookshelf?

I’m currently reading “The Black Swan” by Nassim Nicholas Taleb, and I recently read “Outliers” by Malcolm Gladwell. These books are terrific examples of books that challenge the way we (as engineers) view the world. Engineer’s may find Taleb’s discussions on the fallacy of prediction of particular interest. Engineers love to make predictions and use probabilities, but tend to dismiss flaws in the underlying models . . . which makes the predictions flawed. They can miss the outlier (i.e., the Black Swan) that while improbable could be extremely significant. Gladwell’s book discusses not event outliers, but people outliers, such as the Beatles and Bill Gates. The striking observation he makes is how much circumstances and opportunities play in creating extraordinary successes, which on closer examination, makes them not as extraordinary as one might think

What is your Favorite Quote?

“The information that the solution exists is itself a big piece of the solution” Nassim Nicholas Taleb

Do you have any tricks up your sleeve?

Working in research implies that the path to the right answer is not always clear, and exploring many different paths can be expensive. I think the biggest trick my team uses is our high leverage of academic research. My group actually invests considerable effort in packaging up test cases to release to academia as a series of contests. Each year since 2005, the ACM International Symposium on Physical Design (ISPD) has hosted a physical design automation contest that was run by my research group. Typically, around ten teams of students compete from major universities from around the world on the problems that we release. Often the best solutions give us key insight into how to best solve the problem and help guide us in a fruitful direction. It also helps me identify who the top students in the field are, and some of them have joined my team over the years. The key trick is that we pick the problem and the problem formulation, provide the testcases, and teams come to compete. It not only helps our team but stimulates innovation in the literature.

What has been your favorite project?

I always seem to enjoy the next project more than the previous one. My current project is implementing a new physical synthesis flow with the objective of making designs easier to route and to require less post-routing fixup.

As designs become more complex and projects increase in size, the time it takes for design tools to run is getting longer and longer. What needs to happen to reduce the time or address this issue?

Design teams need to embrace hierarchical methodologies, and this is already happening. Designs that are too big for the tools must be designed in this manner, and then the tool runtime is not a big deal. However, managing a hierarchical design is much more difficult than managing a flat one. Improvements in design tool runtime push the limit of what can be done flat versus hierachically, but this is hardly anything new. It seems design sizes are outpacing tool capacity which forces more designs to be done hierarchically. This may add cost and schedule, but it is not a fundamental problem. Everyone is always trying to improve the runtime of their tools while simultaneously adding new capabilities which inherently add runtime. For example, supporting design rules for advance technologies adds runtime to detailed routing. So while the algorithms and code get faster, the problem constantly gets harder. Sometimes, a tool becomes such a mess of spaghetti code over time due to feature creep that you are better off starting from scratch.

What direction do you see your business heading in the next few years?

There are a number of ways it could go. On one hand, their has been a realization over the last few years that as designs scale and cost pressures increase, custom design is no longer viable. Design teams need to rely on automation more than ever, which provides a wonderful opportunity to invent new approaches and flows to achieving fast and effective automated design closure. Further, there seem to be more and more chips to be built with a fairly static set of designer resources available. On the other hand, the industry has seen a lot of consolidation and there are those who view EDA products as commodities. Several hard problems are commonly viewed as “solved” even though the existing solutions are sub-standard, and these pervasiveness of these perspectives would naturally lead to a reduction in investment in this space.

What do you see as the next big problem to solve with EDA and VLSI tools?

There are not really any big problems to solve. Instead, there are thousands of little problems that make design methodologies and tools inefficient. Every migration to a new technology or design of a new kind of chip exposes more of these little problems, so while some get solved, new ones emerge and the cycle never ends. What makes a problem big is packaging up all of these little problems under an umbrella and giving it a name such as “design for manufacturability”. Close inspection reveals this big problem becomes a bunch of smaller ones, and solving each one of them makes the tools and processes a little bit better.

What challenges do you foresee in our industry?

The challenge of course will be to provide a compelling value proposition to customers to buy and build new silicon despite the end of traditional scaling. Speed is no longer the value, so it has to be area, packaging, cost, etc. So far it seems to me that our industry is doing quite a good job of shifting to these new value propositions. Of course, if you go back to my answer on what’s on my shelf, I would be foolish to try to make any forecasts.