Disk Controller -- Emulation Software

Documentation for the Instructor

University of California, Irvine
School of Information and Computer Science

Student Use

Students only need to be given the following two files:

controller.o: This is the object file that students need to link with their application program
interface.h: This is a header file that the student program must include (#include "interface.h")

For example, under Unix the call "gcc -g controller.o student.c" produces the executable file a.out, which runs the student program; this program then may invoke any of the functions provided by the disk controller. (Note: the header file and the controller module can also be used with applications written in C++).

Instructor Use

The emulation software consists of the following three files:

controller.c: This contains the source code for all functions. It is compiled into an object module (e.g. controller.o), which uses the following two header files
interface.h: This defines the interface to the controller (functions, parameter constants, error constants)
internal.h: This defines various internal functions and constants of the emulator.

Both header functions are included by the controller.c program and must be available when compiling controller.c into the corresponding object module controller.o.

Modifying the Emulator

There are two features of the emulator that may be modified before producing the object module for students: (1) the probabilities of transient errors; (2) the emulated busy-wait times.

Modifying Transient Error Probabilities

Each of the three disk operations, SEEK, READ, and WRITE, may experience a transient error. These are generated probabilistically using error rates specified by the following three constants (in internal.h):

#define SEEK_ERROR      30
#define READ_ERROR      30
#define WRITE_ERROR     30

Each constant may range from 0 to 100, where 0 means that no transient errors will occur and 100 means that every SEEK/READ/WRITE operation always produces a transient error. With the above code fragment, 30% of all operations, on average, would result in a transient error.

Modifying Busy-wait Times

Whenever a new opcode is written into the OP register and the controller is not busy, it becomes busy for a certain period of time. The emulator does not cause an actual time delay. Instead, it mimics the behavior by requiring that the BUSY register must be polled (read using the read_reg() function) a certain number of times. The number of polls required for a given operation is generated probabilistically and can be controlled by setting the following constants (in internal.h):

#define SEEK_POLL       100 /* minimum value */
#define READ_POLL       100 /* minimum value */
#define WRITE_POLL      100 /* minimum value */
#define REPORT_POLL     10 /* minimum value */
#define ILL_OP_POLL     10 /* minimum value */
#define POLL_VARY       50 /* percentage polling varies */

The first three constants give the minimum number of polls for each type of operation. The actual number of polls is calculated by adding a random number to the minimum value. The random number of generated using POLL_VARY, which gives a range of variability between 0% and 100% of the minimum value. For the above code fragment, POLL_VARY is 50% of the minimum value. So, for the SEEK, READ, or WRITE operation, the number of times the BUSY register must be polled will be a random number from 100 to 150.

Acknowledgments

The emulator software was developed by Simon Evens as an undergraduate project and was later modified by Lubomir Bic. For questions or comments contact: bic@ics.uci.edu