Experts At The Table: Next-Generation IP Landscape

First of three parts: Subsystems-on-a-chip; partnerships; demands on IP suppliers increase; last-minute changes and quality requirements.

popularity

By Ann Steffora Mutschler
System-Level Design sat down to discuss predictions about the next generation design IP landscape with Robert Aitken, R&D fellow at ARM; Laurent Moll, chief technical officer at Arteris; Susan Peterson, group director, product marketing for verification IP & memory models in the system & software realization group at Cadence; and John Koeter, vice president of marketing and AEs for IP and systems at Synopsys. What follows are excerpts of that conversation.

 

SLD: Where is the industry headed with IP? There appears to be a lot of movement towards subsystems as IP integration gets more and more challenging.
Koeter: We see this in spades. People want to integrate our IP into subsystems, and the IP integration task is a challenging task. One of the ways we are addressing it at Synopsys is we’re coming out with these IP subsystems that we believe are the next big evolution in IP. So what is an IP subsystem? There are many definitions of it. From our definition, it’s configurable hardware, it’s a verification environment, the transaction-level modeling environment, it’s software that runs on top of it, which is easily as important as the hardware, and it’s also a prototyping environment. A while back we introduced one of our first subsystems—the audio subsystem—which was a complete subsystem having all of those attributes.
Moll: We have customers all the way from people who just assemble chips from IP all the way up to people like Qualcomm, who have very little IP in their chips if anything, although they have a lot of internal IP. But they don’t buy IP. They tend to have a different vision of what IP is—external IP versus internal IP. In these extremely heterogeneous things, while we do see a lot of subsystems happening as the next big thing, because it’s basically ‘subsystems-on-a-chip’ now—it’s not system-on-a-chip—there are a bunch of subsystems hanging together. There are people who will buy a whole subsystem or make a whole subsystem from a team somewhere. There are also people who are very hybridized in terms of building a subsystem out of some pieces of external IP, some pieces of internal IP, and that becomes an internal subsystem. One of the difficulties is dealing with the transition phase of dealing with both external IP and internal IP, because the two can look extremely different. For instance, with internal IP a lot of people still have a lot of different protocols internally. ARM has done a great job with AMBA. People who just start a design today who have no legacy, they might go 100% AMBA. But that’s just not the case for most other big companies that still have a large legacy of other things. Bridging all these things we see as one of the biggest challenges, and at Arteris, in our tools we are specifically trying to address this by trying to interoperate with anybody’s protocol.
Aitken: We see similar things. The platform is a big issue so we’ve been working on those for several years. This is something that isn’t necessarily sold as a product but is sold as a reference. ‘Here’s a way of putting together multiple cores. Here’s how they interact with the AMBA. Here’s how they talk to the cache. Here’s what your cache could look like. Here’s how all of that connects to the graphics.’ There’s a lot of stuff out there and people want to have more and more of it taken care for themselves so that they can differentiate and say, ‘We don’t care about these things. Please provide them for us. We don’t see building that ourselves is necessarily our way forward.’ That is likely to continue in the future as chips that people are building are becoming more and more complicated. They really can’t afford to be experts on all of these subcomponents. They’d like to have the subsystem built up for them. The other thing that I wanted to touch on is how that interacts way down at the bottom, at the physical IP level, because the libraries are required to hide more and more information inside themselves so that nobody really cares anymore what the guts of a standard cell look like. It’s just, ‘Please give me a library and I don’t actually even really want to see it. Just make it do things for me. Make it interact with the rest of the IP so that when it synthesizes, things don’t break and so on.’ Essentially, the complexity of the SoC is driving people to do more and more high-level activity and as a result, have less and less time for lower-level activities. They just want the IP vendor to provide that for them to make their life easier.
Peterson: Reflecting on the keynote addresses at MobileWorld Congress this year, and they were all very technical, ‘Oh, we need finFET and we need this and we need that..’ As I sat in the audience I was thinking about the fact that today, and even more so in the future, requirements for devices like these phones and laptops and all the devices we have in our hands are being driven much more directly by a different end user—your kids, your grandkids, your parents. They are the consumers of this technology and they know what they want. So the fact that they know what they want means companies like Samsung and Apple and now Facebook and Google and Amazon, who are developing these devices, have this really rapid spin. All these years we’ve been in EDA we’ve thought time to market was critical. It’s nothing like, ‘time to back-to-school market,’ ‘time to the new car show.’ This is ‘time to consumer.’ These are real demands with multi-billion dollar impacts if you don’t meet that. Number two, that consumer’s demand for quality is much different than the technologists that we’ve sold to in the past. My concern in the future is that that customers who we’ve traditionally sold to, some of the larger semiconductor manufacturers—even though we’re doing things like application-optimized subsystems, which is our term for subsystems or bigger pieces of subsystems that glue things together—these new, next-generation companies such as the Apples and the Facebooks of the world don’t have the huge infrastructure that some of these semiconductor companies have for gluing together an SoC. One of the reasons that Samsung and Apple are dominating the mobile market right now is that they’ve figured out how to rapid cycle. Application-optimized subsystems that are really high quality, which can be customized to particular applications really quickly—that’s going to be a huge demand in the future. As IP developers and vendors, the onus is on us to provide that IP. But it’s also on us to help our customers help their new customers, who have very different demands than our customers have had in the past.

