The Rise Of The Subsystem And New IP Providers

Even IP providers need EDA tools, and they extend the supply chain from just chips to IP and subsystems.


By Frank Schirrmeister
From the perspective of system development in EDA, the customer landscape and its changes have always had a fascinating influence on our tools. NVIDIA’s recent announcement in a corporate blog post that they will be licensing the Kepler GPU architecture caused me to check again on the customer landscape for which we are enabling system development, for example, with our System Development Suite.

Recently I had written about how dependencies between hardware and software development are changing and how some software development is becoming even more independent from hardware. A while ago I had looked at the changing responsibilities for product development between IP providers, semiconductor houses and system houses in the wireless space. It is time to revisit that picture. Specifically I had to add sub-systems between the IP Blocks and the System on Chip (SoC). I also added HTML Apps above the standard applications to reflect the dynamics between Android and Chrome OS.


In the “good old days,” system houses would integrate chips into systems with software they developed and licensed, such as the Symbian OS. Over time, semiconductor houses would take on more of the software responsibility. Apple changed the equation by providing the full stack of software, and according to teardowns providing hardware based on a Samsung chip and pushing the value into applications. Nokia tried with its Symbian acquisition to match that move, unsuccessfully.

Apple later fully integrated vertically, developing its own silicon. In parallel Google had developed Android as an operating system, mostly to capture “eyeballs” watching their advertisements, adding the Android Market as a channel. At that time subsystems also started to rise—IP providers such as ARC and Tensilica would not only provide core blocks but also integrated sub-systems. In 2011 ARM announced its big.LITTLE architecture for low power, further strengthening the rise of pre-defined subsystems. Google added hardware with its Motorola acquisition and the Android Market became Google Play. Specific competitive manufacturers such as HP tried to match Google’s move and added Palm OS to power its HP TouchPad, for example, combined with a channel, unsuccessful in the long run. HP switched to Android at one point and put WebOS into Open Source.

Also in 2011 the first Google Chrome Books were delivered by Acer and Samsung, based on Intel architectures and running Chrome OS built on Linux. The actual applications were moved up from an App Store like Google Play to a WebStore for the Chrome OS Browser. In 2012 the Nexus 10 was added based on Samsung’s Exynos chip architecture. I own one—when I add an application I am asked whether I want to use the web store adding the App to the browser or whether I want to add the App from Google Play natively on Android. Interesting.

In all this evolution one of the most pressed positions in the design chain has been that of semiconductor companies. With the IP providers providing more and more complex subsystems and the value in system houses moving upward into applications—essentially making the hardware for phones and tablets delivery devices for applications—the differentiation of semiconductor vendors has become harder and harder. Naturally, they have taken on more and more of the software development, which allowed them to optimize key elements of the software for their semiconductor offerings.

When looking at the progression of dependencies as above, the most recent move of NVIDIA to license the Kepler GPU architecture seems like a natural move. NVIDIA becomes an IP provider for part of its design expertise. That allows the company to establish its base GPU hardware across different markets—PC and mobile—and with that also strengthens the software position of programming that GPU by opening it up to more users.

So why do I care as product management owner for system development tools? For one, as described in a recent post, software development, and enabling it to be performed earlier on virtual prototypes, acceleration, emulation and FPGA-based prototyping, is a key driver for our tools and software. It is key that my team and I know the target audience we are selling to within the design chain, as well as understand the power relationships. The other aspect is the delivery of IP such as NVIDIA’s GPU. To allow efficient integration into a licensee’s system-on-chip environment requires verification, validation as well as efficient tools to interact. Again, system development tools such as virtual prototyping and acceleration and emulation are likely to play a key role here, especially given that NVDIA is a key user already and uses these types of tools for the development themselves.

There are certainly no dull moments in EDA and the IP/semiconductor/system/software development design chain it enables!

Frank Schirrmeister is group director for product marketing of the System Development Suite at Cadence.


Leave a Reply

(Note: This name will be displayed publicly)