1 Address space with memory mapped devices

Transcription

1 1 Address space with memory mapped devices In systems with memory mapped devices, the devices appear as regions of memory. The addresses that these devices occupy are determined by the system designer. Generally the memory occupied by these devices is referred to as registers, where each register is 32 bits. The system designer will supply documentation, called the register map, that describes the structure of these registers. These device registers should not be confused with the processor registers. The first type of device that we will deal with is the PIO (Parallel I/O) core device. A core in this case is a digital logic unit that transforms the actual signals of a device into the set of read/write registers presented to the programmer s view of the device. The PIO core supplied by Altera provides basic support for simple devices such as buttons, switches and LEDs. More information about the PIO core may be found in the Quartus II Handbook Volume 5: Embedded Peripherals manual (Chapter 13). Pay special attention to the register map section of the PIO core. Byte Address 0x0000 0x0010 0x0020 word Program & Data Memory 0x7FF0 0x8000 0x8810 0x8820 0x8830 0x8840 0x8850 LEDs Green Registers LEDs Red Registers Buttons Registers Switches Registers Seven Segment Registers SYSID Registers JTAG UART Regs Device Memory Figure 1. Memory Map of Lab 2 Address Space Figure 1 is a representation of the address space for Lab2. The on-chip memory from 0 to (0x7fff) is where the program and data reside. The five devices at addresses from through 0x8840 are separate instances of the PIO core. Each instance is represented to the NIOS II system as four 32-bit registers. Ref PIO core (The other two devices at addresses 0x8850 and 0x8858 are of a different type and are shown here only for completeness.) Page 1 of 10

2 Figure 2 is an example representing the flow of data from the actual switches device through the digital logic unit (Switches PIO Core) to the programmer s view of the switches, which is represented by the 16 bytes of information starting at address 0x8830. Similar flow diagrams can be developed for the other PIO devices. Switches Device x8810 0x8820 0x8830 0x8840 0x8850 LEDs Green Registers LEDs Red Registers Buttons Registers Switches Registers Seven Segment Registers SYSID Registers JTAG UART Regs Switches PIO Core Device Memory system.h. Figure 2. Switches (PIO) Device Mapping /* * onchip_memory_0/s1 configuration */ #define ONCHIP_MEMORY_0_S1_NAME "/dev/onchip_memory_0" #define ONCHIP_MEMORY_0_S1_TYPE "altera_avalon_onchip_memory2" #define ONCHIP_MEMORY_0_S1_BASE 0x #define ONCHIP_MEMORY_0_S1_SPAN #define ONCHIP_MEMORY_0_SIZE_MULTIPLE 1024 #define ONCHIP_MEMORY_0_SIZE_VALUE 32 #define ONCHIP_MEMORY_0_WRITEABLE 1 #define ONCHIP_MEMORY_0_GUI_RAM_BLOCK_TYPE "Automatic" #define ONCHIP_MEMORY_0_CONTENTS_INFO "QUARTUS_PROJECT_DIR/onchip_memory_0.hex SIMDIR/onchip_memory_0.dat " #define ONCHIP_MEMORY_0_INIT_CONTENTS_FILE "onchip_memory_0" #define ONCHIP_MEMORY_0_RAM_BLOCK_TYPE "M4K" #define ONCHIP_MEMORY_0_DUAL_PORT 0 #define ONCHIP_MEMORY_0_ALLOW_MRAM_SIM_CONTENTS_ONLY_FILE 0 #define ONCHIP_MEMORY_0_NON_DEFAULT_INIT_FILE_ENABLED 0. /* * led_green configuration */ #define LED_GREEN_NAME "/dev/led_green" #define LED_GREEN_TYPE "altera_avalon_pio" #define LED_GREEN_BASE 0x #define LED_GREEN_SPAN 16 #define LED_GREEN_HAS_IN 0 #define LED_GREEN_HAS_OUT 1 #define LED_GREEN_CAPTURE 0 #define LED_GREEN_EDGE_TYPE "NONE" #define LED_GREEN_HAS_TRI 0 #define LED_GREEN_IRQ_TYPE "NONE" #define LED_GREEN_DO_TEST_BENCH_WIRING 0 #define LED_GREEN_DRIVEN_SIM_VALUE 0x0000. Figure 3. Lab2 system.h excerpt Page 2 of 10

