Over the last few years people have often made mention of IP subsystems in vague terms, with even vaguer promises on what they will deliver. However, it seems that 2012 is the year when subsystems will finally come into their own with both a clear definition and a clear set of benefits. Multiple companies including Cadence have already announced the availably of IP subsystem solutions.
Before we get into the discussion of subsystems, let spend a moment to consider the variables that are so important to the success of a complex SoC. A lot has been written about IP quality over the years, and the following equation does a good job of capturing that discussion.
This means is that if we want to improve the likelihood of success for a complex SoC we need to either reduce the number of IP blocks, or improve the quality of the IP blocks used - or ideally do both, given the non-linear increases in complexity.
Managing the equation is where IP subsystems come into play.
Characteristics of an IP subsystem
An IP subsystem is more than just a new and bigger type of IP block. A subsystem typically involves multiple related IP functions, each of which may be very large in its own right. These related IP functions combine to perform a new function, but must do so in a way that is applicable to a wide range of applications. This means configurability is a second key requirement of subsystems, and while configurability does not "require" a software component, for a subsystem of any meaningful complexity software will be involved.
Some may say that these two considerations alone - multiple IP functions, and configurability - are sufficient to define a subsystem, but I believe that there is one additional characteristic that differentiates a true subsystem from a simple exercise in packaging IP blocks together.
A true subsystem involves optimizations that result in something greater than the sum of its underlying components. These are optimizations that could not have been achieved by someone other than IP developer, as they require both extensive knowledge of the underlying IP implementation, but also complete access to the design.
To better demonstrate what makes a subsystem, lets look at an NVM Express (NVMe) subsystem recently made available by Cadence. This subsystem brings together multiple hardware and software blocks to deliver a complete solution for customers looking to adopt this new storage interface standard.
What is NVMe, and why is it a good fit for a subsystem approach?
NVMe is a new interface standard targeted specifically to devices utilizing non-volatile memory in storage applications. Traditional storage interfaces such as SATA and SAS were created with the characteristics of spinning media in mind, either exploiting their properties, or hiding behind their limitations. The widespread usage of non-volatile memory in enterprise and consumer storage applications has meant a new class of interface was required that could take advantage of the high degree of parallelism, low latency, and high bandwidth made possible by these devices. NVMe was created to address this need.
NVMe leverages PCI Express (PCIe) as its transport layer, allowing it to take advantage of the rapid improvements that have been happening in that interface. The low latency offered by PCIe and its near ubiquitous presence as the primary interface in computing architectures make it an ideal choice for high-performance storage interface applications.
The NVMe protocol sits on top of PCIe, adding capabilities needed to support non-volatile storage including the ability to process large numbers of simultaneous and outstanding commands. The standard also supports a wide range of capabilities that are needed in both enterprise and client applications including virtualization, data security, error reporting, and low power.
Building and optimizing an NVMe subsystem
Figure 1 shows what a typical SSD controller chip may look like, including the components that make up the NVMe subsystem. Here you can see NVMe brings together three separate Design IP components - PCIe PHY, PCIe controller, and the NVMe controller as well as software IP in the form of firmware. These components are configured and delivered as a single integrated solution, significantly reducing the engineering effort for people looking to add NVMe into a design. Beyond integration, there are also a number of optimizations that can be made during implementation.
Reducing latency was a key driver behind NVMe, and by using the context in which the IP blocks are going to be used in in the subsystem, it was possible to optimize latency. Specifically, if we consider the interface between the PCIe and NVMe controllers (Figure 1), those interfaces could be significantly flattened to reduce latency. This was possible due to having full control over both sides of the interface.
Another optimization was to unify the DMA model used across the controllers, as well as the firmware interface. Additional optimizations were made to utilize command accelerators in the controllers, and leverage the knowledge of those accelerators in the firmware implementation. These optimizations provided significant improvements in the command processing, and CPU overhead.
Figure 1: Typical SSD SoC including NVMe subsystem
Going back to the original definition of a subsystem, you can see that the above description meets all three of the key criteria.
1. Combines a number of related IP blocks
2. Highly configurable and utilizes a software component (firmware API)
3. Delivers an end result that is greater than simple integration of components
So that's "n" what about IP quality?
At the beginning of this article we introduced the equation that represents the driving force behind the move to subsystems. We have discussed how subsystems can control "n" - using our NVMe example a single IP deliverable replaces four (4) IP components, three in hardware, one in software - but how do subsystems help with the need to improve quality?
Any significantly complex and configurable design is impossible to exhaustively verify. In an IP subsystem we exploit the context that the component IP blocks are going to be working in, and they are configured and verified with that context in mind. So while the complexity of the subsystem is greater than the underlying parts, the greater knowledge of how the design will be used reduces the variables that need to be considered making it significantly easier to focus the verification effort on the specific usage cases.
In the case of the NVMe subsystem this begins with building a comprehensive simulation environment leveraging the Cadence Verification IP Catalog, and goes even further in building and delivering Cadence Virtual System Prototype models, Cadence Rapid Prototyping Platform models, and emulation and acceleration support on the Cadence Verification Compute Platform allowing significantly more verification to be carried out, improving the overall quality of the delivered solution.
Evolution in the IP ecosystem
The constantly increasing complexity of SoC's and the need to rapidly ramp to volume in order to cover development costs means the move to subsystem based design is a natural evolution of the IP ecosystem. Subsystems enable us to both reduce the number of discrete IP blocks in the design as well as improve overall quality, which in turn speeds time to volume and improves the overall likelihood of both technical and business success.
Subsystems will be as transformational to SoC design as the advent of the 3rd party IP industry.
Neil Hand is a Group Director of Marketing in Cadence's SoC Realization group focusing on the challenges of SoC Realization, including design IP, design services, and chip planning and management. Mr. Hand has over 20 years of experience in systems and SoC design, customer support, and marketing.