1

University of Waterloo

Electrical and Computer Engineering Department

Digital Computers

ECE-222 Lab manual

For the ORCA RISC-V Soft Core on Logical Step Board*

Winter 2019 January 28, 2019

Mahmoud A. Elmohr, Sanjay Singh, Eric Praetzel, Cathy Gebotys

*This manual was based upon

R.Keshavarzi and H.D.Patel “ECE-222 Lab manual for the Texas Instruments Tiva-C” ,

Feb 20,2018, Winter 2018

and revised for RISC-V (Special thanks to M.A.Elmohr for his port of ORCA into

Logicalstep Board and Sanjay Singh for his valuable assistance)

This manual is for the exclusive use of students registered in the course.

Reproduction or use for any other purpose is prohibited.

2

Contents General Information .................................................................................................................................... 4

Lab schedule ............................................................................................................................................ 4

Lab groups ............................................................................................................................................... 4

Lab marking ............................................................................................................................................. 4

Due dates and on-time delivery ............................................................................................................... 5

Lab-0: Introduction to the RISC-V platform in the lab ................................................................................... 6

Objective ................................................................................................................................................. 6

What you do ............................................................................................................................................ 6

Pre-lab ..................................................................................................................................................... 6

Introduction to hardware and software ................................................................................................... 6

Hardware ............................................................................................................................................. 6

Software .............................................................................................................................................. 7

In-lab procedure ...................................................................................................................................... 7

Running assembly language code on the board .................................................................................... 7

Using Venus simulator.......................................................................................................................... 9

Lab report .............................................................................................................................................. 11

The assembly language code for VENUS ................................................................................................. 12

Lab-1: Flashing LED .................................................................................................................................... 13

Objective ............................................................................................................................................... 13

Background ............................................................................................................................................ 13

Pre-lab ................................................................................................................................................... 14

In-lab procedure .................................................................................................................................... 14

Coding Goals .......................................................................................................................................... 15

Lab report .............................................................................................................................................. 15

The assembly language code: ................................................................................................................. 16

Lab-1 Submission form ........................................................................................................................... 17

Lab-2: Subroutines and parameter passing ................................................................................................ 18

Objective ............................................................................................................................................... 18

What you do .......................................................................................................................................... 18

Pre-lab ................................................................................................................................................... 18

In-lab procedure .................................................................................................................................... 18

Lookup Tables ........................................................................................................................................ 20

Lab report .............................................................................................................................................. 22

The Morse code ..................................................................................................................................... 23

3

Lab-2 Submission form ........................................................................................................................... 24

Labs 3,4 sections of lab manual: will be posted to Learn when ready ......................................................... 25

Appendix A: Memory map ......................................................................................................................... 25

References:................................................................................................................................................ 25

University Expectations and Policies .......................................................................................................... 26

Academic Integrity ................................................................................................................................. 26

Grievance .............................................................................................................................................. 26

Discipline ............................................................................................................................................... 26

Appeals .................................................................................................................................................. 26

Note for Students with Disabilities ......................................................................................................... 26

4

General Information This section contains general information about the ECE-222 lab. All lab contents and resource are posted on the University of Waterloo on-line learning system called LEARN. It can be accessed here: learn.uwaterloo.ca

In the Fall 2012 term a shift from the Freescale ColdFire® to the Keil MCB1700 board with an ARM® CPU was made since many mobile devices were using an ARM based CPU. In Fall 2015 the $13 Texas Instruments Tiva-C microcontrollers was introduced, all using the Keil MDK development software running under Windows.

RISC-V is a free and open source ISA enabling open standard collaboration [5]. Due to the RISC-V ecosystem and opportunity for experts to collectively work on the ISA’s future, RISC-V is expected to support the next era of computing innovation and design. Originally developed in CS division at Berkeley EECS, the RISC-V foundation was established in 2015 with over 100 company members. The ISA been designed to support extensive customization and specialization. In Winter 2019 ECE 222’s instructor adopted RISC-V for both course and lab. In the lab, RISC-V softcore (ORCA implementation by Vectorblox [1]) was ported on top of the Logical Step board based on Altera/Intel Max 10 FPGA. This lab manual is still under development, and highly borrows from lab manuals developed for ARM for the same course.

