Generating MIF files Introduction In order to load our handwritten (or compiler generated) MIPS assembly problems into our instruction ROM, we need a way to assemble them into machine language and then save these machine language programs in a text file where the binary machine instructions are represented as a sequence of ASCII hexadecimal values. For this, we will use a Java-based MIPS simulator called MARS. MARS is an improved version of the SPIM simulator that you may have used in CSCE 212. We have installed MARS in a shared directory, but in order to avoid the need to specify its entire path, you can specify a UNIX alias to make it more convenient to run MARS. Open a terminal and type gedit .profile. In the text editor, add the following line to the end of file: alias mars='java -jar /usr/local/3rdparty/csce611/MARS/Mars.jar' Save the file and close the editor. You will only need to do this once. Now log out and log back into your workstation. Now we can invoke the tool by typing mars in the terminal. You can also download MARS from www.cs.missouristate.edu/MARS or get a copy at your home directory. For the usage of the simulator, please check the MARS tutorial at http://courses.missouristate.edu/KenVollmar/MARS/tutorial.htm MIF Files A memory Initialization File (.mif) is an ASCII text file (with the extension .mif) that specifies the initial content of a memory block (CAM, RAM, or ROM), that is, the initial values for each address. This file is used during Quartus project compilation and/or simulation. The MIF file serves as an input file for memory initialization in the Quartus compiler and simulator. You can also use a Hexadecimal Intel-Format File (.hex) to provide memory initialization data. In this class, we provide you with a script file to automate generate MIF file from MIPS assembly codes. In this tutorial, we will introduce you to MIF file generation in the following example. 1. Open a terminal and copy the file GenMIF.sh from the directory /usr/local/3rdparty/ csce611/CPU_support_files/ to your design directory. 2. For our first program, copy the following file into your home directory:cp /usr/local/3rdparty/csce611/benchmarks/my_program.asm 3. In order to show you what the program looks like, open this file in a text editor: gedit my_program.asm As you will see, this program is composed of a data section and a text (code) section. Our script will generate MIF files for both sections, which correspond to the data memory and the instruction memory, respectively. Also notice that this particular program is quite simple and is composed entirely of load instruction and a branch at the end which is clearly being used to halt the program by deliberately entering into an infinite loop. The reason for this is because in the following tutorial, we will implement the load instructions and the branch instruction used in this program. It will be up to you to implement the other instructions listed in the MIPS instruction set detail on the course webpage. 4. Generate the MIF files using the following command: ./GenMIF.sh my_program You should see the following messages: Reading file my_program.asm Generating ROM1.mif Generating RAM1.mif Generating RAM2.mif Generating RAM3.mif Generating RAM4.mif Memory MIF file generation successful. and you should have the following .mif files in the my_program subdirectory: ROM1.mif, RAM1.mif, RAM2.mif, RAM3.mif and RAM4.mif At this point, the generics in your ROM and RAM instances should point to the ROM and RAM MIF files that you just generated. Congratulations, you have just loaded a program into your computer! Now it’s time to begin to work on your CPU design so you can implement the instructions used in this program.Implementing the MIPS Instruction Set In this tutorial we’ll be adding functionality to the CPU design. Instancing Primary Components to Your Top-Level CPU Design In order to implement the load and branch instructions, we’ll need a few basic components. These will include: - an ALU - a register file - a program counter (PC) - a PC incrementer adder - a PC branch target adder Instantiate the ALU that you have previously designed, as well as the RegFile32x32, reg10, and two add10s from the CSELib. Program Counter Logic Some of these components have fairly obvious connections. For example, we know that the PC keeps track of the address of next instruction to be fetched, so we need to connect it to the instruction address output. However, since we also need to use the output of the PC to increment the PC, we cannot directly tie the output of the PC register to the output pin, because this would involve “reading an output” which VHDL forbids. Therefore we will need tocreate a signal called “PC” for this, which we can rename to InstructionAddr using an embedded block. Also, we know that the PC’s input can come from either the PC incrementer adder or the branch target adder. So let’s add an embedded multiplexer (as you did for the logical unit in the ALU) to the input of the PC, and connect the PC incrementer adder (which computes PC+1) and the branch target adder. Also, you need to connect the PC to the global clock and reset signals. You may want to do this through “signal stubs” with implicit connections. Finally, we will use the same embedded block that we used to rename the PC signal for setting some constants, which we’ll need for ALU carryin inputs (CI), the PC enable, and the input for the PC incrementer. Register File and ALU Next let’s deal with the register file. We know that the ReadAddrA and ReadAddrB inputs come directly from the rs and rt fields of the instruction, so we can connect those signals using bus rippers. Recall that we’re only implementing the BEQ instruction and the load instructions at this time. Of these, only the load instructions write to the register file. As a result, we know the WriteData input to the register file comes from the data memory input. However, since we’llneed to design a data alignment unit for the LH and LB instructions, we’ll just add a signal stub for now, named “DataInAlignedExt”. The WriteAddr input to the