GUI for Computer Architecture Simulation



GUI for Computer Architecture Simulation

Design Report

Team: May01-05

Clients and Advisors: Dr. Somani and Dr. G. Manimaran

Team Members:

Neil Hansen

Benjamin Jones

Jon Mathews

Sergey Sannikov

Submitted: November 28, 2000

Revised: December 13, 2000

Table of Contents

List of Figures ii

List of Tables ii

Abstract 1

Acknowledgement 1

Definition of Terms 2

Introduction 3

General Background 3

Technical Problem 3

Operating Environment 4

Intended Users and Uses 4

Assumptions and Limitations 4

Design Requirements 5

Design Objectives 5

Functional Requirements 5

Design Constraints 6

Measurable Milestones 6

End-Product Description 7

Approach and Design 8

Technical Approaches 8

Technical Design 9

Testing Description 13

Risks and Risk Management 14

Recommendation for Continued Work 15

Financial Budget 16

Personnel Effort Budget 17

Project Schedule 18

Summary 21

References 22

Appendix A – Micro-architecture 23

Appendix B – Micro-architecture Simulation Output 26

Appendix C – Translation Output Format 27

Appendix D – Instruction Set 29

Appendix E – Testing Forms 30

List of Figures

Figure 1 – System Data Flow Diagram 3

Figure 2 – System Data Flow Diagram 8

Figure 3 – MIPS Assembly Converted to Verilog 10

Figure 4 – Data Flow Diagram for GUI 12

Figure 5 – Project Schedule 19

Figure 6 - Example of Screen Layout 23

List of Tables

Table 1 - Proposed Financial Budget 16

Table 2 – Original and Revised Estimated Time Costs 17

Table 3 – Supported Instructions 29

Abstract

The study of computer architecture is a challenging field because of the high degree of complexity involved in any computer system. Simulation tools have been developed to ease this complexity, allowing architectures to be developed, modified, and compared. However, these tools lack a flexible graphical user interface to help visualize the internal operation of the architecture. This has motivated the need for software that will provide an interactive display that shows the computer instructions as they are processed by the computer architecture. This software will be an effective tool for students and researchers alike because it will allow them to see the execution of actual assembly programs. It is expected that the first use of the software will be for teaching computer architecture courses at Iowa State University.

Acknowledgement

Dr. Somani and Dr. G. Manimaran will provide significant advice and guidance throughout this project.

Definition of Terms

Assembly instructions – lowest level of instructions executed by a computer processor.

Control lines – the part of the micro-architecture of a microprocessor that commands the components of each stage.

Control path – see control lines.

Delay slot – a method for reducing the delays caused by a branch instruction. In the MIPS architecture, the assembler is expected to fill in the instruction after the branch with one that will always get executed.

Hazards – in a micro-architecture, a condition that prevents the flow of instructions through a pipeline.

Instruction set – the commands understood by an architecture.

Micro-architecture – the design of a microprocessor with respect to the instruction set.

Microprocessor - a modern computer processor, for example the Intel Pentium.

MIPS – stands for millions of instructions per second, a measure of speed in computer architecture. Also, the name of a company that produces computers; the instruction set used by these computers is referred to as MIPS, which does not stand for anything.

Pipelined processor – a microprocessor that uses multiple stages to process instructions.

SimpleScalar – an architecture simulation program.

Verilog – a hardware description language.

Introduction

General Background

Computer architecture is a challenging subject to study because it involves understanding how a large number of components interact to form a micro-architecture. Although there are tools to aid in the study of computer architecture, they lack a flexible graphical user interface (GUI), which increases the usability of any software. The goal of this project is to develop a GUI for existing micro-architecture simulation software to enhance the design and learning process. Whereas most existing tools produce most of their output as text, this GUI will graphically present the desired output. Furthermore, the main component of this GUI will be an animation of the micro-architecture, consisting of a graphical presentation of the instructions, the data they operate on, and the control signals used.

The software could be used as either a research tool or as an educational aid, but because the first use of the software will be to teach students in CprE 305 (Iowa State University), the software will be geared towards emulating the micro-architecture (primarily the microprocessor) found in the textbook for that course [1].