Please report typos, errors, or other challenges in this manual to the Lab and Course Instructor. We appreciate your feedback and cooperation.

Lab schedule There are three hour lab sessions scheduled for this course are listed here: http://www.adm.uwaterloo.ca/infocour/CIR/SA/under.html

Lab groups All labs are to be done in groups of two students. Groups of three, or more, students are prohibited. If a lab session contains an odd number of students, every effort will be made to pair-up the single students.

It is expected that both members will put equal effort into the lab tasks during the term. Unequal participation or other conflicts in a group should be brought to the lab instructor’s attention at the earliest possible time.

Lab marking The course marking scheme is stated in the Course Outline.

There are three main components related to each lab session. The lab manual for each experiment will tell you what you will need to submit for that component.

- Prelab. It is designed to get you started with the task. Once you accomplish what is asked in this section, you will be ready to start coding in assembly language.

5

- Lab session/Demo. You will present your work to a lab staff to be marked for that section. Questions will be posed to students regarding the contents, procedures, debugging, and techniques used to get the code working correctly. A picture of the Demo form is then uploaded to Learn.

- Lab report. You will submit your assembly language code and a TA will mark your report.

Different labs carry different marks allocated to them. Marking sheets are in the lab manual.

Warning: Failure to complete ALL labs may result in an Incomplete mark for the course. This means each student is expected to attend all lab sessions.

Due dates and on-time delivery Lab reports and lab demonstration sessions will carry some marks associated with each experiment. They should be treated like examination sessions. Students should not miss them without a legitimate reason, otherwise they will lose some marks.

If you have an interview scheduled during a lab demonstration session, or if you have to miss a lab demonstration your partner should demonstrate and you show your understanding of the code in another session.

Details about deadlines and penalties are included in the Course Outline.

Electronic lab report submission is done through LEARN (learn.uwaterloo.ca).

6

Lab-0: Introduction to the RISC-V platform in the lab

Objective We will familiarize ourselves with the basics of the RISC-V platform used in the ECE-222 lab. Here is a short list of what we will do in this session:

• Introduction to the Logical Step board and ORCA RISC-V implementation.

• Introduction to the development environment and scripts.

• How to compile your assembly code into hex file.

• How to program the FPGA to use the RISC-V softcore initialized by the compiled code.

• How to use Venus simulator for debugging.

What you do In this lab you will run a short RISC-V assembly program on Venus simulator [2] and learn how to debug it. Also, you will learn how to load this code to the RISC-V core on the Logical Step board.

Pre-lab N/A

Introduction to hardware and software In order to get students familiarized with the tools used in the ECE-222 lab, let us take a closer look at the hardware and software used in the lab.

Hardware Figure 1.1 shows the Logical Step board. The board employs an Altera/Intel MAX 10 FPGA within which we employ a RISC-V soft core. The ORCA RISC-V implementation by Vectorblox [1] features a 32-bit RISC-V core with the base integer instruction set as well as the standard extension for integer multiplication and division (RV32IM). There are several input/output peripherals available on the board, however, the only ones connected to the core are:

• 4 Push Buttons

• 8 Switches

• 8 LEDs

The core is also connected to a 32KB on-chip memory (16KB instruction memory and 16KB data memory).

7

Figure 1.1 – The Logical Step Board

Software Students need to first simulate as much as possible of their RISC-V assembly code [3,4] using VENUS simulator as there is no software to debug on the FPGA. The provided scripts to develop and facilitate code development are:

• compile.sh <name of assembly file> (this script compiles the provided assembly file and generates a hex file “mem.hex” to be loaded to the core).

• program.py (this script combines the previously produced hex file with a pre-compiled FPGA bitstream, loads the new bitstream to the FPGA to employ the RISC-V soft core as well as to initialize its memory with the hex file).

• reset.py (this script resets the core to its initial state by re-loading the bitstream previously produced by the “program.py” script. No need to use it right after running the “program.py script”).

