If you follow the semiconductor industry, you’ll have read a lot about the “semiconductor productivity crisis”: and it is a business issue, not just an engineering one.

As chips get more complex, the argument goes, they become ever harder to design: the tools available to us haven’t kept up with process technology, Moore’s Law and the increasing use (and re-use) of IP. Complexity has grown exponentially – the intelligence in the development process has not.

And this has a disproportionate impact on the cost and profitability of the business.

But is silicon design REALLY the problem?

Semiconductors: the “long pole” in product development

There’s no doubt that it’s becoming harder and harder to make money as a chip company – and in particular to make a success of a semiconductor start-up.

One reason that things have become difficult for chip makers is that the penalties have become so acute if things don’t go exactly to plan. The advantages of being first-to-market are well documented and quantified: PRTM says that first movers realize three times more lifetime profit.

Today, big SoCs are absolutely fundamental to the operation of most modern products: more often than not, chip development is the “long pole” on the product manager’s project plan. If that pole gets extended, the end product arrives late-to-market. Some recent very high profile examples (especially in the smartphone market) demonstrate how painful this is – and how public it can be.

Indeed, the smartphone market is a great exemplar of this entire dynamic – and it’s probably mature enough now to take as a model. Between 2007 and 2012, the major manufacturers launched a new product generation roughly every four quarters (ie annually). And yet the typical big SoC takes 18 months to develop. That means that if your smartphone SoC project over-runs by 10% (that’s around eight weeks in the real world), then your engineering costs (headcount, tools etc) are 10% higher than budget – which will be several million dollars.

But that direct cost is a tiny fraction of the real cost of delay.

That 10% over-run has also eaten up 15% of your prime market window.

Then factor in the opportunity cost. Your competitors aren’t waiting around while your product is delayed – you will lose sales that can never be recovered. Finally, there’s price erosion to consider – on average the selling price of a smartphone model erodes by 5-7% per quarter, with figures of 10-12% not uncommon. But if your product is late to market, and is pitted against newer competitors, the likelihood is that you will need to discount severely.

So it’s not hard to see how first-to-market advantage could triple net profits over the product life, or how a delay will devastate those profits.

The risk is in the software, not the silicon

But when we look more closely at what derails silicon projects we find something surprising. The risk doesn’t really sit with silicon development per se. Instead, much of it is within the engineering processes that go beyond the hardware.

Yes, chips are becoming more complex. More transistors means more design effort. But the tools and servers have improved massively, and while costs have risen, this is not a fundamental change. The real change in the nature of SoC projects has come after tape-out, not before.

Today’s SoC projects aren’t just about hardware. There’s a whole raft of software that has to be designed, developed, debugged and tested to run on the chip.

Creating this software can require as much engineering effort as designing the hardware it runs on; and for many companies developing SoCs and ASSPs probably more.

Indeed, it is common for SoCs these days to have multiple cores from different vendors, all with their own software – and with the added complication of interactions between them.

And once the chip and software are completed, the whole thing has to be integrated into the customer’s end product. The polite term for this is “customer engineering”: a less charitable description that we’ve sometimes heard is “doing the customers’ job for them”.

In chip companies today, it’s not uncommon for these three dimensions – silicon design, software development and customer engineering – to consume roughly equal portions of the total engineering effort.

And of the three, designing the hardware is probably the best understood, most efficient part of that process – and with the best development tools.

Contrast the other two-thirds of the engineering effort. The software team generally programs in C or C++ using an environment developed for sequential programming. And yet, as we’ve already noted, modern chips are intrinsically parallel (that’s what having multiple hardware blocks really means). So, even at this very fundamental level, it’s hard to argue that the software team is as well equipped as the silicon designers.

It goes without saying that the hardware is complex: so, can the software team really be expected to anticipate every possible state of such a complex system? No matter how much simulation the silicon team has run, there will always be the risk of surprises.

The team can be pretty certain that the IP of the core is good; but they can be equally certain that the software will have problems. Additionally, it is very hard to simulate software with the level of test coverage one would expect of hardware. Worse still, even if each element performs perfectly in unit test, when they are combined, their interactions will always be to an extent unpredictable.

Meanwhile, customer engineering is faced with an even more complex system – the customer’s overall product design.

That’s why the biggest efficiency gains to be made today are post- not pre-silicon.

Making silicon help the software (and customer engineering) teams

Although the trickiest problems lie beyond the silicon, the hardware team certainly have it in their power to help solve them. By designing a chip with monitoring, analytics and communications hooks built-in, they can substantially ease the task of both the software team and the customer engineering team.

There is, of course, a penalty to be paid for doing that: designing-in a system like UltraSoC might cost an extra 1% in die area. That’s a key metric for the quality of a hardware design, and there’s an understandable reluctance to pay that price.

But there is a powerful business case for “spending gates to save time”. Indeed, the post-silicon payback is compelling – our lead customer estimates that they shaved two months off an 18-month SoC project, just by helping the software team debug their code more efficiently. And as we’ve already seen, a 10% saving in overall project duration can have a substantial business impact.

Customer engineering benefits

The benefits for customer engineering are instinctively even easier to identify, because they continue throughout the lifecycle of the final product. Being able to see exactly what’s going on inside the chip once it is operating in a real system – including the ability to interface with high-level tools like TeleDyne LeCroy’s CrossSync and InSight for protocol analysis – makes the entire systems integration process easier.

And the value can be even higher once the system hits the market. I have direct experience of this in my previous role at Picochip/Mindspeed – now part of Intel. We were making complex devices, that were integrated into complex communications equipment for wireless infrastructure. This is a world of “five nines” and our customer engineering investment was substantial.

But our customers’ products in turn became subsystems within an even more complex system – the networks themselves. In this situation, even if a product appears “perfect” when it is first deployed, it is perfectly possible that a subtle bug may reveal itself after days, weeks or even months of operation. And it’s a classic “when a butterfly flaps its wings” environment: a change or an upgrade elsewhere in the system – including other network components of which you may have absolutely no visibility or control – can easily have unexpected and far-reaching impacts.

The bottom line for customer engineering was that firmware upgrades were an established fact of life. Worse than that, they were entirely unpredictable in their timing and extent – just what you don’t need if you’re trying to run a tight, efficient engineering project.

By providing a detailed, real-time window into the operation of the SoC at the heart of the customer’s product, debug, monitoring and analytics architectures like UltraSoC’s give the customer engineering team the ability to integrate more efficiently, and to solve in-field problems more quickly.

Of course, as we’ve said, the “price” is paid by the silicon team – it is they who need to architect and implement the right monitoring and analytics infrastructure, and it is they who have to justify the incremental silicon cost.

But die area is only a small portion of the total cost of a project: engineering time, opportunity cost, margin, quality and customer satisfaction are all critical financial properties too.

Optimizing die area while adding cost to those other aspects would be a foolish economy: conversely, spending gates to gain months in time-to-revenue might be a very wise investment.