Technical Problem

The technical problem can be divided into three distinct parts, illustrated in Figure 2: the model of the microprocessor, the translation layer, and the display of output in a user-friendly manner. Using a micro-architecture simulator, simulation text output will be generated that will be given to a translator and then be fed to a program that will present an animation through the GUI.

Figure 1 – System Data Flow Diagram

Operating Environment

It is expected that the software will run in labs at Iowa State University or on a student’s home computer. The animation will be expected to fit within the size of the screen (the minimum size will be determined later).

Intended Users and Uses

The software is intended to be an educational tool to assist students in visualizing computer micro-architecture. The users will be primarily students in micro-architecture who already have some basic understanding. In addition, instructors can use the software as a presentation tool in class.

Assumptions and Limitations

• It is assumed that the instructors will find a way to distribute the software to the students.

• The screen size will limit the amount of information that can be effectively displayed, therefore only the internal microprocessor components will be shown. The cache and other supporting parts of the architecture are not as important for showing instruction execution and will be left out.

• It is assumed that the initial use of the program will be for CprE 305, so the animation will initially be limited to the micro-architecture presented in the course textbook [1]. If any figures are used from the book to construct the animation, copyright issues will need to be addressed. In addition, the following assumptions are made:

▪ The software will not limit the program size, however, it is expected that the initial programs will be examples for students consisting of less than 60 MIPS instructions. Only the 5 instructions currently in the microprocessor will need to be tracked during execution.

▪ It is assumed that the initial users will be students who are at least in part familiar with the MIPS instruction set.

▪ Initially only the MIPS architecture found in [1] will be supported.

▪ The instructions recognized by the simulation and GUI will be a subset of the MIPS instruction set for simplicity of understanding and ease of implementation. The subset that will be implemented can be found in Appendix D.

▪ The functionality of the simulation will not initially include branch prediction, delay slots (a branch delay technique), and exception handling. This is done for the ease of implementation.

▪ Simulated memory may be smaller than the total virtual space (several kilobytes will be sufficient for this project).

Design Requirements

Design Objectives

The goal of the project is to provide an animation of a microprocessor through a GUI. It will allow the users to select a MIPS assembly program from a collection of pre-made programs for animation. The animation will be based on the figures found in the textbook currently used for CprE 305 at Iowa State University [1]. This brings about a number of considerations that must be met by the software. These are as follows:

The animated microprocessor must mimic the pipelined microprocessor in the book as closely as possible, matching both the look and function of the microprocessor to maximizing understanding for the student.

Initial programs will be examples that illustrate micro-architecture concepts taught in class. Therefore, assembly level control over the programs is required. For example, to illustrate a delay due to data dependencies, a specific sequence of assembly instructions needs to be executed to cause the conditions to be met in the simulation.

The GUI should allow the student to see the process of instruction execution, including information regarding components of the microprocessor such as registers, control components, and instruction flow.

• The interface and graphics should be simple to use and understand. Further, information should be provided in layers that can be added or removed to improve clarity. For example: control lines add another layer of complexity for the student to understand, and should not be displayed until the student is ready.

Functional Requirements

The functional requirements of this project are the options that will be presented to the students through the GUI.

• Micro-architecture display – this will be the visual representation of the microprocessor based on the book on the screen.

▪ Colors – each stage of the micro-architecture will be color-coded.

▪ Assembly instructions – the currently executing instructions will be displayed in a key on the screen. They will be in the color of the stage they are currently in.

• Open program file dialog – students will be able to select a pre-made program to animate.

• Play and fast-forward – the student will be able to step through the animation cycle by cycle or in increments by pressing the appropriate button.

• Quit – the quit button will end the animation and exit the program.

• Layers – the student will be able to select the layers of information presented in the animation.

• End of program display – when the end of the program is reached, it will be indicated to the user on the screen.

• On-line user manual – for explaining the above controls and micro-architecture display.

Design Constraints

• The animation and microprocessor model have to mimic the microprocessor in [1], with the exception of no cache or memory delays to keep the animation simple. This is necessary to maximize student understanding.

• The number of instructions animated will be restricted to the basic and/or most used instructions found in the textbook, also to maximize clarity for the students.

