Executive Summary
The System-on-Chip (SoC) industry has made great strides during the past five years in helping SoC designers keep pace with the ever-growing number of transistors that can be integrated on a chip. But tough new challenges will require a new round of cooperation and standards activity for the industry to stay on a robust growth path.

Hardware reuse is an everyday reality, thanks to the cooperation of the entire industry - including IC, systems, and EDA companies, as well as the VSI Alliance (VSIA). An inexorable trend toward software-configurable SoCs, however, has created a new design paradigm that requires reusable, deeply embedded software to complement virtual hardware components.

The advent of configurable processors, SoC platforms, and the increasing use of DSP algorithms all contribute to an increased dependence on software. But the key element in the sea change in SoC design is financial: it is far more efficient and less expensive to change lines of code than semiconductor masks or hardware IP blocks.

Just as the industry realized five years ago that intellectual property (IP) reuse was the only solution to the hardware productivity gap, its leading thinkers now know that hardware-dependent software (drivers, bootstrap code, algorithms, and the layers of RTOS that interface with hardware) must also become reusable to avoid a new productivity gap.

Coincident with the software-oriented SoC design paradigm is the emergence of platform-based design. SoC platforms are best defined as providing layers of abstraction that communicate with each other through well-defined, standard interfaces. But without reusable embedded software, platform initiatives will not realize their full potential.

Some standards activity has already begun in the hardware-dependent software (HdS) area, but today's efforts are too narrowly focused. Moreover, there is no organized effort to create the infrastructure required for HdS reuse. A taxonomy and standard definitions are desperately needed to jump-start an initiative similar to the one the VSIA has led for IP reuse over the last five years. Also needed are definitions of deliverables, a business model for exchange, and proactive efforts to have developers adopt standards.

The VSIA is uniquely positioned to tackle the HdS reuse problem. It has a successful track record with hardware IP and with creating a system of virtual-component deliverables. It has an existing organizational structure of working groups with the requisite technical expertise and motivation to solve the problem, and it has a membership well-suited to addressing the problem with the help of new members from the software industry.

VSIA has initiated a program to bridge the HdS gap. To be successful, it will require at least the same level of support from the electronics and embedded-software industries that its IP initiatives enjoyed. The VSIA is ready. Are you?

Embedded Software for SoCs:
A New Challenge and A Tested Solution
As 2002 dawned, the System-on-Chip (SoC) industry's future seemed rock solid to the casual observer. After five years of hard work, many standards are firmly in place. Virtual components (VCs) are being reused routinely both inside companies and among them. While it is true that the third-party IP vendor model originally forecast has not been conspicuously successful, other models are taking its place. These models include SoC design platforms from IC, IP and system houses that can be application-based, processor-based, or highly programmable (such as those from Altera and Xilinx). Reuse is a reality. But, as stock prospectuses so often tell us, past performance does not always predict future success.

Let's start with the good news. Over the past decade, deep submicron IC process technology drove the definition of a complex chip from one with 2 million transistors and 100-MHz clocks to one with 40 million transistors and 600MHz clocks. As significant as those performance advances are, however, that progress was evolutionary in the sense that it was predictable and expected -- even if it was difficult to achieve.

During the same decade, a far more significant reuse revolution was underway: SoC designers migrated from creating 90 percent of every new design from scratch in 1991 to at least having the capability of designing chips with 90 percent reused hardware components in 2001.(1) (See Figure 1.) As in most revolutions, IP reuse is entering a period in which gains can be consolidated. For example, IP reuse still has plenty of unrealized potential for reducing SoC design costs.

Figure 1 - The Hardware Reuse Revolution

The gap between the number of silicon gates available to designers, and the ability of designers and design tools to put them to effective use, has become known to the industry as the "productivity gap." This problem has so dogged the industry over the past 50 years that it might be considered a corollary to Moore's Law. Recently, the gap seems to have closed because of the introduction of reusable VCs. Intellectual property (IP) in the form of microcontroller cores, as well as DSP, peripheral and many other cores, is being reused in new designs at semiconductor and systems houses. Engineering teams now design chips with 10 million gates and more in less than a year, sometimes in just a few months. Only recently, such productivity would not only have been impossible, but unthinkable without hardware IP reuse and the exchange of VCs.

