Memory1c description: content adopted and modified from: http://pages.cs.wisc.edu/~karu/courses/cs552/spring2009/wiki/index.php/Main/SingleCyclePerfectMemory ###### Single-Cycle Memory Specification ############################################################### For the first stage 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. 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. +-------------+ data_in[15:0] >-------| |--------> data_out[15:0] addr[15:0] >-------| 16 bit | enable >-------| memory | wr >-------| with | clk >-------| variable | rst >-------| address | createdump >-------| width | | | +-------------+ 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] M[addr] 1 1 Write data_in 0 The width of the address bus is changeable. You may change it to whatever size you need. The data width is fixed to 16 bits. 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"). ######### How to initialize your memory ################################################################## 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 1234 1234 1234 1234 where "@0" specifies a starting address of zero, and "1234" represents any 4-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. ######### How to use the build-in dumpfile generator (maybe not applicable in Quartus) ################### First, you need to uncomment the "createdump" inputs and its assignment. This may cause the memory module no longer synthesizable. 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 ######### Possible changes for the module ############################################################### Examining the source file memory1c.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 memory1c.v is present.