As RISC-V toolchain is currently only available on Linux, we shall compile our code on an ECE Ubuntu server through Secure Shell (SSH) as will be explained in next section. We shall program the FPGA on a Nexus Windows lab station. To facilitate the whole process, without the need to file transfer from Linux to Windows, we will be using the “P” drive on the lab PCs as it’s automatically connected to ECE Linux while it appears on windows as well.

In-lab procedure First, we will see how to build and run code on the board. Then we will review how to use the simulator.

Running assembly language code on the board Follow the steps below in order to get yourself familiarized with the toolchain.

1 Logon to one of the stations (there will be some waiting, but if the terminal hangs, enter ctrl-alt-delete and try again). Make sure the USB cable of the LogicalStep board is plugged

8

into the USB hub. Open a Windows command line terminal (e.g. on Windows start menu, type “Command Prompt”). The Windows terminal automatically starts at the “N” drive. In order to switch to the “P” drive, type “ P:” (space P:) on the terminal and hit enter. If there is no “P” drive run Q:\eng\ece\util\327setup.bat in the terminal. Create a new folder on this P drive called “ECE-222” (e.g. “mkdir ECE-222”). Keep this Windows terminal open. Open a Windows file explorer window. Click on “This PC” on left hand side of the window. Double click on “P: drive” at bottom under Network Locations showing the empty ECE-222 directory (e.g. type file explorer on Windows start menu). Open another Windows file explorer showing the directory Q:\eng\ece. Drag and drop the LogicalStep_RISCV directory from the Q:\eng\ece window into the P:\ECE-222 directory window.

2 Navigate inside the “ECE-222\LogicalStep_RISCV\software\tests” directory. Your assembly files for all labs will be stored here. You will need to use a text editor, such as Notepad++, to create your assembly file and save it under “LogicalStep_RISCV\software\tests” making sure that you save it with “.s” extension. [e.g. To open Notepad++ right click on the Lab0_Template.s in the File explorer and select ‘Edit with Notepad++’]

3 Next we will create a Linux terminal window. On Windows start menu at the bottom left, type “PuTTY” to open the SSH terminal.

4 As in Figure 1.2 for the Host Name write “eceUbuntu.uwaterloo.ca”. Make sure SSH is chosen as the Connection Type and press open. [Note a security alert window may appear, if so then click yes]

5 This will get you a terminal where you will login with your Nexus username and password. 6 Navigate to the LogicalStep_RISCV folder using “cd” command by typing “cd ECE-222/

LogicalStep_RISCV” on the Linux terminal. [Note that in Linux we used a forward slash “/” for directories instead of the back slash “\” as in Windows. In Linux you can use ‘ls’ to list files and ‘cd’ to change directories] This is your Linux terminal which you should keep open.

7 From that directory you can run the compilation script on the “Lab1_Template.s “ assembly file by typing “./compile.sh Lab1_Template ” on the Linux terminal. [Note that we specified the name of the assembly file without the “.s” extension. If you include the “.s” you will get an ERROR ]

8 Notice that after the successful completion of the compilation step, it should generate a file named “mem.hex” under the “software” folder. (Note this file can be seen through Windows also on the “P” drive, as ECE Linux is automatically synced to your “P” drive.)

9 Now time to program the FPGA. On the P: drive, in the LogicalStep_RISCV folder using “cd” command by typing “cd ECE-222\ LogicalStep_RISCV” on the Windows terminal.

10 To program the FPGA run the “program.py” script by typing “python program.py” on the Windows terminal.

9

[Note: if you get an ERROR such as “can’t scan JTAG chain” etc, just re-enter the “python program.py” on the Windows terminal a second time and it should then work. Ignore any warnings or critical warnings. If it says “programming hardware cable not detected, then unplug all cables from USB hub except the LogicalStep board USB].

11 With a successful bitstream loading on the FPGA, you should notice the programming LED on the board blinking in a second and your code runs right after.

12 Notes: It’s helpful to keep both the Windows and Linux terminal command script windows open along with the notepad editor window for all Labs. For example this supports editing your code, saving the code change, recompiling (see 7. above “./compile.sh Lab1_Template ” on the Linux terminal) and rerunning the python script to download the new files to the FPGA (step 10. above “python program.py” on the Windows terminal). [you can use the up arrow key at RHS bottom of key board, next to numeric key pad, on Windows/Linux terminal to repeat the last command entered] If you don’t need to make any code changes, but wish to restart your program you type “python reset.py” on the Windows terminal.