IP reuse could never have happened without standards, of course, or without the basic underlying infrastructure of virtually all successful standards operations: an agreed-upon taxonomy or classification system; a consensus on basic definitions; a well-documented, rigorous specification for deliverables (in this case, IP cores); and, finally, a business model that allows it all to happen across corporate boundaries.

During the years from 1996 through 2001, this infrastructure was created through the cooperation of numerous groups including the Virtual Socket Interface Alliance (VSIA), the Virtual Component Exchange (VCX), and their member companies.

New challenges ahead in software reuse
But now, in 2002, observers with visibility into the future see another productivity gap looming. This time, however, it's due to the inability of software engineers working on SoCs to reuse embedded software efficiently.

Deeply embedded software -- the code deep inside the SoC --is not easily reusable because its execution depends on the hardware it runs on. Although internal design teams are reusing some embedded software today, the reuse is not achieved through a standardized, well-documented and extensible process. As a result, software IP simply has not kept pace with hardware IP in terms of portability.

Why adopt the paradigm of software-configurable SoCs? The primary reason for software's growing importance in the SoC equation is its innate flexibility. Chip architects and designers have found great value in being able to move lines of code around to change a function, rather than ordering new semiconductor masks (in the case of an SoC). A mask set and probe card for a next-generation chip cost more than $1 million for a complex SoC, up from less than $100,000 a decade ago.(2)

Although SoCs and board-level designs share the general trend toward using software for flexibility, the criticality of the software reuse problem is much worse with SoCs. The functions required of these embedded systems have increased markedly in complexity, and the number of functions is growing just as fast. Coupled with quickly changing design specifications, these trends have made it very difficult to predict development cycle time.

Meanwhile, the traditional embedded systems software industry has so far not addressed issues of "hard constraints," such as reaction speed, memory footprint and power consumption, because they are relatively unimportant for traditional, board-level development systems. But, these issues are critical for embedded software running on SoCs.

Moreover, most SoCs already include at least one programmable processor in their design. By definition, programmable processors have a fundamental and unavoidable embedded software requirement.

Exacerbating the problem is the ever-present tension and lack of communication between chip architects and software developers, who generally have a limited understanding of what's going on inside the hardware. Yet these architects, developers, and hardware designers must work together as a team if the newest phase of the SoC revolution -- platform-based design --is to become a reality for more than just a few large companies with vast resources.

The resultant change in the SoC design paradigm is reflected in staffing charts. Gary Smith, Chief Analyst for Design and Engineering at Dataquest, recently documented this shift.(3) In his breakdown of design seats by function, Smith found that in 2000 there were about 95,000 SoC design seats and about 370,000 board-level design seats. Both numbers pale in comparison to the estimated 812,000 seats in what Smith described as the embedded design space, which is primarily software development.

Figure 2 - Design Seats by Function in 2000

What is SoC embedded software, anyway?
Embedded software for SoCs is best thought of as the code that is intimately related to operating the hardware-and affected by the hardware architecture. It is not applications running on the SoC that can be recompiled and executed on many hardware and operating system platforms. Similarly, embedded software for SoCs does not include the top layers of a real-time operating system (RTOS) that provide an application-programming interface to the application software, or the higher levels of "middleware."

What, then, is embedded software for SoCs? Generally speaking, it is software that is always hardware-dependent-and, as such, is sometimes called HdS. A few examples are:

• Device drivers
• DSP algorithms
• BIOS
• Those parts of an RTOS that interact directly with hardware
• Networking stacks and protocol stacks implemented in hardware

Table 1 - Types of Hardware-dependent Software

While it is useful to use an analogy between board-level design and chip-level design to describe HdS, the analogy does not go quite far enough. Configurable processors being introduced by companies such as Tensilica in Santa Clara, California and ARC in Elstree, Hertfordshire, UK, bring with them new types of embedded software that allow designers to employ the configurability that is part and parcel of the processor. These types include profiling, parameterization, and compilation options.

Programmable logic vendors are also fielding products that can be considered true SoC design platforms. These include Excalibur from Altera Corp. in San Jose, California; Virtex II from Xilinx Corp. in San Jose, California; and Varicore from Actel Corp. in Santa Clara, California. For their implementation, these products depend on hardware-dependent software that is difficult to reuse. The result is an HdS landscape that is as varied as it is complex. Reusability of software components such as the ones just described will begin by requiring a rigorous process to create them.

