Aart de Geus: Grand Challenges in IP
June 8th, 2017 by Peggy Aycinena
This is fourth in a 4-part series on Grand Challenges in IP. Previous dialogs featured Sonics CEO Grant Pierce, CAST-IP Board Chair Hal Barbour, and Silvaco IP Division GM Warren Savage. This final, lengthy conversation is with Synopsys co-CEO Aart de Geus, winner of the 2008 Phil Kaufman Award.
To say Aart de Geus is synonymous with Synopsys, an organization he’s led for over 30 years, is not an understatement. His entire professional zeitgeist is wrapped up in the company. Neither is it an understatement to say de Geus is always on-message, always on-point. The interview below is no exception.
Dr. de Geus’ vision of Grand Challenges in IP is informed by the daily, working realities of the needs of the customers that constitute the IP market, and an IP vendor’s evolving response to those needs. We spoke by phone on June 1st.
A marathon of sprints …
“The idea of Grand Challenges is a popular one with academics,” I began, “researchers attempting to discern where technologies will stand 5 or 10 years out and crafting their programs accordingly. As an industry leader, what do you see as the Grand Challenges in IP?”
“The challenge of Grand Challenges?” de Geus responded whimsically.
“Obviously, in hindsight, we’ve climbed some enormous, big mountains. It’s remarkable what we’ve done. By overcoming thousands of little challenges, each of which may have become a Big Challenge, the result has been the continuation of Moore’s Law.
“If you had asked this question in the early 90s, people would have said: We are getting to the end of lithography, this is the Big Challenge of our time. Or they would have said: That’s it, there is no solution.
“Of course, the most advanced chips at 7 nanometers today are being manufactured on the exact same lithography principles of the 1990s. How is that possible?
“That impossible Grand Challenge did get done through improvements, refined over and over again through engineering innovation.
“Similarly, when they asked – Can you put a man on the moon – the problem was decomposed into multiple smaller challenges: Create the rocket. Create a rocket that can fly to the moon. Don’t kill the guy in the rocket. And, the O-rings have to be vacuum proven. Recall, the assumption that a single O-ring failed [in the 1986 Challenger disaster].
“The truly amazing characteristic of our field – which I noted just this morning while talking to a crowd of Wall Street guys – while we have made 10-to-the-12th-or-13th range improvements, we have also had to be backward compatible with everything we’ve learned on the journey.”
“You could say the Big Challenge is [combating the impression] that Moore’s Law is really dead. Imagining anything smaller than 7 nanometers [was deemed impossible]. Yet today people are working like crazy on 4, 3 or even 2 nanometers.”
“So that is the first Big Challenge in our industry,” de Geus said. “Please continue to run the marathon, while remembering that every mile of the marathon is actually a sprint.
“And that’s what is so extraordinary. We’ve done a sprint of marathons [over these last decades]. We‘ve looked at problems that were really difficult, decomposed the problems, worked like crazy, innovations were made, and then we made sure it all worked together.”
“Your optimism implies this industry can accomplish anything,” I noted.
“Not accomplish everything,” de Geus responded, “but many things declared as impossible have subsequently been done.
“Moore’s Law is the single best example ever in the history of mankind. The notion that Moore’s Law is dead [is often discussed]. I myself have given the talk many times on the same topic: How to rescue Moore’s Law.
“But Moore’s Law continues.”
Vectors of complexity …
Returning to the specifics of Grand Challenges in IP, de Geus said, “When I look at IP, I look at four vectors of complexity.
“First, generation after generation, IP is growing in complexity and USB is a great example. USB 1, 2, 3, 4 – each one is a massive increase in complexity. And the same is true for processors and graphics cores.
“Second, now multiply that growth in complexity when going from 28 nanometers to 22, 16, 14, and 7 nanometers. And by the way, switch from flat transistors to finFETs in the process. More unbelievable complexity.
“Third, the IP cores. We think of them as hardware pieces, but the amount of embedded and directly connected software [associated with those cores] is growing by leaps and bounds. More multiples of complexity.
“Fourth and last, but not least, a growing set of new constraints, new standards. And they can range from open-ended – how to make something secure – to something for characterization – how to make it ISO 26262-compliant, for instance.
“And because none of these [constraints] make it any easier, they further multiply the complexity of the other stuff.”
“Why would anyone want to be involved in all of this?” I asked. “It sounds unpleasant and very stressful.”
Aart de Geus chuckled, “Yeah, but in the evening after a day facing these challenges, it’s still wonderful to be alive.
“You could ask: Why do people run marathons? The runners look to be in great pain. But it is the nature of human achievement to do the things you don’t want to do.”
Are standards really Grand?
“Is it within the realm of Grand Challenge,” I asked, “to provide certifiable worthiness for a block of IP. A ‘Good Housekeeping Seal of Approval’ that guarantees a block purchased for a design will function as advertised in that environment?”
Reiterating the critical nature of standards, de Geus said, “Both as a society and within the context of IP, we’ve done remarkably well in nailing down standards. Leading people in the [various] areas get together in a pre-competitive space to ultimately agree and sign-off on the next generation standard.”
“Then someone drops it off in the IEEE mailbox,” he chuckled, “and it gets signed off.”
“For instance, what defines a USB? There are whole telephone books of specifics, so that when you plug [the USB device] you bought from somewhere else into your computer’s USB socket, you actually expect both sides to honor that standard.”
“But do the issues around establishing and maintaining standards actually rank as Grand Challenges?” I asked.
“The Grand Challenge,” de Geus countered, “is the intersection of these challenges.
“The context is changing with unbelievable complexity, just as the nature of silicon is changing with unbelievable complexity, and the software content is growing unbelievably. And all of it, by the way, has to work in a car and meet current safety standards.”
Organization is key …
“What you describe sounds as much an organizational challenge as a technical challenge,” I noted, “getting the many different teams – hardware, software, device physics, automotive systems, etc. – to work in sync.”
“Yes, that is absolutely the essence,” de Geus said, “and compares [in difficulty] to the Man on the Moon Project.
“Yes, it was hard to get the fuel right, the O-rings right, and so on. But making it all work together, and getting those guys safely back from the moon, was astonishing.
“The individual problems in that case were difficult, but the organizational challenge was even harder.
“Which is why, on my closer slides in keynotes, I often say cooperation is actually one of the most differentiating [features] of successful projects and companies.”
“How do you get that cooperation?” I asked.
“What you have to do,” de Geus replied, “is set a common condition and direction for the project.
“Because, when people say [their portion of a project] is going to be well-delivered – a great rocket fuel, or a great landing pad – it’s very different than when the group together says: We are going to put a man on the moon.
“Nobody ever wants to fail the team. For a super good basketball team, if a prima donna does everything, the team will not win.
“It’s about the notion of a common direction, a common ambition. That’s the word I like to use.
“The quality of the decomposition of the problem and the intersection [of the different disciplines involved] is essential, and at the heart of what great engineering has always been.
“Once you decompose the problems, you have two things: You know how to do the pieces, and you know how to make those pieces work together. That’s an important process.”
“Does Synopsys have some sort of handbook,” I asked, “or a series or organizational binders, that show team leaders how to do this? Or is each project a one-off effort?”
“The first form of what you are describing is called the Org Chart,” de Geus said.
“There’s no attempt from the head of HR to do code, or for coders to run HR. We’ve put people into the box appropriate [to their skills].”
Start with architecture …
“And for the chip,” de Geus offered, “it is exactly the same.
“The architecture is so important. If you start with a bad architecture, everything becomes much harder.
“Consider, if you start to architect your house and put the kitchen at one end and the garage at the far other end, nothing can be done to remedy the problem of having to carry the groceries through the entire house.
“Such fundamental architecture decisions are equally important on a chip,
“If you do processor design, everyone knows to put the cache as close as possible to the compute [element]. Otherwise, no matter what you do, you’ll always have to carry the cached data – the groceries to the kitchen. This is a simple example, but a very true one.
“Architecture, fundamentally, thinks through the macro trade-offs, which in essence says the architecture understands where the hand-offs need to be.
“It’s not all that different from a good basketball coach saying, make sure the guy on the left always gets the ball at the right moment.”
The move to sub-systems …
“Which brings me nicely to the next Big Challenge,” de Geus continued.
“Let’s say you have some really good IP blocks, but will they play together easily and predictably? Or are there sources of contention, where they could stop each other [from functioning]?
“For instance, the multiple IP pieces all want the bus to themselves at the same time, so the architecture should know [how to resolve that conflict].
“Therefore, when you develop pieces of IP, more and more we’re seeing the combining of those individual pieces of IP into sub-systems. The architecture says the behavior of those individual pieces might vary in different environments, so developing sub-systems [solves that dilemma].
“In essence, the designer pulls the whole kitchen out of a catalog, with the option of choosing between the dishwasher or the fridge being on the left. That flexibility is important in choosing the correct form of the kitchen sub-system.
“Similarly today, semiconductor IP and sub-systems come with a degree of configurability that can be adapted by the designers [to the needs of the design].”
Trust as tangible asset …
“There’s one more thing that’s a particular strength for Synopsys,” de Geus enthused, “which is relevant to designing good kitchens or good chips – and that is trust. Trust is absolutely essential.
“Many things can go wrong, even with good IP, so you have trust the people who sold the IP to you. Trust is for the things that don’t go right – you have to trust the IP supplier will jump in and help you.”
“I always like to say, both IP and chip design are equivalent to an organ transplant. Yes, the tissue match has to be correct for organ transplants – just as the pieces of IP need [to match] the bits on the bus – but having a really good surgical team is critical.”
“For Synopsys that means half of our IP business is a product business and half is a service business. This is more and more necessary, just as it is with complex organ transplants. Our team is critical to the success of our IP.”
“So when things don’t go correctly with a block of IP in a customer’s design,” I asked, “what do we do?”
“It’s the same as any other business situation,” de Geus said. “You work your butt off to avoid that situation, but if it develops we move to the next step.
“We ask if there are any constraints that can be relaxed [to facilitate the IP functionality in the design]. For instance, can we make it work with a little more power?
“It’s not that the functionality is not there in the IP, but everything is driven to the upmost in terms of the design spec. If the customer wants 3 megahertz and only picowatts in leakage, obviously changing those numbers in the design [to accommodate the IP] may make meeting the specs impossible.
“More often, however, the customer doesn’t know exactly what is feasible, and they set a high ambition.”
Invoking the earlier analogy, de Geus said, “The high ambition is to go to the moon, but first we need to get to space. When the ambition is fully understood, we like to say to customers: There is a solution.”
Ambition crisply defined …
“Does it sometimes require brutal candor on your part to tell a customer their ambition is poorly thought through?” I asked.
“That’s a great question,” de Geus said.
“An IP supplier needs to say to the customer, here is the degree of difficulty [associated] with your expectation. The customer needs to understand the reality of achieving their end result, their end ambition.
“One of the ways we try to protect both parties against over-exuberance is an increasingly sharp definition of the deliverables, and the conditions under which they should be working.
“The customer may say: I don’t need this or that. Perhaps they say they don’t want to buy the verification package. But when there are problems, low and behold, they do need the package.”
“It’s a learning curve for the first-time customer?” I asked.
“Yes, that’s the essence,” de Geus said.
“In any good relationship, you never give up on somebody. Instead you try to say: Next time we will be in a better spot to work with that customer.
“People can get really hurt [by candor], but a good working relationship is a learning relationship. And out of this comes our statement of work, the contract between the IP supplier and the user.
“The customers appreciate this contract because, with few exceptions, when we ask them to read the five conditions in the contract, they say they didn’t know these things and are thankful we’re more specific about these conditions.”
“The contract aims to over-specify to remove any ambiguity?” I asked.
“Exactly,” de Geus said emphatically.
“Over-specification is not sufficient, but often necessary. In a good team effort [between supplier and customer], specification is called practicing together.”
Not competing with customers …
“How does an IP supplier reign in their own ambition,” I asked, “when it looks like they might inadvertently end up competing with a customer.”
“In the late 1990’s,” de Geus noted, “I remember telling the CEO of one of our top customers [about a new IP product]. His first reaction was to ask what we were doing, and to suggest he would call his legal team.
“Initially, there was this risk that we were going to step on the toes of our customers, but we’ve learned over the years. If you do what your customers are doing, [there is a potential problem].
“We also learned, if you do what your customers should do less of, and they can therefore move up to higher levels of the value chain, that is the natural evolution of an industry.
“For us, it’s important to have a reasonable feel for this, and to honestly articulate to our customer how what we are offering is not competing with their offerings. It’s crazy for a customer to do a USB 3.2.1. They’ll get no differentiation and their best designers will be wasted.”
“It seems like a complicated choreography,” I observed.
“It’s not complicated,” de Geus corrected, “if you have the right principles. Think of the customer: If you were their CEO, what would you do?
“You would look at the IP you could actually buy, and ask if the price is right. And if the price is right, you’d know you could take your best engineers [working on a similar block in-house] and re-assign them to something that would provide differentiation.
“If we can put ourselves in the shoes of our customers in this way and do the right thing, we’ll be more successful and [guarantee] our most important long-term asset – the trust of our customers.
Customers who compete …
I asked how de Geus’ organization navigates between customers who are competing on products, all of which contain IP from Synopsys.
He answered firmly, “By definition we serve a customer base that competes with each other. We cannot intermingle the knowledge [we have of the projects] between these competing customers.
“And as a supplier, you never want to be in a situation where the customer asks you to send the plans of another customer. Over the years, we have learned a number of skills and practices [to prevent this], and have extremely precise agreements to stop this from ever happening.
“But as with all such things, policing gets you a long way. If stealing is not okay, put locks on the doors. But first start with an attitude that prevents [the behavior] in the first place.”
Elaborating, de Geus added, “There is a second aspect to this issue, and it runs along a different line of thinking. In a bike race, when you have those breakouts with just 4 or 5 riders, there’s a good chance one of those will be the winner.
“We tend to run with people, customers, who want to run the fastest. In practice, there are only a limited number of people who do such advanced development, so we try to [foster] those relationships.”
Losing IP to theft …
“Do you ever loose sleep over IP that’s lost to theft, either during a customer’s design or during the manufacturing phase?” I asked.
“Those scenarios rarely occur in that fashion,” de Geus answered with confidence.
“And reverse engineering is an extremely difficult thing to do. If you can do it, good luck, is what we say – but you’re not a winner if you do it.
“Can the manufacturing process produce something [in the chip] that wasn’t there in simulation? Yes, but again, it’s a matter of trust to discover what occurred.
“If the customer gets the chip back and it doesn’t work, we and the customer want to know why. Is it the IP or the intersection of the IP with something else?”
Emphasizing his organization’s commitment to the customer, he added, “In some cases, it was our IP and sometimes it was their design. But we are happy to be partners with our customers and want to work hard to make sure it doesn’t happen again.
“We’ve had experiences where it has actually cost us way more than [we earned on the project] to work through these things.”
“It’s the engineering mindset more than the technical issues that define success for an IP supplier?” I asked.
“Yeah,” de Geus confirmed. “When you have the right intent and right skills and right smarts – and you have the right direction – stuff can happen, but we always keep trying to work on our customers’ behalf even so.”
Commercially viable IP …
Picking from my own list of Grand Challenges in IP, I asked, “How does a block of IP emerge as an obvious target for commercialization?”
“It’s never straightforward to say: Here’s a block that’s going to make it,” de Geus said. “Like with any other business endeavor, you have to know when a customer will go for that new block.
“But then it becomes trickier. Should we wait until 5 or 6 customers are ready to commit over the next 6 months, even if there’s already one customer who is willing to be first? Or will it be too expensive if we have to wait [for more customers]?
“We have a number of customer partners who see benefit in being early, and other who see benefit in waiting. This is the money-time-risk assessment that the GM of the IP division has to do all the time.
“The challenge of knowing the exact timing for [introducing a block of IP] is not simple. For instance, we invested a number of years ago in a Bluetooth product, but only many years later did it finally blossom.”
“An acquaintance who is a senior executive in the fashion industry,” I offered, “says buying the right products for an upcoming retail season is a difficult one. It can often prove disastrous if the buyer guesses wrong about upcoming fashion trends. Is there a similar phenomenon in the IP business. Are there fads in the IP industry?”
“It’s my understanding,” de Geus said, “that there’s a meeting of the top fashion designers every year where they decide what will be the key color for the next year.
“Is it going to be emerald green? If you decide as a buyer to plan for a summer of mauve, you may find that nobody will buy your stuff.
“That’s why industry alignments are so important. They are a form of alignment, not by accident but by proclivity. The fashion guys [decide] together what will be the color of the season.”
“In the IP business,” de Geus added, “it’s just of the opposite of a fad. [Trends] must appeal to something that has logic.
“I’m not a fashionista, but if you are a somewhat fashion-conscious person you don’t want to be in yesterday’s color. On the engineering side, it’s even more forceful.
“If Apple decides to go with USB 1, you’re toast if you don’t support it as an IP supplier. If the big names in the fashion industry say it’s emerald, you’re toast if you don’t support it.”
Leading the ecosystem …
“Does Synopsys speak as a leader in the IP industry?” I asked.
“First,” de Geus responded, “we have the privilege of being close to many of the people who really are the top fashion designers in the IP industry.
“Secondly, we are active on the committees that drive new standards and, of course, we interact constantly with the people who are the drivers of those committees.
“And we have a little bit of an acid test: As a customer, are you going to pay for early access [to a new product]? Are your demands real or not? We know that some people ask for information with no intention of commitment. They’re trying to find out the future and they are diplomatic, but they’re not willing to pay for the knowledge.”
“It sounds like a complex feedback system,” I said. “The customer’s needs. The technology advancements. The supplier’s risk assessment.”
“Yes,” de Geus agreed, “it’s sophisticated and there are many dimensions to this feedback loop, including knowing when something is ready to go to silicon. A new technology node, for instance, cannot go to market unless the IP at that node is ready.”
I reminded Dr. de Geus that he was profiled in a 1996 issue of IEEE Spectrum, where he mentioned even then that IP was going to be very important to the future of the semiconductor industry.
“By the 1990s,” he said, “I was using the analogy of the Lego block. As Lego blocks have become even more complex, the Lego company has evolved by providing more and more complex Legos.
“In the early days of EDA, the lowest Lego was the transistor. The breakthrough was assembling 4-to-6 transistors into a gate. Gates became flip-flops, and then a register, and then a processor and a controller – always following the same principle.
“You can increase productivity if you can deal with higher and higher levels of abstraction, and still trust what’s built underneath.
“Now, if you say you want a kitchen [sub-system] in your design, it’s understood to include a freezer, a fridge and a stove – and it’s all described in the catalog. But if you said you wanted a kitchen in the 1940s, it perhaps only included running water and a stove of some kind.”
Pricing as Grand Challenge …
“Yes, pricing is a Grand Challenge for everything,” de Geus said in response to my next question.
“You can do supply and demand and you know the customers, if in deep need, will pay more. But if you do that, you are not investing in the relationship.
“The key to pricing – it has to be reasonable for both sides over the long-term. If you were in your customer’s shoes and you had to buy this IP, what would be the reasonable price. As suppliers, why would we advocate for something else?
“We want the customers who work with us to be more successful than those who don’t. It’s about credibility and, as we’ve just passed 30 years as an organization, I think we’ve succeeded.”
Reiterating de Geus’ earlier sentiment, I asked, “So trust is even more important than the price of the IP?”
“Yes, I do think so,” he answered.
“If the organ transplant is not good, the doctors don’t say to the recipient that they’ll replace it with something else. If the kitchen breaks after the house is built, it’s almost impossible to replace it with a different kitchen.
“It’s the time involved in replacing a block of IP – if that were even possible – even more than the money. Remember, our horizontal axis is time in this industry, but the vertical axis is market share.”
One ecosystem to rule them all …
In closing, Aart de Geus revisited the critical importance of the ecosystem: “When we look at the ecosystem, it includes the foundries, the libraries, and so on.
“And it gets even more complex as every block is growing into bigger and bigger IP. At Synopsys for instance, we now offer several sub-systems.
“But it’s not just about what kind of IP you pursue [as a supplier] and it’s not just about the customers, but the entire ecosystem which is serving the end-system client. The architects, the designers, the IP suppliers, the software guys, the foundries – everybody is moving up the value chain.
“But that does not impact the minutia [that needs to be attended to] to guarantee the quality and verification of a system at the functional level.
“Consider that everything is coming from this super nova in IP and its importance to design, and understanding how all of it works in the larger ecosystem.
“The complexity of it – this is the ultimate Grand Challenge.”
Since co-founding Synopsys in 1986, Aart de Geus has expanded Synopsys from a start-up synthesis company to a global high-tech leader. He has long been considered one of the world’s leading experts on logic synthesis and simulation, and frequently keynotes major conferences in Electronics and Design Automation.
Dr. de Geus has been widely recognized for his technical, business and community achievements with multiple awards, including Electronic Business Magazine’s “CEO of the Year,” the IEEE Robert N. Noyce Medal, the GSA Morris Chang Exemplary Leadership Award, the Silicon Valley Engineering Council Hall of Fame Award, the SVLG Lifetime Achievement Award, and the Phil Kaufman Award. He serves on the Boards of the Silicon Valley Leadership Group, Applied Materials, the Global Semiconductor Alliance, and the Electronic System Design Alliance.
Tags: Aart de Geus, Grand Challenges in IP, Moore's Law, Synopsys