Single Cycle Perfect Memory

Single-Cycle Memory Specification

For the first phase of your project, you are asked to design a processor which executes each instruction in a single cycle. For this, you will use the single-cycle memory module described here. It is called memory2c.v, and the source file and synthesizable versions were included in the project tar.

Since your single-cycle design must fetch instructions as well as read or write data in the same cycle, you will want to use two instances of this memory -- one for data, and one for instructions.

Note: You should instantiate this memory module twice. One instance will serve as the instruction memory while the other will serve as the data memory. Note that the program binary should be loaded into both instances. This will indeed be done (without any additional effort from your side) if you use the same module definition for both instances

                      +-------------+ 
data_in[15:0] >-------|             |--------> data_out[15:0] 
   addr[15:0] >-------| 65536 word  | 
       enable >-------| by 8  bit   |
           wr >-------| memory      |
          clk >-------|             |
          rst >-------|             |
   createdump >-------|             |
                      +-------------+

During each cycle, the "enable" and "wr" inputs determine what function the memory will perform:

enable	wr	Function	data_out
0	X	No operation	0
1	0	Read	M[addr]
1	1	Write data_in	0

During a read cycle, the data output will immediately reflect the contents of the address input and will change in a flow-through fashion if the address changes. For writes, the "wr", "addr", and "data_in" signals must be stable at the rising edge of the clock ("clk").

The memory is intialized from a file. The file name is "loadfile_all.img", but you may change that in the Verilog source to any file name you prefer. The file is loaded at the first rising edge of the clock during reset. The simulator will look for the file in the same location as your .v files (or the directory from which you run wsrun.pl. The file format is:

@0
12
12
12
12
where "@0" specifies a starting address of zero, and "12" represents any 2-digit hex number. Any number of lines may be specified, up to the size of the memory. The assembler will produce files in this format.

At the end of the simulation, the memory can produce a dumpfile so that you may determine what has been written to the memory. When "createdump" is asserted at the rising edge of the clock, the memory will create a file named "dumpfile" in the mentor directory. You may want to use the decode of the "halt" instruction to assert "createdump" for a single cycle.

When a dumpfile is created, it will contain locations zero through the highest address that has been modified with a write cycle (not the highest address loaded from the loadfile). The format is:

0000 1234
0001 1234
0002 1234
Examining the source file memory2c.v, several possible changes should be obvious. The names of the files may be changed. The format of the dumpfile may be changed by modifying the $fdisplay statement; the syntax is very similar to C's fprintf statement. The starting and ending addresses to dump may be modified in the "for" statement. The only thing that cannot be modified is the format of the loadfile; that is built-in.

When you have two copies of the memory, for instructions and data, you may want to let both memories load the same loadfile, but only have the data memory generate a dumpfile.

The way to load programs for your processor is to use the assembler, create the memory dump. Name the memory dump, loadfile_all.img and copy this into the directory where memory2c.v is present.