AI’s Growing Impact On Chip Design

Synopsys chairman and co-CEO Aart de Geus sat down with Semiconductor Engineering to talk about the rapid infusion of AI into electronics, how that is changing chip design and the software that runs on those chips. What follows are excerpts of that conversation.

SE: We’re dealing with a bunch of new markets, more customized design, and AI seems to be creeping into everything. How does this impact design?

de Geus: One need for AI algorithms is more compute power, and one goal for the semiconductor industry is for more ways to sell silicon. So there’s a natural marriage of opportunity that has hit a strong discontinuity. This all began with the Go game being won by a processed solution. That was the beginning of changes from computers to pattern matching, which is what AI is today.

SE: So where do we go next? Does everything become more probabilistic?

de Geus: Pattern matching is probabilistic. The brain is very capable of coming to the conclusion that you are human. But if you had a piece of cardboard with your picture, the brain would figure out additional patterns, such as that one is moving and that one is not. The difference between winning at chess versus Go is that the chess game was won on the basis of deterministic algorithms that had a forward-look reach that was deep enough to beat a human, and then some strategies for optimization. The Go game was based on the notion of finding many patterns that were recognized as more winning than losing. With this came a great ability to truly learn by using more games. It’s possible to make computers play against each other, collect the games, and in the process learn from each other.

SE: That gets really interesting because the training data set has to grow, and as it does it changes. The weights change, and designs may change from one industry to the next. What does that do from the standpoint of the tooling and the methodology?

de Geus: For starters, let’s look at what you have to design. These algorithms, which get applied to larger and more diverse data sets, are eventually computational statistical machines that need to run really fast. The statistics are relatively narrow in terms of computation. Ergo, the more you can in parallel deal with a lot of data, the faster you can make algorithms run. It’s not a surprise that as an intermediate step, graphics processors have had a strong ability to play in this world. Nvidia was a big beneficiary of this, as a developer of massively parallel machines, and it was a big step away from generalized computation. That’s the same as say, ‘If you want something to go fast, make it only do a few things.’ A corollary of that is the more you want to advance this, the more you will need specialized hardware aligned with the algorithms. The more you want to be successful in that domain, the more you need to collect the data in that domain.

SE: And the type of data you collect in that domain may be different from other data, right?

de Geus: It is very different. A car doesn’t care if a dog is a Chihuahua or a Rottweiler. The car is interested in ‘dog or not dog, kid or not kid.’ Doing umpteen studies about differentiation of dogs is not helpful to autonomous driving, although over time it may be. But the point is that if you move up the vertical market stack, the more you can specialize for it, the greater the chance of adding value to it. If you’re in the business of diagnosing imminent cracks due to vibration changes on an airplane engine, the term Chihuahua does not come up. But even then it’s hard to process all the data and figure out which data is useful. By the time you diagnose there may be a crack coming, you wish you could understand how the data came to that conclusion. Today it’s mostly incapable of telling you that.

SE: And that’s one of the big problems with data today. You don’t have the ability to go back and understand why an AI system made a certain choice.

de Geus: This is one of the Holy Grails of AI. I’m fine if it tells me that something is about to go wrong with the airplane. I won’t fly it. The ‘why’ is somebody else’s problem.

SE: So predictive analytics is step one?

de Geus: Yes, and remedial analytics is figuring out why this happened and which part of the vibration caused this problem.

SE: And that’s the basis of ISO 26262, where you have failover even if it’s to another system.

de Geus: Yes. If I read the stats on the plane that says 60% likelihood of a failure, I’m not going on that plane—even if there is failover. I’m enormously happy with the current achievements of AI, but we have a long way to go.

SE: We’re just scratching the surface. What does that mean for chip design?

de Geus: Unwinding the sub-routine, hopefully there are a lot of opportunities in silicon. At the very moment that silicon technology will advance rapidly, the techonomics are slowing down from a Moore’s Law perspective. We are sitting in the midst of that because we’re dealing with a lot of companies that design AI chips. We have an enormously positive impact on that these days. AI has different characteristics in the architecture of the chip precisely because of these massively parallel data streams and the need for very rapid computation.

SE: You also need to keep the data moving through that chip and all processors engaged, right?

de Geus: Absolutely. There is learning and there is interpreting. The learning gives you a hardware-driven algorithm—and implementation of a network—that is used to interpret what an object is. For that, speed is absolutely necessary because you need to have real-time data coming in. For the learning, it may be a question of how many months and how much data do you use.

SE: Are these the same companies you did business with in the past?

de Geus: No.

SE: What types of companies are they?

Photo Credit: Paul Cohen/ESD Alliance

de Geus: There are three categories. There are the companies of the past. They are very profitable and they have invested massively in AI. There are a whole set of new startups aimed at some set of algorithms. There, the tradeoff is whether you go for 10X with more generality, or 100X with less generality. That is a techonomics decision. And then the third category are system houses, which are sitting closer to end applications. They really want to be in the business of, say, interpreting pictures on their network of users. These are all the ones with deep pockets, high ambitions, broad reach, and they have to decide how deep they go into the specifics. Some have very deep, state-of-the-art design groups. Others do the architecture and then go outside for design. But those system houses have an aspiration upward for the economic benefit of AI.

SE: In this market, it’s a question of where you put your resources. For a lot of the industry, it’s turning into a giant matrix. There are multiple sets of companies in different but interrelated market segments, different horizontals, choices on node versus packaging. How do you deal with that?

de Geus: We purposely invested in the intersection of hardware and software a number of years ago. EDA is moving up to that intersection with chip design and system design, and the software sits on top of that. We have put massive resources at the intersection of simulation of software on hardware that doesn’t exist yet. It could be FPGA prototyping or emulation engines. We also decided to build a software integrity business, which allows us to do a variety of analyses on software that lets us look at the quality and security embedded into the software—or find out what’s missing. We’ve managed to grow that to the point where it is 10% of Synopsys. There’s embedded software, operating systems and application software.

