Exercise: OpenRISC Programming

Transcription

1 Exercise: OpenRISC Programming Increasing efficiency of the OpenRISC core with simple instruction extensions Michael Gautschi Antonio Pullini

2 Introduction All exercises will be performed on the following configuration: 4 OpenRISC or10n cores With private instruction cache (I$) 8 banks of shared level 1 memory (TCDM) Large L2 memory for instructions and data Since the focus of this exercise is on the core, only one core is used and the others are put to sleep. or10n processor cores Not used / sleeping

3 Exercise Overview 1. Introduction example Compile & execute Helloworld on the Instruction Set Simulator (ISS) 2. Simulator Basics Analyze ISS output and debug 3. Benchmarking Analyze performance improvements of the new instructions using the simulator 4. RTL simulations and benchmarking Compare to simulator 5. Unaligned memory accesses Program a simple stencil and show the benefit of unaligned memory accesses 6. Auto vectorization Analyze the improvements of vector operations on a matrix addition 7. Interrupts and events Compare interrupts and event response times

4 Getting Started 1/2 Copy data from master account: $ mkdir 2_OpenRISC $ cp /home/soc_master/2_openrisc/openrisc.tar.gz 2_OpenRISC/. $ tar xzf OpenRISC.tar.gz 2_OpenRISC directory Source the instruction set simulator $ source /home/soc_master/germain/pulp-sdk ub14.10_2/env/setup.sh We will be working in the software (sw) and build directories sw-dir: contains application sourcecode build-dir: Holds compiler and simulator output here Simulator and RTL-simulations will be run here sim-dir: Contains precompiled code for RTL-simulation

5 Getting Started 2/2 We will be working on the scratch because we are going to generate some data 1. Create a build directory and set up the compiler $ mkdir /scratch/soc_xx/build_id 2. Start the compiler in a new shell: $ or1k v1.7.3 xterm $ tcsh (switch to cshell) 3. Configure the build directory in the new shell $ cd /scratch/soc_xx/build_id $ cp /home/soc_xx/2_openrisc/build/configure_template.tcl /scratch/soc_xx/build_id/configure.tcl In the configure script: Set the path to your exercise folder: OPENRISC_DIR= /home/soc_xx/2_openrisc $./configure.tcl You have successfully set up the build directory! Lets get started with exercise 1!

6 Exercise 1 Introduction a) The build directory is created, the compiler is configured, and the simulator is set up. We are ready to start with a simple helloworld application. b) Compile Helloworld.c Helloworld.c is located in sw/apps/sequential_tests/helloworld/. To compile the application enter the build folder and run the makefile $ cd build $ make helloworld : to generate an executable for the simulator $ make helloworld.read : to generate the assemebly $ make helloworld.slm.cmd : to generate input data for RTL simulations c) Run Helloworld.c The simulator is called pulp-run and can be started like this: $ pulp-run --load-binary=./apps/sequential_tests/helloworld/helloworld:0xf Console should output helloworld Output is also written to the file: stdout/stdout_pe

7 Exercise 2 Simulator basics 1/4 Simulator commands to run an application Run an application: $ pulp-run --load-binary=./applicationname:0xf Get assembly traces: $ pulp-run --load-binary=./applicationname:0xf --iis-trace Enter debug mode Force entering the debugger in the beginning: $ pulp-run --load-binary=./applicationname:0xf --pdb-break press Ctrl+C during execution Check current status of core: (Cmd) state : bootaddress = 0x1c Breakpoints and inspection of memory (in debug mode) Set a breakpoint on memory access: (Cmd) bkp address region rw Display all breakpoints: (Cmd) bkp_list Remove a breakpoint: (Cmd) bkp_dis ID Inspect memory: (Cmd) mem_dump address size : address = 32 bit memory address; : default region = 0x4 (1 word) : rw = read or write access (default rw) : ID shown in bkp_list : 32bit addresses : default size = 0x4 (1 word)

8 Exercise 2 Simulator basics 2/4 Analyze the rijendael application (aes en/decryption) function header Generate the assembly: $ make rijndael.read Have a look at the assembly file rijndael.read The most important functions are: main compute_aes encrypt encfile decrypt decfile Instruction in big and little endian format PC Disassembled instructions Absolute and relative jump/branch targets

9 Exercise 2 Simulator basics 3/4 Simulator traces: Latency of the instruction New register values, effective addresses Disassembled instructions To trace an application: Run the application with the option --iss-trace Four traces are generated, one for each core we are actually using a four-core configuration of which three cores are sleeping trace_cluster0_core0.log shows the interesting traces! PC

10 Exercise 2 Simulator basics 4/4 Tasks: Run the rijndael application with traces and make use of the debugger and breakpoints Which instructions take more than one cycle to execute? Why are some load/store instructions (l.lwz, l.sw) taking more than one cycle? Do you see an example of a data hazard? How many times is address 0x1c read? What is the encryption key?

11 Exercise 3 Benchmarking 1/5 Intro: The timer can be used to count execution time (in cycles) Check matrixmul.c for example Include <timer.h> and use the functions: reset_timer() start_timer() stop_timer() get_time() Hardware loops To run the application with different hardware loop settings, the compiler needs to be reconfigured There are two options: 1. Create a new build folder with a new configure.tcl script 2. Modify current folder and modify the configuration script: configure.tcl To support different numbers of hardware loops, add the following to TARGET_C_FLAGS in configure.tcl: remove the option -mno-hwlp to enable hwlps -mmax-hwloops=<number_of_hwlp> : number_of_hwlp [0,4] Reconfigure build folder: $./configure.tcl The compiler will generate the following hwloop instructions to produce efficient loops: - lp.start - lp.end - lp.count - lp.counti - lp.setup - lp.setupi

