Overview of Development Tools for the ARM Cortex -A8 Processor George Milne March 2006

Transcription

1 Overview of Development Tools for the ARM Cortex -A8 Processor George Milne March 2006 Introduction ARM launched the Cortex-A8 CPU in October 2005, for consumer products requiring power efficient multi-media computing such as next generation cellular handsets and entertainment products. The CPU (known as Tiger while under development) was launched with four public lead semiconductor partners - Freescale, MEI (Matsushita), Samsung and TI all of whom develop high-integration SoC devices for leading consumer OEMs. Extensive new technology was introduced in the Cortex-A8 processor [1] and this paper discusses some of the impact on software development tool chains which will be used for SoC validation through to application s/w development, on early models through to real silicon. Cortex-A8 CPU Overview & Implications of Features The Cortex-A8 processor key features are: Highest performance, most efficient ARM processor o Target is GHZ ; 5 DMIPS/mW on 90nm process Semi-custom design methodology ARMv7 architecture which includes: o ARMv6 [2] (as deployed in the ARM11 family) which in turn includes TrustZone Thumb -2 MMU enhancements o NEON Multimedia Architecture o Jazelle RCT Execution Environment Architecture Integrated CoreSight DAP (for debug) Integrated CoreSight ETM (for trace) An alternative view is that the CPU is: Reaching new levels of both power-efficiency as well as compute performance First collated implementation of all recent new ARM technology creating full-feature-demand on tools First implementation of ARMv7 architecture including the multi-media NEON technology Offering flexible multi-media CODEC support, especially where standards may change 1 of 9

2 Of particular note, from a tools perspective: Compilation tools need to align with the enhanced focus on performance NEON, a SIMD coprocessor, results in assembly language extensions and a requirement for new compilation support (such as vectorising compiler) Debug is CoreSight-exclusive (DAP/Debug-bus based rather than TAP/scan-chain based), and while this requires changes to the debug tools (especially to JTAG runcontrol hardware) it also enables a range of new tool features. And if you, the reader, have reached this point wondering what all the ARM-originated names and phrases actually mean, then continue reading the next section. If however you are already well aware, for example, of what ARMv6/ARMv7 means or of Thumb-2 and CoreSight, then please skip the next section. ARM Technology Summary The ARM Architecture [2,3] is the instruction set and how it is executed (and includes CPU, Memory and System, Vector Floating-point, and Debug architectures). A version of the ARM Architecture is defined and then implemented in one or more CPUs, for example the ARM11 family implements version 6 of the architecture ARMv6. To provide some indication of specific features/improvements, ARMv6 architecture includes: Improved interrupt latency performance (up to 70% reduction in time to start handler execution) More efficient data-handling (for example for network products) by supporting unaligned data accesses, and mixed-endian data Fine grain access control for the memory protection unit Thumb-2 instruction set (more below) TrustZone denotes the security extensions, which were first implemented in the ARM1176-JZ-S processor. The TrustZone extensions in effect create two CPUs which execute contiguously in time. One CPU and its memory can hide from the debug tools if appropriate input signals are set this is the secure-world. So, considering a time line, there will be a period where debug tools can set breakpoints and single step then when code enters the secure-world (and the inputs are set), the debug tools have no control and the developer has no visibility until the software returns from the secureworld to the non-secure world. Thumb-2 is an evolution of the 16-bit Thumb instruction set and is a blend of both 16 and 32-bit instructions. It provides Thumb level of code density with 32-bit ARM levels of performance. Thumb-2 retains binary compatibility with the older instruction sets. 2 of 9

3 Jazelle is ARM s JAVA acceleration technology which was initially introduced as a. Software-only solution for ARM7-family, ARM920/922, ARM946, StrongARM, XScale CPUs and b. Software/hardware combined solution the hardware part first appearing in the ARM926EJ-S and ARM7EJ-S [4] CPUs, and subsequently in the ARM1136J-S and ARM1176JZ-S [5] processors. The hardware part is now known as Jazelle DBX for Direct Bytecode execution which better describes the hardware operation, and explains how the acceleration is achieved. Another way of regarding this is that DBX is the 3 rd instruction set i.e. 32-bit ARM, 16-bit Thumb and 8-bit DBX. While Jazelle DBX accelerates JAVA byte-code interpreters, Jazelle RCT for Runtime Compilation Target is a complementary technology to accelerate JIT (Just In-Time) or AOT (Ahead Of Time) JAVA compiler code. Jazelle RCT is essentially a set of new 16-bit instructions - added to the Thumb-2 instruction set (also known as Thumb-2EE for Execution Environment) CoreSight refers to the memory-mapped debug architecture introduced in ARMv7 architecture processors, and is designed to replace conventional debug access and control (i.e. JTAG port/scan-chain/test Access Port), especially in high-integration multi-core SoC devices. The evolution of the ARM debug architecture, culminating in CoreSight, is further described later in the paper. Core Tools The ARM code generation tools, supplied within the RealView products, is living, evolving technology and aligning with the Cortex-A8 processor results in continuing emphasis on execution performance. The chart below shows compiler improvement version-on-version, on a relative basis. It can be seen that over these releases of the ARM compiler, there has been an approximate 30 to 40 per cent performance improvement. This evolution is an important factor to note for those developers who standardise on a specific version of compiler. They are advised to plan a migration strategy to future versions of the compiler, as the performance, or code size gains can be significant. GNU & Linux Notes Thumb-2 is already supported by GNU Binutils (assembler/disassembler) and GCC (in late 2005) ARM Linux has already been ported in the lab to the Cortex-A8 processor and will be made available to the open source community in 1H of 9

