IP Subsystems: What Works, What Doesn’t

The SoC landscape has changed substantially over the past decade and so have some of the definitions for aspects of the system—particularly the IP subsystem.

“We’ve been at the point for some time for large SoCs that what we thought about as a building block 10 years ago is now too small,” said Drew Wingard, CTO at Sonics. “This is because we as human beings have trouble managing the amount of information in our heads, especially building a FPGA where I’m repeating 1,000 of these and 800 of those and 400 of these. We just can’t reason in a reasonable fashion about a heterogeneous system that has so many different components in it.”

As such, there really is no choice but to take those smaller IP cores and bundle them together into IP-based subsystems.

The subsystem concept is not new, but the overall complexity has increased exponentially. “For example, subsystems controlling I/O functionality have been around for many years, but today’s integrated SoC subsystems were previously discrete devices in a system,” said Rich Collins, marketing manager for ARC Processors and Subsystems at Synopsys. “Functions such as sensor fusion, graphics, audio processing, and wireless communication are increasingly integrated on a single device.  Resource constrained design teams do not have the bandwidth to become experts in each functional area, so they are looking for drop-in solutions.  This allows them to focus on their area of expertise and also enables rapid deployment of these subsystem solutions across several families of devices.”

He believes the integration trend will continue and more specialized subsystem solutions will be developed.

Kurt Shuler, vice president of marketing at Arteris, noted that the growth of IP subsystems has increased for several reasons:

1. More complexity of functions, such as graphics, video and security on a chip;
2. The ability of commercial IP vendors to have competitive solutions for these functions very quickly, and
3. The organization of SoC design teams around these functions, transitioning from generalists to specialist.

What makes a good subsystem?
Still, the concept of the IP subsystem is a work in progress, Wingard asserted, and it is something that is almost exclusively the domain of the chip companies.

“Most of the interesting subsystems are built by chip companies,” he observed. “The IP industry has a couple shining examples of IP companies producing subsystems. One is the GPU provider. GPU guys were building subsystems a long time ago – not that anyone ever thought of it that way – but if you look at the architectures they adopted inside their machines, they were taking advantage of the fact that graphics processing is very parallelizable. They broke their system up into a collection of different kinds of engines that could do shading and all these other graphical operations. And then they had to stitch them together with internal fabrics with interesting memory hierarchies and with an enormous amount of subsystem-specific software so that the end user could consider the GPU to be largely a black box and wouldn’t need to understand how it works on the inside.”

That’s one of the big differences between an IP core and an IP subsystem. “Good examples of IP subsystems are built in a much more black-box model, where it’s much less likely that the SoC integrator/architect is going to need to understand in detail how that subsystem works. They’ve got ways of making those objects configurable, but the IP vendor is responsible for delivering software that’s going to run on that – not as a reference model but the actual software that’s going to run,” Wingard continued.

In one sense, that makes IP subsystems physically dependent and context-specific, or less black box-like. But looking at audio subsystems, where IP subsystems have thrived, they still work like black boxes. The reason: Audio wasn’t the main selling point.

“The video subsystem, in contrast, has not been very successful, which raises the question as to why,” Wingard said. “At the root, it’s that the audio subsystem essentially became non-differentiated, so it was unlikely that the companies who were willing to buy an audio subsystem were ever intending that the reason someone was going to buy their chip instead of somebody else’s chip was because they were just fundamentally better at doing audio. Audio was a required component in the system chip they wanted to build, but it wasn’t the main component.”

Audio subsystem makers also recognized that in audio that there were so many different codecs and schemes that need to be implemented that the cost of doing all the customer work was enormous. By accumulating all of those codecs as a a library of software that could run on the audio subsystem, not only did the audio subsystem provider really help the customer abstract the subsystem so they never had to see the details but they also eliminated a lot of work in the software and in the system.

