control optimizations using behavioral don't cares - CiteSeerX

CONTROL OPTIMIZATIONS USING BEHAVIORAL DON'T CARES Rajesh K. Gupta Jian Li Department of Computer Science University of Illinois, Urbana-Champaign Urbana, Illinois 61801.

ABSTRACT

Optimization of control ow is an important problem in the synthesis of embedded systems. While considerable progress has been made in data-oriented optimizations, control optimization has been fairly limited to those carried out by compilers at the register transfer level. Control optimizations are needed to make the nal system design insensitive to individual programming styles, and more importantly to provide implementation exibility using the Don't Care(DC) information. Broadly speaking, a DC refers to a condition under which the outcome of an speci ed set of actions is not important. This paper describes the sources of the Don't Care information at the behavioral and structural levels, and its use in optimization of the control ow in system descriptions.

1. INTRODUCTION

Embedded systems are used for dedicated applications some of which may even be `noncomputing'. Examples of such systems can be found in wide range of applications such as automotive, networking and process control. In practice, such systems are implemented using interacting hardware and software components, where dedicated hardware is often used to deliver speci ed timing performance even if the corresponding functionality can be implemented in software. Further, as silicon-based technologies mature in performance, yield and size, it is now possible to build highly integrated systems containing processor, memory and dedicated logic, on the same chip or substrate. The process of combined design of interacting hardware and software components of a system is sometimes referred to as co-design [1]. Co-design techniques are built upon software compilation and hardware synthesis techniques. While system speci cation is an active research issue [2, 3], most practical approaches today use variants of existing programming languages with modi cations to specify concurrency, synchronization and timing attributes.

We take a similar approach in using a hardware description language (HDL) for system speci cation, and focus instead on developing a model of system functionality on which optimization and synthesis algorithms are implemented. In particular, we are interested in a model on which to implement control-oriented transformations and ways to specify and incorporate Don't Care conditions.

2. A MODEL FOR CONTROL OPTIMIZATIONS

Traditionally variants of data- ow graphs (DFGs) and control-data ow graphs (CDFGs) [4] have been used for hardware synthesis and program compilation tasks. Most DFGbased representations are quite ecient in implementing data-oriented transformations, but the modeling of control- ow is often inadequate in carrying out any signi cant alterations in the system control ow. CDFG's often have complicated semantics and control- ow is embedded in a modeling hierarchy that limits the scope of control-oriented transformations. Recent work on control ow expressions (CFEs) [5] uses a representation based on process algebra [6] and regular expressions. Though very successful in identifying synchronization relationships between processes and minimizing process interactions, CFEs do not have information about actions and thus make restrictive assumptions about control-data interactions. These assumptions make it hard to use the DC information in system optimizations. Our tabular model, called Timed Decision Table (TDT), is based on the Decision Tables [7, 8]. Tabular models are not new, a similar model for RTL descriptions has been proposed by [9]. In [10] the authors propose use of relational algebra in formal veri cation of hardware circuits. TDTs are built using conditions and actions. A condition may be indicated by the presence of an input, or an input value, or the outcome of any test action. A conjunction of several conditions is indicated by a rule. Actions include logic, arithmetic, input-output (IO) and

message-passing operations. Actions are of two types: sequential and parallel. Parallel actions represent a group of actions where no ordering between execution of individual actions is assumed. This models the concurrency inherent in hardware models. Each action is associated with an execution delay which may be xed, variable or even unbounded. We assume that condition testing takes zero time. The action delay is typically used to model the data-path delay associated with the operations. A TDT represents a mapping from the set of rules into a (power) set of actions. Visually, a TDT is divided into four quadrants, as shown in Figure 1. Condition Stub Action Stub

Condition Entries Action Entries

Figure 1. TDT Structure Condition stub indicates the set of condition used in building the TDT. Action stub indicates the (power) set of actions that may apply to a given rule. Not all conditions may be applicable to a given rule, indicated by a column in the condition entry. Those conditions that are not applicable to a rule (and thus a Don't Care) are indicated by an `X' in the corresponding row. Example 2..1. A timed decision table. Consider the following program segment: if C1 { if C2 a1; else a2; } else { if C2 a3; a4; }

The corresponding decision table is as follows: C1 Y Y N N C2 Y N Y X A a1 a2 a3,a4 a4 Delay 1 2 3 1 In this table, the condition stub consists of Boolean conditions `C1' and `C2'. The action stub contains a four-valued action called `A'. 2

Execution of the TDT consists of two steps: select the set of rules to apply, execute the actions which may generate events at time stamps indicated by the associated action delays. TDTs are used to represent control ow in a system model as a collection of possible control paths. Iteration, as in looping constructions and

(hardware-modeled) process structures, is represented by process TDTs. A process TDT is executed repeatedly, while procedure TDTs are executed only once each time it is enabled as a part of an action. We note that with addition of iteration, a decision table can implement any computable function [8] or more practically, all language-level systems speci cations can be translated into the TDT representation.

3. DON'T CARES