• The screen size will limit the amount of information that can be effectively presented, so the screen layout will have to be efficient.

• The animation will need pre-made program output to animate, which will be provided by the microprocessor simulation.

• The program will need Java compliant browsers to work on a given platform

• The user’s computer will have to be fast enough to handle animation. The choice of software for animation will affect the minimum speed requirements.

Measurable Milestones

• Microprocessor simulation shows basic output (10%) - instructions move from stage to stage and register data is known.

• Microprocessor simulation produces desired output (25%) - instructions follow all specific features of the micro-architecture.

• Working draft of the graphical user interface (25%).

• Working animation – final product (40%).

End-Product Description

The product is GUI educational tool for students and researchers studying micro-architecture. It animates a set of pre-made files, which describe the execution of MIPS instruction set assembly programs as if they were being executed by the pipelined microprocessor found in “Computer Organization and Design: The Hardware/Software Interface, Second Edition” by Hennessey and Patterson. This helps users to visualize the internal process of instruction execution in the architecture by showing the details of each

instruction as it progresses from stage to stage.

Approach and Design

Technical Approaches

The problem can be decomposed into three distinct components as shown in Figure 2 (repeated from Figure 1):

Figure 2 – System Data Flow Diagram

• Microprocessor Simulation

In order to create an authentic animation of a microprocessor, it is necessary to have a model of the microprocessor’s behavior. Without this information, it would be impossible to determine program flow. The criteria for this approach will be ease of implementation, extendibility to other architectures, and the ability to mimic the microprocessor in [1].

• Translator

The point of the translation layer is to transfigure the simulation output to a form that is readable by the GUI software. This provides a convenient level of abstraction between the GUI and the microprocessor simulation.

• GUI

The display needs to be efficient to make use of the space available on screen. The criteria for this approach will be ease of use and the amount of information that can be displayed.

Technical Design

Microprocessor Simulation

The microprocessor simulation software used can come from several sources:

• Write from scratch using the Verilog hardware description language.

- Pro: simulation using Verilog would provide a more accurate model of the microprocessor.

- Con: an assembler would need to be built/modified to produce the necessary input for the simulation.

• SimpleScalar – a microprocessor simulation written in C that lacks a graphical interface.

- Pro: an assembler is already available for the simulation.

- Con: the simulation would have to be modified to correctly represent the micro-architecture.

Verilog was chosen over SimpleScalar for several reasons:

• SimpleScalar uses a modified version of the GNU C compiler to generate binary programs. These binaries have overhead that makes it difficult to extract the small number of assembly instructions needed to illustrate key micro-architecture concepts. By using Verilog, this problem can be avoided because all of the programs have to be coded into a memory structure in the form of a Verilog file. This lends itself to the small programs desired for the project.

• Verilog is currently used by students in CprE 305 to simulate parts of the micro-architecture presented in [1]. By implementing the simulation in Verilog, it retains the possibility for further use in the educational process. For example, students could create their own components and swap them into the model for design verification purposes.

To simplify the process of coding programs into the Verilog memory structure, an internal tool will be developed to automatically generate the Verilog file from a text file containing assembly instructions, hereafter referred to as the pseudo-assembler. The pseudo-assembler will be coded in Perl because the language has the powerful text processing capabilities necessary for this software, and at least one team member can already code in Perl. The input to the software will be a text file containing MIPS assembly, and the output will be the instruction memory for the simulation implemented in Verilog.

The pseudo-assembler design is fairly simple because it only needs to parse the MIPS assembly and directly convert it into a hexadecimal format (in ASCII) by looking up the appropriate encoding in a table. An example is shown in Figure 3. These numbers are all available in [1]. Only branches and jumps require more than a simple conversion. For these instructions relative addresses need to be calculated, therefore the pseudo-assembler implements labels so the offsets can be generated automatically. It should be noted that the conversion process would be more complicated if it were necessary to support either delay slots or the rest of the instruction set. Supported instructions are found in Appendix D.

Figure 3 – MIPS Assembly Converted to Verilog

