LC4 Project Assignment

This is a team project to be done in pairs. The last day I will accept work is the last day of finals. However, be warned that you must schedule a team interview with me to review the project. Interviews are scheduled on a first-come/first-served basis. Do not wait too long to request an interview time slot, there might not be any slots left by then.

You have a copy of the LC4 design, LC4-v1-base.jelib, in your branch's lib/. Your task is to get the design to be fully functional. That amounts to getting every LC4 instruction to execute correctly. The LC4 instruction set is documented in the comments in 0_LC4_Top{sch}. The LC4 hardware is fully implemented, except the controller. The controller "Decode" is implemented as a ROM. Each output bit is a control signal that effects some part of the datapath. All the ROM's bits are currently set to 0 (except for one that serves as an example).

For an instruction to operate correctly, some control bits must be set to 1. For example, the ALU instruction (opcode = 0000) writes a result value into a register. For that register-write to occur, the RegFile's write-enable input ("Rwe") must be 1. That signal is connected to Decode's output ("Rwe"). So, the Rwe bit for the ROM word at address 0000 must be connected to logic_1, which always outputs a 1: Whenever the current instruction's opcode is 0000, the RegFile will be written.

The Decode's ROM has 16 words, one for each possible 4-bit opcode. The opcode of the current instruction selects which ROM word's bits appear on Decode's outputs. Most opcodes do not specify an instruction. The LC4 has six instructions; so, you will only be interested in those six ROM words. (Actually, there are seven instructions: we implemented the SYS instruction as a HW assignment. The remaining nine opcodes can be considered to be illegal opcodes, in spite of the fact that we have not implemented any means of detecting an illegal opcode.)

Our LC4 implementation has the same simulation interface you have been using to execute LC4 programs (as in "vvp lc4.vvp"). The design's top-level cell is 0_LC4_Top{sch}. To run the LC4 after you have made alterations, you would open that cell, and then do the following:

1. ^Electric.Tools.Simulation(Verilog).WriteVerilogDeck
2. iverilog 0_LC4_Top.v
3. vvp a.out

Recall that our LC4 simulator reads the file "prog.bin" into memory. To test an instruction, you would put the instruction into that file. "prog.bin" is a binary coded file of ASCII 0s and 1s, 16 per line. Each line will be loaded into an LC4 memory word as 16 bits (not ASCII). Loading starts at the address specified in the file's header. Here is an example prog.bin:

@0200
0000111000111000

The LC4 simulation reads plain text files in binary notation, except the header has the symbol "@" and a value expressed in hex. The instruction shown is this,

ALU SR7 SR0 DR7 ADD

and is loaded into memory at address h0200.

Notes:

When you want to change a bit value to 1 in Decode's ROM,

    Disconnect the logic_0 device from the mux's input for 
    the particular opcode. You may have to select and delete a 
    short piece of wire connected to a mux input pin.

    Copy/past the logic_1 device, placing it at the input for 
    the mux. Select its output crosshair and connect it to the mux's input.


The 0v and 1v sources are really verilog 0 and 1 sources, but I wanted to remind 
you that these are actually voltage connections in physical ROMs.


WHAT TO TURN IN

Write up a team report (very short) explaning what you did, and how it worked out.
Make sure all your work is checked into your branch: I will review it at the
interview.
Schedule a  team appointment to explain your work to me. I will ask you questions to
see how well you understand the LC4, its instruction set (formats and semantics), and our 
implementation of the LC4.