CEG2136 - Lab 4

pdf

School

University of Ottawa *

*We aren’t endorsed by this school

Course

2136

Subject

Electrical Engineering

Date

Feb 20, 2024

Type

pdf

Pages

Uploaded by EarlTarsier738

Lab 4 CEG 2138 - Computer Architecture I Fall 2022 School of Electrical Engineering and Computer Science University of Ottawa November 10th, 2022

Index Figure 1.0 - Basic Computer Hierarchy of Design Files………………………………………………… .... 3 Table 1.0 - Logic Operations for lab3controller.bdf….………………………………………………….….6 Figure 2.0 - Design file for lab3top.bdf…………………………………….………………………………8 Figure 2.1 - Design file for lab3controller.bdf (⅓)………………………………………………………...8 Figure 2.2 - Design file for lab3controller.bdf (⅔)…………………………………………………..….…9 Figure 2.3 - Design file for lab3controller.bdf (3/3)…………………………………………………...…..9 Figure 2.4 - Test Machine Code………………………..………………………………………………….10 Figure 2.5 - Final Machine Code………………………………………………………………………….11 Figure 3.0 - Waveform With The Test Machine Code……………………………………….……………12 Figure 3.1 - Waveform With The Final Machine Code…………………………………….……………..12 Figure 3.2 - Close Up of Waveform With The Final Machine Code….…………………………………..13 Figure 3.3 - FPGA Board Running The Final Machine Code…………………………………………….14 2

Hardware Pre-Lab Questions 1. Figure 1.0 - Basic Computer Hierarchy of Design Files 2. Only one register will place an output on the data bus at a time because the BusMUX is an 8x1 Mux, acting as a selector (one mux output at a time). 3. The reset signals are synchronous because they clear the whole system. 4. If a load and a reset signal are simultaneously sent to a register, the register is cleared, because clear sets both AND gates (in register1bit) to 0, which makes OR 0 (and it’s a D flip-flop). 5. The AR is directly connected to the memory because the AR stores the address of the operand or the operand (or the address of the address of the operand) itself to be fetched from memory 3

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

6. They all need to be incremented at various times. 7. Highest to lowest priority: Reset, Load, Increment, because if clear is 1, all AND gates are 0, and if load is 1, increment AND gate is 0 (in counter8bits). 8. No, because the value from memory must be loaded into the DR first, because it is the only register connected to the AC. 9. S2 S1 S0 Operation Description 0 0 0 AC + DR Add 0 0 1 AC + DR’+1 Subtract 0 1 0 Ashl AC Arithmetic shift left AC 0 1 1 Ashr AC Arithmetic shift right AC 1 0 0 AC ∧ DR Logic AND 1 0 1 AC ∨ DR Logic OR 1 1 0 DR DR transfer 1 1 1 AC’ Compliment AC Control Signal Expressions memwrite T 9 Y 4 + T 10 Y 6 CPU Registers AR_Load T 0 + T 2 + T 5 (IR 6 )’ + T 6 (IR 6 )’ + T 7 X 2 4

PC_Load T 8 Y 5 PC_Inc T 2 (S)’ + T 5 (IR 6 )’(S)’ + S’Y 6 (T 11 + T 12 )(DR 0 + DR 1 + DR 2 + DR 3 + DR 4 + DR 5 + DR 6 + DR 7 )’ DR_Load T 8 (Y 0 + Y 1 + Y 2 + Y 3 + Y 6 ) DR_Inc T 9 Y 6 IR_Load T 3 AC_Clear T 5 X 1 IR 0 AC_Load T 5 X 1 (IR 1 + IR 2 + IR 3 ) + T 9 (Y 0 + Y 1 + Y 2 + Y 3 ) AC_Inc T 5 X 1 IR 4 OUTD_Load T 1 CPU ALU 5

ALU_Sel2 T 9 (Y 0 + Y 3 ) + T 5 X 1 IR 1 ALU_Sel1 T 5 X 1 (IR 1 +IR 2 +IR 3 )+T 9 Y 3 ALU_Sel0 T 9 Y 2 + T 5 X 1 (IR 1 + IR 3 ) Bus BusSel2 T 0 + T 9 Y 4 BusSel1 T 2 + T 5 + T 0 + T 10 Y 6 BusSel0 T 9 Y 4 + T 8 Y 5 + T 10 Y 6 Control Unit SC_Clear T 5 X 1 + T 8 Y 5 + T 12 Y 6 + T 9 (Y 0 + Y 1 + Y 2 + Y 3 + Y 4 ) Halt T 5 X 1 IR 5 Table 1.0 - Logic Operations for lab3controller.bdf 6

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Software Pre Lab 2. While counter > 01 M[z] ← M[x] + M[y] M[A1] ← x + 1 M[A2] ← M[A1] + 1 M[A3] ← M[A2] + 1 Counter – Loop 3. The Fibonacci sequence. 4. The use of indirect addresses is useful as it allows us to increment the address by simply using pointers. Theoretical Part In this lab we were tasked to create a basic computer. The lab was divided into two parts spread over two weeks. We were given multiple support files and we simply needed to modify the lab3controller file ( Figure 2.1 - 2.3) to match the equations that we found in our pre-lab. The second part was a bit more complex than the first, this is where we used assembly language to create a program that would add a series of hexadecimal numbers and halt the program when the program would read “00”. Now, let's dive deeper into the first part of the lab… Our first task was to determine the relationship between the different design files that were provided to us. This was drawn in Figure 1.0 . Secondly, we had to determine what our logical operations would be for the lab3controller file, we demonstrate these files in Table 1.0 . Now that the controller is complete, we upload the test machine code given to us as seen in Figure 2.4 . Finally, we simulate the waveform to be able to determine that the program is functioning currently Continuing into the second part of the lab, the software part. We were tasked with creating a program in assembly language to be able to add a series of hexadecimal digits given to us, store the last digit and halt the program. Once this assembly code was complete, we were asked to convert it into machine code and add it to the same memorycontents.mif file where we wrote our test machine code. Finally, we simulated the waveform with the code to ensure our outputs were correct before uploading it to the FPGA board where we ensured our results were correct. 7