With the use of embedded software growing in several aspects of SoC designs, one quickly begins to appreciate that it is taking a bigger and bigger portion of the people-years of development time. Just as hardware IP reuse has grown from 10 percent to 90 percent, so the configurability and complexity of the next generation of SoCs will require that software development will dominate the SoC design process in the not too distant future. Estimates of design-team people-hours spent on developing software range as high as 90 percent.(4)

Platform-based design
Until very recently, there has been little public discussion about software reuse outside the SoC community. Inside VSIA member companies such as Nokia, Motorola, ST Microelectronics, ARM, Infineon, and Alcatel, however, it is a cause for great concern. These companies have committed themselves not only to IP reuse but also to platform-based design (PBD) as a strategic solution.

Alcatel, for example, envisions its SoC implementation path as offering a steady increase in hardware and software integration and to move HW and SW codesign and covalidation earlier in the design cycle. Without platforms and reusable, deeply embedded software, these goals cannot be easily attained internally, says Frank Pospiech, HdS Program Manager at Alcatel. That firm is already deeply committed to the standards-based path in SoC development. An early adopter of VSIA standards, the company expects to improve control over its designs by profiling and packaging its own IP in the common, standard framework provided by VSIA.

Typically, casual observers have described SoC platform-based design rather simplistically as a library of cores all "guaranteed" to work together, and EDA tools that make it easier to combine the cores. In reality, SoC platforms must be built on strategic combinations of hardware and software.

Platform-based design is increasingly being recognized as a key ingredient in producing comprehensive SoC designs. "The expectation is that as the IC industry pursues the process technology evolution, companies will follow this methodology evolution," say the authors of Surviving the SoC Revolution (Kluwer Academic Publishers, 1999). Why? First, because PBD enables the VSIA goal of plug-and-play VCs by creating a commercially viable vehicle for reuse. Just as important, it will offer a more efficient means of leveraging new design technologies and methodologies, because these advances will not have to be integrated by hundreds of design teams acting independently.(5)

A popular misconception is that SoCs are simply an extension of the ASIC methodology that has been successful for two decades. This notion is not true, and the reasons are largely a matter of economics. Increasing mask and manufacturing setup costs are biasing manufacturers toward parts that have guaranteed high-volume production from a single mask set, argue Alberto Sangiovanni-Vincentelli and Grant Martin (a co-author of this white paper) in an article published in IEEE Design & Test of Computers (November-December 2001). By their very definition, however, ASICs are highly specialized, low-volume parts. Platform-based design, on the other hand, calls not only for the reuse of VCs, but also for software, architectures, and as a consequence, IC masks. "Platform-based design can trade off various aspects of manufacturing costs, nonrecurring expenses, and design productivity," say the authors. "Reuse, flexibility and efficiency are key to this approach."(6)

Viewed from the software reuse perspective, it is important to note that these hardware and software combinations are most often pre-integrated and pre-verified for particular application domains. In the future, this mixed HW and SW architecture will increase in popularity as integrators face a larger and larger physical validation and verification challenge and opt to "leave-alone" as much of a design as possible. Modifying or creating new blocks will be done with some reluctance due to design time and issues with both risk and verification.

From a PBD perspective, HdS issues become more specific-and the challenge more formidable. Here are a few examples:

• In order to establish reusability in communication between a microcontroller core and its peripherals, a bridging capability is needed that establishes a base address for each peripheral. Automatic configuration and a standard method of querying the bus for peripherals is another level of reusability.
• Multiple-processor SoCs are becoming more common, which means multiple bridges between the processors and peripherals are required, making the reusability issues more complex. In particular, multiple processors should share a unified view of the memory subsystem if they are intended to share a significant amount of data dynamically, and also have active concurrent collaborating tasks as in multimedia products. Control-oriented devices may have a number of different mechanisms for inter-processor communication and peripheral sharing.
• Interrupt domains are frequently required in SoC designs (depending on the RTOS), and the code that implements them tends to be quite specific to the scenario. Not all interrupts are time critical, however, and the reuse scenario would be to handle them with extendable standard configurations generated by configurators.
• Boot procedures for each processor are fundamental, as well as boot procedures for the entire SoC, built-in self-test routines, compilers, debuggers, and on-chip maintenance and diagnostic software. Once the degree of flexibility is captured, however, the configuration of boot-code, test-code, drivers, and so on, can be automatic.
• Chip-level configuration issues that must be addressed to establish a reuse procedure include PLL programming, system-control registers (SCUs), bus configuration registers (BCUs), device configuration registers (DCUs), and registers to program access details to external memory.

