ESC presenters address growing relability/processing concerns

Developers at Embedded Systems Conference (March 12-16, San Francisco) plan to address the need for better design methodologies and new ways to use old ones to match their design specs to tougher market demands that include higher reliability, better performance, low power consumption and improved quality.

Reliability and security are two areas where changes are urgently needed, the developers note in papers to be delivered at the conference, especially with regard to the new, more open and more demanding connected environment, where multiple sources of unpredictable behavior could cause a system to crash. According to ESC abstracts, embedded development calls for improvements in traditional software programming techniques; honing debug and testing skills; extending the range of hardware to include more DSP and network processor architectures; optimizing operating systems; looking at new communications protocols; boosting real-time performance; investigating new development methodologies; and finding ways to integrate hardware and software development in the context of the new system-on-chip (SoC) technologies that developers of million-gate ASICs and FPGAs are making available.

Of particular concern to the developers is the need for new or revamped programming models and methodologies. Software tool and language development historically have been incremental, but the 24/7 reliability constraints of netcentric computing have changed that, adding an urgency and characteristics to the mix that embedded developers previously associated only with aerospace, medical and military applications.

In his ESC presentation (Class 305), Doron Drusinsky, president of Time-Rover Inc. (Cupertino, Calif.), will point out that embedded designers need to abandon their largely ad hoc methods of testing and debug. Well-designed application programs often include exception-handling routines to gracefully resolve anomalous behavior by the app or its operating system, he notes, but their effectiveness depends on the engineer's ability to anticipate every possible cause for errant operation. That's a tall order for embedded applications that run in reactive systems, because they interact nonstop with an environment that can produce streams of unexpected inputs.

The only way to resolve these kinds of problems is to harness formal specification statements, a strategy that usually is used in scientific computing and only the largest of software development projects. "Intended for run-time verification of an application's design, formal specifications can be translated by a code generator into C, C++ or Java statements to be deployed for catching exceptions in the final product," Drusinsky writes. "Using formal specifications to generate exception-handling routines produces a robust hybrid program having multiple levels of recovery paths. The additional levels shield the application from worst-case scenarios that would otherwise crash it."

That is the same message Michael T. Trader, senior applied specialist, Embedded Solutions Business Unit, EDS (Detroit) will discuss in his paper (Class 461) about developers using more formal inspection procedures. While conducting such processes is on the bottom of most developers' priority lists, such practices can eliminate a number of problems that could cripple a project, increase its cost and delay its time-to-market.

Solid numbers back up Trader's view. "AT&T studied the results of inspections and found that they led to a 14 percent increase in productivity and a tenfold increase in quality," Trader claims. "And HP found that, on average, it took four hours to find and eliminate one defect, while 4.4 defects were found via inspections. Additionally, IBM has found that inspections remove 82 percent of defects before testing the code."

Given these results, Trader writes, it is ironic that many developers will not do inspections unless forced to. "Formal methods and procedures have a perceived 'hassle' factor," he notes, attributing some of this attitude to "sloppy and sometimes overzealous application of the process to projects where the value has not been explained or proven to the team. Software engineers do not respond well to edict, they must internalize process as value-added or they will constantly fight it, ultimately moving to projects or companies where they perceive more individual freedom."

Embedded designers are also grappling with the changing nature of applications, the processor features required to satisfy them; the complex nature of real-time and the deterministic requirements it imposes. Developers face a number of questions that are forcing them to consider now tools and methods of analysis: What mix of DSP and RISC is appropriate? How do you achieve real-time operation in a network environment that imposes heavy demands on the processor's hardware and software's ability to perform multitasking? What is the exact nature of the real-time requirements, and will multitasking on a single processor be the best approach or is a multiprocessor approach required? Finally, what is the best way to identify and quantify the real-time requirements in the much more open environment of network applications?

In many embedded applications where wireless communication is the core, or is the mechanism by which the embedded designer is linking various control elements, for example, developers must decide how much DSP and how much RISC a design requires. In his presentation (Class 340), Jeff Bier, general manager at Berkely Design Technology Inc. (Berkeley, Calif.), notes that many designs call for a single-chip solution, but choosing an appropriate solution entails trade-offs. Five different combinations dominate the choices available to developers: conventional DSPs, enhanced conventional DSPs, VLIW-based DSPs, superscalar DSPs and DSP-enhanced general-purpose processors (GPPs). IN an embedded environment, developers have to deal not only with the specific real-time requirements of the application, but the degree to which a specific architecture finds support from appropriate development tools.

According to Bier, aggressive marketing strategies only complicate life for developers. "Selecting a processor requires consideration of factors such as development cost and risk, system cost, energy efficiency and speed," he said. "Many of these factors are difficult to measure, and vendors do not always provide enough information to evaluate the suitability of a processor to an application." The situation is growing more complex as vendors continue to introduce new solutions, and as the requirements of DSP applications change. Thus, Bier, says, system designers should take advantage of independent analysis of application requirements and of processor technology.