SLD: What’s interesting is that all of you as providers have a huge opportunity and a challenge to figure out what the consumer is going to want and how to get the IP to the developer fast enough to really leverage the opportunity. How do you stay on top of that?
Koeter: The ‘tier ones’ are outsourcing more and more IP these days. In fact, now the top 20 semiconductor companies in the world represent 50% of our IP revenue. When you’re talking about dealing with the biggest people in the world, they are the market makers and the market movers. When you’re working with them and partnering with them, you get a very keen insight into where the markets are going, the features they find valuable whether or not they are incorporated in the specs or not, for example. For us, it’s a matter of working very, very closely with key market-making customers, as well. I have a very large team of marketing people who spend all of their time worrying about future standards, working with key partners like ARM, for example, to understand where the directions are going. We do a lot of customer roadshows, so we are constantly talking to customers, sharing information with them and getting information in return.

SLD: What about the aspect of making sure if they want you to develop IP for them, making sure the resources are there to do that? How do you manage that when you have other customers to support?
Koeter: What we’re doing right now is regularly developing IP on 0.1 PDKs because that’s what the market demands. If you want to engage with the largest of the large, it’s not just a build-it-once on a 1.0 PDK and sell it many times. You need to partner with those guys, you need to have an expectation of a lot of churn early on in the process development cycle, and you have to be prepared in resource to do it. That’s one of the reasons why scale is so important in this business.

SLD: What about for a startup?
Moll: One of the reasons Arteris is successful right now is precisely that people just don’t have time to make chips anymore and we are extremely configurable. We do see the marketing dictates to the architect two weeks before RTL freeze that there will be two more memory channels on the chip, and all hell breaks loose. The way our tool is structured allows them to do this. That’s why, for instance, people like Qualcomm or Samsung use us, because they know that’s going to happen and they know that if they have a team that’s working in a silo for two years delivering something, it’s just not going to work. It’s a little different at our level as we are really the assembly tool. We get the last-second change all the time. In addition to talking to our customers, seeing what’s going to happen—is it Wide I/O, is it cache coherency—all the system features that we have to integrate, that takes time for us to get in. We also have to be flexible enough that we will have to deal with the last five spec changes within the last month and are able to deal with this. Even after the first tapeout, they’ll do 10 derivatives and those derivatives all just turn the crank as quickly as possible. To do this you have to be able to readjust very quickly. For that particular portion, at least, extremely configurability is a necessity. Otherwise it doesn’t work in that crazy cycle of people doing things very quickly.



Leave a Reply


(Note: This name will be displayed publicly)