Figure 1.2 – PuTTY Terminal

Using Venus simulator You must test your code wherever possible using Venus online simulator first before loading them on the development board. Venus simulator can help checking syntax errors as well logical errors thanks to the debugging capabilities it has. You should use the console as shown in the lectures for testing and later replace the console control code with the LED/Pushbutton/switch control code etc…

10

Figure 1.3 – Venus Simulator [2]

As Figure 1.3 shows, you can click on any line of the code (turning it to red) to create a break point, then you can hit “run” to execute the code until this red line. Or you can hit “step” to go through the code line by line.

On the right side of the simulator you can monitor the registers and memory locations in real time after each line execution, by which you can debug your code.

Another debugging tool within the simulator is using the console via environment calls. For more information about how to use the console see [2].

Under the “LogicalStep_RISCV/software/tests” folder you will find “Lab0_Venus.s” assembly file, which you can go through on Venus simulator to get better understanding of RISC-V ISA and assembly code structure, while monitoring the registers and memory locations to help you better understand.

One more note about the difference between Venus simulator and the soft core on the FPGA is that both have different memory segments as illustrated in Table 1.1.

Table 1.1 Memory Segments

Memory Segment ORCA RISC-V Venus Simulator

Text 0x00000000 0x00000000

Data 0x00004000 0x10000000

Stack 0x00007FF0 0x7FFFFFF0

11

Lab report Although there is no mark assigned to this lab, attendance is mandatory and will be checked. You must complete Lab 0 before starting Lab 1.

12

The assembly language code for VENUS ###################################### ## Name: Lab0_Venus.s ## ## Purpose: Reviewing RISC-V ISA ## ## Author: Mahmoud A. Elmohr ## ###################################### # The main function must be initialized in that manner in order to compile properly on the board # this venus file introduces pseudo-instructions and an alternative naming of registers x0-x31 .text .globl main main: # assigning the address 0x10000004 (which is in data memory section) to s0 register lui s0, 0x10000 # assigns the most 18 significant bits of s0 to be 0x10000 addi s0,s0, 0x004 # assigns the least 12 significant bits of s0 to be 0x004

#assigning the value 0x12345678 to s1 register li s1, 0x12345678 # a pseudo-instruction that translates to two consecutive

instructions (lui, addi) as previously done for s0 – note the immediate value is a full 32-bits

sw s1, 0(s0) # stores the content of s1 (0x12345678) to the memory address that that resides in s0 + 0 (0x100000004 + 0 = 0x10000004) sw s1, 4(s0) # stores the content of s1 (0x12345678) to the memory address that resides in s0 + 4 (0x10000004 + 4 = 0x10000008)

addi s2, zero, 5 # assigns the value 5 to s2 register, note zero is equivalent to x0 addi s3, s2, 3 # adds the value in s2 register to the value 3 and assign the result in

s3 register (s3=8)

#swapping s2 with s3 addi t0, s2, 0 # assigns the value in s2 register to t0 register mv s2, s3 # a pseudo-instruction that translates to addi s2, s3, 0 (assigns the

value in s3 register to s2 register) mv s3, t0 # assigns the value in t0 register to s3 register # an infinite loop, almost needed in any embedded systems code while_1: NOP j while_1 # j label is another pseudo-instruction equivalent to beq x0,x0,label

13

Lab-1: Flashing LED

Objective The objective of this lab is to complete, assemble and download a simple assembly language program. Here is a short list of what you will do in this session:

• Write some RISC-V assembly language instructions.

• Interface with memory mapped input/output (IO).

• Run and test the code on the board.

You will flash an LED (Light Emitting Diode) at an approximate 1 Hz frequency.

Background In order to flash an LED, one needs to know how the RISC-V core is connected to the LEDs. The core is connected to LEDs, switches and push buttons using memory mapped IO (input/output). Which means to read/write data to/from IO, load/store instructions are to be used to certain addresses. However, not to be confused, these are not real memory reading/writing, instead it reads/writes to/from specific registers in these IOs that correspond to certain functionalities.

