COMPUTER ARCHITECTURE SIMULATION USING A REGISTER TRANSFER LANGUAGE, by LESTER BARTEL B. A., Tabor College, 1983 A MASTER'S THESIS submitted in partial fulfillment of the requirements for the degree MASTER OF SCIENCE Department of Computer Science KANSAS STATE UNIVERSITY Manhattan, Kansas 1986 Approved by: Majory 'rofessor A11ED5 b565Q3 .TH- Table of Contents List of Figures v Acknowledgements vi 1 . Introduction 1 1 .1 . Purpose of an Architecture Simulator 1 1 .2 . Instruction Set Processor 3 1 .3 . Machine Cycle Simulator 3 1 .4 . Register Transfer Language 4 1 .5 . Silicon Compilers 6 1 .6 . Definitions 8 2 . Review of Existing CHDLs 10 2 .1 . Representative CHDLs 10 2 .1 .1 . CDL 10 2 .1 .2 . ISP 11 2 .1 .3 . AHPL 11 2 .1 .4 . DDL 13 2 .1 .5 . ADLIB 14 2 .1 .6 . DTMS 15 2 .1 .7 . CONLAN 17 2 .2 . Levels of Hardware Description 17 2 .2 .1 . Circuit Level 18 2 .2 .2 . Logic Gate Level 18 2 .2 .3 . Register Transfer Level 19 2 .2 .3 .1 . Structure Level 19 2 .2 .3 .2 . Functional Level 19 .2 . 2 .3 .3 Behavior Level . .20 2 .2 .4 . Instruction Set Level 20 2 .2 .5 . Processor Memory Switch Level 21 2 .2 .6 . Algorithmic Level 21 2 .3 . Applications of CHDLs 21 2 .3 .1 . Descriptive Tool 22 2 .3 .2 . Simulation and Design Verification 23 2 .3 .3 . Design Automation and Hardware Synthesis 24 3 . Introduction to ASIM II 25 3 .1 . Purpose of ASIM II 25 3 .2 . Description of Components 27 4 . ASIM II Operation 30 4.1. Primitives 30 4 .2 . Description of Primitives 31 4 .2 .1 . ALU 31 4 .2 .2 . Selector 32 4 .2 .3 . Memory 33 4 .3 . Implementation Notes 34 4 .4 . Optimization Notes 37 4 .5 . Input and Output 38 5 . Conclusion 39 5.1. Benefits 39 5 .2 . Execution Speed 39 5 .3 . Hardware Construction 41 5 .4 . Future Considerations 42 Bibliography 45 Appendix A ASIM II Documentation Al Appendix B ASIM II Syntax Bl Appendix C ASIM II Source Code CI Appendix D Example Stack Machine Simulator Specification (Sieve of Eratosthenes) Dl in Appendix E Pascal Code for Example Generated by ASIM II El Appendix F Specification and Hardware Circuit Fl IV List of Figures Figure 3.1. Bit Concatenation 28 Figure 4.1. Alu specification and code generated by ASM II 31 Figure 4.2. Selector specification and code generated by ASIM II 32 Figure 4.3. Memory specification and code generated by ASIM II 34 Figure 5.1. Execution time comparison of ASIM and ASIM II 39 Acknowledgements I wish to thank Dr. Thomas Pittman for his suggestion of this topic, and his patient assistance. His suggestions were invaluable in the preparation of this thesis. Secondly, I wish to thank my major professor Dr. Virgil Wallentine, and my committee members Dr. David Gustafson and Dr. Maarten vanSwaay for serving on my committee, for their encouragement and input to this thesis. I also wish to thank my friend Naomi Regier for proofreading this document and providing thoughtful suggestions to improve this thesis. Finally, I wish to thank my parents, Albert and Lavina Bartel for their prayers and encouragement during my graduate studies. This work would not have been possible without their support. vi Chapter One Introduction 1.1. Purpose of an Architecture Simulator As computer chips have grown in complexity, the need for tools to aid the engineer in designing and testing a proposed architecture has increased greatly. Many of these tools are available as computer programs, some of which are silicon compilers, RTL (Register Transfer Language), or ISP (Instruction Set Processor). A silicon compiler deals with the actual hardware mask generation and can be quite difficult to use. ISP defines each opcode as an instruction to be executed, and thus is a one to one replacement of the assembly code to a "high level language". RTL, which is classified as a CHDL (Computer Hardware Description Language), lies between silicon compilers and ISP in terms of the level of abstraction it deals with. This thesis will concentrate on examining and using an RTL. Using a software simulator can greatly reduce the cost of designing a new microprocessor by avoiding physical construction. This physical construction is usually more error-prone and labor intensive than a software system due to the need to actually build the circuit under consideration. Great care must be taken to ensure that wires are hooked up correctly and that the individual chips are working properly. Also, as complexity increases, the length and type of connections becomes critical and may cause problems which are not readily apparent. Some of these problems can be ignored during the simulation phase without serious consequence; they can be dealt with during the production of a prototype. Since the project can be simulated on an existing computer, building a prototype is not necessary until later in the design phase. In the past three years, only brief mention is made of CHDLs in the literature, partially due to manufacturers developing their own CHDL and retaining it as a trade secret [50]. In light of this, it may be quite difficult for a single CHDL to become a standard for computer architecture design, implementation, and comparison. Some of the current CHDL implementations are relatively old and are more difficult to port over to a newer and faster computer. In implementing a new CHDL, it is desirable to promote porting to other computers and to promote standardization of hardware representation at the register transfer language level. It is desirable to provide a complete set of primitives with which a designer can define a circuit. 1 .2. Instruction Set Processor ISP translates each opcode of the test architecture to an expression in a high level language where the instruction execution is often implemented as a large case structure [67]. This level of translation does not lend itself well to actual circuitry generation, but is useful in designing an instruction set for the microprocessor to execute and for simulating that execution. After the instruction set has been generated and tested, it can be converted to an RTL for further testing. The RTL provides a circuit level definition of the microprocessor. 1.3. Machine Cycle Simulator The machine cycle simulator, a technique especially useful in microprocessor design, is somewhat related to the ISP. In addition to the capabilities of the ISP, the machine cycle simulator traces the events at each cycle, thus providing timing information not available via an ISP. This type of simulator is quite close to an RTL simulator in the type of information provided by the simulation run. However, the machine cycle simulator specification is more difficult to convert to an actual circuit than the RTL specification because it still does not represent the hardware in detail. 1 .4. Register Transfer Language RTL machine simulation is the process whereby a program written in the assembly code of the machine to be simulated is read and executed by a different machine. The result is the same as executing the code on the architecture being simulated [67]. Other forms of RTL simulation employ a machine which has characteristics that are not physically present. This virtual machine may have more memory or a different instruction set, among other characteristics. An RTL defines the instruction set of a microprocessor for simulation in terms of a small set of register transfer statements. If the RTL statements are carefully chosen, they will remain unchanged as instruction sets are defined for various microprocessors. An RTL is not limited to microprocessors, but can also be used for almost any other piece of digital electronic hardware. This extends its usefulness beyond computer architecture to the electrical engineering field. The basic composition of an RTL for a microprocessor is as follows. The microprocessor is defined in terms of a set of register transfers which carry out the intended function in the same way the actual microprocessor would perform it. These register transfers are a mapping of the data flow through the microprocessor. A translator then reads these instructions to simulate the proposed architecture. The actual circuitry and the register transfer code generate exactly the same final output. In addition the register transfer execution will typically produce statistics about the actual simulation, such as execution cycles required, memory accesses, and other related information. This extra output is invaluable when the designer desires to view the internal states of a microprocessor. With the RTL model, this is easily accomplished; however, with the hardware prototype, this can be difficult or impossible due to the need to attach additional hardware to monitor the various signals. A model of a real (or proposed) microprocessor can be defined using an RTL. Tests may be run comparing different implementations of the same languages, or of various languages. Studies of this sort could then be applied to various compilers running on this microprocessor. Comparisons could be made on execution efficiency of the compiler. In this way, a compiler writer could ascertain the statements for which the compiler has difficulty generating efficient code, and possibly deal with these inefficiencies at the RTL level. These inefficiencies can be dealt with by changing the register transfer sequences within the microprocessor to make it more closely conform to the way compilers tend to generate code. More importantly, the architecture could be changed with no hardware modifications. 1.5. Silicon Compilers In this study, an RTL compiler written in Pascal is presented that will read the RTL specification and produce a Pascal program. This resulting program will then simulate the target architecture and produce output at each cycle of the simulation.