The concept of Don't Cares (DCs) has been extensively used in logic synthesis for gate-level optimizations and is a key concept in minimization of hardware circuit realizations [11, 12]. For synthesis tasks on behavioral descriptions, the notion of Don't Cares is relatively a new concept [13]. However, it is believed that a proper de nition and use of DCs at higher levels of abstraction will provide a large space for hardware optimization and is essential to make synthesized designs competitive to high quality manual designs. This work diers from earlier work in this area in its de nition and scope of the Don't Care conditions. As is explained below, Don't Cares in earlier work such as [13] are essentially structural Don't Cares targeted for a speci c hardware synthesis. The focus of this work is on behavioral Don't Cares that can be used even before a determination of hardware or software implementation is made for a given system functionality. Most hardware synthesis approaches use a bicameral architecture of interconnected control and data-path blocks. The resulting structure is shown in Figure 2. The controller, typically a nite-state machine, takes control inputs and conditions from the data-path block. It outputs control signals that are used to enable/disable data-path resources (including bus transfers). The conditions used as inputs to the controller are available in the behavioral model and typically are de ned by the branching variables. On the other hand, control signals can be assigned only after the block has been synthesized. We associate Don't Cares with the conditions and control signals as behavioral and structural Don't Cares respectively. The behavioral Don't Care set of an operation is de ned by the set of conditions under which the execution of the operation, or not, will not aect the behavior of the corresponding HDL model. Note that this notion of behavioral Don't Care can be easily applied to any algorithmic speci cation, and therefore, to a software implementation as well. As described earlier, a TDT model speci es relations among a set of operations or actions, A, and a set of conditions C (encapsulated as rules). The behavior of an operation o in an action set is speci ed by the ON-set, OFF-set and DC-set

control inputs

data inputs behavioral Don’t Cares

conditions

Controller

Data Path control

structural Don’t Cares

data outputs

Figure 2. Model of Hardware.

with respect to the conditions as follows:  Behavioral ON-set of o is the set of conditions that operation o much be executed,  Behavioral OFF-set of o is the set of conditions that operation o must not be executed, and nally  Behavioral DC-set of o is the set of conditions under which whether o is executed or not has no eect on the nal system behavior. In this de nition, the set of conditions can be understood as a set of Boolean vectors if each condition is assumed to be a Boolean variable. The union of ON-set and OFF-set is called the Care Set of the operation. If we take the union of the Care Sets of all operations, the Care Set of a behavioral description can now be derived. The Don't Care set of the behavioral description is the complement of the Care Set. Since the conditions are inherently computed in the language-level (HDL or C) model, the DC-set of the behavioral description is a set of conditions that will never occur in the execution of the input language-level model. In [14], the authors use the data- ow analysis to Don't Care determination by introducing the concept of usage conditions of an operation. The usage conditions, which are computed backwards from outputs to the concerned operation, are the union of all possible conditions under which the outcome of that operation will be used. The use of usage conditions has the eect of enlarging the OFF-set of an operation. To understand this, consider the case that the execution of an operation may not aect the behavior of the program under certain conditions, but if the result of such operation is not used, namely its usage condition is false, then the operation is considered as not necessary and such condition should be included in the OFF-set. This leads to the same Don't Care set for all operations, namely the set of conditions that will not occur which is the Don't Care set of the behavioral description.

Therefore, to derive true Don't Cares, we must compute the conditions in terms of the data-path primary inputs. Then the Don't Cares can be derived by AND'ing every pair of conditions. We can also derive the Don't Cares associated with the data inputs, because there are input values that will not be applicable to any execution of the system model. Such Don't Cares are called External Don't Cares (EDC). The Don't Cares which are due to the internal computations of the system model regardless of the data inputs are called, Internal Don't Cares (IDC). The TDT model is useful in capturing both EDC and IDC information. Structural Don't Cares are applicable only to hardware implementations of a system functionality. These DCs are used after synthesis tasks have been completed and operations are scheduled and assigned to available resources. The control signals to data path act as either select signals for multiplexors or load enable signals for registers and busses. It was pointed out in [13] that if a component is not used at a certain control step, the corresponding control signal can be assigned a Don't Care value. Determination of whether a control signal can be assigned a DC value in a certain control step depends upon the type of resource it is controlling, the structure of the data-path and even the choice of VLSI technology, such as static versus dynamic CMOS or use of pass transistor logic. After control signal Don't Cares are identi ed, these are supplied to the FSM minimization and logic optimization for the control circuitry.

3.1. TDT-based Optimizations

TDTs make it easier to incorporate Don't Care conditions by performing DC-based transformations on the matrices representing conditions and actions. These optimizations are implemented as row and column operations on the condition and action matrices. Structurally TDT optimizations fall into following two categories: Column Operations refer to operations on columns in the condition and action entry matrices. The following column operations are carried out in the TDT model: 1. Merge columns using Don't Care information. Two columns can be merged if these dier only in one row in the condition entries and the corresponding action entries are the same. 2. Identify and delete DC columns. These are columns that satisfy externally speci ed DC conditions on the condition variables. It can be shown that column deletion operation subsumed the operation of dead-code elimination implemented in most software compilers.