For this lab, you only need to know that the LED base address is 0x7FF60000, thus you need to write to that address to turn on or off the LED. The least significant byte written to that address will control all 8 LEDs. For more information, read Appendix A for memory map.

Additionally it may be helpful to know that currently the RISC-V core uses a 25MHz clock and you may assume that most instructions have an effective CPI of 1.

In this lab, we will be using conditional branches. You have the freedom to use any conditional branches instructions such as:

• BEQ rs1, rs2, label (Jumps to label if rs1 equals rs2)

• BNE rs1, rs2, label (Jumps to label if rs1 doesn’t equal rs2)

• BLT/BLTU rs1, rs2, label (Jumps to label if rs1 is less than rs2 signed/unsigned)

• BGE/BGEU rs1, rs2, label (Jumps to label if rs1 is greater than or equals rs2 signed/unsigned)

A hint you might need: To perform bitwise logical inversion on specific bits in assembly, by performing XOR on these bits with 1s (XORing 0 with 1 will produce 1, and XORing 1 with 1 will produce 0).

14

Pre-lab

IMORTANT: See “Running assembly language code on the board” section of Lab 0 for toolchain

and FPGA programming procedure.

In order to see a flashing LED, implement a delay between the LED “on” and “off” states. Think about implementing a delay in assembly language.

Hint: Increment or decrement a register in a loop until it reaches a certain value.

There is no deliverable as pre-lab for this lab.

In-lab procedure Complete the given code “Lab1_Template.s” that is given at the end of Lab-1 manual and on LEARN. Feel free to change any part of the code. It uses pseudo-instructions which you may use but this is not mandatory (See RISC-V green card [3] for more information) – note the assembler will change these pseudo-instructions into RISC-V instructions.

Figure 2.1 shows two different approaches for flashing LED. The shorter flowchart leads to smaller code size and it is more efficient. Your code, when demonstrated for marking, must be using the short flowchart.

Don’t forget to insert an approximate 500ms delay in the loop; otherwise the LED blinks too fast to see. To get the delay loop calibrated, count to see if you get 60 flashes in 60 seconds and if not scale the initial value in the timing loop.

15

Figure 2.1 – Flowcharts for flashing LED

Coding Goals The goal is to get the LED flashing at a frequency close to 1 Hz (on for 500ms and off for 500ms). An accurate period of 1,000 ms or 1,000,000 µs is NOT the goal of this lab; time it or count the number of flashes in 60 seconds to scale the number to get better than 10% accuracy. Note the clock frequency of the RISC-V core is 25MHz.

All code should be well commented and all documentation must be within the program.

Lab report Submit your well commented code, and a picture of the marked Submission Form to LEARN. To understand the deliverables, look at the Lab1 Submission form.

16

The assembly language code: ################################################## ## Name: Lab1_Template.s ## ## Purpose: A Template for flashing LED ## ## Author: Mahmoud A. Elmohr ## ################################################## # The main function must be initialized in that manner in order to compile properly on the board .text .globl main main: # Put your initializations here lui s1, 0x7ff60 # assigns s1 with the LED base address (Could be replaced

with li s1, 0x7ff60000) addi s2,zero,0x55

sw s2, 0(s1) # turns the LED on (you can delete if you want, just for illustration on how to turn on or off the LED)

li s3, 11 # sets the counter max # an infinite loop, almost needed in any embedded systems code while_1: # You might write some code here nop #delay: # Write the delay routine here # You might write some code here # Also you might write another delay routine if using the long flowchart given in the

lab manual j while_1

17

Lab-1 Submission form

Class: 001 □ 002 □

201 □ 202 □ 203 □ 204 □ 205 □ 206 □

Demo date:

Submission Statement: We (I) are (am) submitting this report for grading in ECE 222. We (I) certify that this

report (including any code, descriptions, flowcharts, etc., that are part of the submission) were written by us (me) and have received no prior academic credit at this university or any other institution. The penalty for copying or plagiarism will be a grade of zero (0).

Member 1 Member 2 Name:

Name:

