08 / 04: Project 2 delivery until 14/05.

22 / 03: Project 1 delivery until 02/04.

25 / 02: There will be no class on 19/03/2013.

25 / 02: Discipline monitoring worksheet with notes and information about the groups.

08 / 02: Don't miss the important dates of the Graduation calendar.

Improve the concepts learned in the Computer Systems Design course. Reinforce programming concepts in large code bases. At the end of this course, the student should be able to:

• Define and use a benchmark to evaluate the performance of computer systems, comparing the result of multiple equipment;
• Model a high level language processor, considering timing and performance information;
• Model a multi-processed computer system in high-level language, considering interconnection mechanisms, peripherals and software to be executed.

The recommended bibliography for the activities of this discipline is:

• David A. Patterson and John L. Hennessy. Computer Organization Design, The Hardware / Software Interface. Morgan Kaufmann
• Sandro Rigo, Rodolfo Azevedo, Luiz Santos. Electronic System Level Design: An Open-Source Approach Springer, 2011
• Language SystemC. There are books in the library about SystemC.
• Language ArchC (alternate address).

This discipline consists of three projects, to be carried out during the semester. The three projects will have equal weights in the composition of the final grade.

The projects will be carried out in groups of 3 to 5 participants. The composition and size of the groups will be defined by the teacher.

Any attempted fraud during the semester will be punished to the extent of my authority, including a zero score on the discipline for everyone involved.

The appointments will take place on Wednesdays, from 18 pm to 19 pm, in room 3 of the IC. If you need assistance at another time, just arrange by email. In this case, send the email already with a suggested day and time to facilitate the service.

Remember that I will be in the classroom during all classes in the semester.

There will be 3 projects during the semester, each with 5 weeks to be completed. Projects must be carried out in groups, where all components of the group must be aware of all decisions made, being able to justify them. Projects will be evaluated through:

• Final report delivered before the last class of the project period;
• Presentation of up to 15 minutes to be made in the last class of the project period. Answers to questions will be considered in the notes;
• Source code delivered before the last class of the project period;
• Participation of each student in the group;
• Delivery of partial reports as requested by project;

P1: Performance evaluation

Objective: Develop a benchmark with at least 5 components to assess the performance of at least 5 different computers.

Design decisions: What to evaluate, how to evaluate, what guarantees this benchmark provides, what are the boundary conditions, etc.

Deliveries: This first project has a requirement to monitor the teacher more closely, to assist in the development of the methodology. Two partial reports are expected during the period and one final report.

• The first one containing the methodology to be followed, on a page, delivered in print until the end of the first class, for comments during the class period by the teacher.
• The second report, of up to 3 pages, must be delivered within two weeks after the first, with preliminary results and a more detailed description of the methodology followed.
• The final report, of up to 5 pages, must contain all the results of the project and be delivered before the last class of the project, which will have the presentation.

Rating criteria: Clarity in defining the performance evaluation criteria (What did you measure? How? Why?). Ability to reproduce the results obtained on the computers informed and also to add new computers.

Final Report and Presentation: 02/04, during the class period.

P2: High-level processor modeling

Objective: Assess the impact on the performance of an ideal processor that the architectural / microarchitectural mechanisms have. Start with a processor that executes one instruction per cycle and analyze each type of hazard what can happen and its impact on the execution of a program.

General characteristics and motivation: Given a MIPS processor simulator, similar to the processor studied in the classroom. This simulator is called behavioral because it only implements the behaviors of the instructions, without considering any timing information. How to consider timing information regarding instruction interdependencies and other implementation effects. Consider as a base target implementation a pipeline 5-stage, branch predictor, cache and, optionally, a pipeline able to execute two independent instructions at a time.

Infrastructure: It is recommended that everyone use the MIPS processor, the same seen in the classroom, using the SystemC model generated by the ArchC language (see the indicated bibliography and also a brief tutorial for MC723). SystemC is a set of classes / templates in C ++ for hardware modeling with timing support.

Design decisions: How do each of the features described in chapters 4 and 5 of the book affect the performance of a processor? How can you compute your cost? Do you need to measure time or can you compute it?

Rating criteria:Clarity in the definition of the measures / influence of the components in the execution of the programs. Measured values. Veracity of numbers.

Don't miss the opportunity to learn using version control software (git, hg or svn), debugger (try the graphical ddd version of gdb) and also a little more than C ++.

Deliveries: In this project, only two deliveries will be made:

• The first is the specification, on a page, delivered in print until the end of the first class, for comments during the class period by the teacher.
• The second is the final report, of up to 5 pages, which must contain all the results of the project and be delivered before the last class of the project, which will have the presentation. Delivery for 14/05.

P3: Modeling of multi-processed computer system

Objective: Build and evaluate a platform with multiple colors and include the necessary components to run software on this platform. Your final platform must support 8 colors and perform some collaborative activity between them to demonstrate that they are working correctly. In addition, it must also contain a peripheral to speed up the execution of your software.

General characteristics and motivation: Nowadays it is extremely rare to have an equipment with only one core. In addition to the tasks of programming the software to explore parallelism, the system designer also has the need to include the layers of software necessary to support the execution of the parallel hardware. This second part is the focus of this project.

Infrastructure: You will use ARP. (see the indicated bibliography and also a brief tutorial for MC723).

Rating criteria:Clarity in the definition of the measures / influence of the components in the execution of the programs. Measured values. Veracity of numbers.

Don't miss the opportunity to learn using version control software (git, hg or svn), debugger (try the graphical ddd version of gdb) and also a little more than C ++.

Deliveries: In this project, only two deliveries will be made:

• The first is the specification, on a page, delivered in print until the end of the first class, for comments during the class period by the teacher.
• The second is the final report, of up to 5 pages, which must contain all the results of the project and be delivered before the last class of the project, which will have the presentation. Delivery for 11/06.