Real-time Response Requirements Research Articles

Storage assignment optimizations to generate compact and efficient code on embedded DSPs

DSP architectures typically provide dedicated memory address generation units and indirect addressing modes with auto-increment and auto-decrement that subsume address arithmetic calculation. The heavy use of auto-increment and auto-decrement indirect addressing require DSP compilers to perform a careful placement of variables in storage to minimize address arithmetic instructions to generate compact and efficient DSP code. Liao et al. formulated the problem of storage assignment as the simple offset assignment problem (SOA) and the general offset assignment problem (GOA), and proposed heuristic solutions.The storage allocation of variables critically depends on the sequence of variable accesses. In this paper we present techniques to optimize the access sequence of variables by applying algebraic transformations (such as commutativity and associativity) on expression trees to obtain the least cost offset assignment. We develop a new formulation of this problem as the least cost access sequence problem (LCAS). Based on the proposed framework, we develop heuristic algorithms that determine empirically near-optimal solutions resulting in fewer address arithmetic instructions. We have implemented the proposed heuristic algorithms by extending the storage assignment optimization in the SPAM compiler back-end targeted for the TMS320C25 DSP. In the case of SOA, experimental results for programs from the DSPstone benchmark suite show an average improvement of 3.36% in static code size and an average relative speed-up of 7.28% over results obtained using existing SOA algorithms. The average code size reduction over code compiled with a naive storage assignment algorithm is 7.04%. The proposed framework has also been applied to the GOA problem and shows average code size reductions of 2.04% over results obtained using existing GOA algorithms, and average code size reductions of 10.84% over a naive GOA algorithm. Code size reduction and improvement in dynamic instruction counts could be valuable given limited memory and real-time response requirements placed on embedded systems.

A SOFTWARE ENGINEERING DESIGN TOOL FOR MODELING HARD REAL-TIME PERFORMANCE

Hard real-time digital systems are a small but important segment of the installed software base because of failure impact. Deadline feasibility can be optimally determined in this domain through rate monotonic analysis, but performance is difficult to predict unless design change effects on spare capacity are measured. We measure units of concurrency as formal aggregations of reusable modules. In this manner, object-oriented construction can be compatible with hard real-time response requirements.

Speech recognition algorithms for voice control interfaces

Recognition accuracy has been the primary objective of most speech recognition research, and impressive results have been obtained, e.g. less than 0.3% word error rate on a speaker-independent digit recognition task. When it comes to real-world applications, robustness and real-time response might be more important issues. For the first requirement we review some of the work on robustness and discuss one specific technique, spectral normalization, in more detail. The requirement of real-time response has to be considered in the light of the limited hardware resources in voice control applications, which are due to the tight cost constraints. In this paper we discuss in detail one specific means to reduce the processing and memory demands: a clustering technique applied at various levels within the acoustic modelling.

Scheduling for reactive real-time systems

In designing Chinook, a hardware-software cosynthesis system for reactive real-time controllers, the impact of timing constraints on software scheduling has been a central concern. By dividing constraints into two levels, corresponding to low-level interactions with device interfaces and high-level real-time response and rate requirements, we have developed solutions tailored to each aspect. These scheduling techniques enable Chinook to map a high-level specification onto a specified collection of processors and peripheral devices while respecting performance requirements.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Architectural principles for safety-critical real-time applications

This paper addresses the general area of computer architectures for safety-critical real time applications. The maximum acceptable probability of failure for these applications ranges from about 10/sup /spl minus/4/ to 10/sup /spl minus/10/ per hour depending on whether it is a military or civil application. Typical examples include commercial and military aircraft fly-by-wire, full authority engine control, satellite and launch vehicle control, ground transport vehicles, etc. Realtime response requirements for these applications are also very demanding, with correct control inputs required every 10 to 100 ms, depending on the application. These dual goals of ultrahigh reliability and real-time response necessitate computer systems that are quite different from other dependable systems in their architecture, design and development methodology, validation and verification, and operational philosophy. This paper highlights these differences by describing each of these aspects of safety-critical systems. Architectural principles and techniques to address these unique requirements are described.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Bidirectional token flow system

Over the last few years there has been an avalanche of technical literature on techniques for allowing nodes to access and share one of the most valuable resources of a computer communication network, i.e., the bandwidth of the communication media. 1 This report describes the design of a new type of Local Area Computer Network called BID that uses a bidirectional token flow as a form of token passing. 2 The design of BID not only allows it to process messages having various properties but also makes it possible to operate simultaneously in a packet and circuit-switching mode. This latter mode, using minipackets, enables BID to be used for those applications having real-time response requirements. In describing BID this report defines the basic concepts of the implicit token, token carrier, token generator, and token wait time. It also describes a new preemption technique which reduces the walk time normally associated with token and polling systems. A GPSS computer simulation was made of the BID system to determine the average delay times experienced by the various priority classes of messages. An analytical model using a single priority class of messages is presented, and the results of the computer simulation are compared with this. The simulation results also indicate the uniformity of the average delays experienced by the Bus Interface Units across the bus resulting from the use of bidirectional flow of tokens.

UNIX Time-Sharing System: The MERT Operating System

The MERT operating system supports multiple operating system environments. Messages provide the major means of inter-process communication. Shared memory is used where tighter coupling between processes is desired. The file system was designed with real-time response being a major concern. The system has been implemented on the DEC PDP-11/45 and PDP-11/70 computers and supports the UNIX∗ time-sharing system, as well as some real-time processes. The system is structured in four layers. The lowest layer, the kernel, provides basic services such as inter-process communication, process dispatching, and trap and interrupt handling. The second layer comprises privileged processes, such as I/O device handlers, the file manager, memory manager, and system scheduler. At the third layer are the supervisor processes which provide the programming environments for application programs of the fourth layer. To provide an environment favorable to applications with real-time response requirements, the MERT system permits processes to control scheduling parameters. These include scheduling priority and memory residency. A rich set of inter-process communication mechanisms including messages, events (software interrupts), shared memory, inter-process traps, process ports, and files, allow applications to be implemented as several independent, cooperating processes. Some uses of the MERT operating system are discussed.