CSE 378 Project 2

Winter 2001

Due: Friday 3/2/01

Purpose

To implement a simple RISC machine (the SLOOP Machine) using SMOK.

Introduction

The year is 2010 and playing retro video games is all the rage. However, after years of training on modern, high-speed gaming systems, today's gamers find the retro games painfully slow. A game company has contracted you to architect an updated version of the venerable 6502 processor. The 6502 processor (actually the 6507, a variant of the 6502) was used in a variety of home video game/computer systems during the early 80s. Most famously, it was the core of the wildly popular Atari 2600 VCS (Video Computer System).

The Plan

You realize immediately that you have more to offer than simply boosting the clock speed of an aging design. Inspired by the success of companies such as Intel and AMD at developing efficient implementations of aging ISAs (the 80x86), you decide to take a similar strategy. Your plan is to translate the incoming stream of 6502 instructions into a more regular, easier to pipeline instruction set. Realizing you need a secret, off-site location to develop your plan, you retire to the Sloop Tavern, in Ballard. Below is a brief week-by-week progress report:

Week 1: No progress - ate too many fish and chips.
Week 2: No progress - drank too many Sloopers.
Week 3: A breakthrough. The machine has a name: The SLOOP.
Week 4: No progress - intimidated by the bearded, weather-beaten fisherman at the tavern.
Week 5: After a week of staring at the 6502 ISA, you've developed a reasonably regular instruction set for the SLOOP.
Week 6: You write the instruction translator and a C++ simulation of the SLOOP machine. You can play Donkey Kong! Now it's time to work on the organization the SLOOP machine.
Week 7: A particularly difficult and long session erases most details of this meeting, but you do find a sketch of the (single-cycle) SLOOP datapath in your bag the next day.

So that's where you stand today. You have a spec for the SLOOP ISA. You have a translator which can translate incoming 6502 instructions into short sequences of SLOOP instructions. Now it's time to mock up the machine organization using your favorite design tool: SMOK.

Important Links

The purpose of this document is primarily to provide an overview, while many details you may or may not need/want to know can be discovered at the pointers provided below.

Atari 2600 VCS Overview

The Atari 2600 contained a number of components:

A 6502 Processor (actually a 6507, but they're close enough). The 6502 was originally launched by MOS Technology around 1975. It was cheap and widely deployed. It found a home in systems developed by Commodore, Apple, and Atari. The 6502 is an extremely simple accumulator-based architecture with a relatively rich set of addressing modes.
A TIA (Television Interface Adaptor). The TIA's job was to interface between the console system and the television. It was also responsible for performing some game-specific tasks such as collision detection.
A cartrige. Games were deployed as ROM cartridges. They contained between 4Kb and 8Kb of instructions.
I/O. Input came primarily from joysticks. Output was via the television screen and speakers.

What We Provide

We'll provide you with a simulation of everything but the 6502. We're providing a simulation of the TIA, the joystick (through the keyboard: try the ESC key to quit; arrow keys to move; and the space-bar to "shoot"), and the television screen (a window). Sound has unfortunately been disabled. We're also providing some new/modified SMOK components that do the following:

SloopMemory: This unit represents the memory of the Atari VCS system. It allows you to load a ROM game into memory.
SloopFetch: This unit fetches a 6502 instruction and translates it into one or more SLOOP instructions. It keeps those instructions in a buffer and provides them on subsequent fetches.
SloopRegFile: This unit represents the SLOOP register file. It is mostly the same as a traditional register file, although its internal workings differ slightly in uninteresting ways.
SloopALU: This unit is the SLOOP ALU. Again, it is pretty similar to a traditional ALU.
SloopDataMemoryInterface: This unit allows you to load and store to the Atari VCS memory.

At presstime (4AM, 2/21/01), these components are not quite ready for primetime, but will be shortly. There is enough mental preparation required to keep you busy until then.

Warts and Wrinkles

There are a variety of issues that make the SLOOP machine different from traditional RISC machines.

The PC. The program counter does not automatically update on every cycle. Rather the mechanics of determining the next PC are left up to the SloopFetch unit. What this means to you is that you won't be adding 4 (or some other number) to the PC. Rather you'll be latching in a new value provided to you by the Fetch unit (or a branch or jump...). To further complicate things, the PC in the SLOOP machine needs to be loadable/storable from/to memory. This is because the 6502 has instructions that automatically wrote the PC to memory (during subroutine calls).
The Status Register. The 6502 had a status register. Many instructions side-effected this register. For instance, if the result of an ADD was zero, a bit in the status register would be set to reflect this fact. Status registers are usually not found in RISC machines because they complicate the implementation tremoundously, due to the side-effects that occur upon it, and due to increased logic required for forwarding. In the extreme case, the Status Register itself needs to be forwarded between stages of the pipeline! We have attempted to make handling of the status register as simple as possible for you. To do this, we've added inputs for the status register to various components (particularly the ALU and the DataMem) that might modify it.

You'll note that the sketch of the SLOOP single-cycle datapath addresses many of these issues.

What You Need to Do

We're going to ask you to first implement a single-cycle version of the SLOOP machine. Given the sketch of the datapath, you should probably follow a course something like:

Skim the 6502 Intro to get a feel for the 6502 ISA. You don't need to understand this in incredible detail, but it will help.
Read and get a good understanding of the SLOOP ISA Spec.
Read the 6502 to SLOOP Translation Spec. Again, you don't need to understand this in gory detail, but it will give you a feeling for what the Fetch unit is doing.
Study the Datapath sketch. Convince yourself that to a first approximation, it can implement the SLOOP instruction set.
Start thinking about control. In particular, you'll have to build an ALU control unit and a regular control unit. Doing this is the crux of this assignment. The SLOOP ISA is simple enough that you ought to be able to (after identifying the control signals from the sketch) write a table that maps Opcodes/Instructions to control signals. Once you have control worked out (on paper) translating it into a SMOK component should be easy.

Running and Testing

In order to assist you in debugging, we've provided some infrastructure. At the time of writing, it's not all available through SMOK, but will be soon. We do run a "shadow" simulation under the covers so that we can verify that your simulation is doing the right thing. We will stop your simulation when it appears to be behaving incorrectly.

In order to test your design, you'll need some test programs. More on this later.

Error Checking

This assignment is hard enough. Don't worry about unknown opcodes and other weird things that might happen.

Evaluating Your Design

Again, the person(s) who minimize cost and/or cycle time will win a special prize.

Turn-In

Please turn in the following (more detail later):

Printouts of your machine. We'd like a printout of the global view of your machine, as well as detailed printouts for your subcomponents (such as ALUControl and Control).
The .sloop file for your machine, electronically.
Two questions about the course.

This is Too Easy

Well, you can probably guess that we'll ask you to pipeline this sucker before long, so may as well get working on that...

dugan@cs.washington.edu