1 / 20

GUI For Computer Architecture

GUI For Computer Architecture. Team Members: Neil Hansen CprE Ben Jones CprE Jon Mathews CprE Sergey Sannikov CprE. Clients/Advisors: Manimaran Govindarasu Arun Somani. May01-05. April 25, 2001. Presentation Outline. Problem Statement Design Objectives End Product Description

nani
Download Presentation

GUI For Computer Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GUI For Computer Architecture Team Members: Neil Hansen CprE Ben Jones CprE Jon Mathews CprE Sergey Sannikov CprE Clients/Advisors: Manimaran Govindarasu Arun Somani May01-05 April 25, 2001

  2. Presentation Outline • Problem Statement • Design Objectives • End Product Description • Assumptions and Limitations • Project Risks and Concerns • Technical Approach • Recommendations for Further Work • Evaluation of Project Success • Human and Financial Budgets • Lessons Learned • Closing Summary • Questions

  3. Problem Statement • Verilog and SimpleScalar are tools that aid in the study of computer architecture, but they lack a flexible graphical user interface (GUI). • Professors in computer engineering at Iowa State would like to enhance the visualization of the computer architecture that the students are studying.

  4. Design Objectives Develop a GUI for a computer architecture simulator that: • Allows students to see the process of instruction execution. • Is simple to use and understand. Layers are used to show and hide information and to improve clarity.

  5. End Product Description • The product is a GUI educational tool for students studying micro-architecture. • It animates the execution of MIPS assembly programs cycle by cycle. • The animation is based on data generated by a Verilog simulation of the computer architecture. • Instructors can simulate new programs with the provided tools for distribution to the students.

  6. Program Screenshot

  7. Assumptions and Limitations • The micro-architecture is limited to a simplified version of MIPS architecture as described in CprE 305. • Users are expected to be familiar with the MIPS instruction set. • Animations consist of less than 60 cycles. • The simulator must be capable of producing text output. • Screen size limits the effective display of information.

  8. Project Risks and Concerns Possible Risks: • Not finishing on time. • Losing a team member. • Pitfalls of learning a new language. Risks Encountered: • Complexity of the architecture. • Preferred version of Verilog hard to find. • Security issues with Java. • Source management.

  9. Simulator Translator GUI Technical Approach • Micro-architecture simulator (Verilog) • Translator (Perl) • GUI software (Java)

  10. Verilog Instruction Memories Verilog Output Assembly Source Code Assembler Verilog Model Technical Approach (cont.) Micro-architecture Simulation and Tools

  11. Verilog Output Assembly Program Traces Translator Technical Approach (cont.) The Translator

  12. Program Traces Technical Approach (cont.) GUI

  13. Recommendations for Further Work • Support advanced architecture features. • A server version of the software would allow students to submit their own code for animation. • Enhance the quality of the animation with multimedia.

  14. Evaluation of Project Success Milestones: • Assembler to create Verilog programs. • Verilog model of architecture. • Translator from Verilog to GUI. • GUI software. • User and Instructor Manuals • Code documentation.

  15. Project Success (cont.) Testing Approaches • System test • Evaluation test by graduate students and faculty: • Provides feedback on the effectiveness of the tool • Determines the suitability as a presentation tool • User test by students currently taking CprE 305 to provide feedback on the usability of the tool.

  16. Human and Financial Budgets

  17. Human and Financial (cont.)

  18. Lessons Learned • Start early on all deliverables. • Software can disappear from the labs. • Contingency plans are helpful. • Goals and milestones keep the project on track. • Communication and teamwork make for smooth sailing.

  19. Closing Summary • This software allows students to better visualize the internal processes of a micro-architecture. • Instructors are able to present course material in more flexible format.

  20. Questions? Comments…? Concerns…?

More Related