How did the HdS productivity gap happen?
Software became the stepchild of the SoC design paradigm for two reasons. First, it was beyond the tight focus of the standards efforts that proved so successful for creating reusable hardware IP. Those standards initiatives began in 1996 and were led by the VSIA. The initiatives were driven and funded for the most part by IC, EDA and systems companies desperately trying to find a way to use all of the gates Moore's Law was adding year after year. Software wasn't as great a concern in 1996 or even 1999. Designs were less complex, and whether they realized it or not, the people who solved the hardware reuse problem were taking on one problem at a time.

Second, the embedded software industry has always been fractured, with many small companies, each specializing in specific niches. As such, there was no unified voice from the software industry. Even now, the voices calling for a solution to the HdS productivity gap come mostly from inside the leading-edge systems and semiconductor houses that are developing SoC chips and platforms, and feeling most of the pain.

It should be made clear, however, that some HdS reuse is happening now. The fact that SoCs are reaching the market on time means some portability has been established. Embedded software is being interchanged, exchanged, purchased, and reused. But these steps are being accomplished with standard porting techniques, code-generation software and Java. It isn't being done efficiently, even in the relatively small number of companies where it is happening. It isn't portable outside its company of origin, and it isn't anywhere near being a VC in the way we think of hardware IP. For the majority of companies, HdS reuse is still mostly a dream -- but there is a strong desire to have it.

Time for rigor -- and standards
Few proprietary solutions for SoC software reuse exist, and those that do are not flexible enough to serve the entire industry. On the other hand, standards and standards compliance have already proven powerful enablers for HW IP reuse. Even a company as successful as ARM Ltd. has found compliance advantageous to its business objectives-and an integral part of the product development cycle. For example, all of the VCs from ARM meet or exceed the requirements of VSIA specifications, including those addressing implementation, verification, VC transfer, test, and on-chip bus.(7)

Standards are being developed in some key areas but these efforts have yet to achieve critical mass. And, none are aiming for a complete solution to the HdS productivity gap. Examples include the Object Management Group (OMG), the IEEE 1471 subcommittee (which is working on an architectural description of software-intensive systems), and the Information Technology for European Advancement. These bodies are addressing only pieces of the puzzle, and so far, there has been no comprehensive effort to tie these initiatives together and no overarching effort such as the one VSIA began in 1996 for hardware IP.

How is the industry to attack the HdS reuse problem? Probably in much the same way as it addressed the hardware IP reuse issue: with standards and rigorous processes. But where to start?

Due mostly to their unfamiliarity with hardware issues, embedded software developers prefer to approach an SoC using an application-programming interface (API). A familiar concept, APIs have proven their value in the computer world as an abstraction layer at the interface between the operating systems and applications.

Many chip architects have found it very useful to think in terms of an abstraction layer for SoC functionality. To a chip architect, one of the primary added values of a hardware abstraction layer (HAL) is that it extends the capabilities of the hardware. For example, a TCP/IP software stack adds reliable transport functionality so that it doesn't have to be implemented on chip. The TCP/IP stack also shields the software developer from the EMAC (embedded media access controller), which is implemented in hardware.

The API concept from the software world dovetails nicely with the HAL concept already in use by some chip architects. Marrying the two is an important first conceptual step toward HdS reuse.(8) Figure 3 illustrates other examples of an API as an interface to hardware functionality.

Figure 3 - API Examples

The HAL must have certain attributes in order to be a key element in a software reuse platform. First, it must be the only gateway to the hardware. It must also provide access shielding, register shielding, and functional shielding.

Although the API/HAL concept is important to addressing the embedded-software productivity gap, the challenge of defining a complete model has additional layers of complexity. In particular, we must recognize that device drivers -- not protocols such as TCP/IP -- communicate directly with the hardware. To accommodate reuse at this level, a driver transaction interface (DTI) should be added to the model. Above the DTI but still below the API, we need to find a place for functions such as stack protocol execution, file management, libraries, data I/O and operating system kernel services. One way that the model might be conceptualized can be seen in Figure 4.

Figure 4 - Below the API

