Basic ARM Modules and Systems

Transcription

1 Speaker: Kun-Bin Lee Directed by Prof. Chein-Wei Jen Department of Electronics Engineering National Chiao Tung University {kblee, Dec. 5, 2002

2 SoC Development Specification System Level Design Hardware Development High Level Algorithm Model C/C++/COSSAP/VCC/MATLAB Hardware/Software Partition N2C/VCC Communication Refinement N2C/Port-C/VCC Front End Back End Chip Hardware/Software Coverification N2C/Seamless/"Q/Bridge" RTOS WinCE/VxWorks API Device Driver Driveway Embedded Software Software Development 1/28

3 Lab Organization (Current Status in NCTU) Application Profiling Virtual Prototyping Embedded SW Authoring Digital IP Authoring RTOS µhal Driver Getting Start with ADS Working with AXD Software Quality Measurement ARM Integrator Environment µc/os-ii Rapid Prototyping 2/28

4 Semi- HW/SW Co-verification Apps + APIs + HALs + HW models HW models are less accurate (cycle approximate) Verify driver and HW/SW synchronization Spec. Tracer Profiler Page table ARM ISS Memory SW+HW modeling ARMulator/ Mentor CVE SW modeling + HW HDL Simulator Semi- HW/SW Coverification Reuse HAL & Verification Model Two teams: Design & Verification teams DMA Timer Interupter Controller JPEG HW/SW Coverification Mentor CVE (Apps+ APIs +HALs) + (System infra.+ DUT) Verify driver and HW/SW synchronization Both HW & SW can be timing accurate FPGA ARM Integrator/ CIC DB Tapeout Host Commander instead of ISS (host commands) + (System infra.+ DUT) SW is less accurate Verifiy HW and SW synchronization (polling, interrupt, memory-maped I/O) Transactions Read(,,,); Write(,,,); IDLE(,,);... do Read addr = 0xE8 data= 0x27 CLK control WR RDATA WDATA do Write addr = 0xFF data = 0x12 Transactions to signals DUV Signals 3/28

5 Consistent Models in Different Stages Application Programs, e.g., JPEG encoder BS-lh CVS BH-ls CVS HW/SW Coverification ISS commander ISS +BFM Os, Driver, API, HAL Application-specific IP, e.g., JPEG encoder, MPEG4 Shape Encoder Mmeory Organization, e.g., Cache, SRAM, ROM, SDRAM Basic System Peripherals, e.g., timer, interrupt controller, DMA Bus Infrastructure, e.g., Arbiter, Decoder, Bridge Standard I/O, e.g., UART, GPIO External Model, e.g., UART external model, off-chip memory Performance Moniter, e.g., Profiler, Stack Tracker Protocol Moniter, e.g., Bus protocol checker 4/28

6 Lab Module: Software Development Familiarize with ARM software development tools, ADS Project management Configuring the settings of build targets for your project Writing code for ARM-based platform design Software cost estimation The cost of a program includes Read Only (RO) data, Read Write (RW) data and Zero-Initialized (ZI) data Mixed instruction sets, ARM and Thumb interworking, is learned to balance the performance and code density of an application. Profiling utility can be used to estimate percentage time of each function in an application Memory configuration E.g., an embedded system might use fast, 32-bit RAM for performancecritical code, such as interrupt handlers and the stack, slower 16-bit RAM for application RW data, and ROM for normal application code Debug skills to be used to debug both software of processor and memory-mapped hardware design running at the target platform 5/28

7 Getting Start with ADS Existing files/library Creating a new (header) file using CodeWarrior's built-in editor Creating a new project from ARM project stationery Adding source files to the project Configuring the settings of build targets Building the project Debugging the project 6/28

8 Working with AXD Set breakpoints and watchpoints Locate, examine and change the contents of variables, registers and memory Using the command line interface to automate repetitive tasks (advanced user) 7/28

9 Software Quality Measurement Memory requirement of the program Profiling: build up a picture of the percentage of time spent in each procedure. Evaluate software performance prior to implement on hardware Writing efficient C for ARM cores ARM/Thumb interworking Coding styles 8/28

10 Application Code and Data Size armlink offers two options to provide the relevant information: -info sizes (sizes of all objects) -info totals (summary only) ============================================================ Image component sizes Code RO Data RW Data ZI Data Debug Object Totals Library Totals ============================================================= Code RO Data RW Data ZI Data Debug Grand Totals ============================================================= Total RO Size(Code + RO Data) ( 51.49kB) Total RW Size(RW Data + ZI Data) 300 ( 0.29kB) Total ROM Size(Code + RO Data + RW Data) ( 51.49kB) ============================================================= The size of code/data in an ELF image can be viewed using fromelf z a library can be viewed using armar sizes 9/28

11 ARM and Thumb Code Size Simple C routine if (x>=0) return x; else return -x; The equivalent ARM assembly Iabs CMP r0,#0 ;Compare r0 to zero RSBLT r0,r0,#0 ;If r0<0 (less than=lt) then do r0= 0-r0 MOV pc,lr ;Move Link Register to PC (Return) The equivalent Thumb assembly CODE16 ;Directive specifying 16-bit (Thumb) instructions labs CMP r0,#0 ;Compare r0 to zero BGE return ;Jump to Return if greater or ;equal to zero NEG r0,r0 ;If not, negate r0 return MOV pc,lr ;Move Link register to PC (Return) 10/28

12 Memory Map and Size Considerations The linker calculates the ROM and RAM requirements for code and data as follows: ROM: Code size + RO data + RW data RAM: RW Data + ZI data. You may wish to copy code from ROM into faster RAM, which will also increase the RAM requirements Placing the stacks in zerowait state, 32-bit memory onchip will significantly improve over -8 or 16- bit off-chip memory RAM ROM Default memory map 11/28

13 ARM Profiler About Profiling: Profiler samples the program counter and computes the percentage time of each function spent. Flat Profiling: If only pc-sampling info. is present. It can only display the time percentage spent in each function excluding the time in its children. Flat profiling accumulates limited information without altering the image Call graph Profiling: If function call count info. is present. It can show the approximations of the time spent in each function including the time in its children. Extra code is added to the image Limitations: Profiling is NOT available for code in ROM, or for scatter loaded images. No data is gathered for programs that are too small. 12/28

14 Profiler Command-line Options The command syntax is as follows: armprof [-parent -noparent] [-child -nochild] [-sort options] prf_file Sample Output Name cum% self% desc% calls main 17.69% 60.06% 1 insert_sort 77.76% 17.69% 60.06% 1 strcmp 60.06% 0.00% qs_string_compare 3.21% 0.00% shell_sort 3.46% 0.00% insert_sort 60.06% 0.00% strcmp 66.75% 66.75% 0.00% cumulative self descendants calls 13/28

15 In ARM Macrocell JTAG and non-amba signals Inst. & data EmbeddedICE & JTAG ARM Core Inst. & data cache Virtual Address MMU CP15 Write Buffer Physical Address AMBA Interface AMBA Address AMBA Data 14/28

16 Cycle Types, Von Neuman Cores N-cycles S-cycles I-cycles C-cycles Total Non-sequential cycle. The ARM core requests a transfer to or from an address which is unrelated to the address used in the preceding cycle. Sequential cycle. The ARM core requests a transfer to or from an address which is either the same, or one word or one-half-word greater than the preceding address. Internal cycle. The ARM core does not require a transfer, as it is performing an internal function, and no useful prefetching can be performed at the same time. Coprocessor register transfer cycle. The ARM core wishes to use the data bus to communicate with a coprocessor, but does not require any action by the memory system. The sum of the S-Cycles, N-Cycles, I-Cycles and C-Cycles. 15/28

17 Map File If no map file is specified: ARMulator will use a 4GB bank of ideal memory, i.e., no wait states. The map file defines regions of memory, and, for each region: The address range to which that region is mapped. The data bus width (in bytes). The access times for the memory region (in ns) armsd.map typically contains something like: ROM 2 R 150/ / RAM 4 RW 100/65 100/65 Columns are (left to right): start address (in hex) access type (read-only or read/write) length (in hex) read timing in ns (NON-Seq / Seq) name writing timing in ns (NON-Seq / Seq) width (1, 2, or 4 bytes) 16/28

18 Configure for Target System 17/28 ARMulator startup Message Cached core additional statistics

19 Cached with different clock domains 18/28 Dhrystone Analysis TCM on ARM966E-S

20 Lab Module: ARM Integrator Environment ARM Integrator: A set of pre-built, well-defined, wellverified hardware and software components Standalone/Semishoting Resource access uhal or memory mapped device Polling and interrupt Memory usage Performance & constraint of different types of memory (SSRAM, SDRAM, and Flash, and the cache) Data alignment and data layout (in which type of memory) Available data bus and memory bandwidth Peripherals Detail the timers and interrupt controller 19/28

21 Lab Module: Virtual Prototyping Features Trade-off by modifying system parameters & checking results Develop & test device drivers Test the correctness of compiler generated code Visualize behavior of system and peripherals Test the correctness of application algorithms Memory Model USB Model Codec Model BLC Model CPU ISS CPU Debugger (GUI) UART Model Intr cntrl Model Parallel I/O Model Timer Model CPU ICE Rapid Prototype 20/28

22 Building Soft Prototype Requirement Instruction Set Simulator (ISS) with a capability to interface C models of the peripherals C models of the peripherals Processor debugger Limitations Limited capacity Limited speed Accuracy of models synchronization Study ISS Features Check for C Model Interface Support ISS Is Interface Support Yes Create/Modify C Models No Compile Run the Application Debug Errors? No Final Software No Soft Prototype Write/Modify the Application Software Yes 21/28

23 In This Lab Procedure to add the hardware models to ARMulator Verify the hardware models Example hardware models in this lab Memory-mapped IP: timer, MAC Coprocessor: MAC configure the ARMulator to integrate desired model(s) Write your model in C language Build the new model By creating *.dll file Write your *.dsc file Modify default.ami Modify peripherals.ami 22/28

24 Lab Module: RTOS Concept of RTOS Features of µc/os-ii Model ARMulator as ARM Integrator platform Port µc/os-ii to ARMulator with µhal Port applications to µc/os-ii Partition original program into tasks Necessary coding changes Insert system calls into tasks Create tasks and resources in main function Driver authoring 23/28

25 Lab Module: Digital IP Authoring HW/SW partition under the Performance analysis of profiling Architecture exploration Power Attached to a well-defined Area on-chip bus HW/SW synchronization Robust design Coding style: Reuse Methodology Manual, FPGA Reuse Field Guide Verification coverage FPGA proven Test Clocking Flexibility 24/28

26 Coverage-Driven Verification Functional Coverage Determines if all the functionality was tested Metrics are user-defined (explicit) Strengths Complete expressiveness Cross-correlation, and multicycle scenarios Objective measure of progress in regards to test plan Identifies new holes by crossing existing items Weaknesses Only as good as the coverage model Manual effort is required to implement the metrics Code Coverage Determines if all the implementation was tested Metrics are defined by the source code (implicit) Line/block, events, toggle Strengths Reveals untested logic Reveals holes in functional test plan No manual effort is required to implement the metrics Weakness No cross correlations No multi-cycle scenarios Manual effort is required to interpret results 25/28

27 In the Digital IP Authoring Lab IP authoring Algorithm and architecture exploration in IP core design RTL coding guidelines for IP authoring AMBA-compliant IP Hardware/software coordination Verification Identifies bugs or non-synthesizable constructs before emulation. Identify the areas of a design that have yet to be fully simulated. Identifies the smallest set of tests that will meet verification goals AMBA AHB Property Checking 26/28

28 Lab Module: Rapid Prototyping Rapid prototyping Already ready hardware resource in LM Procedure to configure the hardware design to LM and software to CM 27/28

29 Summary Assignments are finished Code development Debugging and evaluation Core peripherals Real-time OS On-chip bus Future work Seamlessly combine all lab modules (includes NTU and NCKU) Organize the material such that the lab modules can be taught in a great many ways Toward platform-based SoC design lab 28/28