Compiler Generation in PEAS-III: an ASIP Development System Shinsuke KOBAYASHI, Yoshinori TAKEUCHI, Akira KITAJIMA and Masaharu IMAI Department of Informatics and Mathematical Science Graduate School of Engineering Science, Osaka University 1-3 Machikaneyama, Toyonaka, Osaka, 560-8531 Japan E-mail:
[email protected]
Abstract
important. Several software development environments generation methods have been proposed. For example, CBC compilers can be generated from a compiler description in nML[1]. However, it is not possible to specify pipeline execution information in nML, then CBC cannot generate efficient object codes for pipeline processors. As a second example, MIMOLA system[2] generates a set of application program development environment, including a compiler, for a target architecture. Target processor specifies with the same MIMOLA language. The compiler generated by MIMOLA is named MSSQ, which is used to analyze the target application and to make a data graph called i-tree. However, because a designer must specify interconnection of hardware resources using selector, it is not easy to modify the target machine description. As a third example, a language LISA[3] has been developed for processor architecture design. LISA inherits concepts from nML. Moreover, pipeline execution information can be described in LISA language. While an assembler and a cycle-accurate simulator can be generated using LISA, no result is reported that indicates compiler generator in LISA so far. This paper introduces a compiler generation method in PEAS-III (Practical Environment for ASIP development). PEAS-III generates an embedded processor core description in HDL from hardware resource description and microoperation description of instructions. The compiler generator uses part of the above processor description for processor core generation. The information used in the compiler generator contains following items: (1) structural information, (2) functional information, (3) resource information, (4) storage information, and (5) instruction set information. The rest of this paper is organized as follows. Related work is studied in section 2. Section 3 presents the outline of PEAS-III. In section 4, a compiler generator for PEASIII is proposed. Finally, section 5 concludes this paper and proposes future work.
A compiler generation method in PEAS-III is proposed in this paper. PEAS-III is an ASIP (Application Specific Instruction set Processor) development environment, which accepts processor specification including hardware resources and clock-based micro-operation description of instructions, and generates data path and control logic description of the processor in an HDL form. Application program development tools generators are under development, which include a compiler generator. The compiler generator in PEAS-III generates necessary information to be used by a commercial compiler generator CoSy from the processor specification description for target ASIP.
1
Introduction
In ASIP (Application Specific Instruction set Processor) development, it is important to explore a processor architecture that matches the target application. In order to achieve this task, it is essential to evaluate or estimate the design quality of architecture candidates with different instruction sets, pipeline stage counts, micro-operations, and combinations of hardware resources, where design quality includes performance, gate count, and power consumption of a design. Because there are so many architectural parameters, there exist a huge number of processor architecture candidates, which make it difficult to find an optimal architecture in a short design time. Compiler generator plays an important role to estimate the performance of processor candidates in the design space exploration. In order to explore the huge design space efficiently, compiler generator for ASIP development should satisfy following requirements: (1) Various compilers are generated according to target architectures under evaluation. (2) Target compilers are generated within a short time. (3) It is desired that the compiler generator can generate two kinds of compilers, that is, compilers for design quality estimation and those for final code generation of application program. These compilers should satisfy different requirements as follows. (4) In compilers for design quality estimation, compilation time should be short, but the object code quality is not so important. (5) Compilers for final code generation should yield high quality object code, but its compilation time is less
2 Related Work Conventional approaches to ASIP generation can be classified into two kinds. First one is a “parameterized generic processor core” such as PEAS-I[4], Satsuki[5], MetaCore[6], 1
CASTLE[7], Xtensa[8] and so on. Their processor models usually have basic instruction sets and a synthesizable ASIP description is generated by adding predefined or user defined instructions to the basic instruction set. Architectures of these processors are suitable for compiler generation, but in many cases have little flexibility on pipeline structure and instruction variations. Then, the variety of architecture candidates by these systems is limited with respect to pipeline stage count, instruction format and micro-operation for each pipeline. Another approach is based on “processor specification languages.” The processor specification languages are originally developed to design ASIPs, and these languages cover a wide range of processor architectures. Generation methods for an RT level HDL description from a processor design description have also been studied. For example, AIDL[9] specifies operations of each pipeline stage and timing relations of stages. AIDL can specify timing relations for designing advanced processor, but modification of instruction set is not easy. Hamabe, et al.[10] proposed a description method of clock based instruction behavior and combination of resources for each stage. However, the designer must specify instruction behaviors considering pipeline registers. The approach of PEAS-III is different from their approaches. PEAS-III is an interactive architectural level processor design environment. PEAS-III system generates a processor from specification of processor including following information: (1) Architecture parameters such as pipeline stage count, number of delayed branch slot, and so on, (2) Declarations of resources to be included in a processor (e.g. ALU, Register File and so on), (3) Instruction format definitions which define operation codes, (4) Interrupt definitions which include cause conditions, and (5) Micro-operation descriptions of instructions and interrupts. PEAS-III implements user defined operations of instructions and interrupts by inserting selectors and pipeline registers automatically, and generating control logic for pipeline interlock. Using PEASIII system, the designer can design a processor in a few days. However, software development environment including compiler, assembler, profiler, debugger, and so on was not generated automatically in PEAS-III. Software development environment generation plays an important role, because time for building the software development environment is very long.
3
Processor Design Architectural Parameter Specification
Resource Declaration
Instruction Format Definition
FHM-DB
Interrupt Definition
FHM-DBMS
Micro-Operation Description of Instructions and Interrupts
Processor Generation
Simulation Model
Compiler Generation
Synthesizable Model
Compiler
Figure 1: Design flow of PEAS-III. time becomes much shorter than traditional register transfer level design. Moreover, modification of design with respect to combination of resources, instruction sets and instruction behaviors is easy. As a consequence, various architecture candidates can be evaluated in short time. The rest of this section explains each design step in more detail.
3.2 Architecture Parameter Specification In the architecture parameter specification phase, designer selects parameter values of the processor. The parameters include the number of pipeline stages and the number of delayed branch slots.
3.3 Resource Declaration In the resource declaration phase, designer chooses resources from Flexible Hardware Model (FHM) database[11][12]. FHM is parameterized with various characteristics such as bit width, algorithm of the operation, etc., and various design instances can be generated according to the given parameter values. Several abstraction levels of design instances can be generated from FHM. Since instances can be generated with various combinations of parameter values, a designer can evaluate many kinds of resources only by changing parameter values of FHM. An example of resource declaration is shown in Fig.2.
PEAS-III System
3.1 Outline Design flow in PEAS-III is shown in Fig.1. In the design flow, processor architecture type is determined first. Secondly, combination of resources is decided. Instruction format and conditions of interrupts are defined and behaviors of instructions and interrupts are described. Then, simulation model and synthesizable model of the processor are generated. The functionality of the designed processor can be validated using the generated simulation model. Hardware cost and clock frequency of the design can be evaluated using the generated synthesizable VHDL. Since a processor is designed at architectural level, design
3.4 Instruction Format Definition In the instruction format definition phase, the designer defines instruction types and operation code. First, the designer defines instruction types. A type name, bit fields and field names are defined for each instruction type. Secondly, the designer chooses instruction type for each instruction and determines operation codes. In a micro-operation description of instructions, field name is used for reference to a bit field of an instruction. Even if bit fields of instruction word are 2
tions and interrupts by inserting selectors and pipeline registers automatically, and generating control logic for pipeline interlock. Since the designer does not need to take care about selectors, pipeline registers and pipeline interlocks, definition and modification of micro-operation description becomes easy.
4 Compiler Generator To generate a retargetable code generator, the target machine specification includes following five kinds of information. structural information : The structural information contains hardware units and their interconnections. functional information : The functional information contains primitive operations which can be executed on the target machine.
Figure 2: Example of resource declaration.
resource information : The resource information contains functional hardware units specification. storage information : The storage information contains the storage resource units specification. instruction set information : The instruction set information contains instruction format and resource and functional usage. The compiler generator makes mapping rules from medium level representation of compiler to instructions of target machine. Moreover, the compiler generator detects throughput, latency and resource usage from structural information, resource information, storage information and instruction set information. Throughput, latency and usage of resources are used in scheduling. The processor design which is described by using PEASIII system contains following five items : (1) architecture parameter, (2) declarations of resources to be included in processors, (3) instruction format definitions, (4) interrupt definitions and (5) micro-operation descriptions of instructions. The functionality of the compiler generator is shown in Fig.4. The compiler generator extracts the five information from the processor specification which is input on PEAS-III system and intermediate representation of processor generator. The rest of this section explains the way to extract each information and the way to use these kinds of information in more detail.
Figure 3: Example of a micro-operation description of SLT. changed, there is no need to change micro-operation description.
3.5 Interrupt Definition In the Interrupt Definition Section, cause conditions of interrupts and execution cycle counts for interrupts are defined.
3.6 Micro-operation Descriptions In the micro-operation description phase, clock based behavior of instructions and interrupts are defined. In the microoperation description of interrupts, hardware behavior such as setting values to special registers or jumping to the interrupt handler routine, is described. Micro-operation consists of three elements: (1) Operations which are executed by resources, e.g. arithmetic and logic operation, read, register write, (2) Data transfers between resources, and (3) Conditions for execution of (1) and (2). An example of a microoperation description is shown in Fig.3. PEAS-III implements user defined operations of instruc-
4.1 Information Transformation 4.1.1 Structural information The structural information is extracted from intermediate representation. Intermediate representation of processor generator includes interconnections of resources. Usage of resources is detected from this information. 4.1.2 Functional information and Resource information The functional information and the resource information are extracted from resource declarations and FHM-DBMS 3
Target machine Specification
adder
Architecuture parameter
Functional information
Resource declaration
Resouce information
Instruction format
Instruction set information
Interrupt definition Micro-operation descriptions
begin functions addition interface in1 a, in2 b, out1 c; latency 1; throughput 1; end functions;
FHM
Storage information
FHM-DBMS
Processor generation Intermediate representation
Figure 6: Example of resource description. Structural information
4.1.3 Storage information
Compiler generation
The storage information is extracted from intermediate representation and FHM-DBMS. This information describes heterogeneous register file and local memory.
Compiler for target processor
4.1.4 Instruction set information The instruction set information is extracted from instruction format definitions and intermediate representation. Resources and functions are used in mapping rule generation. Instruction format is used in code emission.
Figure 4: The Functionality of the Compiler Generator.
addition interface input int 32 a, input int 32 b, output int 32 c; behavior begin c = a + b; end;
4.2 Mapping Rule Generation The compiler generator generates mapping rule between instruction and medium level representation. Generation algorithm is shown in Fig.7. Mapping rule generation includes following phases. 1. Resource tracing To get connections of function interfaces between resources, compiler generator traces resource graph which is from structural information.
Figure 5: Example of functional description.
2. Function expansion
which is resource data base in PEAS-III. Resources in FHMDB have some functions. Functions indicates a set of primitive operations and functions which are in FHM-DBMS. Using this information, compiler generator makes mapping rules from the medium level representation of compiler to target machine instructions.
Functions are expanded using information of resource connection. Expressions which indicate instruction behavior are made in this phase. 3. Rule generation The expressions which are expanded in function expansion phase are used by rule generation. Primitive operations are converted into medium level representation.
An example of function definition is shown in Fig.5. The function “addition” has two input ports and one output port. The input and output port data type are 32 bits integer. The operation “+” is one of primitive operations. Once a function is described and put in FHM-DBMS, the function can be used in the description of another function.
4.3 Scheduling Information Generation The compiler generator generates scheduling information. The algorithm is shown in Fig.8. Scheduling information generation includes following phases.
Moreover, an example of resource description is shown in Fig.6. The addition which is defined in functional information is used by the adder. The interface section describes binding between resource ports and function interfaces. The latency and throughput section are used when calculating throughput and latency of instruction.
1. Instruction classification Instructions are classified by using resource and, its throughput and latency. For example, if “xor” function and addition function use the same resource, throughput and latency, these instructions are same class. 4
while !( all instructions are expanded. )
// Instructions are classified by resource and function. InstructionClassify(); while !( all instruction classes are calculated. )
// “ready” is a set of write functions. ready = GetReadySet; while !( complete expressions are made. )
// “ready” is a set of write functions. ready = GetReadySet; while !( pipeline stages from execute stage to write storage stage are calculated. )
// A set of next resources nextReady = GetPredecessors(ready);
// Get function which is used by this instruction. function = GetFunction(ready);
while !( all paths which are in same pipeline stage are calculated. )
if ( expressions are empty. )
// A set of next resources nextReady = GetPredecessors(ready);
PutFunction( function, expressions );
// Get throughput and latency // which is used by this instruction. throughputTemp = GetThroughput(ready); latencyTemp += GetLatency(ready);
else
// Replace successor ports // which is connected between interfaces. FunctionExpansion ( expressions, function );
if ( throughput
throughputTemp )
throughput = throughputTemp;
ready = nextReady;
ready = nextReady;
RuleGeneration(expressions);
latency += latencyTemp;
Figure 7: Algorithm of mapping rule generation. Figure 8: Algorithm of scheduling information generation.
2. Resource tracing To get connections of function interfaces between resources, compiler generator traces resource graph which is from structural information.
3. Mapping to the target machine The rules which are generated by the proposed compiler generator are used in mapping to the instruction set of the target machine. In this step, the compiler assigns from the medium level representation to the instructions.
3. Throughput and latency calculation Each resource has throughput and latency. Throughput is maximum value of all pipeline stages. Latency is total value of pipeline stages from execution stage to write storage stage.
4. Scheduling The instructions are scheduled taking into consideration the throughput, latency and occupation of resources which are generated by compiler generator.
4.4 Code Generator Compilation process of a proposed code generator is processed as follows.
Through these processes, machine suitable codes are generated by a compiler.
1. Building the medium level representation
4.5 Discussion
In the first step, the compiler builds the medium level representation from a source code.
In PEAS-III system, function definitions in FHM-DB can be reused. This indicates that the designer can make a compiler rapidly because he does not have to describe the functions in every design. Traditional compiler generators such as MSSQ, CBC and so on use the target machine description language. In these compiler generator, however, the designer must describe functions of resources if the resources could have same functions.
2. Optimization The compiler optimizes the medium level representation. The optimization includes loop optimization such as loop unrolling, temporal loop-invariant computing and so on. 5
5
Conclusion
[10] M. Hamabe, A. Nose, N. Togawa, M. Yanagisawa, and T. Ohtsuki, “A Generation System for Hardware Description of Pipelined Processors,” Tech. Report of IEICE, VLD97-117, pp. 33–40, 1997. (in japanese).
In this paper, an architectural level processor design system PEAS-III and compiler generator for PEAS-III are proposed. The designer is able to explore large design space rapidly using PEAS-III system. Our future work includes evaluation of compiler generator and software development environment generation which includes software simulator, profiler, debugger and assembler for PEAS-III.
[11] M. Imai, A. Shiomi, Y. Takeuchi, and J. Sato, “Hardware/Software Codesign in the Deep Submicron Era,” IWLAS ’96, pp. 236–248, Dec 1996. [12] T. Morifuji, Y. Takeuchi, J. Sato, and M. Imai, “Flexible hardware model: Implementation and effectiveness,” Proc. of SASIMI’97, pp. 83–89, Dec 1997.
Acknowledgments The authors are grateful to the members of PEAS Project. This work is partly supported by STARC (Semiconductor Technology Academic Research Center). The compiler generator in PEAS-III generates necessary information to be used by a commercial compiler generator CoSy which is produced by ACE Associated Compiler Experts bv.
References [1] A. Fauth, “Beyond tool-specific machine descriptions,” Code Generation for Embedded Processors, pp. 138– 152, Kluwer Academic Publishers, 1995. [2] R. Leupers and P. Marwedel, “Retargetable Code Generation Based on Structural Processor Descriptions,” Design Automation for Embedded Systems, vol. 3, no. 1, pp. 75–108, Jan. 1998. [3] S. Pees, A. Hoffmann, V. Zivojnovic, and H. Meyr, “LISA - Machine Description Language for CycleAccurate Models of Programmable DSP Architecture,” 36th Design Automation Conference, pp. 933–938, 1999. [4] J. Sato, A. Y. Alomary, Y. Honma, T. Nakato, A. Shiomi, N. Hikichi, and M. Imai, “PEAS-I: A Hardware/Software Codesign System for ASIP Development,” IEICE Trans. Fundamentals, vol. E77-A, no. 3, pp. 483–491, Mar. 1994. [5] B. Shackleford, M. Yasuda, E. Okushi, H. Koizumi, H. Tomiyama, and H. Yasuura, “Satsuki: An Integrated Processor Synthesis and Compiler Generation System,” IEICE Trans. Inf. & Syst., vol. E79-D, no. 10, pp. 1373– 1381, Oct. 1996. [6] J.-H. Yang, B.-W. Kim, S.-J. Nam, J.-H. Cho, S.-W. Seo, C.-H. Ryu, et al., “MetaCore: An Application Specific DSP Development System,” 35th DAC, pp. 800– 803, 1998. [7] R. Campasano and J. Wilberg, “Embedded System Design,” Design Automation for Embedded Systems, vol. 1, no. 1-2, pp. 5–50, Jan. 1996. [8] Tensilica, “Xtensa.” http://www.tensilica.com. [9] T. Morimoto, K. Saito, H. Nakamura, T. Boku, and K. Nakazawa, “Advanced Processor Design Using Hardware Description Language AIDL,” ASP-DAC’97, pp. 387–390, 1997. 6
