Rapid prototyping of embedded hardware/software systems

Design Automation for Embedded Systems, 5, 215–221 (2000) c 2000 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands. ° Rapid Prototyping of Embedded Hardware/Software Systems KLAUS BUCHENRIEDER [email protected] Infineon Technologies AG, CPD DM, Otto-Hahn-Ring 6, D81739 Munich, Germany Abstract. Prototyping of embedded hardware/software systems is important, because it shortens the path from specification to the final product. Prototypes play a major role in decision making, concept and design validation, feature and limit exploration, as well as design verification in every phase of the product development cycle, including product planning, requirement engineering, and product development. This overview discusses the motivation for building prototypes, provides the key areas for research and explains how prototypes can assist in product planning and throughout all steps of the engineering process. Special attention is given to prototyping in the industry to support the design and testing of multimodal and multifunctional embedded systems. Keywords: Prototyping, hardware/software codesign, conjoint engineering product planning, requirement engineering, system engineering, embedded systems. 1. Introduction Michael Dertouzos, Director of the MIT Laboratory for Computer Science, predicted in the early 1980s that in ten years one would find as many computers in every household of the western world as there were motors at that time. In the 1980s, the magic number was twenty-six. Today, there are approximately 25 billion embedded chips in use and the number of new systems is growing rapidly. On average, at least four tiny computers are in use per capita worldwide. Embedded chips are found everywhere and many devices that appear to belong in the hardware domain are actually software products. Most of the functions of a cellular phone, for example, depend on the embedded microprocessors and digital signal processors found in the phone. The hardware merely provides the platform for sophisticated software that has become a vital part of today’s products. As an example, consider a portable phone for a GSM network. It contains a sophisticated chip set driven by 256 KBytes of densely packed code. Without embedded systems many appliances and devices would be more expensive, larger and harder to use. Today, the right mix of embedded software and hardware differentiates products, sets prices and determines business success or failure. The market for software-dominated embedded systems is enormous and growing steadily. Ted Lewis notes that in 1994 two billion chips and microcontrollers were sold, while there were only a miserable ten million personal computers in existence worldwide [1]. These figures clearly indicate a shift away from dedicated hardware to flexible subsystem structures based on small processors and software. Obviously, most of the processing chips produced will never transmit data to a display or receive keystrokes, but rather will be installed in some appliance. In embedded systems, the processing power comes either from a core, an intellectual property module (IP), or from a reconfigurable system on a chip [2]. No matter 216 BUCHENRIEDER which element is used, embedded software combined with soft-configuration is the key to enhanced flexibility. Versatility is achieved through system and core or IP parametrization. Different users thus can design different products with the same IP by soft-code overloading. Reprogrammable hardware structures at the core-level provide unparalleled performance and flexibility for both high-volume cost-sensitive applications and customized highperformance systems. Interfaces between flexible structures and processors enable custom coprocessor designs that provide hardware acceleration to critical system tasks. Current research suggests combining controllers and a fine-granular, flash-programmable gate-array one piece of silicon, so that functions can be freely transferred between the hardware and software domains. As soon as silicon prices drop for reconfigurable logic devices, system development, prototyping and final product realization thus will become integrated into one development step. Combining computing elements, software and reconfigurable arrays into a single embedded system requires that functional prototypes be built and refined throughout the specification and engineering phases. In the specification phase, a soft prototype can help to determine customer needs and feature preferences [3]. A product mock-up, hooked to an external computer, can help to determine how customers view product features and which features will generally result in the final product. As an example, consider the user interface design and the underlying features of a personal communicator. To collect user requirements, one creates a prototype that is indistinguishable from the product for the users, with the exception of a thin cord that is connected to a prototyping system. This system has all the functions of the future product and can be tuned to the preferences of the prospective customer. From the data gathered during product presentation, one can derive the specifications for the IP, software and most other components. By varying product features and classifying the demand-structures, it is possible to devise a product that supplies an almost ideal combination of features with respect to consumer-utility and the producer-profit maximization function. Rapid prototyping is understood as engineering action in which a working technical system is derived from the specification and operated in a real-life environment for evaluation, testing, refinement and operation. Clearly, prototyping is invaluable for design engineers who create classic core or IP-based embedded systems. Sophisticated consumer devices for the multimedia market pose challenges to embedded system designers. The low-cost, consumer-oriented, market-driven, fast-turnaround mentality forces design teams to use hardware/software codesign to cope with growing design complexities. Codesign assists the key characteristics of next-generation networkedembedded systems to communicate across networks and to adapt to different operating environments. Prototyping embedded systems is generally viewed as part of the hardware/software codesign process, while flexible system prototyping is merely a basic enabling technology. Prototyping was the first design technique adopted for simultaneously developing hardware and firmware. It drastically reduced design time because interoperability tests no longer required the final implementation of communication structures for validation anymore. Today, prototyping techniques must support the design and testing of multimodal and multifunctional embedded systems that operate across networks. Multifunctional systems RAPID PROTOTYPING OF EMBEDDED HARDWARE/SOFTWARE SYSTEMS 217 execute multiple applications concurrently, such as capturing video data, processing audio streams, and browsing the web. These systems must often adapt to changing operating conditions to compensate for data loss, i.e. changing network bandwidth, etc. Multimodal systems offer users alternative modes of operation, for example a mobile phone that performs a single function but can change the way it operates to accommodate different communication protocols. System prototyping largely benefits from high-speed and field programmable gate-array (FPGA) technology with a high gate count. The platforms are typically built from finegrained and coarse-grained reprogrammable devices with physically attached controllers, processors and digital signal processors (DSPs). Integrated solutions with several units in one package or on a single die have become popular recently. With this technology it is possible to create dense prototypes for which an engineer remaps a working FPGA design to a one-time programmable device. More and more systems are being developed this way because only one software code needs to be written both for prototype and end product. Thus, the step from system prototype to product is an inexpensive remapping that does not significantly increase development cost. Furthermore, prototyping with reconfigurable devices preserves natural resources no matter how many different prototypes are built. 2. Key Areas Prototypes play a major role in decision making, concept and design validation, feature and limit exploration, as well as design verification in every phase of the product development cycle, including product planning, requirement engineering, engineering and product lifetime extension. For this reason, research centers around the world specialize their research in the following key areas: platforms, design space exploration, architecture selection and component re-use, performance estimation, interface and communications, timing validation, real-time aspects and support structures, debugging and product lifetime extension. 3. Product Planning and Requirement Engineering Product planning and requirement engineering are the first steps in the product development cycle. Functional and non-functional specifications are established for the subsequent engineering action at this point. By using virtual prototypes and “mock-models,” functional and software specifications can be explored together with the client. Here, the prototype is a vehicle to uncover the client’s subconscious expectations. Clearly, it is important to involve and integrate the test subject into the specification process because more and more customers expect solutions and services tailored exactly to their needs. Surveys show that the product will not be well-received if customer expectations are not met. The consumer therefore must be integrated into the process of defining and evaluating soft and working prototypes. Modern techniques, such as conjoint analysis [4] (CA) and CFD are used for data analysis as a base for data-interpretation. As an example, consider the development of a European top-loader washing machine in which the drum rotates sideways with a flap-type opening at the perimeter. The park-position switch and the 40 seconds flap-on-top design would 218 BUCHENRIEDER have never come into existence without customer interaction, thus preventing the creation of this very successful product. In this case, the “Top-40” park position requirement was determined by means of a prototype and the application of the conjoint analysis technique mentioned above. CA is a standard method for determining how product features will be received by a sample group of test persons. In the process, a working prototype is submitted to the test group for evaluation. Individuals in the sample group can select features to be incorporated into or removed from the product during the testing session. All selections as well as an individual’s selection sequence are recorded for statistical evaluation. Iterative feature selection that instantly alters prototype attributes quickly leads to a complete set of requirements and a satisfactory product as a result. Proper sets of requirements that are verified against consumer needs result in products with a high rate of consumer acceptance. The goal, then, is to increase the degree of features implemented in software. 4. Engineering Engineering is generally viewed as the science or art of planning, constructing and designing a system product. The engineering phase ranges from system planning to system integration and product testing. Throughout all phases of the engineering process, prototyping plays a major role because implementation details of the embedded system are worked out and validated via prototyping prior to the final implementation. Prototyping is generally understood as the sum of all activities required to build and evaluate a system prototype in a real-world environment. Its clear advantage over simulation and emulation is that performance and function checks for components or the entire system can be executed and observed under real-life conditions. Consider the prototype of a jog-proof CD player with automatic disk-track adjustment as an example. In contrast to a simulation, this prototype can actually be assembled and taken along on a jog for evaluation and testing. For portable prototypes, fine-grained, high-density gate-arrays with processor interfaces are used that even allow in-system reconfiguration instead of large emulation machines. In industry engineers use design interpreters (DIs) to facilitate integrated development and system prototyping. A design interpreter is a domain-specific tool that integrates a development environment, a reconfigurable prototyper, a recording unit and a system debugger in one single device. A DI consists of a construction and an implementation unit. Using the design unit, system builders can enter the specification, change parameters, synthesize and compile descriptions into components, and execute testing and debugging actions. The implementation unit can be detached and inserted in place of the embedded system under development. During design interpretation, a component description is refined in stages and realized concretely in the implementation unit using combinations of computing elements and FPGAs. If profiling and run-time data are gathered while the implementation unit is embedded in the target environment, recorded data can be analyzed offline. This is convenient when automotive systems are built and tested in a car outside the lab, for example. Then, one uses a DI to record all stimuli and system responses for the entire test drive. If a problem should occur during the test run, i.e. the controller stalls the engine, the recorded data can be evaluated later by reviewing the test run records repeatedly on a prototype in the laboratory. RAPID PROTOTYPING OF EMBEDDED HARDWARE/SOFTWARE SYSTEMS 219 The prototyping platform in the laboratory is often the key for quickly implementing a fully-featured working prototype. Choosing the right platform however, is not easy because many factors impede progress, such as force of habit, availability of funds, existing hardware or a mere lack of design experience. Nevertheless, effectively executing system specifications and compiled functions requires specialized, high-performance hardware. Off-the-shelf PCs, without additional high-performance support, do not have enough processing power and input/output connections to serve as an appropriate platform. Several specialized emulation machines, like QuickturnTM , AptixTM , ZycadTM , etc., are commercially available, but system designers often prefer to contrive customized platforms by using their own combinations of PCs, FPGAs, processors (controllers) and digital signal processors (DSPs. Precise platforms that closely resemble the envisaged product can be erected using such combinations. Architecturally precise prototypes not only reflect the function but also the architecture of the target system. Such prototypes must be constructed when the cost-function relies on more than one independent variable. Consider for example a sophisticated hearing aid that can be precisely adjusted for a patient. Here, power consumption depends on the architectural choice, the algorithmic solution and the implementation technology. The hearing aid is customized upon sale. The filters of the device are then parameterized according to the measurements taken by the audiologist. To the customer, price, overall size, battery lifetime and quick filter response-time are important. These requirements set limits for the design space; these limits must be explored with functional modeling and simulation. Performance data and battery lifetime estimates are determined for different architectures using prototypes and tradeoff analysis. Naturally, a design rich in hardware consumes a lot of power, whereas a software-dominated choice results in a high systemclock. The best architectural choice satisfying most of the requirements lies between the extremes. The investigation of different system architectures allows one to study the reciprocity of algorithms and their effect on output quality. Consider a medical image processing subsystem, for example. Without prototyping, it would be quite difficult to affirm that the subjective quality of the output image is high at varying data rates, while the spatial and the temporal resolution is retained. Only a prototype can provide a true video stream to a screen for subjective evaluation while changes made to parameters and functions are reallocated from software to hardware or vice versa. In order to provide a moving image, the performance of the prototype and product implementation must be accurately estimated. Even though performance estimation is important, it is often impossible to determine or measure the true performance of an embedded hardware/software system by means of simulation or emulation. Since the subsystem is hidden and cannot be tested in isolation, a working embedded prototype must be built to determine bottlenecks and to validate the design either directly or by analyzing recorded data. It is even more difficult to ensure that a system responds in real-time or meets predefined deadlines. In many application areas, the focus of prototyping lies only in the functional correctness of the system. However, when systems must respond in real-time, the prototype must be designed for testing in a real-time environment with real-life data. It must therefore be shown with a schedulability analysis that it is safe to execute the prototype [5]. The system’s design 220 BUCHENRIEDER for meeting difficult timing constraints and deadlines is generally complicated and requires that the environment is captured and modeled correctly. This is a non-trivial and often error-prone task. Building a product-like reactive prototype that adheres to all real-time exactions is difficult because the timing experienced with a prototype containing FPGAs has a different timing behavior than a dedicated implementation. Hence, the positive system validation may no longer apply for the final implementation. Thus, real-time systems cannot simply be mapped onto regular prototyping platforms. Rather, they require configurable and scalable multiprocessor systems to support a network of communicating real-time tasks. In industry, often tightly-coupled clusters of standard processor boards extended with FPGAs are linked through a shared bus. Other platform implementations include closely coupled SharcTM processors or coupled very long instruction word (VLIW) DSPs with multiple processing units. No matter which architecture is adopted, unpredictable performance due to context switching, bus contention, unforeseen interrupts and dynamic actions of the debugger cannot be eliminated. Simulation and system monitoring cannot replace source-level debugging of prototypes because simulation has no link to the architecture and monitoring results have no association to the sources. Debugging embedded hardware/software systems is known as a complex process even when advanced on-chip debugging support (OCDS) is available for all cores and processing elements. Checking for cross-compatibility with the surrounding hardware and with other embedded systems. Consider the electronics of a SMD placement machine or a car designed for the high-end market. Even though these products are very different in function, their underlying computer structures, each with more than fifty embedded processors which are connected with a lean bus structure, are very similar. Even the problems that occur during engineering and testing are very much the same and require similar prototyping techniques for hard- and software. IP integration is practically inconceivable without prototype-based validation. Functional checks and debugging are essentially impossible without introducing extra logic that grants access to “hot spots,” i.e. wires and registers deep within the circuits or between complex modules. Without such additional logic to link subsystems, meeting a simple breakpoint would fragment the system and the observed state of the whole system would be void. Here, prototyping combined with OCDS (i.e., Infineon Technologies TricoreTM level II) provides a friendly, accessible testbed for IPs and their implementation independent systemintegration. Beside IP integration, FPGA-based prototyping environments provide user interfaces for the readback of configuration data, for signal tracing and for reading shadowed registers. 5. Conclusion Prototyping of embedded hardware/software systems is important, because it shortens the path from the specification to the final product. This has been shown in many successful projects in research laboratories and in industrial development centers. Prototypes play a major role in every phase of the product development cycle, including product planning, requirement engineering, and product development. Three trends dominate the future of hardware/software system prototyping: (1) the advent RAPID PROTOTYPING OF EMBEDDED HARDWARE/SOFTWARE SYSTEMS 221 of very large reprogrammable devices combined with several processing elements on a single chip; (2) the continuous expansion of embedded systems into virtually all electronic application fields requiring very flexible IPs; and (3) the reuse of preexisting components together with new software and hardware modules. This poses new technical challenges which we conjecture will be the driving forces of system prototyping in the years to come. References 1. Lewis, T. 1997. Digitopolis meets encalming technology. IEEE Computer 30(9). 2. Motorola Semiconductor Products. 1998. Product Brief: MPACF250—MPA’s CORE+TM Reconfigurable System. Motorola, Inc. 3/98 http://mot-sps.com/fpga/crplus/plus.html. 3. Buchenrieder, K., and Sedlmeier, A. (eds). 1997. CONSYSE’97. International Workshop on Conjoint Systems Engineering. Bad Töz, Germany. 4. Crane, M. 1991. Conjoint Analysis: A Guide for Designing & Interpreting Conjoint Studies. Austin, Texas: Intelliquest, Inc. 5. Färber, G., Fischer, F., Kolloch, T., and Muth, A. 1997. Improving Processor Utilization with a Task Classification Model-Based Application Specific Hard Real-Time Architecture. In Proceedings of the 1997 International Workshop on Real-Time Computing Systems and Applications (RTCSA’97) Ottawa, Canada.