Licensing Interconnect IP for Fun & Profit

“Build or buy” is an age-old question. But here’s another one: Why do you even license IP?

Nobody builds their own Mercedes-Benz from scratch. Even if you’re a third-generation, dyed-in-the-wool automotive engineer from Stuttgart, you still won’t build your car. You buy it.

And why do we buy instead of build? Because the guys at the factory know what they’re doing. They are more experienced, have better tooling, and their product comes with a factory warranty.

So, what can we learn from these businesses, if anything?

It’s that even engineering teams need to reconsider the old make-versus-buy decision. Business principles teach us that we’re supposed to focus on our value-add and leave the other stuff to third parties.

Another consideration in the buy vs. build discussion, can we save money — or better yet, make money — by using outside technology instead of developing it in-house? There’s no easy answer to that question, so let’s look at the numbers.

The big question then becomes, which parts do we design in-house, and which do we bring in from outside? That’s a whiteboard architectural discussion, which can be heated and emotional. Engineers want to build stuff — that’s what they do. Managers want to get a working product out the door as economically as possible — that’s what they do. If the engineers want to make, and the managers want to buy, who wins? Who gets to make that call, and how do they justify the decision?

Financial models, medium-sized project
Let’s go to the financial models. As Figures 1 and 2 show, we’re going to examine the financial implications of a medium-sized system-on-chip (SoC) project. (Time-to-market and risk factors will come later; see below.) Our first assumption is that we’re producing 10 million chips, at the cost of $8/chip, selling for $15. There will actually be two chip designs created. Total R&D cost is projected at $8 million per design. Easy so far.

Figure 1: Basic cost assumptions for a medium-sized SoC project with two chip designs and lifetime production of 10 million units, cost of $8, $15 average selling price, and $8 million total development budget. (Source: Arteris)

But wait — what intellectual property (IP) are we evaluating? What design tradeoff is being considered? Let’s save that detail for later.

For now, we’ll start with the assumptions above and further assume that replacing in-house logic with a licensed alternative will add four more assumptions. One, assume that the overall product volume will increase by a modest one-half of one percent over the lifetime of the product. In our example, that means a total of 10.05 million units out the door.

Figure 2: Further cost assumptions for a medium-sized SoC project. (Image source: Arteris)

Why a half-percent improvement? For that matter, why any improvement at all? One reason is better product quality. The licensed solution will be more reliable and manufacturable than the in-house version. This follows, in turn, because the licensed IP comes from a trusted source with experience in this exact area. Think Ferrari and sports cars, or Kenworth and trucks. Specialists tend to perform better than generalists.

The volume also improves through shorter time-to-market because licensed IP is quicker to configure and integrate than an in-house design. An early debut means increased lifetime sales. More on this later. Overall, a 0.5% increase in unit volume is a very modest proposal.

Our second assumption is that licensed IP will save about one-half of one percent in die area. Again, this is due to the optimized commercial IP versus the in-house alternative.

Third, we project a slight 1% cost savings in direct R&D expenses, which is a slam dunk because we’re replacing a labor-intensive in-house design with a ready-made IP solution. Actual labor savings might be much higher, but it’s good to be conservative.

Finally, the 1% in “additional cost savings” includes quicker development time for derivative products, shorter time-to-market because there is no need to debug licensed IP that’s already verified, and faster response to the inevitable engineering change orders (ECOs).

Crunching the numbers, we come up with $375,000 indirect cost savings due to the slightly smaller die area, $160,000 in direct R&D savings, another $160,000 in indirect savings, and a gain of $375,000 due to increased volume. That comes to well over $1 million in savings — a hefty dividend for a project that only budgeted $16 million to develop the two chips in the first place.

NoC interconnect revealed
So, what is this mystery IP that saves time and money? It’s a bus. Or, more technically, a network-on-chip (NoC). As SoCs have gotten faster and more complex, so have the demands on the interconnect among constituent components. Simple buses have given way to sophisticated packetized on-chip networks. Like your car’s transmission, you don’t think about it every day but it’s totally necessary.

Engineering teams have historically done one of three things: They’ve designed their own in-house bus, they’ve used whatever bus came with some other major IP, or they’ve licensed on-chip interconnect from a specialist supplier. The trend is toward the latter because of increasing chip complexity and the need for differentiation.

Some third-party IP is less controversial to license than others. It’s hard to get engineers to switch processor families, for example, but changing a USB supplier is pretty painless. In this case, we’re replacing the SoC’s internal bus with a bona fide network designed specifically for the task. Most engineers won’t care unless it means replacing their legacy hand-crafted design with a commercial alternative.

Let’s get back to the numbers.

Saving time
Estimating time savings is tricky. Engineering schedules are notoriously slippery, after all. But we can make some educated guesses about schedule adjustment based on dozens of real-life projects and feedback from customers.

