Embedded Processor Watch

Editor: Cary D. Snyder

Contributors to this issue: Max Baron, Amir Eyal and Markus Levy

In This Issue:

• The Hardware People: At It Again
• Challenges in Designing 40Gb Network Processors
• IBM SoCs Into Info Appliances

Have you noticed how many microprocessors, DSPs, and configurable processors are introduced every year? Out of 70 excellent proposals, MicroDesign Resources had to go through the painful process of selecting the best 35 that it could showcase in three days of Embedded Processor Forum. 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.

Challenges in Designing 40Gb Network Processors
By Amir Eyal {6/18/01-02}

As the escalating demand for more bandwidth continues, 40Gb/OC-768 networks mark the new frontier that networking equipment vendors will be venturing to explore. Network processors, fast emerging as key components in newly developed 2.5Gb/OC-48 and 10Gb/OC-192 platforms, will also empower the 40Gb/OC-768 platforms.

Network processor architectures targeting 2.5Gb and 10Gb networking differ from one vendor to the next, and 40Gb designs will not be an exception. However, packet processing at 40Gb line rates presents significant challenges to network processor designs. The challenges are magnified, as silicon-process advances trail behind increasing networking speeds: on average, silicon density doubles every year, whereas network speeds quadruple. Therefore, the transition from 10Gb solutions to 40Gb solutions presents an even greater challenge than that from 2.5Gb to 10Gb processing. Successful design of 40Gb network processors must take into account the following:

• Completing required packet processing within an extremely short frame-time
• Providing buffer and lookup-table memory with sufficient bandwidth
• Providing a smooth software-migration path from 10Gb systems
• Implementing interfaces to surrounding devices
• Maintaining manageable load levels on the control processor

System vendors looking to use a network processor in their next-generation platform should look for a solution that will meet their current needs (e.g., 10Gb processing). The solution should also provide them with a smooth migration path to 40Gb networking-by scaling the same architecture, running the same software, and meeting the challenges outlined above. (The full version of this article is available online to Microprocessor Report subscribers at http://www.mdronline.com/mpr/h/2001/0618/152502.html).

IBM SoCs Into Info Appliances
Improving on Custom Silicon Methods
By Markus Levy {7/9/01-01}

At the recent Embedded Processor Forum, the audience had the opportunity to learn about IBM's system-on-a-chip method for building information appliance platforms. The company has developed an ASIC design strategy that allows its customers to springboard off a reference platform that was collaboratively developed by IBM and Sanyo. This article discusses the proprietary and public methods that include static timing analysis, architectural verification, test-pattern generation, and synthesis. (The full version of this article is available online to Microprocessor Report subscribers at http://www.mdronline.com/mpr/h/2001/0709/152801.html).