To obtain data for animation it is necessary to reproduce the microprocessor’s behavior. This will be done by a simulation model coded in Verilog using the register transfer level (RTL). The simulation model will consist of a number of Verilog modules each simulating specific part of the microprocessor in [1]. The simulation top level module will invoke instances of other modules and print values of variables in the output file in ASCII form. A sample output is shown in Appendix B. The variables to be output contain information necessary to display as part of animation, for example, data in the pipeline registers, states of the control lines, ALU input and output values and so on. This information is critical to understand the concepts of the MIPS micro-architecture and must be correct.

The pseudo-assembler mentioned above will produce the instruction memory module in the form of a Verilog file. This file will contain binaries (represented in ASCII) that correspond to a MIPS assembly program that a user will select to animate. The Verilog simulation will produce all the data relevant to each microprocessor element. Besides the production of the microprocessor simulation data, the Verilog model has to be enhanced to indicate the progress of each instruction in the pipeline. This will free the translator and the GUI animation program from making this decision based on the simulation data.

Translator

The translator will convert simulation output into a standard format as defined below. The software will be coded in Perl because it also requires the language’s text processing capabilities.

The translation output format needs to be fairly abstract to keep the simulation implementation separate from the GUI. Each program that is simulated will be translated into an output file, and thus will resemble an execution trace. The overall format of these files is divided into the following two parts:

• Header

This section of the file contains information about the architecture that generated the trace (for future expansion) and the trace of executed instructions. The instructions are placed here for reference later by the data section and for simplification of the on-screen program listing.

• Data

The data section lays out the execution of the program cycle-by-cycle. During each cycle (marked by a tag), the stages are listed one at a time. Immediately following the stage label is the instruction currently occupying the stage since the GUI should not have to examine the data to determine this implicitly. Instructions are referenced by index in the program listing given in the header. After the current instruction, data for all objects in the stage are presented. Objects are defined as any object that gets read from or written to in the architecture since these are the only objects that the simulation needs to provide data for. If an object is skipped, it is assumed that no change occurred. The end of each stage is marked by a tag and followed by the remaining stages, and then the next cycle.

The objects for the MIPS architecture are listed in Appendix A, and a sample format showing the tags and layout of the translation output format is given in Appendix C.

GUI

Programming of the display will need to be done in a language that supports creation of graphical interfaces. The alternatives considered are listed below:

• Java

• Tk/Tcl

• C++

• Macromedia Flash

For this project, the GUI will be developed in the Java programming language. Java was chosen because it provides built in support for graphics and because of the ease of distribution through the World Wide Web. The other options lacked the combined portability and graphical ability of Java, and thus were not as attractive as alternatives. Although extra education would be required for any of these options, there is already a class offered in Java on campus.

• Operation

The operation of the GUI is very simple. The user selects a file to be viewed in the GUI on a starting screen. After this file is selected the GUI takes input from the translator layer as seen in Figure 2. This input comes in the form of a text file. In Figure 4 the text file is parsed by the GUI code. To accomplish this the user presses the play button and the file is parsed into several data structures that represent each pipeline stage. These data structures will contain the necessary variables in that stage and the corresponding components for the display of information. After the variables in the data structures have been updated. The GUI will update the corresponding screen components with this information. This continues in a cycle as dictated by the user stepping through the program until it is complete. The user also has the option of stepping forward 10 clock cycles. This is accomplished by incrementing the GUI but not updating the screen until the appropriate cycle is reached.

Figure 4 – Data Flow Diagram for GUI

• Display

There will be two main windows to the GUI. The first window will be a file selection window. This window will allow the user to choose which pre-made assembly file they would like to simulate. An add-on feature to the first window would allow the user to view the assembly code of the file they are about to select. The second window will be the actual display of the micro-architecture. This window will have several features. The first is a listing of the five instructions that are currently in the pipeline. Plus the previous five instructions and the next five instructions will also be displayed. Also there will be an option to select which layers the user would like to view. This will be broken down into three layers: the data flow layer, the control lines layer, register values, and everything will be selections to view. These layers will either be mapped on the screen or viewed as pop-up windows as the team deems necessary for clearer viewing. As future work a display of the instruction format of the instruction currently in the instruction fetch stage may be added to the GUI. Another thought for future work would be to have coloring differentiate between an active one-bit control line, and a non-active one-bit control line.

