Net embedded software to grow

Net embedded software to grow
Even as many embedded software-tool and operating-system companies trade punches with Microsoft Corp. over the potentially highly profitable net-centric computing device market populated by Web-enabled set-top boxes, Internet-enabled wireless information appliances and cell phones, their attention is divided. At the same time they are struggling with Microsoft, which finds these net-centric computing devices well fitted to the "feature-rich" marketing strategies and applications software it developed on the desktop, embedded companies are also trying to figure out how to address some fundamental changes in the nature of computing. In particular, companies are mulling over approaches to the embedded computing that is emerging from the datacom/telecom and networking infrastructure.

Here, new embedded processors are emerging to handle the gigahertz clock rate and multigigabit/second bandwidth requirements that networks need to feed the ever-increasing hunger of corporations and individuals for Web access.

CPU vendors are finding that their traditional sequentially programmable von Neumann and Harvard architecture RISC machines are inadequate for this new environment. Indeed, it is data flow, not data processing or event control, which is most important. Moreover, this new environment is not one in which two or three or 10 sequentially programmed processors would fill the bill. Instead, this market needs highly parallelized data flow processors operating in multiprocessor configurations ranging from tens to hundreds, each of which are internally highly parallel and concurrent in design.

The upshot, according to Robert Monkman, vice president of marketing for Core OS and tools at OSE Systems Inc. (San Jose, Calif.), is that embedded-software developers and companies face one of the most complex, nuanced and demanding environments in which they have ever had to compete.

For one thing, issues of performance, real-time response and the degree of determinism required by hardware used in different segments of the market remain unresolved. In the network core where data rates fall in the 10- to 100-Gbit/s range, in equipment that fits into local telecom switching centers and wireless bay stations that deal with data rates in the 1- to 10-Gbit/s range and from the curb to the premises where data rates range from as low as a few tens of thousands to several millions of bits per second, problems must be addressed.

Monkman also noted that in the embedded applications, datacom and networking arenas, areas of differentiation exist: data plane processors concerned only with moving packets; control plane processors that provide the directions for the data plane processors for packet verification, classification, modification, compression and decompression, encryption and decryption, and traffic shaping; and management plane processors, mostly server based, providing the back-end accounting and billing services.

In addition, depending on the segment and performance requirements, a variety of hardware architectural solutions are being employed to create a range of specialized data flow engines: totally new, highly parallelized processors; multiprocessor arrays of existing sequential-flow RISC processors; and single-chip arrays of multiple processing elements; to name a few.

According to Russell Dietz, chief technical officer at Hifn Inc. (San Jose), chair of the Network Processing Forum's Hardware Working Group and a member of its Software Working Group, the challenges embedded developers and companies face in 2002 lie in three areas: operating-system design, programming methodologies and application programming interfaces.

Operating-system vendors are trying to impose a range of solutions that, while superficially similar, differ in subtle ways that could affect their usefulness in the different niches: object vs. process kernels; microkernel vs. monolithic kernel; direct interprocess communications-based messaging vs. indirect message/mailbox mechanisms; coarse- or fine-grained memory protection; and task-based vs. driver-based interrupt structures.

Embedded-software vendors seem to have a handle on this problem with new OS extensions and upgrades that address several issues in this radically new embedded market. Most new OS implementations for this market include extensive multiprocessing support; quick, efficient, direct-messaging capabilities between cooperating elements within a specific location and throughout a network; fine-grained memory segmentation and protection; high availability; in-service upgrade capability; heartbeat services and checkpointing to allow more-sophisticated failure detection; and sophisticated failure-recovery mechanisms.

Less well-defined are the strategies that must be taken to deal with the new programming methodologies and the diversity of application programming interfaces that are emerging in this market.

"Generally, most of the major RTOS [real-time operating system] vendors who are making a major play in the telecom/datacom and networking environment have been moving in these directions," OSE's Monkman said. "The big question is how to get from what is available now to what is needed in the new network computing environment. Do you adapt and evolve an existing RTOS to the new requirements, or do you start from scratch with an RTOS with all of the key features part and parcel of its fundamental architecture?"

Programming notes
The difficulty programmers face in this new embedded environment has to do with the concurrency models that most conventional processor architectures use. These models originally were conceived when multitasking was expensive and programmers had to use threads sparingly. In most traditional OSes threads are associated with one of two things: specific pieces of code or instances of large objects. The result is software with many threads that are interdependent, and thus spend a lot of time waiting on each other. The problem for programmers is that the data flow environments found in routers and switches using network processors are event driven, deterministic and real-time to a degree that would give most embedded developers nightmares, full of asynchronous and concurrent interactions.

However, the programming languages and techniques in common use now, and the code that results, is sequential. Developers writing in C and C++, for example, must take highly parallel operations and convert them all into a sequential series of statements: functions, callbacks, control blocks, data structure and link lists. This process is time-consuming to a painful degree, and the code that results does not make efficient use of the computing resources, to the detriment of the overall throughput of the system.

The decisions facing developers and the companies that supply the programming tools, said Hifn's Dietz, are to accept inefficiencies and try to make up the difference in faster processors, memory and interconnect; switch to programming languages based on alternative concurrency models; develop explicitly parallel programming tools and methodologies to ease the transition for developers from the sequential approach; or shift to implicitly parallel strategies in which programmers are allowed to do development sequentially and use parallelizing compilers to convert the code.

Beyond the issue of parallelism, Dietz said, network processors are forcing embedded developers to think the unthinkable: shift not to just another type of procedural language, albeit much more parallel in orientation, but to an entirely nonprocedural language modality with a more function-oriented programming paradigm.

Used as teaching tools in colleges and universities, the advantage of functional languages such as Caml, Scheme, Opal and Haskell in that environment is that they allow programs to be written primarily to perform some task. Functional languages, Dietz said, are being investigated for the network-processing environment because they are good at implementing mathematical algorithms — such as extracting data from a table or performing a calculation and then executing some sort of control function based on that calculation. In many network applications in the control and data plane, a lot of time is spent accumulating tables, calculating results and then forwarding a packet based on the values calculated. "In this environment, a procedural language would be concerned with the execution of a specific protocol," Dietz said, "whereas a functional language would go down one step." The trade-off is that you gain more efficient control of device resources at a level somewhat higher than machine/assembly coding, but it is not as sophisticated as high-level procedural code that is easier to write and implement.

One quality that makes a functional language attractive in the network-processing environment, Dietz said, is that it strictly defines an operation in terms of the function to be performed, not as a set of procedures to be followed with a single object. With a procedural language, process and methodologies and the objects called change, depending on the return result from a call.

General language
Because of perceived benefits, organizations such as the Network Processing Forum are looking seriously at developing a general-purpose functional language with some procedural features specific to this new environment. A number of companies, including Agere, AMCC, Intel, Motorola and Solidum, each have developed their own functional-language implementations. Work in this area continues at other companies.

"It is really important that we come to some common agreement on the nature of the programming language methodologies that we use," Dietz said. "Otherwise we are going to be faced with a diversity of language alternatives: procedural, nonprocedural, parallel, sequential and functional. Not only will that make it difficult for CPU makers to convince developers to use their architectures, it will slow down the development process and increase its cost. It will also make life extraordinarily difficult for the programmer and developer."

See related chart