in Techspeak

When SoC met IP.

In this article I’d like to address a common misconception that I often see reprinted in many articles. When presenting the relationship between IP vendors and chip makers, an image of fierce competition is repeatedly (and wrongfully) painted in the media.

Let’s start by stating one simple fact:

IP vendors are not competing with semiconductor manufacturers, at least not from a business point of view.

To prove this, I’m going to expand on the diagram below to illustrate my point.

Enabling innovation in SoC IP_v3fA simplified view of the manufacturing chain

There are multiple IP vendors in existence at the moment; for the sake of simplicity, I will focus on Imagination, since the company targets a wide range of markets. These IP providers primarily battle to achieve two things:

  • Design highly competitive IP technologies (mainly architectures and cores, but more recently IP subsystems too)
  • Convince semiconductor vendors to choose their IP technology (architecture, core, subsystem, etc.) over the competition’s or over in-house solutions

The confusion often appears when talking about processor IP, chips, and the companies that make them. For example, some rank MIPS CPU IP directly against Qualcomm Krait and Intel Silvermont; others mention PowerVR GPU IP fighting against Nvidia’s Maxwell architecture.

Here is the difference: the IP vendor designs a blueprint (an IP core or architecture); the semiconductor manufacturer then licenses that blueprint and turns it into a physical product (a chip) with the help of a foundry. This model creates a three-way ecosystem between IP vendor, chip maker and foundry that is based around mutual trust and close cooperation, not bitter rivalry.

CPU IP can be delivered in many ways; for example, some companies prefer to take the RTL and perform the physical layout (the placement of the CPU on the SoC) themselves. Other chip makers who wish to pay extra – and get to market quickly – opt for a hard macro: a ready-made CPU that has been already laid out by the IP vendor according to a predefined set of performance, power and area considerations.

Try to think of processor IP as a Swiss army knife: it has many use cases (mobile, home entertainment, wearable, IoT, automotive, networking, etc.) and fits into almost any pocket (phone, tablet, smartwatch, home router, etc.).

Continuing the Swiss army knife analogy, an in-house processor is a very precise tool usually designed for a very specific use case. It might lack the flexibility of a Swiss army knife, but it makes up for it in application-specific performance efficiency.

For example, several companies have chosen to design custom, high-end CPUs for mobile or server devices while others pick and mix off-the-shelf CPU IP; a few even do both.

Let’s take a look at a few examples.

MIPS Warrior

MIPS Warrior is a CPU IP family built by Imagination and based on Release 5 and Release 6 of the MIPS32 and MIPS64 architectures. Members of this new generation of MIPS CPU IP cores include:

  • 32-bit CPUs: P5600, M5150, M5100
  • 64-bit CPUs: I6400

MIPS Warrior roadmapMIPS Aptiv and Warrior CPU portfolio

Altair Semiconductor, Baikal Electronics, Mobileye, Standing Egg, and others incorporate MIPS Warrior CPUs in embedded SoCs.


cnMIPS is a 64-bit CPU (again, not CPU IP) family built by Cavium and based on the specifications of the MIPS64 architecture. The latest cnMIPS cores (cnMIPS III) are implemented using Release 5 of the MIPS64 architecture and include features like hardware virtualization, and content and security acceleration.

Cavium OCTEON III - cnMIPS - MIPS64_fcnMIPS CPUs are used exclusively by Cavium in OCTEON III SoCs for networking, storage and security applications. Primarily designed to execute highly parallel operations at very low power, cnMIPS CPUs efficiently scale from single- or dual-core 800 MHz configurations to 48-core versions clocked at 2.5 GHz each.

Broadcom nxCPU (XLP II)

nxCPU is another 64-bit CPU based on the MIPS64 architecture. Built by Broadcom for the XLP II family of SoCs, nxCPUs target the networking, security and storage space, delivering very high performance at reduced power.

Broadcom XLP II - nxCPU - MIPS64One of the leaders of the XLP II pack is the 20-core XLP980 processor which presents a superscalar, quad-issue pipeline with out-of-order execution tuned for high single-threaded performance.

Architecture vs. off-the-shelf

Cavium and Broadcom are examples of CPU architectural licensees. These companies have created deeply customized, 32-bit and 64-bit CPUs that are suitable for specific markets and use cases: ultra high-end mobile and networking, respectively.

