Processor Design Suite

8/8/2019 Processor Design Suite

1/102

Department of Electrical and Computer EngineeringUniversity of Toronto

Final ReportTitle: Parameterized Processor Design SuiteProject ID #: 0192000

April 11, 2001Date:

D. BeresfordSection Coordinator

5Section:

Stephen BrownSupervisor:

Navid Azizi [email protected] Bradel [email protected] Czajkowski [email protected] Krejcik [email protected]

Prepared by:

Page 1


2/102


3/102

3 Team Members Contributions

Tables 3.1 through 3.4 outline the contributions made by the authors to thedesign project. Table 3.5 outlines the contributions each author made to the writing ofthe final report.

Table 3.1: Contributions Made by Navid Azizi

Navid AziziTesting and Numerical Analysis ofSpecified Processor and Components

Navid AziziTesting of Instruction, Resource and

Signal classes

Navid AziziDevelopment of Instruction, Resource,and Signal classes for Instruction Set

Based Component Selection

Navid AziziTesting and Simulation ofParameterizable Processor Templates

Navid AziziDevelopment of ParameterizableProcessor Templates in VHDL

Navid Azizi(this responsibility was shared with the

other members of the team)

Design Project Research

Individual Responsible For the TaskTask

Page 3


4/102

Table 3.2: Contributions Made by Borys Bradel

Borys BradelIntegration Testing of Java DesignSuite

Borys BradelTesting and Simulation of JavaModules to Read and Write defined

XML Interfaces

Borys Bradel

(this responsibility was shared withMichael Krejcik)

Development of Java Modules to Read

and Write defined XML Interfaces

Borys BradelTesting and Simulation of I/O Interfaceto Parameterizable Processor

Borys BradelDevelopment of I/O Interface toParameterizable Processor