4 40% 30% Improving Compiler Performance Total gain: % = Delivered on ARM9E = Targets for ARM9E Extra Cortex-A8 Optimisations +15% u-arch Harder 10% 20% Extra ARM11 Optimisations Easy 30% 10% Generic Optimisations 25% generic 0% future Core Tools support of NEON Multi-media Architecture The demand for efficient implementation of signal-processing-type functions, such as DCT (discrete cosine transfers - which are widely used in MPEG4, MP3, and other video/audio algorithms) lead to the development of NEON multi-media architecture. I ARM D NEON The Cortex-A8 processor includes a NEON data processing engine which is attached at the end of the main processor pipeline. This results in a simple programmer s model, with a single instruction stream, single view of memory, and single debug/trace view. The ARM handles the control, the NEON unit handles the data. Debug/Trace (The NEON unit in Cortex-A8 processor handles both the NEON media instructions as well as the VFPv3 instructions NEON instructions are based on Packed SIMD processing. Registers are considered as vectors of elements of the same data types. Instructions perform the same operation in all lanes. This is shown diagrammatically below. 4 of 9

5 Source Registers Dn Elements Dm Operation Dd Lane Destination Register Impact on Code Generation Tools The specific enhancements required are: Assembly language extensions to support the NEON instructions Compiler enhancements to support NEON The assembly language extensions will be introduced in two parts initially the base notation (in Q1 06) followed by the programmer s notation which provides manipulation extensions for data types. Compiler support in the ARM tools will also be introduced in two parts initial support will be through intrinsics i.e. built-in C functions, where the software developer is required to tell the compiler which SIMD instructions to use. Later, vectorising compiler support will be introduced. (See above diagram for explanation of vectors). GNU Tools & NEON NEON (and VFPv3) support is planned for Q for GNU Binutils and Q for GCC. Target A new CPU will not appear in silicon for many months after delivery of the design database to the semiconductor vendor. In order to develop the tools, validate the debugger, tune the compiler, a variety of pre-silicon targets need to be made available. In addition, lead developers will use early or beta versions the tools to start device driver development, OS porting and other software work (i.e. ahead of silicon availability), and will also use models are their targets. 5 of 9

6 Cortex-A8 Model The initial Cortex-A8 processor model will be a cycle approximate (CX) simulation model, running at approximately 2MIPS. The model will be made available in the following variants: 1. Instruction Set Simulation Model (ISSM) complete with two timers, two UARTs and an interrupt controller, sufficient to boot an OS 2. Cycle Approximate System Model (CXSM) similar to the above but extendable (with additional peripherals/memory) and with larger set of peripherals including three UARTs, two timers, interrupt controller, colour LCD controller and keyboard & mouse input. An ISSM is normally used by the software developer using typically the ARM RealView Development Suite, a conventional assembler/linker/debugger tool chain. A relatively new type of development environment is the ESL (Electronic System Level) tool where the typical user is a SoC architect. This environment is used to describe/model the on-chip configurations and through bus monitoring, profiling and other tools, the performance/operation can be assessed. An example graphical dragand-drop display is shown in the accompanying figure Cortex-A8 FPGA Image A traditional pre-silicon target is the soft macrocell model - an FPGA bit image which is then programmed into FPGA boards. The Cortex-A8 processor is a sophisticated design and when the FPGA image is built and partitioned, requires five (standard ARM) logic tiles. The complete development board stack comprises: Five logic tiles.. Interface module.. Integrator/CP baseboard The FPGA image is programmed using a standard ARM JTAG run control unit (Multi-ICE or RealView ICE). This provides a Cortex-A8 processor running at 2.8 MHz and debuggable using a JTAG port. Note: Image availability is restricted to lead developers only 6 of 9

7 Cortex-A8 Test Chip A test chip, operating at a target frequency of 800MHz, is planned for late 2006 with board availability in Q3 07. The test chip will be mounted on a core tile, which in turn will be plugged onto the Emulation Baseboard. The test chip will include a 32kB L1 cache, 256kB L2 cache, ETM and one AXI interface. These boards will be standard products and available to all developers. Debug ARM debug has evolved over time into a formal architecture and the Cortex-A8 processor implements the ARMv7 debug architecture. To understand the increasing sophistication of SoC debug (and the pressure on the debug tools to keep-up), it is useful to briefly summarise the evolution of the ARM debug architecture. Stopped Clock Monitor Debug CoreSight Interface ETM Trace ARM 7 DI ARM 9 ARM 9 E ARM 10 v 6 Debug v 6. 1 Debug ( v6 Z) ARMv 7 Debug ( optional) Instruction Transfer Register Coprocessor Interface The Stopped Clock bubble refers to Halt Mode when the CPU enters debug state, the clock is stopped and the core is isolated from the system allowing access to the internal state of the core without affecting the rest of the system Introduced in the ARM9E and carried forward to the Cortex-A8 processor is monitor mode. When a breakpoint is hit, an exception generated and a debug monitor program, such as Real Monitor, can communicate to the debugger via the core s debug comms channel and this allows other high priority interrupt requests to continue to be serviced. The RealView Debugger Running System Debug feature uses this mode. 7 of 9

8 Introduced for the ARM10 is control of the debug unit through coprocessor CP14. The core is set into the appropriate debug state using CP14 s Debug and Status Control register which remains accessible on the TAP / scan chain. Also introduced at this time is the Instruction Transfer Register to allow the debug tool to send instructions to the CPU when the CPU is in debug state, it will only execute instructions received via this register New for ARMv7 CPUs such as the Cortex-A8 processor is the CoreSight interface where the TAP/scan chain structure is replaced by a DAP (debug access port) and a Debug Bus. Cortex-A8 Debug Requirements Summary The collated requirements on debug tools are significant and include: Disassembly of new instructions o Including Thumb2, and Unified Assembly Language o Including NEON (SIMD) instructions; 64- and 128-bit registers o Including Jazelle RCT instructions (not JIT compiled code) TrustZone support o GUI Windows to show Secure or Normal worlds o Simultaneous view of Secure-world and Normal-world memory o View breakpoint (in Secure or Normal world) o Authentication dependent on SoC hardware assumed proprietary ETMv3.3 Trace - Instructions only (ETM limitation) o Trace-stream decompressor update Target Connection Support i.e. o Model o Target h/w via JTAG Run Control Unit Memory-mapped debug (i.e. CoreSight architecture) support o Topology awareness, especially for multi-core SoC o CoreSight components e.g. DAP access, configuration via debug bus Summary This paper has attempted to provide a cross-tool summary which leads to both technical and commercial/availability considerations for developer. Code Generation tools evolution (in terms of improving performance, improving code density) must continue while new SIMD instructions and vectorising compiler technology is introduced. New targets (simulation models, FPGA images, test chips, boards) are all required for diverse reasons to assist in the development of the development tools themselves e.g. for ASIC validation, through to full-speed applications porting/tuning/new development. Debug tools must support new versions of traditional debug IP (such as the ETM) but connected within a new memory-mapped architecture (CoreSight). Many developers pick and choose their tools having different suppliers for their compilation tools, models and modelling environment, and debug tools. The early availability of interoperable tools is the normal challenge faced when any new CPU or SoC device is introduced. However, as the Cortex-A8 processor, for the first time in any one CPU implementation, includes not only the different ARMv6 technologies (such as TrustZone and Thumb-2) but also new ARMv7 technology (such as NEON and CoreSight), the developer should confirm feature availability across the different tool versions from his suppliers. 8 of 9

9 It is also the author s personal opinion that the Cortex-A8 processor will become an exceptionally popular CPU selection for designers of high-integration SoC for consumer applications. This will provide tools vendors with challenge of how to maximise the commercial opportunities! References [1] ARM White Paper, Architecture and Implementation of the ARM Cortex-A8 Microprocessor, October 2005, [2] ARM White Paper, The ARM Architecture Version 6, January 2002, [3] David Seal, ARM Architecture Reference Manual, Addison-Wesley, ISBN [4] ARM DDI 0214B, ARM7EJ-S Technical Reference Manual, December 2001, [5] ARM DDI 0333C, ARM1176JZ-S r0p1 Technical Reference Manual, August 2005, 9 of 9