3 Altera Debug Client will automatically produce a system.h file each time that the.ptf is associated with a configuration. The system.h file represents information that C programs can use in order to access the devices for a particular system. Though the.h file cannot be used directly for assembly language programs, it provides insight into the devices connected to the system, and can be used to manually create a comparable file that is usable for assembly language. Figure 3 is an excerpt of the system.h file generated by Altera Debug Client for Lab2. (Note that Figure 1 was developed by investigating the contents of this system.h file.) Since we re working with assembly in Lab 2, we need to create the assembly language version of the system.h file. We will call this assembly language file the system.inc to distinguish it from the C language version. Figure 4 represents a template for the assembly language variant. As you can see, the C language variant of the.equ directive is #define macro. Note that the system.inc file in Figure 4 is only partially complete; you are to complete Lab2 system.inc before coming to lab. system.inc.equ MEMORY_START,0x0.equ MEMORY_SIZE,32768.equ STACK,MEMORY_START+MEMORY_SIZE.equ LEDS_GREEN,.equ LEDS_RED,0x????.equ BUTTONS,0x????.equ SWITCHES,0x????.equ SEVEN_SEG,0x????.equ SYSID,0x????.equ JTAG_UART,0x???? Figure 4. Lab2 system.inc Now let s take a closer look at the device registers for the green LEDs. The system.h definition, shown in Figure 5, provides information on the device name (highlighted in gray), type, address (highlighted in yellow), span (highlighted in blue), and other features. Figure 6 is a visual representation of the green LED registers, based on the information in the system.h. (Note that there are four registers, with 32-bits each.) /* * led_green configuration */ #define LED_GREEN_NAME "/dev/led_green" #define LED_GREEN_TYPE "altera_avalon_pio" #define LED_GREEN_BASE 0x #define LED_GREEN_SPAN 16 #define LED_GREEN_HAS_IN 0 #define LED_GREEN_HAS_OUT 1 #define LED_GREEN_CAPTURE 0 #define LED_GREEN_EDGE_TYPE "NONE" #define LED_GREEN_HAS_TRI 0 #define LED_GREEN_IRQ_TYPE "NONE" #define LED_GREEN_DO_TEST_BENCH_WIRING 0 #define LED_GREEN_DRIVEN_SIM_VALUE 0x0000 Figure 5. system.h definition for green LEDs LEDs Green Registers Figure 6. Visual representation of LED Green Registers (software perspective) Page 3 of 10

4 At this point we only know that the device takes 16 bytes of memory address space (LED_green_span), so the above offset representation is in bytes (+0, +4, +8, +12). However, additional information on the PIO device is available in the Quartus II Handbook (Q2H). The table below (from Q2H) shows us that, from a hardware perspective, the 16 bytes are really viewed as 4 words (or device registers). This register notation is shown in Figure 7. Taken from Quartus II Handbook. Refer to the PIO Core (Chaper 13) for more information. LEDs Green Registers +0 data +1 direction +2 interruptmask +3 edgecapture Figure 7. Register Notation (hardware perspective) Note, however, that programming instructions reference registers in terms of bytes, so the register offsets in Figure 7 must be re-interpreted as shown in Figure 6. Analyze the following instructions and how they will work. For example, the instruction ldwio r9,0(r8) will read from the data register at offset 0 and place the word from the device s data register into register r9. movia r8, ldwio r9,0(r8) # read from data register stwio r9,0(r8) # write to data register ldwio r10,4(r8) # read from direction register stwio r10,4(r8) # write to direction register ldwio r11,8(r8) # read from interruptmask register stwio r11,8(r8) # write to interruptmask register ldwio r12,12(r8) # read from edgecapture register stwio r12,12(r8) # write to edgecapture register (The appropriate usage of ldwio vs. stwio is dependent upon the type of PIO device and what result is required.) Further information about the configuration of a device can be found by scanning the lab2.ptf file, shown below. The MODULE definition for the led_green device reveals that the port has 9 active bits. Page 4 of 10