Testing Description

The product needs to meet the design criteria stated in the design objectives section of this document. The product will be tested in 4 phases:

• Unit test

Unit tests verify that each software component works independently.

The following unit tests are planned:

▪ Simulation

For each instruction (or type of instruction), verify that:

o Registers are properly updated

o Control lines are correctly simulated

Verify that hazards are detected.

Verify that flags are set to indicate instruction advancement in the pipeline.

▪ Translator

Verify that output is correctly formatted as per Appendix C.

Verify that instruction advancement is noted and all objects are updated each cycle.

▪ GUI

Verify that buttons work correctly.

Verify that menus work correctly.

Verify that each animation element displays correctly (colors, data).

Verify that data displays such as the program listing work correctly.

Verify that layers work correctly.

• System test

System tests will check the functionality of all the components once they are assembled as a whole. Although the simulation is only run when a new program needs to be animated, it is necessary to verify that the integrity of the software from the original assembly file input to the final animation. The following tests are planned:

▪ The GUI parses translator output and animates the data correctly.

▪ The entire system works from simulation to animation – data can be traced from the beginning to end without error.

• Evaluation test

An early version of the software will be demonstrated to graduate students and faculty in the computer engineering department to obtain early feedback. These tests will determine the following:

• correctness of the simulation

• suitability as a presentation tool

A questionnaire will be prepared to help determine whether these criteria are met.

• User test

Students currently taking CprE 305 will test the usability of the interface and provide feedback on its suitability as an aid for learning computer architecture.

A sample set of questions is provided in Appendix E, which will be administered over the web.

The intermediate products will consist of the software components: the Verilog based simulation, the translator, the GUI. It will also include the pseudo-assembler used to generate Verilog files from MIPS assembly to help automate the simulation process.

The product acceptance criteria are as follows:

• The animation should be similar enough to the architecture in [1] that students can cross-reference the concepts.

• Students should find the display simple to use (determined by testing).

• A user manual and technical manual will be prepared to accompany the software.

Risks and Risk Management

Risks Encountered:

• The architecture in [1] is a full and complex architecture, and it has proven difficult to simulate it in its entirety. As noted in the project plan, the differences between the animation and the architecture will be noted. Further, the reduction in amount of complexity comes mostly from a reduced instruction set and should make the concepts easier to understand for students in the long run.

• Since Java has been chosen as the language to develop the GUI in, it has become necessary to learn the language. Since this has been a part of the project schedule from the beginning, it yet to become a problem.

Possible Risks:

• To handle the possibility that the project cannot be completed in time, the software features will be done in stages so that at any given time a working version will exist (at the very least, a proof of concept). This refers to implementing support for each instruction from simulation to animation instead of attempting to support the entire set all at once.

• In the event that team members are lost, the project should still be able to continue because each team member will be knowledgeable about all aspects of the project. Also, the team is split into two groups: one to work on the graphical interface, and the other to work on the micro-architecture simulation.

• If it becomes difficult to learn enough Java in time to implement some of the more complicated parts of the GUI, it may be necessary to complete a reduced form depending on what language features are known.

Recommendation for Continued Work

At this time, it is recommend that the reduced version of the project as outlined in this document be completed. The reductions are as follows:

• A subset of the MIPS instruction set will be supported, focusing on the most used instructions as listed in Appendix D.

• Delay slots, branch prediction, and exceptions will not be supported. This will help increase student understanding since these topics are not discussed to the same extent as the other micro-architecture concepts, and it will also significantly reduce the complexity of the simulation software.

Financial Budget

The following table is the proposed budget for the GUI for computer architecture project:

Table 1 - Proposed Financial Budget

|Item |Original Estimated Cost |Total Cost to Date |

|Poster |$50 |$44 |

|Total |$50 |$44 |

The budget in Table 1 is based on the fact that this project is completely software oriented. Therefore, it is not necessary to purchase any parts that many other projects normally budget money for. Any books that are purchased for programming reference will come out of pocket because the team members will keep the reference books.