Looking at video, a lot of companies that build SoCs believe they are still adding value in video either because they used to be a company trying to sell digital TV chips or set-top box chips, which pretty much covers all of the big chip companies, Wingard observed. “Also, it’s much more difficult to address the scalability question. We use video in lots of different SoCs, today but the size of the screen we’re displaying on may be very different. The use for video in the application may be very different. [i.e., a point of sale terminal that displays video ads] That doesn’t mean they’re very highly capable video subsystems, whereas the thing that’s going to be on the scoreboard at the new 49ers stadium probably needs pretty good video processing because there are a whole lot of pixels being driven up there and there is a huge dynamic range because of the difference in screen sizes and pixel depths and requirements for image quality. That means it has been very difficult to build a single subsystem that scales to exactly what the customers wants.”

Defining subsystems
So what exactly is a subsystem? From Shuler’s perspective it has to meet these characteristics:
•Be focused on a well-defined set of functions that do not overlap with other functions on the chips (audio, graphics, security, communications, etc.);
•Not be dependent on another piece of SoC IP to function. An IP subsystem provides functionality independent of the chosen IP for other functions like CPUs (ARM vs. MIPS), DSPs (CEVA vs. Tensilica);
•Have its own well-defined hardware and software interfaces for setup, communication and control;
•Have its own verification test harnesses and IP so that users can independently verify its functionality and fitness for use without creating this from scratch, and
•Have its own software IP required to integrate and implement the subsystem functionality into the complete HW/SW system.

However, Shuler said the biggest areas where the IP industry falls short is in the last two items—deliverables for verification and software integration. “For software, if someone is licensing an IP subsystem, it’s usually not enough to offer non-production ‘sample firmware,’ ‘sample driver’ and/or ‘sample middleware’ deliverables to the IP licensee.

He noted that IP vendors often have “preferred service providers,” which can create custom software for the IP licensee for a fee. “In these cases, the IP vendor is leaving value on the table. How hard is it to do a little marketing to figure out what are the primary operating systems to target? It’s Android for mobile, Linaro for server, FreeRTOS or VxWorks for embedded RT systems. Develop real production driver and middleware software for these OSes, charge the customer less than what they would pay to have a third-party do it, and reap the benefits of increased revenue and better learning about your customer’s requirements. And if the IP customer is using a different OS than the ones you chose, still charge them for the closest version so the customer can use that as a starting point for their own development. It’s still cheaper and faster for the customer to pay the IP provider for these things than to figure it out for herself.”

On the verification side, he doesn’t believe this is a huge issue, especially with IP subsystems that are configurable. “Not only does the IP provider have to internally verify all the deliverables given to a customer, but he also has to provide an automated means for the customer to verify their own configuration of the subsystem. For IP subsystems with only a few configuration options, this isn’t much of a problem. But for IP that has an infinite number of configurations (like interconnect fabrics), the IP vendors had better be smart and deliver an automated means of simulating an IP configuration and integrated it with the customer’s existing verification methodology. If you’re speaking to an IP vendor of configurable IP and they look at you with a blank stare when you mention SystemC, UVM, IP-XACT, etc., then run away,” he added.

Collins pointed out that finding the appropriate level of integration is the challenge in building subsystems. “It is fairly simple to lump a core and a whole bunch of peripherals together into a sea of gates, but this approach will likely be too big and/or too generic for most customers’ needs. The most effective subsystems provide a complete solution for a specific problem, easing the customers overall SoC or MCU integration and verification effort.”

This is the approach Synopsys has taken. The company’s sensor subsystem combines a low-power processor with DSP accelerators, sensor specific peripherals, and software libraries for a complete sensor control solution. They’ve done the same with audio codecs and peripherals for a complete audio solution. The software is critical to the deliverable – providing hardware alone only solves half of the problem, he noted.

It’s too early to place bets in many markets on what will emerge as a profitable IP subsystem business, but as the IoT gets going and more electronics are added into a variety of vertical markets, there will be no shortage of companies trying to build and sell them.