Figure 3 charts the typical timeline for in-house bus/network design, which comes dangerously close to an entire year. As the figure shows, it’s divided roughly into thirds: with about 80 days spent in architectural design — that is, defining what and how the in-house bus should work in all cases. Another 40 days generating the detailed register transfer language (RTL). And more than 100 working days in so-called physical design. This includes place-and-route, timing convergence, debugging, and design for manufacturing (DFM). Again, these aren’t just finger-in-the-breeze estimates, but data taken from actual customers.

*Figure 3: Relative time scales for each stage of an SoC-development project. The majority of the time savings – several months – comes during backend layout and convergence. (Source: Arteris)*

In comparison, the licensed NoC takes about half as long to get to the same place. Architectural design drops to almost nothing because the designers aren’t creating their own bus from scratch or figuring out how it will work, including all the obscure corner cases and unforeseen conditions. The middle phase of RTL generation isn’t much different in either case, although the laborious data-entry work is almost nonexistent with a licensed NoC. Finally, physical design is slashed to just 40 days because the licensed NoC is ready to go. Overall, the timeline has been compressed from nearly 12 months to less than five months. How much is that time worth?

Moreover, the engineering team is now doing less grunt work and more value-added work. It’s not as if they’ll suddenly have time on their hands or go on vacation. They’ll be reassigned to more valuable parts of the project that are, frankly, more interesting for them. Interconnect logic is highly technical but error-prone. It either works or it’s broken, so the engineers responsible are either invisible or scapegoats.

Assessing risk: don’t be late
Now let’s look at risk. We’ve seen how a licensed NoC can potentially get the product to market a bit sooner, but let’s also examine the opposite result. What if the chip is late?

In our example of 10 million chips selling for $12 apiece, the total gross revenue is $120 million. Let’s assume that’s spread over a 24-month market window.

According to Prasad’s canonical Analysis of Pricing Strategies for New Product Introduction (1997), a four-month slip in product introduction results in a crippling 44% drop in total revenue (see Figure 4). That’s a $53 million hit. Reducing the delay to three months still results in a $41 million loss, and a two-month delay (hardly any delay at all) still gives away 24%, or $28 million. As we know, time-to-market is king.

*Figure 4: Standard economic models predict substantial revenue loss after even minor product delays. (Source: Arteris)*

Risk, then, is the most expensive commodity of all. It makes sense to minimize risk by relying on proven, tested, and verified components wherever possible and to cut back on original, risky, in-house attempts to reinvent the proverbial wheel. Ego can play no part in this. Yes, engineers like to engineer things; but they also like to remain employed. That can’t happen when teams cling to favored pet projects over reliable commercial alternatives.

The big money
The models so far have assumed a medium-sized project. What if it’s a bigger project, with more volume, lower per-unit costs, and some potential follow-on projects? How would the numbers come out then?

Figure 5 is the corollary to Figure 1, but for more ambitious projects. Unit volume is 60 million over four chips, cost and ASP are reduced to $5 and $10, respectively, and the R&D budget grows to $10 million. The 12-month development cycle and 24-month market window remain the same.

*Figure 5: Cost assumptions similar to those in Figure 1, but for a larger project with lower costs, higher production volume, and a bigger R&D budget. (Source: Arteris)*

Lifetime unit volume increase and silicon area reduction are both projected at 1% (up from 0.5%) because a more-complex chip benefits more from the commercial NoC’s advanced features and reduced risk (NoC’s scale much better than buses and crossbars.). Direct cost savings are projected at 2%, with additional savings contributing another 1%. Those numbers yield a nice $3 million return just in reduced silicon area, another $3 million in increased sales through additional volume, $800,000 in reduced R&D expenditure, and $400,000 in project cost savings. Altogether, that’s $7.2 million over the life of just one project.

The risk factor becomes even more daunting (see Figure 6). With a projected $600 million in gross revenue, a four-month delay cuts out $293 million from that total. Even a nominal two-month delay eats away $141 million, or $73 million after a mere 30 days. Is an internal pet project worth that much?

*Figure 6: Revenue losses for a larger product are considerable: on the order of $100–200 million after just a few weeks of delay. (Source: Arteris)*

One intangible benefit of a commercial NoC is engineering product throughput. That is the number of products or projects one engineering team can produce in a given amount of time. A typical company might have three independent engineering teams working in parallel, perhaps different facilities. Each project is “pipelined,” or overlapped, with the others so that new products roll out at a regular cadence. Each project might take three years, but with three teams, the company can announce its latest product every year.

The pace of new-product introductions could be tightened to one every nine months if the development teams don’t waste their time on undifferentiated bus interconnects and instead adopt a commercial NoC alternative. Each team is just as busy as before, but now they have more tangible results to show for their efforts. Employment levels stay the same; P&L stays largely the same; team structure stays the same. The engineers are just more productive and more profitable. Maybe enough to buy their own Mercedes-Benz.