SE: So what happens when you start changing the starting point for the design, shifting from hardware or software to the data? That data has to flow through at a very high rate. And what impact does that have on the tooling?

de Geus: There’s more attention spent on figuring out the optimal architecture. If you have a bottleneck in the architecture, you can’t just put this all data into cache. These architectures can be explored. If you change these ratios or buses and architectures and the amount of computation and external access to memory, what happens depends on all the parameters. Architectural tuning is becoming more important. But that’s another way of saying the traditional von Neumann machine is evolving to the next generation of machines, based on creativity of the people designing it. If I have this kind of data flow, what could I do to maximize this kind of computation? Once the architectures are designed, you may have an RTL description of a machine. That’s the perfect situation to say, ‘Why don’t I run some software on it.’ Well you don’t have a machine yet, but we can take that RTL-level description, do a prototype, and run it. And back to the notion of verticals, one industry that is embracing this by virtue of necessity is the automotive industry. Automotive has gone from software, which was at best an afterthought, to software as the greatest vulnerability, because cars have been hacked and because the trajectory is toward autonomous driving. It is becoming a completely different object.

SE: With automotive, they’re just now inventing the technology. It’s never been done at this level.

de Geus: What is different in automotive is the most sophisticated supply chain ever built. A car is the result of thousands of companies, literally, down to every bolt. If you are a car manufacturer, are you also a great bolt manufacturer? No. But are you going to drill down on the price of that bolt until it’s really small? Sure. Except there’s a catch. You need to do that with multiple suppliers that can provide the volume you need when you need it, and it has to be available for 19 years. So now you can see the word ‘software’ translate into the word ‘nightmare.’ You have to be able to do bug fixes on a 12-year-old car and still guarantee that it’s safe.

SE: And it has to be exactly the same as the replacement part. But now we’re dealing with different companies that may not have been involved in this industry. Some are brand new, and not all of them are going to survive 19 years.

de Geus: The person coming to fix the thermostat can’t fix it today. So they just put in a new one.

SE: So are we looking at modules that are just swapped out?

de Geus: That’s absolutely part of the design. But to do that you need a very sharp understanding of what’s in those modules. Just as importantly, you need to be able to verify that the new module works in the car that’s already been in your garage for five years.

SE: And it has to be characterized exactly the same way as the previous module, right?

de Geus: Yes. All of these are partially revolutionary, partially evolutionary. But to capture all the chips, the system, to build them, we as a tool set, IP and software provider need to play at all these levels. We have to do atomic-level simulation in the chip. You need to have quantum physics. The thickness of the layers is down to six or seven layers of atoms. To model that correctly you need to have a structure of atoms. But it all illustrates that it’s all getting more complex. You will only do advances there if you have breakthroughs, because it upsets the value chain in the transistor, which ultimately is IR. What’s the current? What’s the voltage? It didn’t get any better.

SE: How has all of this affected the type of people you hire?

de Geus: I’ve always argued we’re a six-deep Ph.D field. Over time, that stacks up for the older technologies because every lesson learned in the past is still applicable. Cross-capacitance was developed in 1997, but if you forget that today no chip will work. It’s this whole body of knowledge that you need to need to bring forward. Plus, all of these things are interacting. So you have to optimize systemic complexity, which is multi-dimensional on a matrix. In software, there are the same problems, but it’s governed less by verification. If you do a tapeout on a chip and you find some bugs, and it comes back not working, you’re out $5 million to $7 million in mask costs and time. For software, you send out a patch. The discipline has been less rigorous. But as software complexity increases, the statistics are against you.

SE: The tolerances are tightening everywhere, though. It’s not just the software. It’s the hardware, too.

de Geus: Not only do you have a Moore’s Law in hardware. You also have the equivalent of a Moore’s Law in software. And now you have the systemic complexity of the two being interdependent. We are going from scale complexity to systemic complexity.

SE: Where do you see potential problems?

de Geus: When you’re early in a field, you can do individual developments and optimization independently. You can do the architecture and then the RTL and then the layout. That works perfectly well. As things become tighter—more things, and things that need to run faster—you no longer can fix in the gate synthesis an architecture that wasn’t that great. And by the way, you no longer can fix software written with unbelievable misuse of energy and have the chip make it up. If you put an app on your phone that calls a GPS 30 times a second, which some of the early apps did, that’s a problem. The GPS does an enormous amount of calculations, and battery life went straight down. If you’re looking for parking spot, you don’t need that kind of speed. Since then, the indendence of the steps gradually went away. We have recently introduced a quite radical step forward with Fusion, which will be our development platform for the next 10 years. When you synthesize something, it’s hundreds of algorithms that figure out how to best do something. What if all of these were also available in this tool, and you have a data representation that can go through the whole thing, and in addition to synthesis and place-and-route we can also throw in the timing and the power. Now we have an opportunity to look at these as one mega-tool platform, where a number of the algorithms are interchangeably used. That has two benefits. First, the tool understands optimizations the same way. And second, you can reduce the problem where an algorithm goes in one direction and then you need to correct it. We introduced Fusion Compiler, which is synthesis, place-and-route, and the signoff (timing) all in the same tool.

SE: What holes does this close up?

de Geus: You want each step to be better. So if we’re loading bricks on a truck and we’re too slow, we can go to the gym, get stronger, and then we can load the bricks faster. But we miss the fact that every time I hand you the brick I open my hands and the brick can drop. The previous rule has to work at exactly the same as the next one, and if one of those is not running at the same speed there’s a big problem.