API will bridge HW/SW design gap

A typical system-on-chip (SoC) design has two or more processors, memory, one or more dedicated subsystems specific to the application and a complex, sometimes hierarchical communications system between them. As such, these chips contain multiprocessor real-time operating systems, complete with I/O drivers, utilities and diagnostic subsystems, along with their specific software applications. The exploding complexity of software in these new SoC designs has already resulted in the software design costs exceeding the hardware design costs for some of the more complex designs. The problem now is how to manage that software cost. So where can improvements be made?

Let's begin by looking at the SoC design process. Chip architects start with a high-level concept, which they translate into a high-level functional model. They then define the appropriate hardware architecture for the design, and separate out which parts of the function belong in hardware and which parts belong in software. This is typically done by reorganizing the functional model into its hardware and software components, along with a model of the communication between them into a cycle-approximate model.

Beyond this, the process of translating a cycle-accurate architectural model down to the actual silicon design is becoming manageable, with sufficient design reuse and existing hardware design techniques, as is the process of translating the partitioned functional software components into code for the finished, working SoC. This leaves the hardware/software interface design and implementation, which is becoming the most significant effort in SoC design.

Mapping to a specific architecture requires inserting all the layers from the application interface, through the operating system, I/O subsystem, processors a nd communications hardware between the software and hardware models. Even with off-the-shelf processor cores and real-time operating systems (RTOSes), a large amount of custom hardware-dependent software is needed to integrate these components together. While much of the code is repetitive, it represents such a large effort that there is a reluctance to change the RTOS and processors used by the applications to minimize the effort, often resulting in less-than-optimal architectures for the design.

One solution to software reuse is to use standard application programming interfaces (APIs), such as Posix (the IEEE standard P1003.1 Portable Operating System Interface X), between the RTOS and applications interface. It defines a minimal standard set of common OS commands to make applications more portable. The existing versions were developed from Unix, for computer systems, but vendors are now developing extensions for embedded RTOSes.

Standards also exist on the hardware side. The Virtual Socke t Interface Alliance's Virtual Component Interface (VCI) recently merged with the Open Core Protocol (OCP) of the Open Core Protocol International Partnership (Portland, Ore.), to make hardware intellectual property more portable with a common bus interface.

With the hardware and software standards, a common set of OCP/VCI transaction-level operations, corresponding to a subset of Posix commands, can be used to construct a generalized communications module. Those high-level functional modules for software and hardware can then be mapped to a combination of reusable hardware and software modules containing Posix and OCP/VCI interfaces, and connected to a communications module via the APIs. This frees the SoC developers to focus on the new modules and on integrating the RTOS, processor and communications systems together.

To reuse the hardware-dependent software modules, it is necessary to expand such a generalized communications module into the hardware-dependent software, the actual RTOS and the processors. If a standard existed between the RTOS and the hardware-dependent software of the system, the generalized communications model described above could be translated into a specific RTOS environment, the actual bus architecture and a translation module. The translation module would translate from this new API to the bus interface a set of standard test or diagnostic interfaces and custom hardware controls created for the SoC design. This new API could shield the software above from the address-specific information below. Specification of these initialization registers and device ad-dresses could then be assigned through traditional link-and-load operations via hardware tables such as those defined when generating or configuring operating systems to their underlying processors.

This hardware-dependent software API should have I/O operations similar to those in the standard OS (such as Posix) and bus (such as OCP/VCI) interfaces. The I/O drivers, diagnostic modules and hardware-dependent k ernels of the RTOS could be developed to interface to this API, making them portable over a wide range of processors and applications. This would limit the amount of custom hardware-dependent software. With this API, the next step in the design process-to replace the lower-level communications module with the actual hardware-dependent software and corresponding communications hardware-could then be highly automated, virtually eliminating this component of the escalating SoC development effort.

VSIA's hardware-dependent software effort is developing just such an API. It will make it easier to move an application and, more important, the associated communication layer below the RTOS from one hardware environment to another.

Larry Cooke is vice president of business development at the Virtual Socket Interface Alliance (San Jose, Calif.; www.vsia.org).

See related chart