5 MODULE led_green { class = "altera_avalon_pio"; class_version = "6.0"; HDL_INFO { PORT_WIRING { PORT T in_port { direction = "input"; Is_Enabled = "0"; width = "9"; PORT out_port { direction = "output"; Is_Enabled = "1"; width = "9"; PORT bidir_port { direction = "inout"; Is_Enabled = "0"; width = "9"; SLAVE s1 { SYSTEM_BUILDER_INFO { WIZARD_SCRIPT_ARGUMENTS { Figure 8. Excerpt of lab2.ptf Since only 9 bits of the 32 are used, it is important to determine which are the ones being used. Figure 9 below represents a typical alignment of used and unused bits in the data register. LEDs Green Registers +0 data +1 direction +2 interruptmask +3 edgecapture LEDs Green Data Register UNUSED USED 8 0 Figure 9. Bit representation of green LEDs data register The following definitions (from the system.h file are also worth noting and comparing to other PIO devices to see how different features are represented. #define LED_GREEN_HAS_IN 0 #define LED_GREEN_HAS_OUT 1 #define LED_GREEN_CAPTURE 0 #define LED_GREEN_EDGE_TYPE "NONE" #define LED_GREEN_HAS_TRI 0 #define LED_GREEN_IRQ_TYPE "NONE" Page 5 of 10

6 Note that each PIO device utilizes 16 bytes as described in the system.h file, and each four bytes or word is considered a register. 2 Memory stack structure + examples Figure? shows a revised version of the memory address space to include the stack region of memory. The concept of a stack is to allow for dynamic reuse of memory. It allows us to utilize memory on a last-in-first-out basis. In the case of typical program/data organization, the stack starts at the end of writeable memory (actually the address after the end this address should never be written to), and grows in size by adjusting the stack pointer to lower memory addresses. In the figure below, the address for the stack pointer (sp) should be set to a value of (0x ) at initialization (which is the end of writeable memory in this case). At this point, the stack is considered empty. But as shown in this figure, the value for the sp is actually 0x7FE0. If 8 bytes of space is needed, then the stack pointer should be reduced by 8 and when no longer needed the sp should be increased by 8. As show the stack pointer register (sp) should contain the value 0x00007fe0 and reflects that 32 bytes of memory are allocated to the stack. When the stack is empty the value of sp should be 0x x0000 Memory Address Space Instr 1 Instr 2 Instr 3 0x0010 Program Memory Data 1 Data 2 Data 3 Data Memory Current sp Initial sp 0x7FD0 0x7FE0 0x7FF0 0x8000 Dynamic Stack Space Figure? Memory Address Space with Stack.equ MEMORY_START,0x0.equ MEMORY_SIZE,32768.equ STACK,MEMORY_START+MEMORY_SIZE Figure?. Excerpt of system.inc Figure? shows an excerpt of the system.inc file previously created. It reflects the starting location of memory as address 0x0 and the length of memory as (0x8000). The sum Page 6 of 10

7 of these two values should point just beyond the last accessible location of memory, in this case 0x The following assembly language instruction placed at the beginning of a program will initialize the stack pointer for subsequent usage. For compatibility the FP register is sometimes used in conjunction with the sp register. For our purposes we will not use the FP register until a later time. movia sp,stack To allocate and use memory on stack use the following instruction sequence addi sp, sp, -16 stw r16, 0(sp) stw r17, 4(sp) stw r4, 8(sp) stw ra,12(sp) To recover memory space and data stored on stack use the following instructions. ldw r16, 0(sp) ldw r17, 4(sp) ldw r4, 8(sp) ldw ra, 12(sp) addi sp, sp, 16 More details of stack usage will be given in class lecture. Before we go any further, let s create a template program that can be used for many future programs. The systems that we ve seen so far have the reset address set to the first address in memory, which (in the systems we ve seen) is 0x0. Another important address is the exception address. We will not cover the usage of this address until a later time, but the address that it is usually assigned is 0x20. In order to avoid any problems with this address, it is wise to relocate our program code to some location following the reset address and allow enough space for code. As a program is being assembled, a location counter is being maintained for each section (i.e..text and.data). In the template program shown below, for location 0x0 we place a to jump around the areas that we wish to preserve and to the location where our code does its work. Once the jump instruction is done, the location counter is updated to a value of 0x4. However, we can force the location counter to an absolute location with the usage of the.org directive. Since we know that it is possible to have exceptions and the processor will always jump to the exception address (0x20), we can place a eak instruction at this location to stop execution if an exception happens. By placing a.org 0x20 after the PROGRAM_START instruction, we can ensure that a eak is placed at address 0x20. Now, using the.org directive again we can reserve space for future code that will handle exceptions. It is unknown just how much space is needed, but it s handy to have the program Page 7 of 10

8 start location occur at a known location for debugging purposes. So, for now we choose address 0x100. With these considerations, we have a template for future programs that will work until such time as we need to handle interrupts. # file: template.s.include "system.inc".text.global _start _start: PROGRAM_START.org 0x20 eak.org 0x100 PROGRAM_START: movia sp,stack # optional if exception happens # optional this will stop exec # nice place to start program # Setup the stack pointer # main code goes here PROGRAM_END: eak PROGRAM_END.data.end 3 Register usage Before going much further, we need to consider the usage of the general purpose registers as they relate to function calls. We will define the following register group names. Group Usage Registers M-Regs Main routine registers r16-r23 R-Regs Return values from function r2-r3 A-Regs Arguments to function r4-r7 S-Regs Suoutine (function) registers r8-r15 Usage of these register conventions will cover any applications that only have function call depths 1 layer deep. More complex situations will be explained in lecture. Why are the.global directives needed in the Code 2 suoutines? Notice that the system.inc included is no longer needed in the top level program. One of the first steps in writing good code is the eaking up of the code into layers. By isolating the code involved with different hardware devices into separate modules, we can hide the details of working with a device inside of the module and provide the basis of hardware abstraction. In this example the details of which bits are associated with a specific switch or LED have not been hidden, but that can come later. Page 8 of 10

9 4 Suoutines You are to learn how suoutines work from Code 1 and Code 2, on the following page. Note that suoutine modules do not need all of the startup code as the main routine. Observe that values are passed to the suoutine via r4 and values are returned via r2. Now, try to send the data from switches to seven segment LEDs. Once you have done so, you need to create a new assembly suoutine to interface to the green LEDs and tie in to the main assembly program. Compare Code 1 and Code 2 on the following page. What are the main differences between Code 1 and Code 2? # file: lab2_dev1.s.include "system.inc".text.global _start _start:.org 0x100 PROGRAM_START: PROGRAM_START loop: call SWITCHES_Get mov r4,r2 call LEDR_Set loop_end: loop PROGRAM_END: eak PROGRAM_END SWITCHES_Get: movia r8,switches ldwio r2,0(r8) ret LEDR_Set: movia r8,leds_red stwio r4,0(r8) ret.end Code 1 # file: lab2_dev2.s.text.global _start _start:.org 0x100 PROGRAM_START: PROGRAM_START loop: call SWITCHES_Get mov r4,r2 call LEDR_Set loop_end: PROGRAM_END: eak.end Code 2 loop PROGRAM_END # file: SWITCHES.s.include "system.inc".text.global SWITCHES_Get SWITCHES_Get: movia r8,switches ldwio r2,0(r8) ret.end # file: LEDR.s.include "system.inc".text.global LEDR_Set LEDR_Set: movia r8,leds_red stwio r4,0(r8) ret.end Page 9 of 10

10 5 Macros Consider the assembly code below. This assembly programs sets up a 32-bit number using the movia instruction. The next two instructions shift the 32-bit register and mask with 0b1111 (same as 0xf). This gets 4-bit ( 6 ) out of the 32-bit number. movia r4,0x srli r2, r4, 8 andi r2, r2, 0b1111 The following assembly code sets up a 32-bit number using movia insruction again, then replace 6 with b. movia r2,0x movi r4,0xab andi r4, r4, 0b1111 slli r4, r4, 8 movi r3, 0b1111 slli r3, r3, 8 nor r3, zero, r3 and r2, r2, r3 or r2, r2, r4 Now copy the following assembly code into the template again. Run and observe. Now get and replace different bits. The macros needed to be inserted before the.text directive in the template..macro getbits rego, regi, offset, mask srli \rego, \regi, \offset andi \rego, \rego, \mask.endm.macro putbits rego, regi, regw, offset,mask andi \regi, \regi, \mask slli \regi,\regi,\offset movi \regw,\mask slli \regw, \regw, \offset nor \regw, zero, \regw and \rego,\rego,\regw or \rego,\rego,\regi.endm movia r4,0x getbits r2,r4,8,0xf movi r3,0xa putbits r4,r3,r5,8,0xf More example code can be found lab zip file. Page 10 of 10