3 Challenges Of Delivering Configurable Semiconductor IP

Over time, commercial IP products have morphed from single function blocks to 100% configurable IPs where no two instances are the same. In this article I point out the challenges of creating configurable IP, and the best-known practices to address them.

IP Configurability Spectrum
Throughout the history of chip design, there has been a spectrum of configurability that has been built into internally developed and commercial semiconductor design IP. In the early days of chip design, sections of chip designs (i.e. IP blocks) were mostly fixed-function and therefore were not configurable. We still see this today, with standards-based IP, where there is a very limited set of functionality that is configurable, or even no configurability at all. This type of IP is shown as “Mostly Fixed” in Figure 1, “IP Configurability Spectrum”, below.

Figure 1. IP Configurability Spectrum

The next step up in configurability is “Pre-made Fixed Configurations”. This is common in commercially available CPU core IP, like the ARM Cortex-R series. An example is the ARM Cortex-R7 processor, which offers single core and dual core lockstep options.

These first two configurability methods shown on the left side of the spectrum in Figure 1 limit the number of IP combinations the vendor must provide and verify to a specific, known number of combinations. The methods shown on the right side of the spectrum are different because they create an infinite number of possible IP configurations that must be managed.

The first method that produces an infinite number of possible configurations is “Configurable Extensions/Subsystems”. This method is used in the Synopsys ARC CPU Extensions and the Cadence Tensilica Instruction Extensions (TIE). In these cases, the majority of the IP component is a fixed configuration but the vendor provides the capability to extensively modify a subsystem of the component. In the case of Synopsys and Cadence, both of these processors offer means to create custom additions to the CPU instruction set and provide ways to automatically modify the compiler tool chains to use these new hardware instructions. Although there are an infinite number of possible instructions to verify, this capability is limited to a pre-specified region and scope within the IP. This helps limit the additional verification burden.

At the far right of the IP configurability spectrum is “100% configurable” IP, which means that no two instantiations of that IP will ever be the same. An example of this is network-on-chip (NoC) interconnect fabric IP, which serves as the SoC backbone communication means for all the IP blocks connected on a system-on-chip (SoC). In this case, the end-user is given a tool suite that allows an unlimited number and type of IP configurations to meet the boundless requirements of a modern SoC. I liken it to giving a developer a copy of Microsoft Word: She can write a poem or prose, a sonnet or a novel, elegantly or horribly. The possibilities are unlimited.

The more configurability available for an IP, the more challenging it is to implement in a timely fashion. The three major challenges of creating commercial configurable IP are IP Configuration, Verification and Integration.

Challenge #1. Configuring the IP
Any chip design project has a set of requirements that the IP must meet under certain use cases. No matter which method is used to generate the configurable IP, the IP must be configured to meet specified performance, power or other criteria. The only way to know for sure a configuration meets these requirements is to generate a configuration, then simulate that configuration using the requirements and use cases as inputs.

The current state-of-the-art in configurable IP is to converge on an optimal solution based on simulating requirements and use cases running on a candidate IP configuration, then comparing results. This is by its nature an iterative process. There is academic work regarding technologies, such as formal methods and neural networks, that may someday help replace or reduce the amount of simulation required when configuring an IP. But relying on these methods in their current state today would be very risky.

Figure 2. IP Configuration Flow

Given that simulation is required to create a configuration of an IP that will meet requirements, it is important for the IP vendor to offer a convenient, self-contained solution to quickly simulate candidate solutions, determine if they meet requirements and how they compare to previous simulations, and then provide feedback for configuration changes that will improve performance for later iterations. The key is to make it easy for the chip designer to quickly “close the loop” and converge on candidate IP configurations.

As shown in Figure 2, “IP Configuration Flow”, many design teams output simulation models of configurable IP for further SoC-wide analysis using simulation. These simulation environments include SystemC and commercial simulation, debugging and performance analysis tool suites like Synopsys Platform Architect and Carbon SoC Designer. It is a requirement for configurable IP vendors to provide a means to output simulation models of an end user’s specific configuration for use in SoC-wide simulation.

Methods of creating configurable IP: The dangers of algorithmic synthesis
Given the work that the end user must do to create her custom IP configuration, it is important that the underlying technology used to generate the IP eases the amount of work the end user must do, rather than add to it. The current state-of-the-art for 100% configurable IP is to have a database of IP elements that have all been verified individually, and then assemble these elements automatically using the end user tooling.

There has been academic work on algorithmically synthesizing configurable IP based on a set of input requirements, but this technology is immature and introduces many issues, especially in verification.

Challenge #2. Verifying Configurable IP
To explore the downsides of using an algorithmic approach, lets look at a common product that uses algorithmic means to synthesize inputs into a usable output: The C compiler. (Note: I’ve been the product manager and product marketing manager for two C compiler products, so I’ve personally felt the pain involved in this!)

One of the big problems with the algorithmic synthesis approach is that small changes to input source code or compiler directives can lead to huge (and unexplained) changes in output object code size and performance. It takes years of time and billions of lines of source code to be run through the compiler before the compiler engineering team has enough information to “fix the corner cases” and deliver a robust compiler that outputs predictable and repeatable object code.

The maturation of a C compiler is similar to algorithmic EDA products like synthesis and place-and-route tools, which both required many years before they provided predictable and repeatable results that an end user could rely upon.

For a configurable IP product to be successful in the market, the IP vendor must shoulder as much of the IP verification burden as possible. This is why a solution that uses pre-verified components as the basis for the configurable IP is preferable: Its use provides repeatable and predictable verification results.

For IPs on the left side of the IP Configurability Spectrum in Figure 1, it should be clear that the fewer the configurability degrees-of-freedom, the more likely the final IP product is to be fully pre-verified by the IP vendor. Any user-specified features must be ultimately be verified by the user. However, the IP vendor must it make easy for the user to verify the final configured IP.
In addition to using pre-verified elements, a configurable IP needs to include automated links to the user’s verification test bench using the user’s chosen industry standards, whether VMM, OVM or UVM. In addition, the configurable IP must automatically ingrate with industry-standard verification IP (VIP) suites like Cadence Verification IP and Synopsys Discovery Verification IP.

Challenge #3. Integrating Configurable IP
The next challenge is how to integrate a configurable IP into a system-on-chip. This used to be particularly difficult with 100% configurable IP that touches almost all the IP block on a chip, like NoC interconnect IP, but has been resolved after years of work with customers and hundreds of SoC designs.

The keys to successful integration of configurable IP include:

• Compatibility with the user’s EDA methodology and tools. New entrants to the commercial IP market often fail to account for the diversity of EDA tools and methodologies that design teams use. It is up to the IP vendor to adapt to the end user’s needs, not the other way around.
• Support for industry-standard and user-defined protocols and interfaces. Depending on the configurable IP, this could include transaction protocols (like AXI and OCP), debug interfaces, external communication interfaces and software interfaces.
• Flexibility to work within the user’s pre-defined SoC-wide requirements. Examples include voltage and frequency domains, power control systems, security and key management schemes, and quality of service guarantees.

The important point for successful integration of any configurable IP is that the IP vendor must anticipate and adapt to the end user’s requirements, as opposed to forcing the end user to change her environment to adapt to the IP.

At this point it should be clear that delivering a commercially useful configurable IP product is orders of magnitude more difficult than delivering a fixed-configuration IP. The IP vendor must exert a lot of resources to make it easy for the end user to configure, verify and integrate the IP. In fact, I estimate that only 20% of the development cost of a configurable IP is for RTL development. The other 80% is for automation, simulation and verification.