Design Figure 2.0 - Design file for lab3top.bdf Figure 2.1 - Design file for lab3controller.bdf (⅓) 8

Figure 2.2 - Design file for lab3controller.bdf (⅔) Figure 2.3 - Design file for lab3controller.bdf (3/3) In the first part of the lab we were tasked with designing the logic circuit of the lab3controller.bdf (Figure 2.1, 2.2 & 2.3) we’re we used our previously derived logic equations (Table 1.0) to create our circuit. The only file we had to work on was this lab3controller.bdf file as all the other ones were given to use except for the lab3top.bdf (Figure 2.0) where we discovered an error with the sevensegcontroller where the outputs a1…g1 were reversed with the outputs a2…g2, a quick swap around fixed this slight oversight. 9

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Figure 2.4 - Test Machine Code 10

After properly completing our lab3controller.bdf file, we had to ensure that it worked correctly before we could attempt to upload our trial software. For this, we were given the machine code as seen in Figure 2.4 where we then proceeded to run a waveform simulation as seen in Figure 2.5 . Figure 2.5 - Final Machine Code 11

Now confirming that our hardware implementation was correct and working as expected, we were tasked with creating a code in assembly language that would allow us to add consecutively each number of the sequence: 21, B5, 37, 08, 5C, 84, A1, 1D, 72, FF, F6, 43, 03, A9, D4, 19, 31, D9, 47, 82, 14, 52, 07, CA, 04, store the number when it would be equal to zero and then halt the program. Our program can be seen in Figure 2.5 . The program has two parts to it, the first being the code for the operations themselves (00-1F) and the second is the data given to us found between addresses 80 and 9A. As per our calculations, we expect to program to stop at D9 and for it to be stored at the address FF, we will confirm this in the simulation part. Simulation and Verification of Real Implementation Figure 3.0 - Waveform With The Test Machine Code Figure 3.1 - Waveform With The Final Machine Code 12

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

Figure 3.2 - Close Up of Waveform With The Final Machine Code In this final stage we were tasked with proving that our design files and software worked properly. We ran two different waveform simulations demonstrating that the output of our program was correct. The first, used the machine code that was given to us as a trial, as seen in Table 2.4 and the waveform being Figure 3.0. Now knowing that our hardware functioned correctly, we tested the machine code in Table 2.5 for the waveform to be that as seen in Figures 3.1 & 3.2 . Taking a closer look at these waveforms, we can confirm that the software does its job correctly and stops at D9. 13

Figure 3.3 - FPGA Board Running The Final Machine Code The final part of this lab was to prove that we could run this program on the FPGA board. Hence, after verifying that the hardware and software both run as expected on the simulated waveforms, we uploaded the project onto the FPGA board and ran it, as seen in Figure 3.3 . You’ll notice on the board, taking a look from left to right, that SW17 is high, this allows the program to run automatically. Additionally, switches SW0-SW7 were all brought high, reading the information at address 11111111 2 or FF 16 , and, as seen on the display, the information at address FF is D9, hence proving that our project works as well on the FPGA board! A quick note, we realized shortly after first uploading the program on the FPGA that the outputs on the seven-segment display were reversed (it was showing 9D rather than D9), a quick dive into the sevensegcounter file demonstrated that the connections were accidentally reversed, a quick fix solved the issue. 14

Discussion and Conclusion In this final lab, we got our first taste of assembly language and machine code, it was definitely a steep learning curve… Nonetheless, we were able to combine the hardware knowledge that we gained in the last lab to at least ensure that we weren’t going to have any hardware issues and mainly focus on the software aspect of the lab. Nonetheless, when we discovered it to be particularly difficult to implement the machine code we started doubting our hardware component of the lab, regardless, there were no hardware issues, only software based. After much trial and error, we were able to create a software program that worked as expected and without issue. Once we overcame this final barrier, we could really appreciate the workings of this lab. To summarize, in this lab we were introduced to the use of assembly language, machine code and the use of a memory file in a project and how one can use them to create more complex projects. This allowed us to make a hardware circuit that was easily modifiable and thus allowed it to be able to perform a multitude of different operations with a multitude of different data in just a few instants just by changing the currently loaded machine code. We then created said machine code file to be able to create a program of our own to solve a specific problem. 15

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version