LAB 7: G-CPU: Assembly Programming and Hand Assembly

Transcription

1 Page 1/5 OBJECTIVE The objectives of this lab are to understand the structure of a functioning simple computer (the G-CPU), to learn how to write assembly code, and to understand the correspondence of the assembly language with the timing simulation. MATERIALS G-CPU documentation (on the web site) Assembly_List.xlsx (on the website) INTRODUCTION With the knowledge gained in earlier labs, you now have a detailed understanding of the internal structure of a simple Central Processing Unit (CPU). Instead of continuing with your previous existing hardware designs, you are now given a more complete CPU, which is denoted as the General CPU (or G-CPU). In Part A of this lab you will dissect and simulate the assembly code that is given with the G-CPU. In Part B, you will write a G-CPU assembly code program. You will then simulate this new code in Quartus in order to observe the G-CPU bus and register changes during program execution. MATERIALS The website has several files that describe the G-CPU. These files are available in both zipped and un-zipped formats. You may want to print out each of the documents in the zip file found under the heading Zipped G-CPU Documentation and Simulation files or these same files in the folder called Documentation and Simulation files. Printable Quartus bdf and mif can be downloaded and printed from the website under the heading Documentation and Simulation files. Printing is NOT necessary. I distributed these printouts in class. SPECIFICATIONS 1. Since the G-CPU is too large to fit into our CPLD device, we will need to do a functional compilation/simulation for the G-CPU. Change the device to a Cyclone V, use the last device in the Cyclone V list of devices, and use a functional qlation/simulation. If you have not already added the Cyclone V to your installation of Quartus, see the ROM Creation Tutorial for Quartus Prime Lite Edition 17.1 to learn how to do so. 2. Download GCPU archive file: gcpu-u18.qar. 3. Double click on the file gcpu-u18.qar (or Open Quartus and select Project Restore Archived Project ). a. Specify a Destination folder:. I suggest c:/3701/gcpu. b. In Quartus, open the file computer.vwf. This will open the MultiSim Simulator Waveform Editor. Select Simulation, then Simulation Settings, then the Restore Defaults button on the bottom of this screen, and then select Save. This will fix the path information for the destination you used for the GCPU files. 4. The project has many folders, all under the destination folder you selected above. The main (top level) file, computer.bdf, is in this folder. The mif files and the simulation (.vwf) files are also in this folder. MIF FILE CREATION INFORMATION Note: When opening a MIF file in Quartus, be sure to select Open as: Text (not Auto). If you use auto, all the comments described below will disappear! When you write new code, you will hand assemble your code and put it into the eprom.mif file. As observed in Part I., this file already has a sample program, which you can use as a template. Key points related to this file are: 1. The comments are surrounded by % signs. The left most number (or numbers) represents the address (or range of addresses) followed by the hex value to the right. For example: 37 :7C % Address=$37, Data=$7C% [37..42] :A3 % Address=$37-$42, Data=$A3% 2. The last line of code in the eprom.mif, file (after your program) should insert zeroes for all the remaining data in the ROM. This is accomplished as shown below: [XX..FFF] :00 %zero remaining memory% where XX represents the next address after the last address of your code. For example, if the last byte of your assembly program resides in memory location $25, then replace XX by $26 as shown below: [26..FFF] :00 %zero remaining memory% This will initialize all your remaining unused memory to a known value of zero. (A zero happens to represent the TAB instruction.) Note: When opening a MIF file in Quartus, be sure to select Open as: Text (not Auto). If you use auto, all the comment described below will disappear! PART A. SIMULATING EXISTING CODE (Prelab) 1. Open the file called eprom.mif in the main folder. IMPORTANT: Open this file after setting Open as to Text from the default Auto. If you already opened the file with Auto, do not save any changes you make. Close it and open it with Open as: set to Text. The file eprom.mif is the code that is run out of reset (Address = 0) at start. 2. Describe the purpose of this program. 3. The data for the program in eprom.mif can be found in the file sram.mif. This is just a sample data file; later you will modify this file to create different data to test the program. Create a small table (see Table 1) that describes how the registers change as the program is executed. For each row in the table, enter the value

