CSE 378 Homework #5: Memory Mapped Character I/O

Supplement to the main assignment.

This page focuses primarily character IO. Once you understand it, you'll should have no problem understanding disk IO from the description of the block controller component in the SMOK documentation.

What To Do

The overall goal is to implement the character and disk input and output portion of the Cebollita I/O architecture. That archtitecture employs memory mapping to expose the character controller device that lets software write to the console and read from the keyboard. Understanding how it works requires understanding two different issues: memory mapping and I/O controllers.

Getting Started

You'll want to use the SMOK container that is included in the model distributed for this assignment. It handles much of the complexity of the new functionality required.

Connect the container to your machine so that it handles loads/stores to addresses 0x40000000-0x4000003F. Also make sure that you do NOT write to memory if the address is in that range. This will require adding just a few new components to the datapath. There are no changes required to control -- the new container has an output that tells you whether or not it thinks it's handling the address.

(Character) I/O Controllers

Code that uses the character (and disk) controller is already implemented in iolib.c. You can complete this part of the assignment just by implementing memory mapped devices, without needing to know how they work - the sample code knows. Looking at that code MAY help clarify things that aren't made clear by this description.

There are two parts to I/O controllers, the I and the O. Both sides are a little different than what we're accustomed to. On the input side, there is no instruction that can cause a character to be typed - the user types one whenever s/he feels like. So, input is asynchronous with instruction execution; it happens when it happens. On the output side, output is slow, requiring many cycles to complete. Because of this, output as viewed by the software is demarcated by two events. The first is the start of an output operation. That is caused by the software telling the controller to perform an output, using a controller-specific command. The second event is output completion. This is signalled by the controller raising one of the bits of its output to indicate that it is done. While an output operation is going on, it is a software error to tell the controller to start another one (meaning the result is undefined).

To accomplish these tasks, the controller has a command set (more or less a set of instructions that it knows how to execute) that it accepts as its input. When the software wants the controller to start an output, it sends it a command to the character controller (by writing some data to it) indicating what it wants (e.g., "write a character" and the character).

The controller also has an output. The output indicates the current state of the controller, e.g., "ready to accept a new output command" and/or "a keyboard input character is available" (or neither).

Given this, it is the software's responsibility to use the controller correctly. (Note that the software using it correctly is the responsibility of the software implementer, not the ISA implementer. I'm explaining it here just to give you some context about how what you're implementing fits into the larger picture.) For output, the software must do this:

1. Wait for the controller to indicate that it is ready to accept an output command. This is done by sitting in a loop reading the controller output until it indicates that the controller is ready.
2. Send a command indicating that the software wants to output a character, and what the character is.
The character will appear on the console after some unpredictable number of cycles.

When the software wants to read a character, it must do this:

1. Sit in a loop reading the controller output, until the controller indicates that a keyboard input character is available.
2. When the value the software reads from the controller indicates that input is available, the character is included as part of what was read - "character is available" is a higher-order bit of the controller output that was read in the loop, and the character itself is in bits 0-7.
3. Because the software has read that character, it sends a command to the controller telling it to turn off the "keyboard input available" bit in its output. That way the software can tell the next time a character is typed.

The details of how this work depend on the controller. We'll be using SMOK's Character Controller Device. Its documentation tell you what the controller's command set is, and what the controllers output bits mean.

Memory Mapping

Okay, we know how the software can read and write characters, except for one thing: how does it send commands to the controller, and how does it read the controller's output?

We could create new opcodes for this: RFCC (Read From Character Controller) and WTCC (Write To Character Controller). That would work, but the downside is that we'd need a different pair of opcodes for each controller attached to our system. Besides being cumbersome, that would make it impossible to attach controllers that were designed after the processor was built (since the processor wouldn't have the needed opcodes).

Instead of using new opcodes, we note that sending commands to the controller is basically a store operation: "Take the contents of this register and send it to..." Similarly, reading the controller's output is basically a load: "Get ... and put it in this register." So, instead of special opcodes, we'll just use sw and lw.

How can that work? How does the machine know we want to talk with the character controller, rather than memory, on a sw or lw? The answer is that we use a special address to indicate that we really mean the controller, not memory. In particular, Cebollita uses the address 0x40000000. A sw to that address should take the register contents and store it to the character controller (and not anywhere in memory), and a lw from that address puts the character controller's output into a register.

To get this to work is relatively simple: you just need to add enough control to notice that the instruction is a lw or sw and that the address is 0x40000000. Under those conditions, you route the data to/from the character controller, and (even if it's a sw) you do NOT cause the memory interface to do a write to ram.

(Note: The Cebollita ISA defines the meaning of loading or storing to just some of the addresses in the range 0x400000000-0x40000003F. Loads or stores to other addresses have undefined result.)

Building Test Applications

To test the character device, you can use the program chartest.c. It calls printString() and readString() to read/write from/to the terminal. Compile and assemble it as always. After that, you'll need to link it with iolib.o and prologue-noos.o. Make sure to put the prologue first in the command that links, otherwise the initial value of the PC in your SMOK model (which is almost certainly 0) will not be pointing at the first instruction that should be executed.

To test the disk controller, you can use blocktest.c. It needs to be linked with iolib.o as well. Additionally, to run it you need to connect a "virtual disk" to the block controller in the memory map container (right-click / Properties). That's simply a file that the block controller will read/write. Note that the file will be altered by writes, so don't use anything valuable. (I copy the file blocktest_diskfile_master.smokdisk to blocktest_diskfile.smokdisk, and connect the latter to the block controller, but you can use any file you want (that is at least something like 3KB in size).)

Running Applications

You're going to want to run Cebollita in sync mode with SMOK for this assignment, so you should get that working now. When you do, type input into the SMOK window, not the Cebollita one.

cebsim --sync ceb-final.smok mytestprogram.exe

Should you want to run Cebollita alone on the apps you build for some reason, it requires a little extra work. Because SMOK apps assume the hardware is doing IO, with no interference by the OS, while Cebollita runs on top of an actual OS, there is a bit of a mismatch. The shell script cebrun.sh can be used to invoke Cebollita, taking the required steps to get the OS out of the way:

$ ./cebrun.sh a.exe

If you're using CYGWIN, for that to work you must have environment variable CYGWIN set to "tty" before the Cygwin shell is launched. Did I mention BEFORE. You can't do it in your .bash_profile, for instance, you have to do it the raw Windows way.