UW-ID (NOT student #)

UW-ID (NOT student #)

Signature:

Signature:

Note: Reports submitted without a signed submission statement will receive a grade of zero (0).

Weight Grade Comment

Part-I Pre-lab 0 --

Part-II Lab-demo

Lab completion (short flowchart)

35

Questions 35

Part-III Lab report

Code quality 15

Code comments 15

Total 100

18

Lab-2: Subroutines and parameter passing

Objective In structured programming, big tasks are broken into small routines and the main program calls these short subroutines.

In most cases when a subroutine is called, some information, parameters, must be communicated between the main program and the subroutine. This is called parameter passing.

In this lab, you will implement a Morse code system and use:

• Subroutines

• Parameter passing

What you do In this lab you will turn one LED into a Morse code transmitter. You will cause one LED to blink in Morse code for a five-character word. The LED must be turned on and off with the specified time delays until all characters are communicated.

Pre-lab Think about implementing Lab-1 code using subroutines. Write a subroutine called LED_OFF that turns LED-0 off, and another subroutine called LED_ON that turns LED-0 on. Write a third subroutine called DELAY that takes one input parameter (register a0 or x10) and waits for a0 * 500ms before returning.

There is no deliverable as Pre-lab for this experiment.

In-lab procedure A template code for lab-2 is available on LEARN. Add to it what you learned in lab-1. Start by initializing the on-board LEDs to off. Then additional functionalities are added to the code as shown in the flowchart depicted in figure 3.1. This is described in the following steps:

- Turn all LEDs off - Put the initials of the two lab partners together to create a four-character word (Capital

letters only). Add a fifth character of your choice (capital) which is different from the four previous ones. Set the five characters in your program at the InputLUT label.

- Write a subroutine called LED_OFF that turns LED-0 off - Write a subroutine called LED_ON that turns LED-0 on - Write a subroutine called DELAY that causes a0 * 500ms before returning to the main

program. a0 is passed to subroutine from the main program.

19

- Write a subroutine called CHAR2MORSE that converts an ASCII code into a Morse pattern. You will use registers for parameter passing between subroutines and the main program. Note that for RISC-V call convention: a0-a7 are used as subroutine’s parameters. And a0-a1 are used as return values. Thus, for CHAR2MORSE, a0 will be passed as the character ascii value, as well as the Morse pattern should be stored in a0 before returning to the main function.

To deal with each of the characters in the InputLUT string:

• Fetch a character by reading from the memory (from the first to last). It is in ASCII format as shown in table 3.1

• Subtract 0x41 from the ASCII value to get the index for the Morse LUT (look up table)

• Read the Morse pattern from the Morse LUT (using the index)

• Blink the LED for the Morse pattern. This step can be broken into the following sub-steps: a) Move the Morse code pattern for a character from register a0 to any other register

(e.g. t0) b) Remove the trailing zeros in the pattern by shifting right t0 until the least significant

bit equals ‘1’. You need to perform bit masking in order to check one bit c) If the least significant bit is ‘1’, then call the LED_ON subroutine d) If the least significant bit is ‘0’, then call the LED_OFF subroutine e) Call the DELAY subroutine with a delay of 1 f) Shift right the t0 to get the next value g) If the whole register (t0) becomes 0, the pattern has been all displayed h) Otherwise go to step c

• Insert long delay (equivalent to three dots) before fetching the next character

• Repeat the above steps for all characters. If the whole string has been processed, then insert another four DELAY intervals and start from the beginning again as a new word

Hint: Bit masking is an operation we do to isolate particular bits from the whole register for further

processing. For example, if the register contains 0xABCD, masking the least significant four bits (Performing

AND operation with 0x000F) will result in 0x000D, which isolates the needed bits.

Note: There are two types of right shifts; Logical right shift, which replaces the most significant bit with ‘0’

and arithmetic right shift which duplicates the previous most significant bit to be the new most significant

bit, to maintain sign. Check RISC-V ISA for corresponding instructions.

20

Figure 3.1 Morse Code Transmitter Flowchart