Row Operations when implemented on the

condition entries refer to optimizations related to control- ow. Row operations when implemented on the action entries represent operations on the data- ow portions of the given description. A row can be deleted in presence of dependent conditions. This reduction is performed by rst checking condition dependence in the condition stub and then eliminating redundant rows. Condition dependencies can be speci ed by the user as external don't cares, or produced in the data- ow as internal don't care conditions.

4. RESULTS AND SUMMARY

We have implemented the TDT model generation and optimization algorithms as a part of the Vulcan co-synthesis system for embedded systems. A given description of system functionality using HardwareC HDL is compiled into a TDT model consisting of a set of tables. The representation is then subject to table merging operations that enlarges the scope of subsequent control optimizations. The system also provides HardwareC output description from TDT models. This is useful in taking the HDL output through the subsequent synthesis process. External don't care information can be supplied by the user as a part of the HardwareC description or interactively by de ning implication relations between control variables used in the behavioral descriptions. The latter is quite useful as it obviates the need for modi cation of the original system description during the design process where a particular system implementation may use Don't Care information that may or may not be applicable in other implementations. Our experimental methodology in evaluating the eect of TDT optimizations was to compare the synthesis results in terms of total number of cells used from input HDL descriptions to those produced after TDT-based control optimizations. Sample designs were input to hardware synthesis tools using OLYMPUS [15] and a target technology of LSI logic 10K library of gate-level cells. We found a 3% reduction in size for the description of the trac light controller without applying any Don't Care conditions. This reduction, therefore, is entirely due to the simpli cation of the control ow using TDTs. On applying Don't Care conditions to the behavioral description of a trolley controller benchmark, size reductions upto 88% were obtained based on the set of Don't Care conditions relating to trolley veer conditions. We believe the ability to specify additional information about the system environment in model generation and optimization is more im-

portant than the actual numerical reduction in circuit size since the latter is strongly dependent upon the external DC information available. Early optimizations using Don't Care on the behavioral descriptions can improve the design process by raising the abstraction level at which the designer input is useful. We have so far considered only direct implications as external DC conditions. We plan to explore ways to incorporate DC conditions that relate to sequences of actions by the system.

5. ACKNOWLEDGEMENTS

This research was sponsored by a grant from NSF No. 95-01615 and a grant from the NSF Engineering Research Center Grant ECD 89-43166.

REFERENCES

[1] W. Wolf, \Hardware-Software Co-design of Embedded Systems," IEEE Proceedings, vol. 82, no. 7, pp. 965{989, July 1994. [2] D. D. Gajski, F. Vahid, S. Narayan, and J. Gong, Speci cation and Design of Embedded Systems. Prentice Hall, 1994. [3] N. Halbwachs, Synchronous programming of reactive systems. Kluwer Academic Publishers, 1993. [4] A. L. Davis and R. M. Keller, \Data Flow Program Graphs," IEEE Computer, vol. 15, no. 2, Feb. 1982. [5] C. Coelho and G. D. Micheli, \Dynamic schedulingand synchronizationsynthesisof concurrent digital systems under system-level constraints," in Proceedings of the IEEE International Conference on Computer-Aided Design, pp. 175{181, Nov. 1994. [6] J. A. Bergstra and J. W. Klop, \Applications of Process Algebra," in An introduction to process algebra (J. C. M. Baeten, ed.), pp. 1{21, Cambridge University Press, 1990. [7] P. J. H. King, \Decision Tables," The Computer Journal, vol. 10, no. 2, Aug. 1967. [8] A. Lew, \On the emulation of owcharts by decision tables," Communications ACM, vol. 25, no. 12, pp. 895{905, 1982. [9] K. Rath, M. E. Tuna, and S. D. Johnson, \Behavior Tables: A basis for system representation and transformational system synthesis," in Proceedings of the IEEE International Conference on Computer-Aided Design, 1993. [10] A. J. W. M. ten Berg, C. Huijs, and T. Krol, \Relational algebra as formalism for hardware design," Microprocessing and Microprogramming, pp. 403{410, Sept. 1993. [11] G. D. Micheli, Synthesis and Optimization of Digital Circuits. McGraw-Hill, 1994. [12] S. Devadas, A. Ghosh, and K. Keutzer, Logic Synthesis. McGraw-Hill, 1994. [13] R. A. Bergamaschi, \Control optimization in high-level synthesis using behavioral don't cares," in Proceedings of the Design Automation Conference, pp. 657{661, 1992. [14] H. Juan, V. Chaiyakul, and D. Gajski, \Condition graphs for high-quality behavioral synthesis," in IEEE International Conference on Computer-Aided Design, pp. 170{174, 1994. [15] G. D. Micheli, D. C. Ku, F. Mailhot, and T. Truong, \The Olympus Synthesis System for Digital Design," IEEE Design and Test Magazine, pp. 37{53, Oct. 1990.