ECE 332L Microprocessors Lab ASM-2 Spring 2008 PIO Devices Page 1 of 10 C:\ece332\NiosII\Ch3_Assembly\ASM_2.doc 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. 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 32767 (0x7fff) is where the program and data reside. The five devices at addresses from 0x8800 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.) word 0x7FF0 0x0000 0x0010 0x0020 0x8000 Byte Address 0x8800 0x8850 Program & Data Memory Device Memory LEDs Green Registers SYSID Registers JTAG UART Regs 0x8810 LEDs Red Registers 0x8820 Buttons Registers 0x8830 Switches Registers 0x8840 Seven Segment RegistersECE 332L Microprocessors Lab ASM-2 Spring 2008 PIO Devices Page 2 of 10 C:\ece332\NiosII\Ch3_Assembly\ASM_2.doc 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. Figure 2. Switches (PIO) Device Mapping system.h . . . /* * 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 0x00000000 #define ONCHIP_MEMORY_0_S1_SPAN 32768 #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 1142980205 SIMDIR/onchip_memory_0.dat 1142980205 " #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 0x00008800 #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 Switches Device 0x8800 0x8850 Device Memory LEDs Green Registers SYSID Registers JTAG UART Regs 0x8810 LEDs Red Registers 0x8820 Buttons Registers 0x8830 Switches Registers 0x8840 Seven Segment Registers Switches PIO Core 0 1 2 17ECE 332L Microprocessors Lab ASM-2 Spring 2008 PIO Devices Page 3 of 10 C:\ece332\NiosII\Ch3_Assembly\ASM_2.doc 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,0x8800 .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 0x00008800 #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