SRG: NetOS:
Student Projects 2000

Hardware Related
UoCCL


 Microprocessor Performance Analysis Hardware  2000  Student Projects  NetOS 

Contact: Ian Pratt  email

Nemesis, along with other real-time operating systems, is designed to enable fine-grained quality of service guarantees to be made to applications. This means that the processor must context switch between different applications at a much higher frequency than on conventional operating systems.

Modern processors are not designed to do this- they are pretty fast but they can't turn corners. They contain internal state that records past behaviour of a program in order to optimize current execution (instruction, data, branch prediction, and jump target caches etc.) Unfortunately, context switches typically cause all the accumulated state to be discarded.

The aim of this project is to measure how context switch frequency affects the performance of modern processors like the Alpha 21164 and Pentium Pro. This can be done by devising suitable experiments in which multiple applications (such as those in the SPEC benchmark suite) are run in parallel on a single processor. The end result could be a new set of Operating System and processor benchmarks which give an indication of how well the CPU can be multiplexed between a number of concurrent tasks.

This project is research. It requires some good experimental computer science, but needn't be particularly difficult for someone with reasonable knowledge of C and the operation of microprocessors.


 Simple Super-Scalar CPU Design Hardware  2000  Student Projects  NetOS 

Contact: Ian Pratt  email

Modern CPUs such as the Pentium II, R10000 and Alpha 21264 use a technique called `dynamic execution' to enable them to execute instructions out-of-order relative to the order they appear in the program. Instructions are executed when all of their input operands become ready. This technique enables such processors to seek out Instruction Level Parallelism in the code, and hence execute multiple instructions in a single clock cycle.

The aim of this project is to write a Verilog implementation of a dynamic execution CPU that executes a simple instruction set. The Verilog simulator can be used to `execute' short programs on the CPU, enabling correct behaviour to be verified, and number of execution cycles to be counted. The design should be modular, to enable different numbers of functional units to be experimented with, along with different dynamic-scheduling algorithms.

A further aim of the project will be to use a synthesis tool to generate a structural net-list for the design. This can then be examined to understand the number of transistors required by different parts of the design, and to assess what the critical paths that would limit the clock rate are.

This could be a really good project. There are endless extensions, features and experiments that could be conducted with the virtual CPU that would allow for a very interesting dissertation.


 8-bit CPUs in Verilog Hardware  2000  Student Projects  NetOS 

Contact: James Bulpin  email

Field programmable gate arrays (FPGAs) have become quite fast and now contain a substantial number of gates and flip flops. It is now possible to implement an 8-bit CPU, such as a 6502 or Z80, in an FPGA.

The first stage of the project would be to write a behavioural Verilog model of a chosen 8-bit processor. This can be tested by simulation of simple programs. The design can then be synthesised and programmed into an FPGA. The next phase would be to ensure that the processor can run at least as fast as a conventional version.

Following this, spare gates on the FPGA can be utilised to provide further features found on home computers using the chosen CPU. For example, a UART or keyboard interface could be designed to allow the device to communicate with the outside world. The end goal would be to have an implementation of a home computer such as a BBC Micro, Spectrum or C64 on a Teaching Board.

Special Resources: Use of a Xilinx/Altera Teaching Board. Access to the appropriate tools to use the board.


 Hand-held Commodore 64 Hardware  2000  Student Projects  NetOS 

Contact: James Bulpin  email

This project is to interface a C64 emulator running on an ix86 based credit-card sized PC to an LCD panel and suitable input device(s).

The project would involve building an interface between the PC and an LCD panel, probably using the PC's IDE interface. It would require modifying and existing emulator to use this new hardware. The aim would be to have a prototype device looking similar to a Game Boy.

Special Resources: Use of a single board computer. Probably the use of a teaching board (and software tools) to develop hardware. An LCD panel and other required hardware. A suitable C64 emulator.


 Remote PC Console Hardware  2000  Student Projects  NetOS 

Contact: James Bulpin  email

When administrating PCs remotely, there are times when standard remote communication methods such as telnet are not available. This will be the case when a machine is in the BIOS start-up sequence, before starting any network services or when the machine does not have sensible remote access facilities (e.g. a Windows machine).

What is required is a way of sending output intended for the local display over a serial or network connection and receiving keyboard events coming over the connection and feeding them into the PC's keyboard port.

A simple approach would be to create a device that pretends to be a graphics card (or alternatively snoops the bus) and writes text characters intended for the display over its own serial connection. It would have circuitry to fake out a keyboard and create keyboard events for incoming serial data.

Since systems like Windows NT make use of graphics while booting, it may be more beneficial to be able to send graphical data over the external connection as well as text. This could be done by running a protocol like VNC over a network connection straight onto the board.

Special Resources: Use of a Xilinx/Altera Teaching Board. Access to the appropriate tools to use the board. Access to a PC on which to test the hardware.


 Phone controlled PC Reset Hardware  2000  Student Projects  NetOS 

Contact: James Bulpin  email

When computers are located in inconvenient places such as machine rooms far away from their administrators, a crash is very inconvenient. Watchdog timers exist to automatically reset a PC if it has not sent a ``keep alive'' signal to the watchdog for a while. However, these devices are not always suitable and there are situations where they are unable to detect a crash or reset the machine at the desired time.

A useful addition/replacement would be a device that can be contacted when the PC has crashed, and instructed to reset or power-cycle the PC. This could be done in a number of ways. A device could connect to a serial line or directly to the network. The availability of both these methods of connection may be limited and if it happens to be a network switch you want to reset you may need to isolate the device from the network in question.

This project is to prototype a device to connect to a phone line (probably an internal extension) and answer calls. It would then have some way of deciding whether to reset a machine based on what it heard on the line. This could be a series of tones. It would make sense to have one device able to reset more than one machine. Care would have to be taken to ensure a wrong number or a malicious call does not reset a machine.

Special Resources: Use of a Xilinx/Altera Teaching Board. Access to the appropriate tools to use the board. Some hardware to interface to a phone-line. Use of a University Network phone-line when testing.


  Hardware  2000  Student Projects  NetOS 
Valid HTML 4.0!
 Richard.Mortier@cl.cam.ac.uk
$Id: hardware.html,v 1.5 2000/08/01 14:52:35 rmm1002 Exp $