Personnel Effort Budget

The following table is the proposed effort for the team over the next two semesters.

Table 2 – Original and Revised Estimated Time Costs

(in hours)

|Team Member |Design |Coding |Testing |Evaluation |Meetings |Totals |

| |est |rev |est |rev |est |rev |est |rev |est |rev |est |rev |

|Hansen, Neil |20 |20 |20 |30 |10 |15 |15 |15 |100 |140 |165 |220 |

|Jones, Ben |20 |20 |30 |35 |5 |10 |5 |5 |100 |140 |160 |210 |

|Mathews, Jon |20 |20 |30 |40 |15 |15 |5 |5 |100 |140 |170 |220 |

|Sannikov, Sergey |20 |20 |20 |20 |20 |20 |15 |15 |100 |140 |175 |215 |

|Total Est. Effort |80 |80 |100 |125 |50 |60 |40 |40 |400 |560 |670 |865 |

Table 2 presents a revised estimate amount of effort for the project. As indicated in the table, most of the time will be in meetings. Meeting time was budgeted for weekly advisor meetings and for creating the poster and project plan, and has been revised to reflect the actual amount of time being spent on these activities. Because the project is mostly coding, the testing and evaluation stages are listed in addition to time spent designing and coding.

Project Schedule

The following Gantt chart in Figure 5 on the next page represents the revised estimated time line and progress to date for the project. Each item is linked where one task is dependant upon the completion of another task. A bold line through the task indicates that it was completed before the estimated time. Tasks such as learning SimpleScalar and redesigning SimpleScalar were cut due to design decisions. Learning Verilog and designing the Verilog simulator were added to reflect the changes. Note the basic steps for project design such as functional requirements, preliminary design, and software design take up the majority of the first semester. Coding, testing, and evaluation are the major events of the second semester.

[pic]

Figure 5 – Project Schedule

Project Team Information

Clients/Faculty Advisors

Name: Arun Somani

Address: 3108 Coover Hall

Ames, IA 50011

Phone Number: (515) 294-0442

Email Address: arun@iastate.edu

Name: Manimaran Govindarasu

Address: 3219 Coover Hall

Ames, IA 50011

Phone Number: (515) 294-9175

Email Address: gmani@iastate.edu

Team Members

Name: Neil Hansen

Address: 4625 Steinbeck Apt. #5

Ames, IA 50014

Phone Number: (515) 292-0222

Email Address: nhansen@iastate.edu

Major: CprE

Name: Ben Jones

Address: 407 Welch Avenue

Ames, IA 50010

Phone Number: (515) 292-5266 x302

Email Address: bjonz@iastate.edu

Major: CprE

Name: Jon Mathews

Address: 2331 Hawthorn Court

Ames, IA 50010

Phone Number: (515) 572-7754

Email Address: jmathews@iastate.edu

Major: CprE

Name: Sergey Sannikov

Address: 29B Schilletter Village

Ames, IA 50010

Phone Number: (515) 572-4199

Email Address: sergey@iastate.edu

Major: CprE

Summary

Currently students in CprE 305 have no way of visually simulating the processing of assembly level instructions through the micro-architecture. This project will allow the students to better comprehend the flow of data through a microprocessor, and how each instruction is executed. By having this program on a web-server the students will be able to reach the animations from virtually anywhere allowing for a flexibility not obtained by looking at figures in a book. This will also allow professors to be able to simulate assembly level instructions that coincide with the material that is currently being learned in the course.

References

[1] Hennessy, John and Patterson, David [1998]. Computer Organization and Design: The Hardware/Software Interface. Morgan Kaufmann Publishers Incorporated, San Fransico, CA.

[2] Java 2 Software Development Kit. Sun Microsystems. .

[3] Morgan Kaufmann Publishers. .

[4] SimpleScalar. .

[5] SPIM. .

Appendix A – Micro-architecture

This appendix contains an example screen layout and a listing of micro-architecture elements that will be shown on the screen that require simulation data.

Figure 6 is an example of the screen layout. The stages of the micro-architecture are highlighted in color to reflection the instructions currently in each stage, as can be seen in the assembly code listing on the lower left. Controls are shown on the lower right. The actual animation will make further use of color to highlight the functional units and control lines.