2 Page 2/5 in columns labeled A through PC, assuming that the instruction has already been completed. 4. Compile the computer.bdf file (functionally) with the give program file eprom.mif and data file sram.mif. Before simulating the first time (after restoring the archive), in the Simulation Waveform Editor, select Simulation Simulation Settings; then select Restore Defaults at the bottom. Functionally simulate this design. The simulation should include MCLK, CLOCK, RESET, STATE, ADDR, DATA, R_/W, IR, A, B, X, Y, ALU, N_FLG, and Z_FLG. 5. I suggest that you use the file computer.vwf already available after you open the gcpu_f12.qar file. Perform a functional simulation with the computer.vwf file. 6. Compare the hand simulation results in your table with the Quartus simulation results in computer.vwf. 7. Use your table to identify when the flags (i.e., status bits Z and N) change and specify why they are set at a particular time. Annotate your table and the Quartus-generated simulation to indicate what is going on during each step of the simulation. You do not have to include the entire simulation in your submitted lab document, just enough to prove that you understand what is happening. 8. Use your table and the simulation to identify where data is being written into memory or read from memory. Pay close attention to the address bus. Annotate your table and the Quartus-generated simulation with this information. 9. Modify the data in sram.mif and repeat steps 4-7 above. Note: When you change data in either the eprom.mif file or the sram.mif file, you must recompile the computer.bdf file. Include the simulation results in your submitted lab document. 10. Compile all the documents described above into your lab document. PART B. NEW PROGRAM CREATION (Prelab) 1. Write a program to get the higher of Input Data Table two numbers. The input table is OutAddrLow arranged as following: OutAddr, OutAddrHigh TabSize, Num1a, Num1b, Num2a, TabSize Num2b, The input table is Num1a arranged as following: OutAddr, Num1b TabSize, Num1a, Num1b, Num2a, Num2a Num2b Num2b, Your task is to write a Num3a program that creates an output table Num3b that starts with max(num1a, Num4a Num1b), then has max(num2a, Num4b Num2b), etc. OutAddr is the starting address of the output table. TabSize is the number of number pairs for NumTabSizea which the maximum will be NumTabSizeb determined. When you have completed the data processing, execute an endless loop (like a dog chasing its tail). 2. Assume that the input table is in ROM starting at $037E. It could just as well be in SRAM at address $137E, for example. (Note that the output table must be in SRAM, since you don t write to ROM.) To test your program, you will have to create the program and some data in the ROM (eprom.mif) file as well as setup the SRAM (sram.mif) file for storing your results. (If the data was instead in the sram.mif file, your program should still work, as long as you knew the starting location.) 3. Use the X register to point to the data that is read from the input table and use the Y register to point to the output table. 4. REG A should be used as a loop counter. REG B should be used for calculations. (Hint: You may need to temporarily store the loop counter in memory, i.e., SRAM, while REG A is used for other purposes.) 5. Hand assemble your program and write a list file that has addresses, opcodes (machine codes), assembly language instructions, and comments. To create the list file, use Table 2 or one of the following two documents on our website: Assembly_List.docx or Assembly_List.xlsx. Copy the completed table into your lab document. 6. Verify the program works by creating a eprom.mif. For this verification, use OutAdd = $1F00, TabSize = 3, and use three sets of data. Predict the simulation result with a table like that described in Part 1. Annotate this table as in Part 1. The simulation results and annotations with the instructions should be submitted in your lab document. Your program must work (with no changes) for a completely different sram.mif file, i.e., do not embed the number $1F00 for the output or 3 (the table size) in your program. 7. Copy the list file into your lab document. Also include the annotated table from Part A in your lab document. Submit (through Canvas) this file along with your design archives, and summary document. Also as usual, bring a printout of your Summary document to lab. Finally, bring a copy of the GCPU documents to your lab. Note: If you wish to use variables or store values in your code, you must reference the RAM area of you memory space. RAM is located in $ $1FFF. ROM is read only. Note: When you change data in either the eprom.mif file or the sram.mif file, you must recompile the computer.bdf file before trying to simulate. IN-LAB REQUIREMENTS 1. Show your TA the pre-lab work associated with Part A results. Your TA will ask you general questions on the operation of the code in simulation. 2. Show your TA the pre-lab work associated with Part B results. Your TA will again ask you general questions on the operation of the code in simulation.

3 Page 3/5 3. Your TA will give you another input table with which to test your algorithm from Part B. Your TA will then ask you to make another table. You might want to make a blank table for this purpose and bring it to your lab. 4. The TA will now ask you to write a short program (very simple task). Create and simulate the desired program (by making another table). You might want to make another blank table for this purpose and bring it to your lab. Table 1: Sample table for Prelab Part A, #3 (and elsewhere). Notes: All values in hexadecimal except Z & N. The first row past the header row is an example row. Address(es) Opcodes Instruction A B X Y Z N PC LDX #$

4 Page 4/5

5 Page 5/5 Table 2: Sample table for Prelab Part B, #5. This table is also available on our website in Assembly_List.docx and Assembly_List.xlsx. Address (hex) Opcodes (hex) Assembly Language Instructions Comments