Vol 15, Issue 23

June 25, 2001

The Hardware People: At It Again

By Max Baron

An increasing number of chips are being designed to perform specialized functions in systems, but there have been only a few corresponding introductions of new operating systems and compilers. This situation already happened once, when computers were in their infancy and hardware design predated software programming. A quick look back may be in order.

In the beginning, as some old computer books maintain, people began building computers for use by math and physics scientists. The scientists presumably took great delight in using toggle switches to enter data into registers, bit by bit, before running short programs at breakneck frequencies of thousands of cycles per second. The builders of these computers, later referred to as "the hardware people," soon started getting complaints from the writers of programs, later known as "the software people." The hardware people were designing computers that were hard to use. The software people wanted to increase programming and debugging efficiency. The hardware people needed to save memory and CPU components. Both groups were eager to increase performance.

Leapfrogging each other rather slowly, as they gained experience in computer architecture and programming, hardware and software engineers developed efficient operating systems and compilers and brought improvements to processor architecture. Earlier, however, at the beginning, the software people wished for a magical, programmatic way that would allow them to directly create hardware architectures to fit each and every class of application. And, as is often the case with wishes, people should be careful about them, because this one was granted.

Thanks to impressive advances in design tools, it has become possible for hardware architects to write programs that generate specialized processors and state machines. Processor design has become widespread, due to migration of engineering talent from one company to another, better research tools, and an accumulation of literature on the subject. Hardware engineers can now integrate multiple different processors on one chip, although not without some difficulty and risk. They can deliver computing power for embedded systems that couldn't be built before.

Having been granted the wish, software engineers now face the task of creating the programs and managing the resources of systems whose complexity goes far beyond that of a general-purpose computer. The relatively comfortable model of one processor running an operating system to manage system resources is no longer suitable. Intended at first for single-processor systems that drive relatively slow peripherals, this type of operating system has also been the basis for symmetrical multiprocessing: it provided each processor with an environment that allowed it to operate almost as if it were the only one in the system.

Today's embedded systems are far more demanding. Combinations of different microprocessors, DSPs, and custom processors are beginning to populate systems that previously used analog components. Analog functions like rotation of antennas and amplification of signals in radio receivers can be executed by DSP devices. These devices may, in turn, connect to other digital engines that manage communications, correct errors, decrypt data, and decompress video and audio. System block diagrams are beginning to look like factory assembly lines that use different processors and special engines to execute different tasks at aggregate speeds that would intimidate even the fastest single processor. Several assembly lines of this kind may be required to concurrently run and intercommunicate, to ensure overall system performance.

Inside complex systems, special processors come from different design groups. They are delivered with their own machine language and home-brew additions to C or C++ and may have no operating-system port, due to small-volume expectations. Some vendors see no need for an operating system: they expect the system programmer to provide the glue. Lacking a common set of processor abstractions, OEM companies must therefore assign dedicated engineers to learn, use, and maintain special-purpose processors.

An adequate operating system must manage and optimize a heterogeneous system's high-speed resources. Some OS vendors are already proposing operating systems that could support the new and more-complex structures: Virtuoso (from Wind River's Eonics group) and Enea (from OSE Systems) are examples of the new thinking. Virtuoso virtualizes the processor, which, in a few words, means that the operating system uses a model of a processor and the generic communications it must conduct with other processors. This abstract model can be used (well, most of the time), irrespective of the processor it represents or the tasks it must accomplish. Enea uses a virtual model of processes, following the same broad principles outlined for the processor. It stands to reason that both may be able to envelop several virtualized elements into a single higher-level virtual element. With processes that can define and manage the work of a whole "assembly line," Enea's approach may be more efficient as a system manager than Virtuoso's. It may, however, be less efficient in managing the processors, which is where Virtuoso's strengths will come into play.

Combining both models may be feasible if the resulting software overhead is not prohibitive. Teja, a company that focuses on network-processor operating systems, is working to provide a higher level of programming abstraction, beyond assembly language and C. Abstractions can introduce compatibility between network processors and can be applied to other specialized architectures and the programming models they employ. Teja's processor-neutral Network Processing Operating System adheres to a tiered operating-system approach and is designed to work under control-plane operating systems.

Whether from lack of theoretical concepts or for proprietary reasons, software development tools and operating systems are still supporting parts of the problem instead of solving the whole problem. Once more, the hardware and software people need to embark on a new journey, this time one that will lead them to an understanding of distributed processing.