[pic]

Figure 6 - Example of Screen Layout

A catalog of the objects (every wire and logic element that needs data from the simulation) follows.

Conventions:

• Each stage list the objects that originate at the stage

• Objects start without a prefix

• Prefixes: b – bus, c – control line, bc – control bus);

IF Stage:

b.Pcin

PC (b.PCout)

b.Pcnext

Instruction Memory (b.Instruction)

ID Stage:

IDregister (b.IDPCnext, b.IDinstruction)

b.IDReadRegister1

b.IDReadRegister2

RegisterFile(RFout1, RFout2)

b.IDinstructionRs

b.IDinstructionRt

b.IDinstructionRd

b.SignExtendin

SignExtend (b.SignExtendout)

ShiftLeft2 (b.ShiftLeft2out)

b.PCbranch

b.Controlin

Contol(c.Exception, c.Branch, c.IF.flush, c.EX.flush, c.ID.flush, bc.Memory)

HazUnit(c.IDcontol, c.IDwrite, c.PCwrite)

EX Stage:

EXregister (b.ExceptionPC, b.EXRFout1, b.EXRFout2, b.EXSignExtendout, b.EXinstructionRs, b.EXinstructionRt, b.EXinstructionRd, bc.EXWB, bc.EXM, bc.EXEX, c.ALUsrc, c.RegDst)

bc.muxEXWB

bc.muxEXM

b.ALUin1

b.ALUin2Reg

b.ALUin2

ALU (b.ALUout)

ALUControl(bc.ALUControl)

ForUnit(c.ALUin1, c.ALUin2)

b.EXWriteReg

MEM Stage:

MEMregister(b.MEMALUout, b.MEMData, b.MEMWriteReg, c.MemWrite, c.MemRead, bc.MEMWB)

DataMemory(b.Dataout)

WB Stage:

WBregister (b.WBdata, b.WBALU, b.WBWriteReg, c.RegWrite, c.MemtoReg)

b.WriteData

Appendix B – Micro-architecture Simulation Output

The micro-architecture simulation will produce output in a form similar to that below. This is given as a reference to illustrate the need for a translation component.

time, Instr_ID, PCout , ID_Rs, RF_OUT1, ID_Rt, RF_OUT2,clk

0 , xxxxxxxx, 00000000, xxxxx, xxxxxxxx, xxxxx, xxxxxxxx, 0

5 , xxxxxxxx, 00000000, xxxxx, xxxxxxxx, xxxxx, xxxxxxxx, 1

10 , 20080007, 00000004, 00000, xxxxxxxx, 01000, xxxxxxxx, 0

15 , 20080007, 00000004, 00000, 00000000, 01000, xxxxxxxx, 1

20 , 20090001, 00000008, 00000, 00000000, 01001, xxxxxxxx, 0

25 , 20090001, 00000008, 00000, 00000000, 01001, xxxxxxxx, 1

30 , 01008814, 0000000c, 01000, 00000000, 00000, xxxxxxxx, 0

35 , 01008814, 0000000c, 01000, xxxxxxxx, 00000, 00000000, 1

40 , 01099016, 00000010, 01000, xxxxxxxx, 01001, 00000000, 0

45 , 01099016, 00000010, 01000, xxxxxxxx, 01001, xxxxxxxx, 1

50 , 1109fffc, 00000014, 01000, xxxxxxxx, 01001, xxxxxxxx, 0

55 , 1109fffc, 00000014, 01000, 00000007, 01001, xxxxxxxx, 1

60 , 00000000, 00000018, 00000, 00000007, 00000, xxxxxxxx, 0

65 , 00000000, 00000018, 00000, 00000000, 00000, 00000000, 1

70 , 00000000, 0000001c, 00000, 00000000, 00000, 00000000, 0

75 , 00000000, 0000001c, 00000, 00000000, 00000, 00000000, 1

Appendix C – Translation Output Format

The following listing is a short example of a program after the translator converts its simulation data. Example simulation output can be found in Appendix B. Comments are provided in the text.

# comments are preceded by a pound sign

[HEADER]

