Embedding software in the SoC World

Embedding software in the SoC World
By Frank Pospiech and Stephen Olsen , EE Times
September 19, 2003 (12:11 p.m. EST)
URL: http://www.eetimes.com/story/OEG20030919S0046

The semiconductor industry continues to follow Moore's Law, doubling the complexity of ICs every 18 months, to the point where it will soon be able to manufacture chips with 100 million gates. Entire systems can fit in less area, so just as the hardware design industry has begun to accept the need for design reuse as a way to manage its exorbitantly increasing design cost, the playing field is changing.

Now that whole systems can be put on a single piece of silicon, IC design is as much a software design challenge as it was a hardware design problem. Today's typical system-on-chip (SoC) design includes two or more processors, memory, dedicated subsystems specific to the application and a complex, sometimes hierarchical, communications system among them. These chips contain multiprocessor real-time operating systems (RTOS), complete with I/O drivers, utilities and diagnostic subsystems along with their specific software applications. The exploding c omplexity of software in these new SoC designs has already resulted in the cost of software design exceeding the cost of hardware design for some of the more complex ones.

Looking at this total complexity increase, the question now is not how to manage just the SoC hardware design cost but how to manage the total SoC design cost. Finding the solution is virtually impossible without a deep understanding of what embedded software in the world of SoC actually means, what SoC software design costs are and how an embedded software design flow really works.

To design complex chips, architects start with a high-level concept that they translate into a high-level functional model. This model reflects the basic functions of their system but contains no distinction between the software and hardware. In the process of defining the appropriate hardware architecture for the design, they must separate which parts of the function belong in hardware and which 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. This has been done, and probably will continue to be done, by a few high-level architects.

The process of translating a cycle-accurate architectural model down to the actual silicon design is well understood and practiced, with sufficient design reuse and existing hardware design techniques. Likewise, there are no problems with translating the partitioned functional software components into code for the finished working SoC.

However, what remains an obstacle is the efficient hardware/software interface design and implementation. This is now becoming one of the most significant and growing efforts in SoC design. It is clear that efficient hardware/software interface design is not possible without sufficient understanding of the other world's architectural principles, methods and tools.

What does efficient interface design mean in this context? First, those interfaces need to allow hard ware and software designers to design their parts as independently as possible from one another, just to be able to parallelize their design processes.

Second, those interfaces have to be standardized. With the always increasing number of hardware architectures on the market, software adaptations to any one of them become much too expensive. Ideally, some standard APIs could help to retain portability across different hardware platforms.

Third, the way these interfaces are designed, as well as how the overall SoC design process is followed, must take into account--besides the “classical” hardware design flow--the way modern embedded software development works. All this leads to a change in the SoC design paradigm, which now becomes much more software-centric than it has been.

As we look at the overall SoC development costs, the software/hardware design ratio exceeds 2-to-1. While the development of the hardware and the software parts could easily be done in parallel, a greater effort must be spen t to verify and validate the complete SoC. Meanwhile, verification and validation costs make up to 60 percent of overall SoC design costs.

Understanding how software works and how it interacts with the hardware can greatly reduce the overall verification complexity and hence the cost. Currently, verification and validation of the SoC largely rely on hardware testbenches to test the hardware with the help of some software deeply embedded inside the SoC that is present to test the more complex internals of the chip.

There needs to be a methodology that will allow system designers to model the core components irrespective of their hardware or software domain. Unlike general-purpose systems--like personal computers--embedded systems are dedicated ones. They serve a well-defined purpose and usually all resources in the system are dimensioned according to their purpose.

Embedded systems typically interact with physical processes, be it via sensors, actuators or the like. But unlike general-purpose sys tems, critical properties of embedded systems tend to be nonfunctional: real-time, fault recovery, power, security or robustness. They typically have to interact concurrently with multiple processes and must operate at the speed of their environment.

Simplistically speaking, embedded software is software designed for and running on embedded systems. Since many of the properties mentioned before are actually implemented in hardware, one of the most important properties of embedded software is its close link to hardware. That link is demonstrated not only by compiling for the direct hardware dependence, but also through intimate knowledge of the hardware specifics (for instance, register and interrupt structures). Some of the properties mentioned above are increasingly implemented in software, or directly influence the way to write embedded software. The classical example is real time.

The RTOS plays an important role in embedded software. Besides serving as a layer on top of which parts of the embedde d software can be implemented relatively independent from the actual hardware platform, the RTOS also provides a framework into which plug hardware drivers.

Embedded software itself can be structured into different software layers:

Hardware-dependent software (HdS), all software that is directly dependent on the underlying hardware.

Hardware-independent middleware, or application software, that runs on top of the HdS.

The RTOS as a vertical “layer” that offers services that span both hardware-dependent and independent parts that may be used by all the other embedded software layers.

The HdS layer must expose hardware internal features in a way that releases developers of higher layer software from requiring too much processor-specific knowledge. Ideally, the SoC functionality should be exposed in a way that completely hides details of the underlying hardware platform and its evolution. The best way to do so is via a functional API, the so-called HdS-API.

While application software is reusable and portable because it is largely independent of actual hardware platforms, embedded software must be structured so as to achieve portability or reuse. For instance, highly optimized DSP algorithms take full advantage of each hardware feature. However, for this kind of software, reuse methodologies are rather difficult to apply.

The embedded-software-development process has to take into account its specific dependencies on the hardware and software development cycles. The specification of APIs must be a condition for starting the application software design. On the other hand, the embedded software design can't be finished before the final hardware prototype is available. Many techniques to decouple hardware and embedded software development are being investigated or are available in first products. Most of these techniques try to provide early hardware models, which are on an interface level identical to that of the later prototype.

In general, the embedded software process follows clas sical software development paradigms. Usually all of the phases, like specification; top-level design; detailed design; implementation; unit test, integration and integration test; and system qualification and acceptance test can be found as well. However, integration and integration test here mainly means integration with the hardware platform. By its nature, embedded software design deals with hardware-specific tools, like instruction-set simulators, hardware simulators and emulators, and distributed debuggers.

Models on parade

The use of models in software is steadily increasing. This way software engineering gets closer to classical engineering disciplines. Based on executable models, automatic code generation becomes possible.

Unified Modeling Language, or UML, is based on the concept of the object. The idea is that all features (procedures, data) of a logical unit are combined into a single package called an object. A software system is defined as a structure of collaborating objects .

An SoC can be regarded as an API to embedded software developers, so the SoC should have an abstraction layer, which exposes its functionality. We call it Hardware Abstraction Layer (HAL). The HAL might even enhance the SoC's capabilities while it hides hardware details that are irrelevant for upper layer software implementations. A typical example is an RTOS board support package), which hides the processor internal timer and interrupt dispatching, but adds multitasking and time functions.

So it is useful to develop a standard abstraction for the software that “sits directly on top” of the hardware, that is, HdS. Examples are:

Hardware drivers.

Boot strategy, load.

Built-in tests (basic level, offline tests).

Hardware-dependent parts of communication stacks.

Algorithms implemented in software on DSP.

The main purpose of HdS is to shield the hardware for upper-layer application software. Ideally, this software communicates with the hardware platform via stable API s only. Another motivation to define HdS is retaining portability across various simulation and target environments.

Frank Pospiech is HdS program manager in the CTO hardware coordination department at Alcatel (Nanterre and Paris, France), and Stephen Olsen is senior software engineering manager for the IP division of Mentor Graphics Corp. (San Jose, Calif.).