Lookup Tables Lookup tables are used to provide data to a program. You should be careful about how you read the data and index into it. Data can be 8-bit (byte), 16-bit (half-word) or 32-bit (word). Data has been stored using “.ascii” (to store bytes in a string terminated with NULL) or “.word” (to store data in words, where word means 32-bits). “.align” may be used before a lookup table to assure data alignment for the first data block.

With the Morse pattern for a

character in t0

Right shift off trailing 0’s in t0

with a loop

Shift t0 right.

check least

significant bit LSB is 0

LSB is 1

Turn LED on Turn LED off

Delay for 1 dot

Flashing

character

completed

T0 = 0?

Done shifting

all bits?

21

Here is some simple code to read a character: .data .align 4 # To make sure we start with 4 bytes aligned address (Not important for this one) InputLUT: .ascii "ABCDE" # Put the 5 Letters here instead of ABCDE .align 4 # To make sure we start with 4 bytes aligned address (This one is Important) MorseLUT: .word 0xE800 .word 0xAB80 .word 0xBAE0 .word 0xAE00 . . . .text .globl main main:

la s3, InputLUT # assigns s3 with the InputLUT base address la s4, MorseLUT # assigns s4 with the MorseLUT base address lbu t0, 0(s3) # loads the first byte from the InputLUT lbu t1, 1(s3) # loads the second byte from the InputLUT lhu t2, 0(s4) # load half word of the first word from the MorseLUT (can use lw though as we store each pattern in a new word) lhu t3, 4(s4) # load half word of the second word from the MorseLUT (can use lw though as we store each pattern in a new word)

In order to read a 32-bit data you need to use “lw‘”and increment by 4. To read 16-bit data you need to use “lh/lhu” and increment by 2. To read a byte you need to use “lb/lbu” and increment by 1.

Note: Although the Morse patterns are 16 bits, each is stored in one word, hence the need to

increment by 4 whether you used “lw” or “lh/lhu”

22

Example: Suppose the lab partner’s initials plus a fifth letter compose the word BIRDS. Then the

program should extract the letters (B I R D S) and create a Morse code pattern like this:

Lab report Submit your well commented source code, and a picture of the marked Submission Form, to the lab-2 drop-box on LEARN. Examine the Lab-2 Submission form to see what you will need to deliver.

23

The Morse code Table 3.1 shows corresponding Morse codes for English language alphabets.

Note the “Morse code” pattern is left justified and the “Binary Morse code value” is flipped.

Table 3.1 – The Morse code

Letter ASCII value

Morse code Morse code value

Flipped Binary Hex

A 0x41 1110 1000 0000 0000 0xE800

B 0x42 1010 1011 1000 0000 0xAB80

C 0x43 1011 1010 1110 0000 0xBAE0

D 0x44 1010 1110 0000 0000 0xAE00

E 0x45 1000 0000 0000 0000 0x8000

F 0x46 1011 1010 1000 0000 0xBA80

G 0x47 1011 1011 1000 0000 0xBB80

H 0x48 1010 1010 0000 0000 0xAA00

I 0x49 1010 0000 0000 0000 0xA000

J 0x4A 1110 1110 1110 1000 0xEEE8

K 0x4B 1110 1011 1000 0000 0xEB80

L 0x4C 1010 1110 1000 0000 0xAE80

M 0x4D 1110 1110 0000 0000 0xEE00

N 0x4E 1011 1000 0000 0000 0xB800

O 0x4F 1110 1110 1110 0000 0xEEE0

P 0x50 1011 1011 1010 0000 0xBBA0

Q 0x51 1110 1011 1011 1000 0xEBB8

R 0x52 1011 1010 0000 0000 0xBA00

S 0x53 1010 1000 0000 0000 0xA800

T 0x54 1110 0000 0000 0000 0xE000

U 0x55 1110 1010 0000 0000 0xEA00

V 0x56 1110 1010 1000 0000 0xEA80

W 0x57 1110 1110 1000 0000 0xEE80

X 0x58 1110 1010 1110 0000 0xEAE0

Y 0x59 1110 1110 1011 1000 0xEEB8

Z 0x5A 1010 1110 1110 0000 0xAEE0

Notes: - A dash is equal to three dots - The space between parts of the same letter is equal to one dot - The space between two letters is equal to three dots - The space between two words is equal to seven dots