# Identifies the architecture that generated the simulation data

Architecture = "MIPS (Hennessy/Patterson)"

# Assembly instructions executed, for the listing.

# Instructions are referred to later by number starting

# with 00000001 (decimal). If there are more than

# 10 million instructions, the counter will either

# wrap or get extended. The Program Counter is also

# listed for completeness.

0x40000140 add t1, s2, t3

0x40000144 lw k0, 0x3390

######################################################

[DATA] # Run time data section.

# Objects retain the last value they are assigned -

# therefore, they don't have to be repeated every

# cycle when instructions are stalling, but repetition

# is also allowable. Instruction transitions are

# explicitly noted by referring to the instruction

# order.

# All numbers are in binary to indicate the value as

# well as the exact number of bits. The animation

# software is expected to convert to different formats # where appropriate.

@1 # cycle counter

# stage label

*00000001 # instruction 1 from the program listing is in the stage

# note that all numbers are in binary

PCOut = "00000000 00000000 00000000 00000100"

D-InstMemOut = "00101010 01111011 11111000 00110101"

# end of the fetch stage section

# note that there is no data for the rest of the cycle –

# in an actual simulation, it may be necessary to

# provide initial data values for everything

@2 # cycle 2

# stage label

*00000002 # instruction 2 from the program listing is in fetch now

PCOut = "00000000 00000000 00000000 00001000"

D-InstMemOut = "00101010 01111011 11111000 00110101"

*00000001 # inst 1 from the program listing is in decode now

C-IF.Flush = 1

C-ID.Flush = 0

[END] # no more simulation data

Appendix D – Instruction Set

The MIPS instruction set can be categorized based on the three kinds of instruction formats: arithmetic, immediate, and jump. The instructions supported by the pseudo-assembler are listed in Table 3. The micro-architecture simulation will support them when completed. For a more complete reference, see [1].

Table 3 – Supported Instructions

|Arithmetic |Immediate |Jump |[nothing] |

|add |addi |j |nop |

|addu |addiu | | |

|and |andi | | |

|nor |beq | | |

|or |bgez | | |

|sll |bgtz | | |

|sllv |blez | | |

|slt |bltz | | |

|sltu |bne | | |

|sra |lui | | |

|srav |lw | | |

|srl |ori | | |

|srlv |slti | | |

|sub |sltiu | | |

|subu |sw | | |

|xor |xori | | |

Appendix E – Testing Forms

The following will be used for Unit and System test forms:

Component: __Simulation____

|Date |Name |Test |Description |Pass/Fail |Comments |

|2/3 |JM |Asm2 |Assembler output for add |P | |

|2/4 |JM |Sim3 |Verify add instruction control |P | |

| | | |lines | | |

| | |Sim4 |Verify add inst register | | |

| | | |manipulation | | |

| | | | | | |

| | | | | | |

The following questions will be given to users as a part of the User test. A section will also be provided for comments. These questions will most likely be administered through a web page linked to from the software so data can be collected quickly and without much effort on the part of the users.

1. Upon opening the simulator's web page, did the program load up quickly?

2. Was there any problem loading the translation file?

3. Was there any glitches in the GUI when running the simulation?

4. Does the GUI provide a clear understanding of a micro-architecture simulation?

5. Do you believe the simulator can be a helpful tool for learning micro-architecture design?

-----------------------

GUI Screen Display

Write Back Structure

Memory

Structure

Decode

Structure

addi $t0, $0, 7

addi $t1, $0, 1

add $s1, $t0, $0

sub $s2, $t0, $t1

beq $t1, $t0, -4

nop

'h00000000: dataout='h20080007;

'h00000004: dataout='h20090001;

'h00000008: dataout='h01008814;

'h0000000c: dataout='h01099016;

'h00000010: dataout='h1109fffc;

'h00000014: dataout='h00000000;

Execute Structure

Instruction Fetch Structure

Text File

Translator

GUI

Simulator

Translator

Translated

Simulation

Output

Micro-architecture Simulation

Assembly

Code

Assembly

Code

Micro-architecture Simulation

Translated

Simulation

Output

Translator

Simulator

GUI

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download