Computer Systems DV1, Fall 2007, Project Assignment

Final Project Presentation Schedule

Thursday, December 20, Room 1345

10.00 - Team 3
11.00 - Team 2
13.30 - Team 1

Staff

Printed Hand-ins

To John Håkansson's mailbox (4th floor, box 136).

Lab Assistant Hours

By appointment
Or just drop in and ask (room 1237)

Groups

The project is performed in groups of six.
All groups will appoint a group leader who acts as the face of the group outwards, and who is responsible for making sure that all group members participate in the work.

Group Membership (as of 31 October, 11.30 CET)

Team 1

Nils Jonsson Forsblad
Daniel Josefsson
Göran Nehlin
Dan Petrescu
Daniel Rong
Jari Stenman (team leader)

Team 2

Fabian Alenius
Emil Holmström
Nicklas Nordenmark (team leader)
Christian Rennerskog
Peter Renström
Kristoffer Wallin

Team 3

Axel Andrén
Mattias Ohlsson
David Piuva
Jonas Rosling (team leader)
Johan Rydén
Peng Sun

Progress Report Meetings

Each group will present their design sketch and receive guidance and feedback on progress to date from the teaching staff.
This meeting will take approximately 30 minutes. During the first 15 minutes the group presents progress towards implementation of the specification based on the goals set by the group for themselves at the first meeting. A minimum goal is to produce an implementation of the minimum requirements for a pass in the course.

Approximately every two weeks after this first meeting there will be scheduled progress report meetings for each project group with the teaching staff. These meetings provide an opportunity to follow up problems with realising the goals the group has set up and to make work plans for the following two week period in collaboration with the staff guiding the project.

Grading

The grades for the project are pass or fail (G or U). However, groups that do a very good project can raise their grades on the exam from a pass (G) to a pass with distinction (VG), provided they score close to VG on the exam (typically 80+ out of 100 points). Doing a very good project is defined as completing one or more extra credit requirements, as found in the specification of the project.

All projects are to be handed in at a specific date, before Christmas. If the project does not fulfil the basic requirements at this point, you will need to give a good structured explanation for why your project failed to produce the required output to pass the project. There will be no extensions given.

Time Plan

The project starts after the exam of part I of the course, and runs up until Christmas. In detail, this means:

30/10 -- official starting date of the project
06/11 -- hand-in project description (your interpretation of the requirements)
12/11 -- architecture sketch due, Goal setting meetings with all groups.
23/11 -- system design due
29/11 -- 30 minute Progress Meetings for all groups (1406 booked 13-15)
10/12 -- 30 minute Progress Meetings for all groups (1345 booked 13-15)
20/12 -- demonstration and final hand-in held at (1345 booked 10-15).

Important

Before writing specifications, you need to understand the architecture and tools used in the project:

Do the Simics introduction lab.
Understand the example files. To make sure you understand, try for example to combine the three examples into one, i.e. with a single exception handler that can handle timer interrupts, serial communication (UART) and system calls.

It is a good idea to familiarize yourself with the tools you will be using early on in the project. For example, make sure to setup cvs and do the Simics introduction lab.

On the hand-in day (Thursday, 20 December), there will be a final handin session (in room 1345). Each group is given approximately 45 minutes to demonstrate their OS implementation. The sessions are scheduled as follows:

10.00 - Team 3
11.00 - Team 2
13.30 - Team 1

Tools

In the project, you will use a range of programming and project management tools, some of which will be new to you.

To compile your C code, you will use a gcc MIPS cross-compiler.
The main execution environment for your operating system kernel will be simulated MIPS computer based on a MIPS 4Kc processor and featuring some simple I/O capabilties. The computer will be simulated using Virtutech Simics, a very sophisticated simulator.
You will be using '''CVS''', the concurrent versioning system, to track your source files and changes to these files. Documentation for CVS can be found at www.cvshome.org, as well as on the project CVS page.
To debug your code, you use a gdb MIPS cross-debugger, with Simics as the remote target.
There is a set of example files to help you.
The context of a process is described by its stack and register area. Here is a tip on how you can initialize a register area for a new process:

    registers.epc_reg = (uint32_t) program; /* Code pointer */
    registers.sp_reg = (uint32_t) stack + STACK_SIZE - 32; /* Stack pointer */
    registers.gp_reg = 0x80000000; /* Offset for global data */
    registers.ra_reg = (uint32_t) kinit_reg_ra; /* return adress */

The return adress is initialised to point to a function 'kinit_reg_ra':

    static void kinit_reg_ra()
    {
     // We get here if a program returns.
     while(1);
    }

Datorsystem DV1