SOCcentral - ASIC, FPGA, EDA, and IP news and design information

October 5, 2009 -- Semico Research estimates that over 50 semiconductor intellectual property (IP) cores are present, on average, in SOCs being developed today, and that the number of cores will continue to increase rapidly for the foreseeable future. As a result, computer bus style SOC architectures, which have been the defacto standard for many years, are now giving way to distributed computing, multicore architectures. With all this processing now contained in the SOC, the ability to coordinate and mange all the SOC resources becomes a task which is also growing in complexity.

For many, this first shows up with coordinating access to external memory. But how do you coordinate and manage power and security among the cores? How do you coordinate error and violation recoveries? Or how do you execute boot and reset sequences? Some of these questions are being addressed today at the physical or logic design and firmware layers for specific functions, but what about the system coordination of all these? This is an architecture issue.

If we look back at the evolution of the PC architecture for direction, we discover virtualization. When the levels of complexity on the motherboard became overwhelming to manage, PCI decoupled all the functions and coordinated them through an independent system block. Now that software is becoming overwhelming, several companies are offering products that abstract and virtualize the PC software. Likewise, as the new SOC topologies are making it increasingly difficult to manage system functions, virtualization will play a role in SOCs.

Analysis shows that on the SOCs using multicore architectures today, no one IP core can easily be given enough accessibility to control the other cores without complicating the architecture. And with many software operating systems and applications present on the single SOC, synchronizing their states with their support hardware state changes is also complicated. So what role can virtualization play?

Insight lies in the way the problem is viewed. For example, if power and security management are addressed at physical or logic hardware design, or in firmware, chip or IP solutions commercially available solve aspects of the architecture problem as well. But they are specific to the instantiation, not the architecture itself. As more functions are absorbed or change, how does each of the piece-meal solutions come together to coordinate the entire system successfully? Here lies the viewpoint change needed to understand SOC system-management virtualization.

Instead of engineering system-management solutions as functions are developed, they are abstracted and managed top-down as a system-level task. A dedicated entity on the chip can then consolidate the tasks and mange them independent of the specific functions. The system-management tasks have now become virtualized. And since this is an architecture-level virtualization, hardware and software still have ways to have their specific function requirements met, but without all the overhead of coordination and execution.

There are two important components required to achieve this kind of virtualization. The first is the availability of a hardware block that can operate independently from the rest of the SOC, but can also connect to and control the other blocks. The second is to create a mechanism for the independent hardware block to facilitate communications with the software operating on the other hardware blocks, so that as hardware state changes are made, the software can remain synchronized. These two elements allow this new entity to execute "policies" that describe how the system must be managed at various points in time. This is how each function can get what it need while having the independent entity executing the tasks on their behalf.

ChipStart's SSM (SoC System Management) is a hardware-software combination, called a subsystem, that facilitates such an virtualization approach.

Figure 1. SSM hardware virtualization comes from its independent operation.

In addition to SSM's independent operation, SSM connects to the control signals of the other blocks using an A2R register-style interface and bus. A2R contains a 16-bit data path that enables message passing between the SSM and the blocks at the hardware level. SSM also contains a software kernel that operates a stack as shown in Figure 1. Drivers connect to the various software elements on the SOC to communicate status when SSM makes hardware state changes (power down, for example).

SSM supports command structures that are C language constructs. SOC developers create chains of these commands, called scripts, which represent the order of operations that SMM will execute state changes. Scripts are loaded into the RAM memory of SSM, and SSM then executes the scripts. Scripts can come from any hardware or software source and can be changed at any time by re-loading the SSM RAM space. When a state change is required, a different script is loaded and executed.

In this manner, system management can be architected before chip or software development begins. Scripts decouple the tasks, which relieves cost and verification burden off the development team (where these are normally completed) and can be implemented by a vast number of resources, such as architects, design engineers, verification engineers, software engineers, or even quality assurance engineers.

The direct impact that SSM has on a development project is to inject new technology at the architecture level which has a ripple savings effect on capital and labor utilization. Software developers do not have to create similar schemes to manage their software. Extra logic sometimes associated with system management is eliminated. Verification is simplified because the pre-verified scripts can be developed far in advance of top-level integration. And the next chip can use the same scripts as the current chip. So how much ripple savings is there? Using Advance Tech Marketing Production Curves (for a 90nm, 5 to 7 million gate design), the savings are shown graphically in Figure 2.

The red curve represents the estimated capital and labor mixes necessary to produce a chip before adopting SSM. The capital includes all the flow and automation tools needed to deliver the chip. As engineers are added, they complete some of the tasks by other means than automation and they also can share tool keys.

If point A is the optimal point for this example, it will take 300 person-months and $3.25 million (USD) to produce the SOC. Acquiring SSM shifts the production points to the green curve, and point A shifts to point B, which is 270 person months and $2.25 million in capital. Using SSM therefore reduces capital requirements up to 25% and labor requirements up to 10%. And if capital expenditures were held to $3.25 million and SSM was used, the labor requirements would drop to 175 person-months, for a 42% savings.

If SSM also enables a 6-month time-to-market acceleration, their can be as much as a 25% gross profit gain. The Advance Tech Marketing forecasting curves in Figure 3 shows this.

The chart shows the estimated distribution of units sold for the chip over a 33-month period. The red curve represents the expected distribution before using SSM, and the green curve is based on using SSM. The blue curve is the estimated gross margin erosion expected as competition enters the market and the end product matures in its life cycle. The shift from the red curve to the green curve brought about by SSM indicates that more units at better gross margin will be sold as a result of the 6-month time-to-market acceleration. This can be up to a 25% gross profit gain when compared to the red curve.

The curves then point to the power of virtualizing SOC system management using SSM and what it can mean to the return on a product line investment. SSM offers a new way to address the problem, which is more harmonious with distributed processing, multicore trends. The ripple savings effect that results, in development costs, and time-to-market, also compounds with increased use of SSM. This is because of the extra profits. Fewer required resources and shorter design cycles make even more resources available for the next development project. As a result, system management virtualiztion can reap big gains for complex SOC designs.

Phil Casini is a managing partner for Advance Tech Marketing (ATM), a management, sales enablement, and marketing consulting and training firm. Prior to founding ATM, Phil spent 26 years in high technology companies including Intel and Dallas Semiconductor, with 14 years as an executive at Cirrus Logic, Cradle Technologies and Sonics Inc.

SoC System Management IP Virtualizes SOC System Management