Borys Bradel(this responsibility was shared with the




Page 4


5/102

Table 3.3: Contributions Made by Tomasz Czajkowski

Tomasz CzajkowskiTesting and Simulation of ProcessorControl Unit

Tomasz CzajkowskiDevelopment of Processor Control Unit

Tomasz CzajkowskiTesting and Simulation of ScriptProcessing Engine

Tomasz CzajkowskiDevelopment of Script Processing

Engine

Tomasz CzajkowskiTesting and Simulation ofMemory/Cache and Controller

Tomasz CzajkowskiDevelopment of Memory/Cache andController

Tomasz Czajkowski(this responsibility was shared with the




Page 5


6/102

Table 3.4: Contributions Made by Michael Krejcik

Michael KrejcikTesting of assembler

Michael KrejcikDevelopment of assembler

Michael KrejcikTesting of Graphical User Interface

Michael KrejcikDevelopment of Graphical UserInterface

Michael Krejcik(this responsibility was shared with

Borys Bradel)

Development of Java Modules to Readand Write defined XML Interfaces

Michael KrejcikDevelopment of XML Interfaces

Michael Krejcik(this responsibility was shared with the




Page 6


7/102

Table 3.5: Contributions made by the Team Members for the Final Report

Navid Azizi10 Conclusions

Navid Azizi

Michael KrejcikTomasz Czajkowski

Borys Bradel

9 Design Sections 9.1, 9.3, 9.7.1,

9.7.3, 9.10 Sections 9.2, 9.8, 9.9 Sections 9.4, 9.6, 9.7.4 Sections 9.5, 9.7.2, 9.7.5

Borys Bradel8 Introduction

Tomasz Czajkowski7 Acknowledgments

Navid Azizi6 Table of Contents

Borys Bradel5 Revised Timeline

Borys Bradel4 Old Milestones

Navid Azizi3 Team Members Contributions

Borys Bradel2 Executive Summary

Navid Azizi1 Cover Page

Individual Responsible for the SectionSection

Page 7


8/102

4 Old Milestones

There are four main milestones that relate to the actual design of our project:

Our processor design completed by the first week of March

The processor parameterizer completed by the second week of February The assembler completed by the second week of March

Our testing and analysis completed by the third week of March

The complete list of milestones as stated in our proposal is given in Section 5.2along with the status of these milestones at the end of our project. Appendix 1 containsthe timeline that corresponds to the initial set of milestones. We found that, althoughthe initial milestones did not change significantly when examined from afar, some partsof our project took more time than expected and others took less time than expected.This phenomenon is interesting in that these parts were sometimes gathered under asingle milestone. A good example of this is the processor parameterizer, which wasdivided in two, and yet had a single milestone.

The original division of responsibilities has the same shortcomings as our initialtimeline. The responsibilities were not detailed enough and had to be modified. Thefollowing is the original division of responsibilities taken verbatim from our proposal:

All four people will work equally hard on the submission unit, and the final testingof the processor. The processor parametrizer and the assembler will be developedprimarily by Borys and Michael. The initial planning and first attempt at designing theprocessor will be performed by all four people and divided based on personalpreferences. The latter parts of the processor design will be dealt with primarily byNavid and Tom. The work will be divided evenly between everybody, and every personwill have to know and understand what the other people are doing so as to gain themaximum benefit from this project.

5 Revised Milestones

The following sections describe the various factors that affected our timeline anda comparison between our accomplished and original milestones. The differenttimelines that we had throughout the project are described in Appendices 1, 2, and 3.Appendix 1 contains our original timeline. Appendix 2 contains the timeline that we hadat the time of our interim reports and Appendix 3 contains our most recent timeline.

5.1 Reasons for Modification

The main factor that affected our schedule is the realization that certain parts ofour project are tightly coupled to each other and that the rest are almost completelyindependent. Two other factors are a heavier than expected workload in the secondterm and a limitation of the hardware that we have available.

We discovered in the latter part of the first term that the Hardware GenerationProgram and the controller for the processor are more complicated than we firstanticipated and are dependent on the instruction set and design of the processor. For

Page 8


9/102

this reason, these two tasks were moved to a later date in the schedule. To make roomfor these tasks, everything else that could be moved to an earlier date in the schedulewere moved. As a result Mike concentrated exclusively on the GUI and assembler,while the other three people concentrated on the hardware and the HardwareGeneration Program. Using this division of responsibilities we were able to do

everything in parallel and harness the synergy of having several people working on twotightly coupled problems.

Unfortunately we had a heavier than expected workload in the second term. Thiscaused us to complete some of our milestones, namely the controller of the processorand the Hardware Generation Program, later than we wanted. Hardware limitationsalso made it impossible to place our processor on an FPGA. We could not fully compilethe processor at home because our versions of Max+plusII do not have the properlicenses to create designs for the appropriate hardware. There is not enough RAM onthe undergraduate sparc machines for us to compile the design, and when we tried tocompile the processor on a friend's EECG account, we ran out of hard drive space onthe partition. So we have concentrated on compiling individual sections of the processor

and looking at their performance characteristics. Our final timeline is presented inAppendix 3.

5.2 Milestone Status

The following is a list of our original milestones and their status at the end of ourproject:

1. Technical Proposal [3rd week of Oct.] Achieved on time

2. Completion of all processor units [2nd week of Dec.] Achieved on time

3. Interim Report [1st week of Jan.] Achieved on time

4. Debugging of all processor units [3rd week of Jan.] Only the controller was not completed on time

The controller was completed by the end of the 3rd week of Feb.

5. Completion of the first attempt at the processor parameterizer [4th week of Jan.] The final version of the GUI was completed by the 3rd week of Jan.

The final version of the HGP was completed by the 3rd week of March

6. Completion of the first attempt at an assembler [3rd week of Feb.] Reached by the 1st week of Jan.

7. Completion of a debugged version of the processor [1st week of March]

Reached by the 2nd

week of March8. Completion of the assembler [2nd week of March]

The assembler was finished by the 4th week of Feb.

9. Completion of Testing [3rd week of March] Testing could not be as complete as we wanted it to be due to hardware limitations

Testing was completed in the last week of March

10. Final Report [1st week of April] Achieved on time

Page 9


10/102

6 Table of Contents

Page 329.3.2 Arithmetic and Logic Unit (ALU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 319.3.1.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 319.3.1.1.2 Output Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 309.3.1.1.1 Input Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 299.3.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 299.3.1 Registerfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 299.3 Processor Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 289.2.5 Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 269.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 259.2.3.3 The New GUI Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 249.2.3.2 Disadvantages of the Initial GUI Design . . . . . . . . . . . . . . . . . . . . . . . . .

Page 249.2.3.1 Advantages of the Initial GUI Design . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 249.2.3 Evolution of Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 239.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 239.2.1.5 Cross Platform Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 239.2.1.4 Limit User Input to only Acceptable Values . . . . . . . . . . . . . . . . . . . . . . .

Page 229.2.1.3 Display Parameters the User can Choose . . . . . . . . . . . . . . . . . . . . . . . .

Page 229.2.1.2 Provide Information About the Program . . . . . . . . . . . . . . . . . . . . . . . . .Page 229.2.1.1 Ease of Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 219.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 219.2 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 209.1.3 Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 199.1.2.1 Parameterized HDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 199.1.2 Hardware Generation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 189.1.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 189.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 189 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 178.4.3 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 178.4.2 Measurement Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 168.4.1 Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 168.4 Design and Measurement Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 168.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 158.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 158.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 158 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 147 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 106 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 95.2 Milestone Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 85.1 Reasons for Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 85 Revised Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 84 Old Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 33 Team Members Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 22 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 10


11/102

Page 609.7.3.3 Signal Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 609.7.3.2 Resource Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 599.7.3.1.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 599.7.3.1.1 Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 589.7.3.1 ProcParameter Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 579.7.3 Instruction Set Based Component Selection . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 579.7.2 Read XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 579.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 579.7 Hardware Generation Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 559.6.3 Design Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 549.6.2 Mapping Function and Replacement Algorithm . . . . . . . . . . . . . . . . . . . . . . . .

Page 549.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 549.6 Memory/Cache Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 539.5.7 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 539.5.6 VGA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 529.5.5 Generic PS/2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 519.5.4 Mouse Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 519.5.3.3 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 509.5.3.2 Generic PS/2 Port and the Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 499.5.3.1 Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 499.5.3 I/O Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 489.5.2 I/O Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 479.5.1 I/O Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 479.5 Processor Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 469.4.2.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 469.4.2.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 469.4.2 Design Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 459.4.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 459.4 Processor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 449.3.3.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 439.3.3.2 Processor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 429.3.3.1.7 Register Data Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 419.3.3.1.6 Program Counter (PC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 419.3.3.1.5 Memory Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 409.3.3.1.4 Shift Amount Input, ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 399.3.3.1.3 Input B, ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 399.3.3.1.2 Input A, ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 389.3.3.1.1 IR and Register Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 389.3.3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 379.3.3 Processor Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 369.3.2.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 359.3.2.1.3 Complete ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 339.3.2.1.2 Bit-Wise Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 329.3.2.1.1 One-Bit ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 329.3.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 11


12/102

Page 97A7.5 Assembler: Java Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 96A7.4 Script Processing: Java Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 95A7.3 Instruction Set Based Component Selection: Java Code . . . . . . . . . . . . . . . . . . . . .

Page 94A7.2 XML Input/Output: Java Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 93A7.1 GUI: Java Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 93Appendix 7: Sample Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 91A6.5 Memory Mapped Bus Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 91A6.4 Generic PS/2 Port Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 90A6.3 PS/2 Mouse Port Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 87A6.2 ALU Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 86A6.1 Registerfile Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 86Appendix 6: Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 85Appendix 5: Instruction Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 84Appendix 4: Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 83Appendix 3: Final Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 82Appendix 2: Timeline from Interim Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 81Appendix 1: Timeline from Technical Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 8010.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 7910 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 769.10 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 739.9.3 Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 729.9.2.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 729.9.2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 729.9.2 Assembler XML Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 709.9.1.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 709.9.1.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 709.9.1 User Information XML Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 709.9 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 699.8.4 Current Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 699.8.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 679.8.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 679.8.1.2 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 679.8.1.1 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 679.8.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 679.8 Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 669.7.5 Write XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 669.7.4.2.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 659.7.4.2.3 Expression Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 649.7.4.2.2 Script Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Page 649.7.4.2.1 Script Processing Ideology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 639.7.4.2 Script Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 639.7.4.1 Script Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 639.7.4 Write VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 629.7.3.5 Processor Specification Determination . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 619.7.3.4 Instruction Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 12


13/102

Page 102Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 101A7.9 I/O: VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 100A7.8 Cache Controller: VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 99A7.7 Control: VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 98A7.6 Datapath: VHDL Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page 13


14/102

7 Acknowledgments

The authors would like to acknowledge their fellow students for giving theirtechnical advice during the course of this project. In particular the authors would like tothank Deshanand Singh for his contribution to the project. Stephen Brown, the projects

supervisor, is also acknowledged for his inspiration and motivation throughout the termof the project.

Furthermore, the authors would like to acknowledge that a significant portion of theconcepts required for the completion of the project were acquired in the various coursesoffered by the University of Toronto's Edward S. Rogers Sr. Department of Electricaland Computer Engineering. Moreover, the publications cited throughout this reportprovided the authors with new ideas and different perspectives, and assisted theauthors immeasurably. Applicable references are cited as much as possible in thereport, and we sincerely apologize for any omissions that we have made in thereferences.

Page 14


15/102

8 Introduction

Our project involves the creation of a software suite with an easy to use interfacethat will give users the opportunity to implement custom processors based on theirneeds. The software suite includes a Graphical User Interface (GUI) that allows the

user to specify the parameters for a processor, a Hardware Generation Program (HGP)that produces the Hardware Description Language (HDL) code for the user-specifiedprocessor, and an assembler that allows the user to create programs for this processor.

The project raises questions concerning the extent to which a processor can beparameterized. Our processor design must achieve a balance between a too genericmodel, which will be hard to implement, and a more specialized model that will limit thechoices a user can make.

8.1 Motivation

Processors are traditionally implemented on Application Specific Integrated

Circuit (ASIC) chips. Designing a processor on an ASIC chip is usually very costly andtime consuming due to the long and expensive manufacturing process that is involvedin the physical creation of the chip. As a result, programmable logic chips have beenused as an alternative processor platform. The two main types of programmable logicchips are Field Programmable Gate Array (FPGA) and Complex Programmable LogicDevice (CPLD) chips. These chips allow users to change their designs withoutincurring the manufacturing costs and delays involved in ASIC design. Programmablelogic chips, however, require the user to know an HDL to be able to program them. Ourproject removes this need while retaining the benefits of using programmable logicchips.

8.2 Background

To lay a better foundation for our project a brief overview of the following topicswill be given: an introduction to FPGA/CPLD chips, the differences between ReducedInstruction Set Computers (RISC) and Complex Instruction Set Computers (CISC) andthe MIPS architecture. These topics are relevant to the report and provide backgroundto some of the design decisions made in the project.

An FPGA/CPLD chip is an integrated circuit that is characterized by an array ofreprogrammable logic blocks and a flexible configurable interconnect structure. Forexample, an Altera FLEX EPF10K40 has 2304 logic blocks [1]. Logic blocks can beviewed as building blocks and when these building blocks are combined together theycan implement many different functions. The connection between different blocks isachieved via a matrix of wires and switches between the blocks. The matrix along withthe logic blocks allows an FPGA/CPLD chip to be customized to meet the individualusers needs.

There are two kinds of paradigms for processors: RISC and CISC. CISC chipsare based on the principle of providing users with many complex instructions, with eachcomplex instruction encapsulating many simpler instructions. Conversely, RISC chips

Page 15


16/102

provide users with only simple instructions. RISC instructions are usually a constantsize, perform one function per clock cycle, and access memory with a limited number ofinstructions. This allows for a simpler processor design and the ability to pipelineinstructions, which increases the speed of the processor.

The MIPS architecture is a specific implementation of the RISC ideas presented

above. MIPS makes an additional simplification that memory can only be accessedwith load and store instructions, thus allowing the processor control and datapath to besimplified even further. The processor implemented in this project is based on theMIPS architecture.

8.3 Objectives

There are several objectives that we wanted to achieve. Section 8.4, Design andMeasurement Methodology, explains our approach to attaining these objectives whileSection 9, Design, describes how we actually achieved them. The objectives of ourproject are to:

Design a set of hardware components to be used as a basis of auser-defined processor

Create a set of easy to use, portable, and flexible software that allows a userto create a processor without knowing a Hardware Description Language

Analyze the performance and benefits of using our approach

8.4 Design and Measurement Methodology

We have made several decisions at the beginning of our project that determinedthe focus of our work. The design that we selected stayed unchanged while our initialideas for measurement had to be modified.

8.4.1 Design Methodology

There are two aspects to our design. The first is a set of software tools thatallows the user to specify, generate, and use a processor. The second is a set of coreprocessor components that indicates the underlying structure of the processor.

We decided to make all of our software flexible, user friendly, and portable. Wedesigned our software so that it is divided into three components. These componentsare a GUI, an HGP, and an assembler. This division was made so as to make eachpiece of software as independent of the other pieces of software as possible. Theindependent pieces of software can be individually modified without affecting the other

parts of the project. Each piece of software is also designed to take full advantage ofobject-oriented design so as to facilitate expansion of the software. The initial interfaceis also generated on the fly whenever it is executed based on a file that containsinformation regarding the choices that the user can make. To make the software userfriendly, we developed an easy to use and intuitive GUI. All of the software is alsowritten in Java and all of the interfaces between the different pieces of software useXML. These two factors make the software extremely portable because Java can be

Page 16


17/102

run on many operating systems and XML files are well-defined text files that should bereadable on any operating system.

Processors are usually implemented on ASIC chips. FPGA chips have beenused only to add functionality to these processors in the form of coprocessors [2-6]. Themethodology for our project differs from the above in that, in addition to producing

reconfigurable coprocessors or modules and connecting them to the processor, thewhole processor is reconfigurable. Our project follows many of the design principlesfrom Rapid Prototyping of a RISC Architecture for Implementation in FPGAs[7] , butallows for much greater flexibility.

8.4.2 Measurement Methodology

Our design allows the user to customize the whole processor on an FPGA. Thecustomization is achieved through the use of the HGP that uses parameterizable HDLmodules to create the precise user specified processor. This allows for theimplementation of a processor that will not contain more functionality than needed. We

have taken measurements of our final product and have answered questions on theefficiency of our model.

To determine the efficiency of our model we analyzed two aspects of the FPGAimplementation of the processor. First, the maximum clocking frequency of the circuitwas documented for a fully featured processor compared to a processor that lacks thefunctionality to perform multiply, divide, and shift operations. Second, the number oflogic blocks used in the FPGA was measured. Both of these measurements have beenperformed within the Max+plus II hardware compilation program. Initially we werethinking of making measurements on the entire circuit. This, however, is impractical,due to limitations of the hardware that we have access to. The limitations have alreadybeen described in Section 5, Revised Milestones. The measurements that we have

taken are presented in Section 9.10.

8.4.3 Report Outline

The report is divided into three parts. The first part contains introductory andwork management information. The second part describes our design. The final partcontains our conclusions. The sections that precede the introduction of this report givean overview of the work distribution for this project. The sections contain a descriptionof the contributions of the different team members, the modifications that were made tothe timeline of this project, and a review of our performance in relation to our initialmilestones. The description of our design is described in the next section. At the end

of our design description we present the results that we have obtained. At the end ofour report we analyze our results, discuss the projects benefits and limitations, anddescribe possible extensions and applications of the project.

Page 17


18/102

9 Design

9.1 Overview

Our project can be divided into many different components. These components

include a Graphical User Interface (GUI), a Hardware Generation Program (HGP), andan assembler.

The design flow for the use of the suite of software tools is show below in Figure9.1.1.

Figure 9.1.1: Design flow for design tool

An overview of all three components, GUI, HGP, and assembler will be givenbelow, and then a discussed of the whole project will be given in greater detail in thefollowing chapters.

9.1.1 Graphical User Interface

The GUI allows the user to create a customized processor. The GUI includes alist of supplied instructions with checkboxes. If the user wants to include an instructioninto the processor, they can check the corresponding checkbox. Furthermore, there areother parameters such as bus width and register sizes that have sliders for the user tospecify. Once the user is satisfied with all of the parameters, they will click on theCreate It button and the GUI will create an XML file which will be submitted to theHGP.

The GUI is written in Java and Java Swing. The reasoning behind this choice isthat Java can be run on a multitude of hardware and operating systems such as UNIX,Linux, Microsoft Windows, and MacOS. Therefore the GUI will look and act

Page 18


19/102

fundamentally the same on all platforms and no extra time will be needed to port theprogram to other platforms.

To pass the information gained from the user to the HGP, the GUI must create afile standard. An XML (Extensible Markup Language) file has been chosen for thispurpose. XML is very flexible in its ability to provide information about objects; custom

fields and their properties can be created and parsed easily. Due to its flexibility andsimplicity XML has become a de facto standard for many data sharing protocols, andtherefore for future expandability and extensibility XML was decided upon as the fileformat for the transfer of information between different modules of the project.

9.1.2 Hardware Generation Program

The HGP is the program that performs the most critical part of the work in theproject. It uses the information contained in the User Information XML file to create acustomized processor. The datapath of the processor is created by using a library ofparametrized HDL code. The HGP extracts the relevant information from the XML file,

and instantiates the HDL modules with the proper parameters. Some modules willalways be instantiated by the HGP, although with different parameters, while othermodules will only be instantiated when needed by the user specifications.

While the construction of the datapath of the RISC processor is a comparativelysimple process, the creation of the control is complex. The HGP will need to analyze allthe modules present in the datapath and create opcodes, as well as the sequencing forall control signals inside the processor. Once this is complete an HDL file describingthe control module is created and a complete processor is available.

The HGP is written in Java for the same reasons that the GUI is written in Java.Furthermore the object-oriented nature of Java allowed for reasonable implementations

of instructions and control signals.The HGP has two outputs: the first is the complete customized processor written

in HDL, and the second is an Assembler XML file. The Assembler XML file allows theHGP to communicate to the assembler (discussed below) what instructions areavailable in the custom processor and the instruction format for each instruction. Onceagain XML is used due to its flexibility to transfer information.

9.1.2.1 Parameterized HDL Code

The reconfigurable HDL code that is the source of the generated processor isbased on the MIPS architecture. The MIPS architecture is a simple RISC architecture

that is the foundation of many commercial processors, such as the processors found inSilicon Graphics workstations. MIPS processors can only access memory through loadand store instructions, which move a variable from memory to the register file (orvice-versa). Other instructions such as add or subtract cannot have operands that existin memory, the operands must exist in the register file. Such a system simplified thedesign of the control for the processor.

The MIPS architecture has four major components: a datapath , a control system,input/output (I/O), and memory. The datapath is comprised of the components in the

Page 19


20/102

processor that perform functions on data. These components in a MIPS processorimplementation include the register file, the ALU, and the internal memory. Since theproject will be a modified version of the MIPS implementation, the datapath will containother components such as special function generators. The control system of theprocessor commands the datapath and memory according to the instructions of the

program.The HDL code written to implement these components was written in a fashion

that allows the HGP to easily load and change the code to implement the desired userconfigured processor. More specifically, the customization of the HDL code wasachieved by using techniques such as writing components as an amalgamation ofrepeated smaller modules, and other techniques.

9.1.3 Assembler

An assembler was written to transform source code written by a human intomachine readable code that is decoded by the custom processor. Un like most other

assemblers, this assembler must be able to deal with the availability of differentinstructions and different machine codings for instructions. The assembler will gatherall the information needed about the particular hardware it is assembling from the XMLfile produced by the HGP, and then translate the user supplied assembly languagesource code.

The assembler will output the machine code that will be stored in the processorsinstruction memory in a format understandable by the FPGA used.

Page 20


21/102

9.2 Graphical User Interface

The GUI needs to inform the user about how to use our program and to displaythe parameters of the processor that the user can choose. Currently, the design allowsthe user to choose values for the number of registers, bus width, address width, and theset of assembly instructions the processor will recognize.

9.2.1 Design

In order to meet our design requirements, the GUI should, in decreasing order ofimportance:

1. Be easy to use2. Provide information about the program3. Display parameters the user can choose

Assembly instructions Bus width Address width Number of registers

4. Limit user input to only acceptable values5. Be cross platform portable

The current design of the GUI that meets these requirements is shown in Figure9.2.1.

Figure 9.2.1: Graphical User Interface for the Parameterized Processor Design Suite

Page 21


22/102

9.2.1.1 Ease of Use

Ease of use was chosen as the number one criterion for the GUI because theGUI is the first thing potential users see. If users are intimidated, have a hard timeusing the program, or never learn about all the features, then a lot of our hard workgoes to waste.

A number of features have been added to the GUI to make it easy to use. Thetop-level menu contains a Help menu item. The Help menu item is one of the firstthings the user sees when the application is displayed. Clicking on it will providedetailed instructions to the user. Another way ease of use was added into the interfacewas through the use of standard controls. Users of common graphical based operatingsystems recognize standard controls like buttons, check boxes, menus, sliders, andtabbed panes. This makes the interface intuitive even though the user may notunderstand the purpose of the controls. Tool Tips were added to all of the standardcontrols to give the user extra information about the functionality of the controls. Alsostandard controls were grouped into four logical sections: Assembly Commands,

Number of Registers, Bus Width, and Address Width. This way the user knows whatchoices they are making depending on what area they are in. All of these featuresprovide the user with an easily accessible interface.

9.2.1.2 Provide Information About the Program

The GUI contains a Help menu item that leads to documentation about theprogram. The documentation contains information about how to use the GUI and howto use the Parameterized Processor Design Suite.

One feature of the documentation is that each assembly instruction that the usercan choose is given a complete description. An example of the documentation

provided for the Add assembly instruction is shown in Table 9.2.1 and a complete list ofall the assembly instructions with descriptions is shown in Appendix 5. Thedocumentation tells you what category the assembly instruction belongs to, theinstructions full name, the parameters it takes, the result of using the instruction and atext description of the instruction.

The sum of registers rs and rt isplaced in register rd

rd = rs + rtrd rs rtAddAddArithmeticDescriptionResultParametersInstructionNameCategory

Table 9.2.1: Example of Documentation for assembly instructions

9.2.1.3 Display Parameters the User can Choose

The main function of the GUI is to provide the user with all of the choices theycan make. This criterion is accomplished by using standard controls to obtain inputfrom the user. When the user clicks the button labeled Create It! the programcaptures the current state of the controls. The GUI uses tabbed panes to present eachof the assembly instructions the user can select. This also allows instructions to begrouped together by category. Also sliders are used for parameters such as bus width,number of registers, and address width.

Page 22


23/102

9.2.1.4 Limit User Input to only Acceptable Values

Limiting user input to acceptable values removes the need for parsing the inputafter it is entered. This also adds less complexity to the user interface.

The GUI achieves this goal by using checkboxes and sliders for input. These

controls have only a limited range of values that the designer can control.

9.2.1.5 Cross Platform Portability

Portability was achieved in the design of the GUI by using Java and the standardJava Swing library. By taking advantage of the Java framework the design istheoretically portable to any platform that has a Java Virtual Machine (JVM) written forit. Grounding our design in Java takes us a step further in making our design portablethan by using any other framework available today.

9.2.2 Implementation

The GUI can be partitioned into two sections: the front end and the back end.The front end collects user information about the processor and the back end outputsthe user information into an XML file. The XML file is used by the next process in theParameterized Processor Design Suite.

The front end of the GUI is written in Java using the Java Swing library. One ofthe major concerns about the implementation of the front end of the GUI was thepossibility of future changes to the specification. Therefore the implementation had tobe written in a way to make it easily adaptable to change.

The implementation of the front end of the GUI has very few hard codedelements in it so as to be as flexible as possible. Instead, the front end relies on an

external file to produce content and only hard codes the manner in which the contentwill be displayed. For instance the GUI knows that it will display a number of checkboxes organized into categories. The actual categories for the checkboxes, the numberof checkboxes, the captions that will go on the checkboxes, help content for thecheckboxes and Tool Tips are all read in from a file before the GUI is displayed. Thesame holds true for the sliders in the GUI. This scheme means that no extra code hasto be written if the project requires additional assembly instructions to be added to theGUI checkbox list. To accomplish this the GUI uses an XML file that contains all thenecessary information. A lower level discussion of this process is included in Section9.2.3.3.

The back end of the GUI has one requirement, which is to output the usersselections into a User Information XML Language (UIXL) compliant XML file.Information about our design specifications of UIXL are included in Section 9.9. Thebackend starts generating the file when the user presses the button on the userinterface marked Create It!

Page 23


24/102

9.2.3 Evolution of Graphical User Interface

The GUI has gone through a cycle of design, coding, and testing. The currentmodel of the interface is a result of what was learned from the initial design. Figure9.2.2 shows the initial design of the GUI.

Figure 9.2.2: : Initial design of the Graphical User Interface

9.2.3.1 Advantages of the Initial GUI Design

The initial GUI design already contained several key features that have beenused in the current design. The initial design effectively separates the interface intothree regions where the user selects the assembly commands to be included, thenumber of registers and the bus width. Standard components, such as check boxesand sliders, have been used in the design. As mentioned earlier, using standardcomponents has two advantages. First it minimizes the users learning curve sincethese components are familiar to the user. Second it limits the users input to correctvalues.

9.2.3.2 Disadvantages of the Initial GUI Design

There are several drawbacks to the initial design. Specifically problems included

the effective use of space in the layout, usability, and flexibility of the design.

When the design of the instruction set, shown in Appendix 5, was completed itincluded over sixty assembly commands. The area allocated for assembly commandsin the initial GUI design will not support over sixty commands. Even if the space wasexpanded, sixty checkboxes cannot be effectively displayed on the screen at one timewithout overwhelming the user.

Page 24


25/102

User testing was conducted in order to obtain useful feedback about theinterface. This testing revealed that although the interface was straightforward itprovided little additional information about the choices the user was making. Forinstance, the assembly instructions should have detailed information about theinstructions upon request. Also the commands should be grouped in a logical order so

that similar commands are presented next to each other. Finally general instructionsfor the entire program should be included.

The initial design also lacks flexibility. Instructions are hard coded into theprogram. This makes changes to the instruction set difficult to implement in the GUI.After the initial design was completed it was determined that another option should beadded to the user interface that allows the user to specify the address width. With theinitial design this option would have to be hard coded into the design as well.

9.2.3.3 The New GUI Design

To improve on all of the problematic areas in the initial design a new GUI design

was planned.In order to allow for greater flexibility and future growth of the project the GUI

now reads its assembly instructions from a Parameters XML file. The Parameters XMLfile layout is shown in Figure 9.2.3. This file contains not only the name of theinstructions but also what category they should be grouped into, the number and type ofthe parameters, the result of the instructions, and a description of the instructions. ThisXML file, with all fields filled out, has been generated for the instruction set. If additionalinstructions need to be added then they can easily be appended to the list.

Page 25


26/102

Figure 9.2.3 : Layout of the Parameters XML file used by the GUI to read in instructions. Note thatellipses are used in the diagram to indicate that a parent tag may include more than one child tag.Specifically the ParameterList tag may include many Category tags and Category tags may includemany Instruction tags.

Add

add

rd

rs

rt

r d = r s + r t

The sum of registers rs and rt is placed in register rd

...

...

In the current design, after the GUI reads in the Parameter XML file, it displaysthe options to the user. Assembly commands in the same category are now displayedon the same tabbed pane. Using tabbed panes allows the number of commands on

the screen at one time to be reduced. A help menu has been added to increaseusability. The help menu contains information about the instructions as well as theoverall usage of the program. Features such as tool tips have also been added to helpusers understand the options they are choosing. Context sensitive help has also beenadded to the GUI. Context sensitive help means that when a user presses F1, a helpmenu appears with information specific to the part of the GUI that currently has focus.Finally another slider has been added to allow the user to select the address widthparameter. A diagram of the new features added to the GUI is shown in Figure 9.2.4.

9.2.4 Testing

Testing of the interface was done using two methods. First, users unfamiliar withthe GUI performed usability testing. Secondly tests were developed to make sure theGUI was stable. These tests were further divided into testing the reading of theparameter XML file, general GUI functionality, and writing of the UIXL output file.Finally integration testing was performed to make sure the interface between the GUIand the HGP works.

Page 26


27/102

Usability testing is important to the GUI in order to discover what potential usershave trouble with. Since the change from the old design of the GUI and the addition of

all the help features usability tests results have improved greatly.

The actual code of the GUI was tested in two different ways. First general

behavior of functions was tested to make sure they perform adequately under normalconditions. Next, testing was performed to make sure the program degrades gracefullyunder adverse conditions. For instance tests such as removing the input file, enteringerroneous data, or inputting too much data were performed.

Since the interface between modules was decided on near the beginning of the

project, integration testing produced few errors.

Figure 9.2.4: Revised design of the graphical user interface with added Help Menu, Tabbed panes, ToolTips, and Address Width selection

Page 27


28/102

9.2.5 Current Status

Currently the graphical user interface is complete. All of the features discussedhave been implemented. This includes the new features discussed in the interimreport. Testing of the GUI has resulted in a stable product.

Page 28


29/102

9.3 Processor Organization

9.3.1 Registerfile

The registerfile is the portion of the processor that keeps intermediate results of

program instructions. It is characterized by a range of registers, which hold theintermediate results, along with functions to retrieve values and to store new values.

9.3.1.1 Design

The registerfile required for the design of the processor needed two maincapabilities. First, due to the Reduced Instruction Set Computing (RISC) paradigm thatthe processor design was following, the registerfile needed to be able to supply twovalues at once. Second, the registerfile needed to be able to be parameterized tohandle different bus widths and to have a varying amount of registers available.

To accommodate the above two requirements the registerfile needed to fit the

Very High Speed Integrated Circuit Hardware Description Language (VHDL) componentdescription seen in Figure 9.3.1.

Figure 9.3.1: Registerfile VHDL Component Declaration

COMPONENT registerfileGENERIC (

BUSWIDTH: INTEGER:=32;NUMREG: INTEGER:=32;LOG2NUMREG: INTEGER:=5);

PORT (write : IN STD_LOGIC;clk : IN STD_LOGIC;readreg1 : IN STD_LOGIC_VECTOR(LOG2NUMREG - 1 DOWNTO 0);readreg2 : IN STD_LOGIC_VECTOR(LOG2NUMREG - 1 DOWNTO 0);writereg : IN STD_LOGIC_VECTOR(LOG2NUMREG - 1 DOWNTO 0);writedata : IN STD_LOGIC_VECTOR(BUSWIDTH - 1 DOWNTO 0);readdata1 : OUT STD_LOGIC_VECTOR(BUSWIDTH - 1 DOWNTO 0);readdata2 : OUT STD_LOGIC_VECTOR(BUSWIDTH - 1 DOWNTO 0));

END COMPONENT;

As can be seen from the component description the registerfile can becustomized with the use of BUSWIDTH and NUMREG parameters (Note:LOG2NUMREG is itself not a parameter, but the ceil(log2(NUMREG)) and is included inthe parameter list due to an inability of VHDL to perform arithmetic computations in thedeclaration of a component).

The design within the registerfile can be seen in Figure 9.3.2. There are 3 mainparts to the design: the registers, the output circuitry, and in the input circuitry, all ofwhich can be individually parameterized to construct the correct registerfile

Page 29


30/102

Figure 9.3.2: Registerfile

9.3.1.1.1 Input Circuitry

The input circuitry of the registerfile allows new data to be stored in theregisterfile. As can be seen from Figure 9.3.2, the Write Data Signal, which containsnew data to be stored, is connected to the data input of all the registers. However, thedata cannot be written into the register unless the enable signal for the particularregister is high.

Thus a particular register must be selected with the aid of a decoder that takesthe Write Reg signal (which is a integer from 0 to the number of registers -1) and setsthe enable signal of the particular register to high. This scheme, however, allows for aregister to be written to at every clock pulse. The output of the decoder is ANDed withthe Write Enable signal so that the processor can control when new data is written intoa register.

Page 30


31/102

9.3.1.1.2 Output Circuitry

The output circuitry of the registerfile allows data to be extracted from theregisterfile. As per the requirements for RISC architecture, there are two output ports.The Read Reg 1 and Read Reg 2 signals (which are integers from 0 to the number ofregisters -1) select the appropriate register through the use of a multiplexor.

The multiplexors in the design are quite large (due to the multiplexing of a largenumber of registers and the fact that each register output is also composed of manywires) and therefore use many logic cells within the FPGA. A, simpler and more spaceefficient design would consist of tri-state buffers, as seen in Figure 9.3.3, used toconnect all the registers to the output signal, but since FPGAs do not haveprogrammable tri-state buffers, multiplexors must be used instead.

The multiplexors were created with the aid of LPMs (Library of ParametrizableModules) from within Max+plus II and are parameterizable, and therefore the specificmultiplexor needed can be easily created.

Figure 9.3.3: Tri-Stated Output Circuitry

9.3.1.2 Testing

The registerfile module has been completed and fully tested in simulation thusmeeting the mid-November deadline. Please see Appendix 6 where the timingdiagrams for the test cases are available. The test cases outline a scenario whereinformation is stored in each register and then the information is retrieved from eachoutput port.

Page 31


32/102

9.3.2 Arithmetic and Logic Unit (ALU)

The ALU is the component of the processor that performs all the arithmeticoperations such as addition and multiplication as well as all the logical operations suchas comparison testing and shifting.

9.3.2.1 Design

The ALU required for the design of the processor needed to be extensivelymodular so that the removal and addition of arithmetic and logic operations by the HGPcould be performed without upsetting the rest of the ALU. Furthermore, the ALUneeded to be able to handle different bus-widths and therefore, not only needed to bemodular per instruction, but also in terms of the size of inputs it could handle.

The design of the ALU thus proceeded from the design of a one-bit ALU, whichcould then be integrated into any size ALU.

9.3.2.1.1 One-Bit ALUThe one-bit ALU is the building block of the whole ALU, and therefore needs to

be designed in a parallel fashion to reduce the dependencies between instructions.The VHDL component description of the one-bit ALU can bee seen in Figure 9.3.4.

Figure 9.3.4: One-Bit ALU VHDL Description

COMPONENT onebitaluGENERIC (BITWISEALUOPSIZE :INTEGER:=4;

NUMBERBITWISEALUOP: INTEGER:=16);PORT (

a : IN STD_LOGIC;b : IN STD_LOGIC;carryin : IN STD_LOGIC;slt : IN STD_LOGIC;slte : IN STD_LOGIC;sgt : IN STD_LOGIC;sgte : IN STD_LOGIC;

seq : IN STD_LOGIC;sne : IN STD_LOGIC;bitaluop : IN STD_LOGIC_VECTOR(BITWISEALUOPSIZE-1 DOWNTO 0);binvert : IN STD_LOGIC;f : OUT STD_LOGIC;carryout : OUT STD_LOGIC;addoutfinal : OUT STD_LOGIC);

END COMPONENT;

The one-bit ALU is characterized by two parameters and a series of inputs. TheNUMBERBITWISEALUOP parameter is the number of bit-wise operations the ALU canperform. The second parameter is actually a transformation of the first(ceil(log2(NUMBERBITWISEALUOP)) and is included due to the inflexibility of VHDL

noted above.The inputs to the one-bit ALU also constitute a parameterizable aspect of the

ALU that the HGP can play with. As can be seen from the design of the one-bit ALU inFigure 9.3.5 the inputs slt (set on less than) through sne (set on not equal) can beincluded, or not included depending on the user specifications. For example, If the user

Page 32


33/102

Figure 9.3.5: Design of One-Bit ALU

needs a less than comparison then the slt (Less in Figure 9.3.5) will be included,otherwise it will not be part of the design. The other sXX inputs can be added orremoved in the same fashion by the HGP. Furthermore, as can be seen from Figure9.3.4, one-bit operations such as AND and XNOR can be removed from the one-bitALU without affecting the other ALU operations. The user specifications will determinewhich gates are included in the one-bit ALU during compile time.

The control signal Bit Invert is used to allow for subtraction. If subtraction, andall other operations that need subtraction (such as branching or comparisons) are not

required in the ALU, this control signal and the accompanying multiplexor can beremoved from the one-bit ALU by the HGP.

9.3.2.1.2 Bit-Wise Operations

Following the design of the one-bit ALU, many one-bit ALUs can be used intandem by the HGP to construct a variable size ALU that can perform bit wiseoperations (Figure 9.3.6). All the one-bit ALUs are exactly the same, and therefore the

Page 33


34/102

HGP can generate as many one-bit ALUs as necessary to develop the customizedprocessor.

Figure 9.3.6: Variable Size ALU

The only difference between the one-bit ALUs used in the total ALU is thesource of their input. The first one-bit ALU receives its Less, Greater and Equal signalsfrom the comparison-checking module, and all others receive 0 as their input. Thismechanism is used to provide the set on less than and comparable instructions. The

comparison-checking module receives the result of input A minus input B (not shown inFigure 9.3.6) and thus can determine if the input A was equal, less than or greater thaninput B. Furthermore the comparison-checking module will determine if overflow hasoccurred during the arithmetic operation.

Page 34


35/102

9.3.2.1.3 Complete ALU

With the ALU designed above, the processor can perform a limited number ofoperations. For a more extensive list of operations, such as multiply and divide, theALU designed above must be incorporated into a larger ALU. In Figure 9.3.7, the

bit-wise ALU is just one part of a larger modular ALU.

Figure 9.3.7: Full ALU

The complete ALU contains modules for shifting, rotating, multiplying, anddividing, as well as containing the bit wise ALU. These former modules were createdwith the aid of LPMs contained in MAX+plusII and therefore can be easily modified bythe HGP to handle different bus-widths. Furthermore, any or all of these modules canbe removed by the HGP without affecting the functionality of the other modules.

Page 35


36/102

With the removal of either multiply or divide, the two multiplexors adjacent to theHi and Lo registers in Figure 9.3.7 can be removed by the HGP. With the removal ofboth multiply and divide the two registers can also be removed. The Hi and Lo registersare contained in the ALU due to observation that both multiply and divide will produceresults that are 2*N bits wide given inputs that are N bits wide, and thus the result must

be stored within the ALU so that the program can store each portion of the resultindividually.

Figure 9.3.8: Complete ALU VHDL Description

COMPONENT total alu

GENERIC (N : INTEGER :=32;ALUOPSIZE : INTEGER :=5;BITWISEALUOPSIZE : INTEGER :=4;FUNCTALUOPSIZE : INTEGER :=3;SHIFTSIZE : INTEGER :=5);

PORT (clk : IN STD_LOGIC;a : IN STD_LOGIC_VECTOR(N-1 DOWNTO 0);b : IN STD_LOGIC_VECTOR(N-1 DOWNTO 0);aluopin : IN STD_LOGIC_VECTOR(ALUOPSIZE - 1 DOWNTO 0);shiftamt : IN STD_LOGIC_VECTOR(SHIFTSIZE - 1 DOWNTO 0);funct : OUT STD_LOGIC_VECTOR(N-1 DOWNTO 0);zero : OUT STD_LOGIC;overflow : OUT STD_LOGIC;lt : OUT STD_LOGIC;lte : OUT STD_LOGIC;gt : OUT STD_LOGIC;gte : OUT STD_LOGIC);

END COMPONENT;

From the VHDL component description of the of the complete ALU it can beseen that the ALU can be parameterized with five parameters:

1. N: bus-width2. ALUOPSIZE: ceil(log2(number of operations available))3. BITWISEALUOPSIZE: ceil(log2(number of bit-wise operations))

4. FUNCTALUOPSIZE: ceil(log2(number of operations - number of bit-wise opr.)5. SHIFTSIZE: ceil(log2(N))

With these parameters the number of operations and the bus-widths can beselected, and the HGP must then remove the unneeded modules from the ALU toconstruct the final ALU needed for the customized processor.

9.3.2.2 Testing

The ALU module has been completed and fully tested in simulation thus meetingthe end of November deadline. Please see Appendix 6 where the timing diagrams forthe test cases are available. The test cases outline all the ALU operations being

performed on 2 sets of inputs.

Page 36


37/102

9.3.3 Processor Datapath

The processor datapath is the organization of different components within theprocessor. The datapath displays how components such as the registerfile and ALUare connected to each other. The general datapath for the processor that the HGP willcreate can be seen in Figure 9.3.9. (For simplicity control signals are not drawn in full,but are replaced with red stubs)

Figure 9.3.9: Datapath

Page 37


38/102

9.3.3.1 Design

The design of the datapath followed the MIPS architecture and was influencedby the instruction set that the HGP supports (displayed in Appendix 5). The datapathneeds to be able to handle all possible instructions, and their combinations. Toillustrate the design decisions made for the datapath, the use of each multiplexor in the

design will be discussed. The Instruction Register (IR), which plays an important part inthe datapath, will also be discussed.

9.3.3.1.1 IR and Register Selection

The design of the binary values that constitute instructions is of vital importancefor making the datapath efficient and simple. Due to the variability of the instructionformat that the HGP will generate, only a brief discussion will follow.

It is assumed that instructions will follow one of three formats. Following is a listof the three formats along with the information stored in the format in parentheses.

1. Reg-Type, register to register operations such as add:(Opcode, read reg1, read reg2, write reg, shift amount)

2. Immediate/Address-Type, operations involving natural numbers such as addimmediate and branch(Opcode,read reg1, write reg, immediate value/address)

3. Jump-Type, instructions to unconditionally jump from one region of a programto another.(Opcode,address)

The IR contains the instruction presently being executed in the processor, andthe instruction can be in one of the three formats explained above. Thus the

information flowing out of the IR loosely follows Figure 9.3.10. (It is not exact due to thevariability that can be generated by the HGP.)

Figure 9.3.10: IR and Register Selection

Page 38


39/102

With the three different instruction formats it can be seen that the inputs to ReadReg 1 and Read Reg 2 always come from the same portion of the IR. The Write Reginput however may come from the 4th portion of the IR (in reg-type instructions) or the3rd portion of the IR (in immediate-type instructions). Since the Write Reg input maycome from different portions of the IR, a multiplexor is needed to select between the

different inputs depending on which type of instruction is being processed . The selectsignal (not shown in Figure 10) for the multiplexor comes from the processor controlwhich determines what instruction is being performed from analyzing the opcode field inthe IR.

Note that this portion of the datapath cannot be simplified unless only reg-typeinstructions were available in the processor, but such a design would serve no practicalpurpose due to the inability to use memory.

9.3.3.1.2 Input A, ALU

The first input to the ALU can originate from two places as seen in Figure 9.3.11.

The ALU input can originate from register A, which temporarily holds the informationreceived from the first output of the register file, or the ALU input can originate from theProgram Counter (PC), which contains the address in memory of the current instruction.The first scenario is used when any reg-type instruction is being performed and thesecond scenario is used whenever the address of the next instruction must becomputed (usually PC = PC + 4). Thus, regardless of the user specifications, thisportion of the datapath also cannot be simplified by the HGP.

Figure 9.3.11: Input A, ALU

9.3.3.1.3 Input B, ALUAs the first input to the ALU can originate from many place, so can the second

input to the ALU. It can originate from four locations as can be seen in Figure 9.3.12.The four locations and scenarios are the following:

1. Register B, temporarily containing the information received from the secondoutput of the register file. This scenario is used with all reg-type instructions.

2. The number 4, used to increment the PC (i.e. PC = PC + 4)

Page 39


40/102

3. The output of the Sign Extension Module, which receives an immediate valuefrom the IR and expands it to fill the whole bus-width. This scenario is usedwith any immediate instruction such as add immediate. (immediateinstructions have a constant embedded into them)

4. The output of the Shift Left Module, which receives a sign extended address

from the Sign Extension Module and shifts it left to convert the word offset.This scenario is used with branch instructions to convert the word offset to abyte offset.

Figure 9.3.12: Input B, ALU

If immediate instructions are not needed then the third input to the mu ltiplexorcan be eliminated by the HGP, and if there are no branch instructions in the userspecifications the fourth input to the multiplexor can also be eliminated. Furthermore, ifboth immediate and branch instructions are not needed by the user, the Sign Extensionand Shift Left Modules can be both eliminated by the HGP during the creation of thecustomized processor.

9.3.3.1.4 Shift Amount Input, ALU

The Shift Amount Input to the ALU is used to determine how many bits input Ashould be shifted when a shift or rotate instruction is being performed. As can be seenin Figure 9.3.13, the number of bits can originate from two places depending on if theshift is a normal shift operation or a variable shift.

In a normal shift operation the number of shifts is hard-coded in the IR , but in avariable shift operation the number of shifts is stored in a particular register in theregisterfile, and thus is temporarily stored in Register B.

If either type of instruction, normal shifts or variable shifts, is not in the userspecifications, then the HGP may remove the multiplexor.

Page 40


41/102

Figure 9.3.13: Shift Amount Input, ALU

9.3.3.1.5 Memory Inputs

The memory is where the instructions composing the program and the majorityof the data used within the program are stored. The design of the memory is notdiscussed in this section as it is discussed in Section 9.6. Suffice it to say that thememory takes a memory address and either supplies the value or stores new data atthat memory address depending on the value of Read/Write control signal.

Figure 9.3.14: Memory

The address for the memory may originate from either the PC, to retrieve thenext instruction in the program, or AluOut, where the computed address for a load orstore instruction is stored temporarily. Regardless of the user specifications, the HGPmay not simplify this portion of the design as it is required for even the simplest

processor.

9.3.3.1.6 Program Counter (PC)

As explained above the PC contains the memory address of the next instructionto be performed in the processor. The contents of the PC are usually incremented topoint to the next instruction to be retrieved, but jumps and branches can alter theprogram flow and place arbitrary values in the PC.

Page 41


42/102

Figure 9.3.15: PC input

As can be seen from Figure 9.3.15, the new value for the PC may come fromfour sources:

1. AluOut: To handle regular PC + 4 update2. Reg A: To handle the jump register instruction where the next value of

the PC is held in the registerfile.3. ALU: To handle branches where the old value of the PC is added to the

branch offset.

4. Shift Left: To handle jump instructions where the word address in the IR isshifted left to construct a byte address and then combined withthe most significant bits of the original value PC to obtain the newvalue of the PC.

This portion of the datapath can be considerably simplified by the HGP if jumpinstructions are not required; the top two branches in Figure 9.3.15 can then beeliminated. In addition, if branches are not required then the multiplexor can also beremoved.

9.3.3.1.7 Register Data Input

New data that will be stored in the register file can originate from two places.Either the data is the result of an arithmetic or logic operation and is stored temporarilyin AluOut or the data is being retrieved from memory by a load instruction and is storedtemporarily in the Memory Data Register (MDR). Thus, as can be seen in Figure9.3.16, there is a multiplexor to select between the two sources of data into the registerfile.

Page 42


43/102

Figure 9.3.16: Register Data Input

The HGP cannot simplify this portion of the design since a processor withoutload or arithmetic operations would be useless.

9.3.3.2 Processor Parameters

After reviewing the design of the processor, the parameters needed to constructa custom processor can be readily chosen. Figure 9.3.17 contains the VHDLcomponent description for the processor.

Figure 9.3.17: VHDL Description for complete processor

ENTITY proc IS

GENERIC (BUSWIDTH: INTEGER:=32;NUMREG: INTEGER:=32;LOG2NUMREG: INTEGER:=5;NUMINSTRUCTIONS: INTEGER :=32;OPCODEFIELDSIZE: INTEGER :=6;REGFIELDSIZE: INTEGER:=5;SHAMTFIELDSIZE: INTEGER:=5;FUNCTFIELDSIZE: INTEGER:=6;JUMPFIELDSIZE: INTEGER:=26;IMMEDIATEFIELDSIZE: INTEGER:=16;WORDTOBYTEOFFSET:INTEGER:=2;

ALUSRCASIZE_A: INTEGER:=1;ALUSRCBSIZE_A: INTEGER:=2;POWERALUSRCBSIZE_A:INTEGER:=4;PCSOURCESIZE_A: INTEGER:=2;POWERPCSOURCESIZE_A:INTEGER:=4;

ALUOPSIZE_A : INTEGER :=5;BITWISEALUOPSIZE_A : INTEGER :=4;FUNCTALUOPSIZE_A : INTEGER :=3);

PORT (clk : IN STD_LOGIC;aluout : OUT STD_LOGIC_VECTOR(BUSWIDTH-1 TO 0));

END proc;

The parameters include all the parameters needed for the creation of theregisterfile and ALU as well as parameters such as PCSOURCESIZE_A whichindicates the number of possible locations that the value of the PC can come from.Furthermore, parameters such as REGFIELDSIZE are included so that the differentcontent within the IR can be connected to the appropriate places.

Page 43


44/102

9.3.3.3 Testing

The complete datapath has not been tested since the computing resourcesneeded to compile the processor are not available (Please see Section 9.10).

The testing of the modules in the datapath, including the Sign Extension

Modules and Shift Left Modules have been fully tested in simulation. Please seeAppendix 6 where the timing diagrams for the test cases are available

Page 44


45/102

9.4 Processor Control

The control circuitry is what controls how each instruction is being processed bythe processor. The control system is essentially a finite state machine (FSM) [8]. Thestate machine transitions through a set of states for each instruction in order to ensureproper instruction execution.

The program will use the state information for each instruction along withpredefined states to generate a new transition table with all necessary states. Eachstate will be responsible for handling a part of the execution of a single instruction.

9.4.1 Flow Control

The processor executes commands on an instruction by instruction basis. Inorder for the program to be executed correctly the processor control circuitry repeatedlyprogresses through four stages of instruction execution. The four stages are shown inFigure 9.4.1.

The first step is to fetch an instruction from the memory. The instruction beingloaded from memory is located at the address specified by the program counter (PC).Once this instruction is loaded into the instruction register (IR) it can then be decoded.In the decoding step, the controller reads the opcode of the instruction to identify itspurpose and if necessary reads additional information from memory. The next step is toexecute the instruction. This is done by loading all appropriate registers and executingthe instruction specified by the opcode. The last step is to store the result of theoperation in a specified location.

Figure 9.4.1: Processor Modes of Execution

Page 45


46/102

9.4.2 Design Approach

In order to properly design the control unit for the parameterizable processor wedecided to create a generic control unit upon which all control units generated by oursoftware are based. The main advantage of this decision, is that if a processor with afull instruction set worked with the specified control units, then removing control stepsfor unused instructions would not affect the flow of control for other instructions. Thefollowing sections will explain how the control unit was designed and tested.

9.4.2.1 Design Principles

The design of the control unit follows the four stage model of execution as seenin Figure 9.4.1. Each instruction, with a few exceptions, has exactly the same fourstages to execute before it completes. This similarity allows for optimization, such ashaving only one instruction fetch state set for all instructions, rather than separate setsfor each instruction. The second advantage of this approach is the ability for someinstructions to take less time, because a step in the execution model has been skipped,

since it was unnecessary. For example, the jump instruction only requires three stages.The reason for this is that unlike instructions such as add, subtract or multiply, the jumpinstruction only needs to update the program counter (PC) register with a new addressvalue. This value is stored in the opcode of the instruction, and therefore it does notneed to be computed by the ALU. This allows one stage of execution to be skipped.

9.4.2.2 Testing

The testing of the control unit was done based on the full instruction set. Thebasis for our testing method was the fact that if the control unit was able to properlycontrol all instructions provided by the design suite, then it would also properly control asmaller subset of those instructions.

Once the testing was complete, we have decided to test a reduced version of thecontrol unit. This stage of testing was necessary in order to verify that there are nodependencies between states of different instructions, as well as to prove that the HGPproperly optimized the control circuitry.

Page 46


47/102

9.5 Processor Input/Output

An I/O interface was designed, created, and tested for the processor. Theinterface uses memory mapped I/O that allows the processor to only communicate witha limited set of devices. There are two different ways to access input and outputdevices in the majority of computer systems. The two different ways are direct portaccess and memory mapped access. Direct port access requires that devices have aseparate set of connections to the processor and that the processor has extrainstructions to deal with these devices. Memory mapped access on the other handallows the processor to have a simpler design. Extra logic, however, must be addedoutside of the processor to figure out if the processor wants to access memory or an I/Odevice [8]. Only memory mapped I/O was implemented so that the processor, the mostcomplex hardware, component is as simple as possible.

The VHDL files that are being generated can be divided into two large sections,the processor, and everything outside the processor. The processor can be furthersubdivided into a register file, an Arithmetic Logic Unit (ALU), a data path, and a control

circuit. The processor can communicate with everything outside of it through a set ofaddress, data, and status lines that connect it to everything else. Everything elseincludes memory for storage, I/O devices that allow the processor to interact with theoutside world, and a way to figure out if the processor wants to communicate with thememory or with the I/O devices. Figure 9.5.1 is a block diagram that represents how thedesign looks like at a high level of abstraction.

Figure 9.5.1: High Level Abstraction of Hardware

9.5.1 I/O Interface

The I/O interface examines the information that has been sent by the processorand then determines which device the processor wants to communicate with. The I/Ointerface can be connected to a mouse, a keyboard, any number of PS/2 devices, andto a monitor. The mouse, keyboard, and other PS/2 devices have relatively simpleinterfaces, while the monitor has a rather complicated interface. Figure 9.5.2 showshow the I/O interface is divided.

Page 47


48/102

Figure 9.5.2: I/O Interface

9.5.2 I/O Controller

The I/O controller communicates with the processor in the same way thatmemory does. The processor sends an address, a signal that indicates when theprocessor wants to communicate, a signal that specifies if the processor wants to readdata or to write data, and data, if the processor wants to write data. These signals arepassed along wires that have been labeled a (address), as (address strobe), rw(read/write), and d_in (data in), respectively.

The processor in turn can receive signals from the I/O interface. These signals

include a signal that indicates that the operation is successful and data that the devicesends to the processor if the processor wants to read information. These signals arepassed along the dtack (data acknowledge) and d_out (data out) lines respectively.

This entire unit also uses a clock to synchronize with the monitor and a slowclock to communicate with any PS/2 devices. The devices also interact with the outsideworld by using several lines that end in pins that can connect to the devices. EachPS/2 device requires data, clock, ground, and power supply lines. The monitor requirespins that carry red, green, and blue intensities as well as horizontal and vertical refreshsignals. These pins must go through all of the design files in a cascading fashionbecause they must be assigned as pins in the main program file that encapsulates all ofthe design files.

The I/O controller waits until the processor wants to interact with an I/O device.Once this event occurs, the I/O controller looks at what device the processor wants tocommunicate with, and whether the communication is a read or a write. The device isselected based on the address that the processor sends. The controller then passesthe appropriate information to the device it has chosen and waits until thecommunication has completed. The operation is completed when the address is nolonger valid. Once the communication is completed the selected device becomes

Page 48


49/102

unselected and cannot send any more signals to the processor unless it is selected

again.

9.5.3 I/O Devices

Unlike the rest of the processor, I/O devices have a fixed number of pins thatthey use. All PS/2 devices have six pins in their sockets. PS/2 devices however, onlyrequire four pins and the rest of the pins are unused. [9] A VGA monitor requires fivepins as mentioned previously. PS/2 devices usually operate at a frequency between10 and 33 kHz [9] while a monitor has a very specific way that it has to be dealt with so

that it works correctly.

9.5.3.1 Mouse

A PS/2 mouse communicates with another device through a 6-pin PS/2connector. The 6 pins on the connector are:

1. Data2. No connection3. Ground4. +5 V5. Clock

6. No connection

The pin layout f

Date post:	10-Apr-2018
Category:	Documents
Upload:	mbosc
View:	218 times
Download:	0 times

Processor Design Suite

Documents