12 Exercise 3 Benchmarking 2/5 Tasks: Check if hardware loops are generated (in the matrixmul.read file) How many instructions are actually saved? Compare the matrixmul.read with and w/o hwloops. Estimate the speedup with 1,2,4 hardware loops Do your measurements match your estimations? Why is the benefit of the first one higher? Baseline Hardware loop (1 register set) 2 register sets 3 register sets 4 register sets Execution time: (# cycles/ % improvement)

13 Exercise 3 Benchmarking 3/5 Pre/post increment immediate: Activated by default! Deactivate with mno-idxls Pre/post increment register: From a hardware perspective, what is the drawback of this instruction? Deactivate with mno-rrls Multiply-accumulate instruction: Old architecture: Accumulation register stored in a special register which is not in the register file Accumulation result can be accessed in two cycles New architecture: Accumulates directly on the register file Enable new MAC with -mmac3 Old MAC: New MAC:

14 Exercise 3 Benchmarking 4/5 Vector Instructions: Add, sub, mul, mac, comparisons are all supported in vector mode In parallel one can compute: One word Two halfwords, or Four bytes Enable the vector extensions with the compiler option: mlv32 for vector generation -munaligned-ls for unaligned memory accesses Check in the.read me if vector code is generated. Vector instructions have the format: lv.{mul,mac,sub,add, } Tasks: Run the matrixmul application with the different compiler options Summarize your results in the first column on the next page

15 Exercise 3 Benchmarking 5/5 Baseline Hardware-loop Pre/post incr. imm. Pre/post incr. reg mac Vector Unaligned access Execution time: (# cycles/ % improvement) Simulator: RTL-SIM: Can you explain your results? Are the results you obtained optimal? What can be done better? Try to improve the matrix multiplication such that vectors are used more efficiently

16 Exercise 4 RTL Simulation 1/2 The simulator is not 100% accurate because: It is still under development Not all components are modeled (no caches/memory contentions/ simplified DMA) But a lot faster than RTL simulation Start RTL simulations with the Makefile in your build folders: $ make testname_vsim Rerun the matrixmul in the RTL simulation and complete the table If you have a build folder for each configuration, you can run the simulations in parallel (each RTL-sim will take ~5min) Are you able to reproduce the previously obtained results? Do you observe any differences? Do you have an explanation?

17 Exercise 4 RTL Simulation 2/2 In matrixmul.c the function computegold() which is actually computing the multiplication is called two times with the same inputs and outputs! Code snipped of matrixmul.c: Why do you think this is the case? Compare the execution time of the first iteration between the RTL-simulation and the simulator! What do you observe?

18 Exercise 5 Unaligned Memory Access Unaligned memory access If data is not aligned, for example when computing the stencil over an image, a lot of memory accesses and shifting is required. If data can be accessed in an unaligned fashion, the shifting is not required anymore. The or10n core supports unaligned accesses in two consecutive cycles! Image 1 stencil Pixel = 1 char Tasks: Complete the stencil template program (sw/apps/sequential_tests/stencil/stencil.c) which computes four stencils in parallel over a 32x32 pixel image Do you observe a speedup with unaligned memory access enabled? Compare to a vector only implementation 4 parallel stencils computed with vectorial unit

19 Exercise 6 Auto Vectorization In the matrixmul example, the automatic vector support did not bring the desired speedup If the matrices are accessed in a more regular fashion, this is expected to change! Run the matrixadd{8,16,32} applications in RTL simulation and measure the speedup. matrixadd8 is based on characters matrixadd16 on short integers matrixadd32 on integers Run the motion_detection application and compare first the execution time of the baseline and the optimized architecture without vector support. And then add first unaligned memory access, and then vector instructions Baseline Without vector Unaligned access With vector Execution time: (# cycles/ % improvement) matrixadd32 matrixadd16 matrixadd8 motion_detection

20 Exercise 7 Interrupts & Events 1/2 Core 3 is used to model an external interface in the following Receiving and processing of data is completed as follows: 1. Core 0 configures its interrupt or event mask before completing other tasks/going to sleep 2. Core 3 generates data and sends/places it in a buffer (here in L2 memory) 3. Core 3 sends commands to global event unit, to generate an event for core 0 4. Core 0 receives an interrupt/ wakes up and processes the data in L2 memory 5. Continue from beginning

21 Exercise 7 Interrupts & Events 2/2 Task 1: Interrupts Check out the interrupt/event template: sw/apps/sequential_tests/event_interrupt.c Define an interrupt handler Copy data from receive_buffer to your memory (received_data) Initialize interrupts Add interrupt handler on interrupt GP0 (see sw/libs/sys_lib/src/int.c) Set interrupt mask (1= interrupt is not masked) Task 2: Events In the function wait_and_proc_data(): go to sleep, wait for event When an event is received: copy data from receive_buffer to your memory (received data) Task 3: Comparison Compare the two solutions: Execution time Measure the time required to process one package in modelsim $ make event_interrupt_vsim_debug Hints to measure time: Events: observe the clock of core 0 Interrupts: observe the state of exception routine (exc_running_p) What are the benefits of using events?

22 Questions & Answers You have successfully completed the exercise If you are interested in a mini-project we can offer you: Implementing and optimizing of a benchmark, using the multicore pulp environment See last exercise about the pulp architecture Compare simulator and RTL simulations and come up with examples how to improve it Add performance counters on RTL level Compare OR10N core to a state-of-the art micro-controller with DSP functionalities like the ARM Cortex M4 Add a small unit which observes the stack pointer, and issues an exception if a stack overflow has been detected We are open to your own ideas!