Yet, even if developers are able to select a design with the correct mix of DSP and RISC capabilities, they will find that traditional methods of emulation and debug are unsuitable, especially in complex multiprocessor designs, says Debbie Keil, Systems Software Architect at Texas Instruments Inc. (Dallas) (Class 543). In traditional emulation, the CPU to be emulated is usually removed from its socket and replaced with an emulator pod. The emulator pod typically houses a replacement CPU, plus various amounts of random logic and memory to monitor what is happening on the CPU pins.

"With modern CPUs such as DSPs, the traditional approach has several problems," Keil explains. "The first problem is the speed of newer DSP chips. Bus cycle times can be 25 nanoseconds or shorter, and all instructions typically execute in a single cycle. This makes it difficult for a traditional emulator to allow emulation at full speed. The number of pins to monitor can be staggering, with chips having multiple 32-bit address and data buses, making a traditional emulator expensive. The second, and more serious, problem is that DSPs often have on-chip caches, pipelines, memory and peripherals. Sometimes a whole algorithm can execute without any activity on the CPU pins."

Scan-based emulation provides a solution to these problems. With this process, the CPU is never removed from the socket; indeed, it can be soldered directly onto the board. The CPU sports a serial scan interface, which allows the emulator to scan the internals of the device through a standard connector. A standards committee defines the pinout for this connector, which means a single emulator can support several devices.

Adding complexity to the design decision is a shift to SoC ASIC and application-specific standard product designs, where the high levels of integration and the lack of visibility into the internal workings make it impossible to get a clear picture of the adequacy of the design decision. This makes it that much more important that the developer find, or create, says Bier, a set of benchmarks for the important parameters in a design: performance, power consumption, memory requirements, response and cycle time.

Further complicating design approaches and decisions are SoC-based ASIC and FPGA designs The challenge here lies not in the complexity of the design methodologies chip designers use, but rather in determining how best to integrate hardware and software development in which the system is no longer a set of circuits on a board, but a set of functional blocks on a high-density piece of silicon. These technologies have been part of the embedded designers' world for quite some time, but they existed as just one element in an overall design rather than as the center of the design.

Now that entire systems that once required one or more boards to implement can be put onto a single chip, there's a new urgency to finding ways to integrate hardware and software development. Designers now must answer such questions as: How do I partition the hardware elements of the system? What functions do I put in hardware and which in software? How will these choices affect the power, speed and determinism of the final design?

Presenter Prem Jain (Class 532), chairman and co-founder of Cynergy System Design (Austin, Texas), notes that multiprocessor-based SoCs have become so complex that it is no longer cost-effective to use traditional methods to detect and correct functional and performance design errors after fabrication. This is especially true for high-performance control-dominated SoCs where the functionality and performance of the SoC depends on the interface between the hardware and the embedded software controlling the hardware. "Due to this close coupling between hardware and software in an SoC, developing hardware and software concurrently is now a new requirement for SoC projects," Jain notes. "The key to fulfilling this requirement is adopting a new methodology that drives SoC projects through lock-step hardware-software co-development."

Finally, embedded designers are increasingly being forced to consider applications and platform requirements unlike anything they've worked on before: What are the best conditions under which wireless can be added into a design?

There seem to be more questions than answers in this arena: How do you deal with issues like handoff in an ad hoc wireless network that is a far cry from the deterministic, reliable environment developer are accustomed to? How do you sort through the many new protocols now available to connect previously isolated and closed embedded designs? How do you do designs in which the application may be distributed among several boards in network architecture? How do you handle new data formats such as streaming media in the extremely constrained, small footprint and power-conservative environment of an embedded application? What testing challenges are required in a network environment, and what are some new methods for doing such testing?

Regardless of the networking or data com protocol, the bottom line for developers is to determine how to perform testing. According to presenters Raj S. Mitra and Ajit Sequeira (Class 520) of Interra Technologies Inc. (Santa Clara, Calif.), embedded developers must remember that the implementation of a protocol stack has to be tested for compliance with the original spec, in terms of correctness and clarity of behavior, speed/performance characteristics and the handling of various error situations. "The test-case suite has to represent the entire gamut of usage scenarios, covering all the features of the protocol," Mitra writes. "It takes an expert on the protocol and its domain to create a test case suite that is truly representative of all the features of the protocol. An especially difficult task is the enumeration of all possible error situations and how they are expected to be handled, and this requires a very detailed understanding of the protocol's behavior."

On the other hand, Sequeira notes, the implementation of the protocol as software, hardware or as a simulation model calls for a different kind of expertise: a thorough knowledge of the operating system kernel, clocking / pipelining strategies and other hardware techniques, or the script language of a simulation. "Since these two categories of expertise are quite different and complementary, it is indeed difficult to find a single person who can handle both these tasks," he writes. "Usually, when the protocol is being implemented, we choose an implementation expert, and train him or her in the protocol specification and domain, and when the protocol is being experimented with and simulated, we choose a protocol expert and impart training on the simulator."