The model is valuable but it raises still another issue. It requires an agreed-upon taxonomy for the model's components -- that seems simple enough. But bluntly put: Without an agreed upon set of definitions and classifications, embedded software reuse cannot happen.

To complete the scope of a reuse model, note that HdS also includes SoC debug and test and embedded software that executes in hardware such as DSP algorithms and bootstrap procedures at the bottom layers of the RTOS.

Roadmap to a solution
Clearly, a great deal of work lies ahead for the industry if the HdS productivity gap is to be bridged. One of the underlying problems, however, is that although there is a recognized need for HdS reuse, there is not, as yet, a compelling economic model to fashion a broad-based solution.

In other words, the industry is at virtually the same crossroads where it found itself in 1996 with hardware IP reuse. Its challenge is the same: to move from a scenario of 10 percent software reuse to 90 percent reuse in a relatively short period of time.(4) This rapid evolution is shown in Figure 5.

Figure 5 - The HdS Revolution

The solution for hardware IP reuse was a standards operation that sought contributions from all of the stakeholders in the then fledgling SoC industry: EDA companies, IC companies and large systems houses that needed SoCs to continue to deliver ever more highly integrated versions of ever more complex products. The SoC industry has largely answered that challenge.

Beginning in 1996, VSIA has identified and isolated the nature and complexities of the HW IP problem, taking the following steps:

• Worked with companies from all parts of the industry until a critical mass of membership was recruited.
• Set up working groups staffed by volunteers
• Received contributions of IP from member companies
• Launched a media campaign to inform the semiconductor community at large of the problem
• Created specifications and standards for HW reuse along with an exhaustive listing of VC attributes and deliverables.

It is now time to begin the process over again -- this time for HdS and platform-based design. With the experience VSIA acquired over the past five years, however, the effort should make faster progress. VSIA cannot do it alone, of course, because the nature of HdS reuse reaches into other technology areas. Fortunately, a number of more limited standards efforts are already underway at several organizations. What is lacking is an organization to stitch these worthy efforts together and to identify and fill the gaps that no other organization is addressing. VSIA has the experience with hardware IP reuse, making it the natural candidate to fill that role.

The VSIA created an organizational infrastructure to address the HdS productivity gap. At its September 2001 meeting, the VSIA Board approved the formation of the Hardware dependent Software (HdS) Development Working Group (DWG) chaired by Frank Pospiech at Alcatel and Michael Kaskowitz at Mentor Graphics. The Board also approved the formation of a Platform-Based Design (PBD) Study Group, which will be chaired by Bob Altizer at Motorola and John Goodenough at ARM. Together with VSIA staff, these new groups will engage the SoC industry in the same kind of recruitment, consensus building, and standards efforts that it developed in the hardware IP standards initiative.

HdS reuse will benefit everyone. The resulting guidelines, standards, and precisely defined deliverables will keep the SoC industry on its robust growth curve. On the other hand, if the industry does not seek a cooperative solution under the aegis of a non-partisan body, it will remain confused and unable to realize the promise of platform-based design.

Jack Shandle is a consultant and freelance writer who was formerly chief editor of ChipCenter.com and Electronic Design. He has a bachelor's degree in electrical engineering.

Grant Martin is a fellow in the labs of Cadence Design Systems. His research interests include system-level design, systems on chips, platform-based design and embedded software.

References:
1. L. Cooke, "VSIA's Role in the World of SoCs," VSI Alliance Presentation, Oct. 2001.
2. "NRE Charges for SoC Designs to Hit $1M, Study Says," Semiconductor Business News, Oct. 1999.
3. Gary Smith, "The Embedded Software Design Crisis," Dataquest Presentation, VSI Alliance, Oct. 2001.
4. L. Cooke, VSIA's Role in the World of SoCs, VSI Alliance Presentation, Oct. 2001.
5. H. Chang et al., Surviving the SoC Revolution: A Guide to Platform-Based Design, Kluwer Academic Publishers, Norwell, Mass., 1999.
6. A. Sangiovanni-Vincentelli and G. Martin, "Platform-Based Design and Software Design Methodology for Embedded Systems," IEEE Trans. Design & Test of Computers, Nov.-Dec. 2001.
7. "VSIA Adoption and Use Report," VSI Alliance, Nov. 2001.
8. G. Martin and B. Altizer, "VSIA Embedded Systems Study Group Conclusions and Recommendations"