CMSC356: Concurrency and Co-Design in Operating Systems
Lab 4: Hardware and Software for Interrupt-based I/O
In this lab, you will once again investigate low-level hardware and software support for input and
output for the HERA processor, this time with interrupt-based I/O. Re-form your small teams of
2-3 people from Lab 2, and collaborate with the other group (i.e., everyone writing software
should be using a different processor from Lab 2, and everyone building a processor should be
supporting at different software team). Once again, your collaborative goal is to produce a
working hardware/software combination. Unless you have approval in advance to do otherwise,
organize your coordination around the following sequence of steps:
1. Have a meeting of Hardware and Software teams to create a shared document in which
you clearly describe a set of “unit tests” for each component, and a set of “integration
tests” to test the combined system. Giving detail here will probably help you to coordinate
your thoughts about later steps. You may either write this document directly in the provided “TestSuiteDescriptions.txt” file, or set up a GoogleDocs document to allow real-time
shared editing. If you do the latter, record the URL in the file in Eclipse, give your
instructor access to the document, and copy the contents into the file for your final submitted work.
2. Have a meeting of both teams (possibly the same meeting as for Question 1) in which you
discuss preliminary design choices that will impact both teams, such as how you choose
the “interrupt vector” that directs the system to the interrupt service routine. Record
these in the file WhatAndWhy–DesignDecisions.txt (using the same rules as Question 1).
3. Develop the hardware and software, with all members of each team being present for each
step, and with whatever degree of in-person coordination you like between the hardware
and software teams. As in Lab 2, use Eclipse’s Team→Commit and Team→Update frequently, to keep backup copies and exchange work.
4. Have periodic meetings of both teams to assess progress and discuss new questions and
thoughts about tests or design decisions. Record new decisions in the files mentioned
above.
5. Have a final meeting before submitting the final result, in which you confirm that each
team member can demonstrate the system. As in Lab 2, you will all share credit for the
overall functioning of the system, and each team will recieve credit for the functionality
and clarity of their component, and for having every member of the team understand their
component.
The hardware and software projects are:
HARDWARE. Modify a HERA microprocessor so that it can handle interrupt signals, and
connect a terminal so that it generates interrupt signals when it is ready to receive or send
the next character. Note that, for the purposes of I/O, having interrupts happen only at
the start of a clock cycle is fine, so you can use a flip-flop or latch to make sure you don’t
get interrupted right in the middle of an operation (this is not o.k. for interrupts for virtual memory, but we will not be doing this in the lab).
1
Before you start work, coordinate with the software group to set standards as necessary.
Check out a fresh project for Lab 4; and either start with a HERA processor that includes
the modification from Lab 2 or with a fresh pre-CMSC356 HERA processor. As you work,
you should keep separate “release” and “development” versions of your processor, so that
you can explore changes in the “development” version and do Team→Commit to exchange
work with your hardware teammates without causing chaos for the software team; then,
when the development version functions better than the “release” version, copy the development version over the release.
SOFTWARE. Write interrupt routines to handle interrupts for input and output. When the
terminal is ready to send a character to the processor, the interrupt routine should load
that character and save it in a buffer; when the terminal is ready to receive a character,
the processor should send it one if one is ready in the output buffer, or simply record the
fact that the terminal is ready. Update your functions to print and read tiger strings so
that they simply access the buffers; print should now just add characters to the buffer
and start transferring if the terminal is waiting; getchar and getline should transfer one
character (or line) from the buffer if one is there, or (for now) busy-wait until enough data
arrives.
Before you start work, coordinate with the hardware group to set standards as necessary.
Check out a fresh project for Lab 4; you may copy Lab 2 software into it as needed. However, since the organization of this lab is quite different, I strongly recommend you only
copy small elements as you need them, rather than beginning with a full copy of Lab 2
software and then trying to change the structure.
Remember to account for the possibility that an interrupt could occur while the interrupt processing code is running, or during a print or read function.
2