- LED on for one dot

- LED off (same length as one dot)

24

Lab-2 Submission form

201 □ 202 □ 203 □ 204 □ 205 □ 206 □

Demo date:

Submission Statement: We (I) are (am) submitting this report for grading in ECE 222. We (I) certify that this

report (including any code, descriptions, flowcharts, etc., that are part of the submission) were written by us (me) and have received no prior academic credit at this university or any other institution. The penalty for copying or plagiarism will be a grade of zero (0).

Member 1 Member 2

Name:

Name:

UW-ID (NOT student #)

UW-ID (NOT student #)

Signature:

Signature:

Note: Reports submitted without a signed submission statement will receive a grade of zero (0).

Weight Grade Comment

Part-I Pre-lab 0

Part-II Lab-demo

Lab completion 40

Questions

40

Part-III Lab report

Code quality 10

Code comments 10

Total 100

Marking TA:

25

Labs 3,4 sections of lab manual: will be posted to Learn when ready

Appendix A: Memory map

Table A.1 shows base addresses for the IOs connected to the RISC-V core.

Table A.1 IOs Base Addresses

IO Base address

8 LEDs 0x7ff60000

4 Push Buttons (lower 4-bits of addressable byte)

0x7ff70000

8 Switches 0x7ff80000

References:

[1] ORCA RISCV by Vectorblox, https://github.com/VectorBlox/orca

[2] Venus Simulator https://github.com/kvakil/venus/wiki/Simulator , Venus Documentation https://github.com/kvakil/venus/wiki [3] RISC-V ISA green card, https://www.elsevier.com/__data/assets/pdf_file/0011/297533/RISC-V-Reference-Data.pdf#RISC-V%20Reference%20Data , (or https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf )

[4] The RISC-V Assembly Programmers Manual, 2017 https://github.com/riscv/riscv-asm-manual/blob/master/riscv-asm.md

[5] The RISC-V instruction set manual, specification v2.2, 2017 https://content.riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf

26

University Expectations and Policies The following statements represent university expectations and policies with respect to academic integrity, discipline, grievance, student appeals, and academic accommodations. If you would like more clarification, please contact your course instructor directly.

Academic Integrity In order to maintain a culture of academic integrity, members of the University of Waterloo community are expected to promote honesty, trust, fairness, respect and responsibility. [Check uwaterloo.ca/academic-integrity for more information.]

Grievance A student who believes that a decision affecting some aspect of his/her university life has been unfair or unreasonable may have grounds for initiating a grievance. Read Policy 70, Student Petitions and Grievances, Section 4, uwaterloo.ca/secretariat/policies-procedures-guidelines/policy-70. When in doubt please be certain to contact the department’s administrative assistant who will provide further assistance.

Discipline A student is expected to know what constitutes academic integrity [check uwaterloo.ca/academic-integrity] to avoid committing an academic offence, and to take responsibility for his/her actions. A student who is unsure whether an action constitutes an offence, or who needs help in learning how to avoid offences (e.g., plagiarism, cheating) or about “rules” for group work/collaboration should seek guidance from the course instructor, academic advisor, or the undergraduate Associate Dean. For information on categories of offences and types of penalties, students should refer to Policy 71, Student Discipline, uwaterloo.ca/secretariat/policies-procedures-guidelines/policy-71. For typical penalties check Guidelines for the Assessment of Penalties, uwaterloo.ca/secretariat/policies-procedures-guidelines/guidelines/guidelines-assessment-penalties.

Appeals A decision made or penalty imposed under Policy 70 (Student Petitions and Grievances) (other than a petition) or Policy 71 (Student Discipline) may be appealed if there is a ground. A student who believes he/she has a ground for an appeal should refer to Policy 72 (Student Appeals) uwaterloo.ca/secretariat/policies-procedures-guidelines/policy-72.

Note for Students with Disabilities Access Ability Services, located in Needles Hall, Room 1132, collaborates with all academic departments to arrange appropriate accommodations for students with disabilities without compromising the academic integrity of the curriculum. If you require academic accommodations to lessen the impact of your disability, please register with Access Ability Services at the beginning of each academic term.