Taking an architecture license does not automatically imply a ban on off-the-shelf usage. Moreover, some companies source CPU IP from two (or more) competing vendors.

Qualcomm is another great example that illustrates this point. In addition to building Krait and Kyro CPUs using an ARM architectural license, Qualcomm also adopts ARM CPU cores in its products.

Furthermore, Qualcomm leverages standard 32-bit MIPS CPU IP cores from Imagination in certain Atheros Wi-Fi chips.

Broadcom is another interesting example of both architectural and off-the-shelf usage from ARM and Imagination: Broadcom set-top box SoCs incorporate either MIPS or ARM off-the-shelf CPUs.

When it comes to the networking market, Broadcom goes even one step further for MIPS-based chips. The XLP II many-core family adopts a 2-for-1 strategy, integrating up to 80 MIPS-based, 64-bit nxCPU cores custom-built for deep packet inspection as well as 32-bit, off-the-shelf MIPS CPU IP cores for packet pre-processing.


I hope it is clear that semiconductor companies taking up architectural licenses to build their own processor are not doing so to compete directly with IP vendors. Instead, an architecture license is usually employed to tailor IP technologies for a custom-built product that addresses a unique market or a specific application.

When creating a new architecture, IP vendors ask for feedback from every licensee (be it architectural or off-the-shelf). These constructive comments and feature requests are then carefully evaluated by the architecture team, ultimately leading to better products that ultimately benefit everyone. For example, Cavium provided very important feedback related to hardware virtualization to the MIPS team; that feedback was used when the engineers defined the first draft of the MIPS Release 5 architecture.

Here are four key points to remember about IP in the context of SoC design:

First, IP is (usually) process-agnostic; it needs to be otherwise you wouldn’t be able to knock on so many doors: in a world where semiconductor company A relies on GLOBALFOUNDRIES, B prefers TSMC, while C and D have their own foundries, you must be able to talk to everyone. Making silicon IP process-sensitive severely limits your business opportunities.

Second, IP is extremely configurable: silicon IP will not be used only in one market (e.g. mobile) or for one device (e.g. a phone), but across a wide variety of applications, including automotive, IoT, networking and so on. Moreover, one company’s chip can look very different to another’s, even if they start off using the same building blocks. Decisions like number of cores, cache sizes, bus protocols, SoC fabric etc. can have profound effects on the performance, power and area characteristics of chips.

Third, IP is very flexible: a piece of IP will usually live on the same chip with other IP blocks and/or in-house solutions; therefore, processor IP must be designed to work well with other hardware engines, including the competition’s. While in-house solutions may implement only specific interfaces or standards, processor IP cannot afford this luxury. For example, the team responsible for a SoC family designs those chips knowing they will pair an in-house designed CPU with other in-house designed components, including a GPU, a DSP and other components. On the other hand, IP vendors build their products and technologies with more open assumptions regarding other elements in an SoC – other elements may or may not be known and so IP must be flexible Obviously, specific synergies can be achieved at the system-level if an SoC architect picks multiple blocks from the same IP provider (e.g. tighter integration between graphics, video and vision functions). However, locking out a competing architecture by design is considered to be a big no-no.

Finally, IP has long life: as silicon technology advances, IP can get new lease on life by proving upgraded performance when moving to smaller geometries.

In conclusion, comparing two chips is fair game to me. But putting an equal sign between a physical CPU inside a chip built on a specific process node and generic, process-agnostic CPU IP requires some rough approximations where a lot can be lost in translation.

Moreover, funky titles like IP vendor A takes on semiconductor vendor B with release of new processor C create the impression that somehow IP vendors are racing to outmanoeuvre silicon vendors – this is not the case.

In reality, IP vendor A tries to pitch this shiny, new processor C to a vast range of semiconductor vendors – and there is a great chance that vendor B is on the list. Meanwhile, IP vendor A also attempts to license the underlying CPU architecture used to build the same processor C to a select group of companies (again, vendor B might be on this second list too). Finally, if all goes well, either processor C and/or the CPU architecture are licensed to several partners; by that time, the engineers at IP vendor A are already working on processor D, igniting a whole new marketing, business development and sales cycle.

It doesn’t make for an exciting title but it’s how it works.