VSIA takes hard look at embedded software reuse

VSIA this week will reveal that its hardware-dependent software (HdS) DWG has been meeting quietly since November. Additionally, the alliance has set up a platform-based design (PDB) study group, which is working on a taxonomy for platform-based design and which may someday turn into a DWG that can craft standards.

Another cusp

Larry Cooke, vice president of marketing for VSIA, said the organization was launched six years ago be cause of a compelling need for hardware IP reuse. "Now we're at another cusp, where instead of just having a very large chip we have a whole system-on-chip," he said. "As we look forward, we see the same problem we saw with hardware, only it's with software."

Cooke said that SoCs are approaching a "crossover" point at which embedded software development costs are starting to exceed hardware design costs. That trend will accelerate, he said.

Systems-on-chip "are becoming more and more software-oriented," said Anssi Haverinen, research manager for Nokia's research center in Boston and a member of the HdS DWG. "The HdS effort is part of the hardware reuse effort, because to reuse a hardware block you have to be able to write software for it. We want a standard API for hardware-dependent software."

Haverinen said he's most interested in reusing such software as DSP tasks and hardware control code. "We don't care so much about the applications software, because there are standard operating systems," he said. But when it comes to hardware-dependent software, he said, there are no standards, and all current solutions are proprietary.

The VSIA announcement is a "very important move," said Gartner Dataquest analyst Daya Nadamuni. "Until now, with the exception of Mentor Graphics and to a small extent Cadence, embedded software has been completely ignored by EDA vendors and by the hardware side in general."

VSIA is being very specific about the type of software it's focusing on. Hardware-dependent software, Cooke said, is exactly what the name implies — software that interacts directly with the underlying hardware. Examples include device drivers, DSP algorithms, networking and protocol stacks, embedded controllers, debugging software and real-time operating system (RTOS) elements that interact with hardware. Not included are applications that are insulated from hardware.

Hardware connection

"Most SoC developers who want to buy hardware IP, such as a PCI or USB interface, would like to buy software drivers along with it," Cooke said. As such, he noted, there's a need for software virtual components — elements that, like hardware VCs, are crafted in accordance with standards for reuse.

There's not a lot of reuse today, Cooke said. "Device drivers and other software directly connected to hardware do not have an abstraction layer that allows you to use them elsewhere," he said. "If you have a device driver for a particular SoC, you need to rewrite it to move it to another SoC. There are different bus characteristics, port addresses and protocols for interacting with the rest of the system, even with the same RTOS."

That's where the HdS DWG comes in. One of its tasks is to develop application-programming interfaces (APIs) that will define a "hardware abstraction layer" for embedded software. That layer will abstract out enough hardware details so that software developers won't have to worry about SoC-specific addresses, protocols and ot her hardware features. Such a layer won't necessarily slow software performance, Cooke said. "It depends on how you do it. If there's a translation table built into the software, yes, there's a potential delay. But if you're compiling some of these things in, there may not be a hit at all."

One issue to be resolved with APIs, Cooke said, is the creation of APIs for single-processor and multiprocessor systems. Another question is whether there can be a broadly applicable standard or whether there will need to be separate APIs for such applications as wireless and multimedia.

The HdS DWG is also chartered to define or extend existing VSIA specifications to software IP. For example, Cooke said, the bus transaction language proposed by VSIA's on-chip bus DWG may serve as a starting point for software-hardware communications.

Another HdS DWG task is to come up with a taxonomy and set of definitions "so we're all speaking the same language," Cooke said. The current plan is to have the taxon omy finished in the first half of 2002, have a draft proposal for one or more APIs in the second half of the year and to create the first version of a software VC specification sometime in 2002.

Current HdS DWG members include Alcatel, Analog Devices, Beach Solutions, Cadence Design Systems, Infineon, Mentor Graphics, Nokia, Synopsys, ST-Microelectronics and Toshiba. Michael Kaskowitz, vice president of Mentor's embedded systems division, co-chairs the group with Frank Pospiech, hardware coordinator and HdS program manager at Alcatel.

Laying the groundwork

The PBD study group has also been meeting since November. Since it's a study group rather than a DWG, it can't create standards. What it will do, Cooke said, is develop a taxonomy of definitions and lay the groundwork for a future DWG that can create standards documents.

"What's interesting about platform-based design is that if you get a group of people into a room who think they know what it is, there will be a t least one more definition than the number of people in the room," Cooke quipped.

Members of the PBD study group hail from such entities as Alcatel, ARM, Cadence, Infineon, the Japan Special Interest Group, Mentor Graphics, Motorola, Nokia, Palmchip, Philips, Synopsys and Toshiba.