Make Vs. Buy

With system-level planning and estimation tools giving engineering managers insight into designs earlier than ever, it’s increasingly obvious which pieces of IP need to be acquired or internally sourced.

popularity

By Ann Steffora Mutschler
The confounding ‘make versus buy’ decision is understandably muddled by design complexity. Millions of gates, thousands of blocks, dozens of cores, plus software, packaging, and worries about physical effects don’t make this decision any easier.

In some cases the process can be simplified by mandating that anything that doesn’t add differentiation really is an IP block, and as such, it should not be built in-house. The exceptions, of course, are large fabless semiconductor companies that have an internal IP group, and which can amortize the development costs across a large number of chips.

Alex Haggenmiller, director of central R&D at Lantiq, a developer of SoCs focused on next-generation networks and the digital home, said his company has a simple rule: “The one rule is everything that is standard and where you do not have to expect major changes, this we will license. USB, PCI, DDR—this is not worthwhile to do in-house because we don’t have many analog designers.”

Also, if the company does not have expertise for a particular IP it needs, and that available from a third party, it will be licensed, he said. “But if we see that we can differentiate on one or the other IP, and we have the know-how, then we will do it in-house. For example, a T PHY, a 10/000 or 1,000 Gbit Ethernet PHY, where you need to embed this and from a power perspective be very attractive, then we will do this in-house. The prerequisite of course is always that we have the know-how, because if you have to build up the know-how and then do an in-house development you lose too much time.”

For standard IP, Lantiq’s goal is to go 100% with external providers.

Depending on the user category, however, the reason behind the “make” decision can vary, said Kalar Rajendiran, senior director of marketing at eSilicon.

For a foundry, foundation IP such as basic standard cells, standard I/O, and memory-bit cells are core to their business. Second-tier foundries may decide to hire companies to build more than foundation IP for them because the third-party IP companies are busy developing IP based on top-tier foundries’ processes.

When it comes to semiconductor companies developing (n+1)-process-based products, because foundries are very tight-lipped about openly sharing technical information on their very leading edge processes, third-party IP companies are unable to develop IP for these processes early on. So these semiconductor companies work directly with the foundries to develop the required IP. Sometimes they hire third-party companies as contractors to develop IP for them. Because they are always staying at the very leading edge, they maintain an in-house IP development team, if not for developing the entire IP set, at least to manage and interface with the third-party IP company that is on contract.

Then, for companies developing products based on exotic-processes, Rajendiran noted that because there is not a large market for this kind of IP, it is difficult to convince a third-party IP company to develop this IP. So these companies will end up developing IP on their own or by hiring a contractor to develop it for them.

For all other users, buying from the broad third-party IP supplier base is what will make sense, he said. If some customization is required, the customer is better off negotiating an IP customization contract with an IP company or a value-chain producer. The difference is that with a value-chain producer, the customer shares the common goal of taking the IP into volume production as part of their ASIC or ASSP whereas with an IP company, which just agrees to customize the IP, the contractual responsibility typically ends when the IP is customized and the design database is delivered to the customer.

Particular market segments can make a difference too. In the mixed-signal arena, there is a significant move to outsource a lot of IP thanks to modern SoCs, which contain a high level of complexity in the interfaces, said Neil Hand, group marketing director for Cadence’s SoC Realization Group. “This means there are complex interfaces involving high-speed SerDes, analog front ends, and all kinds of mixed-signal IPs that are particularly sensitive to the design they are going in and require special skills. So then you ask, ‘Do I build out my own expertise to build this or just go buy the IP? When it doesn’t work, do I have the expertise to fix it?’ If I’ve got third-party IP, its the vendor’s responsibility to resolve the problem.”

Sonics’ Jack Browne agreed. “The make versus buy question around a microprocessor—MIPS, ARM, Tensilica or ARC—is really about the software and ecosystem and what you are trying to accomplish with it. The real make versus buy is what it costs to build your own ecosystem for a processor. Everybody needs software tool, compilers, debuggers and you can get a lot of that open source.”

With approximately 20% of designs today in the 100 million-gate range and above, interesting challenges are emerging for IP, EDA and software, observed Navraj Nandra, senior director of marketing for analog and mixed-signal IP at Synopsys. “From the IP side of it, customers are expecting ready-to-go blocks that are fully verified in the latest technologies. And for many customers, they’ve already gone through this make-versus-buy transition because they’ve realized in their design team in order to put together a 28nm, 100 million-gate chip it’s going to take a big design team comprised of design engineers, verification engineers and software engineers.”

Overdesign contributes to decision-making
It is safe to say that many – if not most – SoCs are overdesigned today. But what is the impact on the cost equation? Cadence’s Hand questions what the cost of overdesign is versus the cost impact of underdesign? “Right now, if you tried to design to the limit you have two impacts. First, if you get it wrong, you’ll miss the market and you’re no good anymore. Second, you may be limiting yourself in terms of how widely you can apply something.”

In that way, Hand says overdesign is necessarily a bad decision. “Overdesign may be the most cost-effective way of getting somewhere. Let’s say you need to get to a point as quickly as possible. If you’re not really worried much about power or squeezing every last drop out of the system, you can drop a much bigger processor in there, do a sloppy job on software, get to market sooner and maybe increase the cost of your device by a few pennies. I’m not saying people should do that, of course.”

Preferring to call ‘overdesign’ by a more user-friendly term, ‘redundancy,’ Synopsys’ Nandra explained that pressures leading to redundancy are the ability to make sure the design will work in different cases, along with the ever-daunting time to market.

“These chips are going into product lifecycles of a year at most, then the next generation comes out. Basically, they’ve got to work right off the bat. If you’ve got to go through another re-spin and fab cycle, you’re going to lose your market window. That’s where overdesign or redundancy comes in. What you’re trying to do is cover your bases. If the memory compiler doesn’t quite yield in this new technology, we’ll put lots of redundant bit cells in there to make sure that at least we’ll get this block to work in production. What you’ve done is halved your risk, but you may have increased the area. The overdesign happens to solve some of these challenges of yield, but you don’t always get an optimum design in terms of area or power consumption.”

Here is where the chip planning, IP management and architectural analysis tools promise to give greater visibility into what is being built, improve predictability, and give the cost perspective up front.

For now, the make versus buy decision is no easier than it has been in the past due to complexity. But pulling in data from early in the tradeoff stage can help not only with architectural decisions but shining light on the cost equation, as well.