Skyrocketing complexity and integration challenges are opening the door to system IP.
By Frank Ferro
Just how important are IP subsystems to complex SoC designs? It appears much more than you may have thought just a few months ago.
With the emergence of SoCs that now support the cloud computing revolution and every major cloud-connected device, SoC complexity is increasing at a dizzying pace. We commonly now see increasing number of IP cores, cores from multiple sources, different protocols and core frequencies, and so on. And of course, the growing challenges this level of complexity brings to SoC designers and their ability to execute a successful SoC program are also major considerations. So the answer to the above question drove an interesting panel discussion on the emergence and importance of IP subsystems at this month’s DAC.
The discussion intrigued me because dealing with all this IP complexity for advanced SoCs is where Sonics lives. Sitting at the heart of the SoC, the on-chip network design currently plays a critical role in pulling all these IP pieces together, so hearing designers’ perspectives on these challenges is helpful, and perhaps even more so, reaffirming. Case in point: In the discussion, Open-Silicon stated that on a recent design they had more than 100 IP blocks from 16 different vendors! These IP blocks accounted for 60% of the die area and we can easily see this number growing to 80% over the next two to three years.
Clearly, as the number of IP bocks and vendors grow, IP subsystems offer some level of relief to SoC design companies. By logically consolidating IP blocks into pre-tested, pre-verified subsystems (in some cases with software), SoC designers have the potential to reduce the number of cores and vendors to be managed. IP subsystems already have emerged with the availability of audio and video subsystems, and now CPU vendors are working to consolidate and perhaps even standardize this “hybrid processor” by combining CPU and GPU functions. The goal of combining these processing elements is not to simply make the designer’s life simpler, but to introduce superior performance, power and programming efficiencies that are required to meet the demands of what I call cloud-scale computing. IP subsystems can be architected to maximize performance by having better integration of IP blocks–ensuring that the interfaces are fully optimized, thus reducing communication inefficiencies in the system.
Although the advantages of IP subsystems may seem obvious, some participants on the panel were arguing that IP subsystems may not be practical due to the current lack of standardization (no such thing as plug-and-play), the ability to verify these subsystems will function properly, and that pre-configured subsystems will limit the freedom of designers to optimize the SoC for their specific application. Although compelling arguments, I believe that IP subsystems are not only necessary, but now a critical part of the new formula for SoC design to progress at the rapid pace that is required beyond 2012. No single company, except perhaps the most vertically integrated, can own and manage all this IP. And, the good news is there are real solutions to each of the above challenges. In fact, this requires a new class of IP so designers can specifically resolve the IP integration problem.
First, let me address the last objection on system optimization. Having personally been a product manager for many consumer SoCs, I absolutely understand the need to optimize performance and minimize gate count (i.e. cost). Having said this, one of the most important challenges for any chip program is execution (i.e. time-to-market). Missing a market window can be fatal for any program. Many chip companies have done very well grabbing market share by being first to market with “sub-optimal” chips. Once a company establishes a strong market position, cost reductions can be achieved later, so I don’t see optimization ultimately being a major stumbling block in the use of IP subsystems.
System IP: The Winning Formula. To address the first two concerns (standardization and functional verification), it requires technology and tools used to architect SoCs and integrate IP…or more simply, System IP. System IP includes the on-chip network, performance analysis tools, debug tools, power management and memory subsystems. These primary IP components give SoC designers the capability to assemble and test the performance and functionality of all the other IP components and subsystems in the SoC.
As already mentioned, the on-chip network provides the universal connectivity for IP blocks in the system; performance analysis tools allows for system testing and optimization–ensuring that each of the IP cores function at optimal bandwidth with minimal gates. And these system tools are not simply software, but work in conjunction with IP that is embedded in the SoC for better visibility and control of the system. Since most cores in the system need to access memory, having the proper memory subsystem design is critical to the overall system performance. Finally, the ability to debug these complex systems (networks embedded within networks) is also vital to the overall success and implementation of all these subsystems.
No standards…No Problem. I agree that standardization of IP cores and IP subsystems will take time, if it ever truly happens at all. But fortunately, with the emergence of system IP, standardization is not really necessary. The reason is that system IP components are specifically aimed on solving the challenges associated with using multiple heterogeneous IP blocks and subsystems from multiple vendors. So at this point we can safely take that issue off the table. System IP helps to overcome that design dilemma by providing universal connectivity–allowing seamless integration of IP cores from different sources with different protocols. This capability along with embedded IP blocks for testing, optimizing and verifying IP provides a complete solution of IP that makes IP work—cool concept!
—Frank Ferro is director of marketing at Sonics.
Leave a Reply