Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 8
Текст из файла (страница 8)
It has an ARM CPU, memory, display and audio interfaces, multimedia accelerators and many more peripherals. I will now20HARDWARE FOR SYMBIAN OSfocus on these components, their integration and how they interact witheach other.2.2 System-on-Chip (SoC)SoCs are known by two other names: ASICs (Application-specific Integrated Circuits) for custom chips and ASSPs (Application-specific Semiconductor Parts) for commercial parts. All three terms are used impreciselyand interchangeably.
SoCs are designed and manufactured by all of themajor silicon companies: Texas Instruments have a product family calledOMAP and Intel have their XScale range of processors. Figure 2.2 showsa typical System-on-Chip design.Each sub-component within the SoC is an intellectual property (IP)block. The blocks are linked to interconnecting buses through industrystandard interfaces. The IP blocks can be licensed from many sources.The most well known IP licensing company is ARM Ltd, who licenseARM CPU cores.The example SoC is driven by an ARM 926 CPU for Symbian OS,and a DSP for multimedia codecs.
These two cores are both masterson the system bus, which is a high-speed, low-latency, 32-bit widebus, connected to the DRAM controller. The system bus and memorycontroller funnel all data accesses into main memory, so they must bedesigned for high bandwidth and low latency transfers to avoid starvingthe CPU and reducing its effective performance.ARMCPUDSPLCDDMAcontrollerSYSTEM BUSPICIRAMRTCSLOWMemorycontrollerUARTIRFASTI/OUSBAudioFigure 2.2 System-on-ChipIPCNANDSYSTEM-ON-CHIP (SoC)21The DMA engine and LCD controller are additional bus masters,both accessing memory through the same bus. The remaining peripheralblocks are known as bus slaves – they cannot access memory directly,and require their masters to feed them with commands and data.
Theslave blocks are cascaded off the two peripheral buses, one of which is arelatively fast bus for DMA devices, and the other is a slow bus for simplelow-bandwidth peripherals.Peripheral buses are connected to the system bus through bus bridges.These translate between the bus formats and compensate for any speeddifferences, necessary since peripheral buses normally run slower thanthe system bus. A good SoC design will pay attention to these bridges toensure that critical timed or high-bandwidth peripherals can be accessedquickly by the CPU.Further information about ARM SoCs can be found in the book, ARMSystem-on-Chip Architecture by Steve Furber.12.2.1 Physical memory mapThe buses and their connections determine the physical address mapof the chip – with 32-bit addressing there is 4 GB of addressable space.Symbian OS uses the CPU’s Memory Management Unit (MMU) to remapthe reality of the chip’s address space layout into a consistent virtualaddress space for the software.As an example, the 4 GB address space of the SoC might be dividedinto large regions by the system bus controller.
By only decoding the topthree address bits, it produces eight regions, each 512 MB in size:Address startAddress endContent0x000000000x1FFFFFFFROM Bank 0 (Boot Rom)0x200000000x3FFFFFFFROM Bank 10x400000000x5FFFFFFFDSP0x600000000x7FFFFFFFFast Peripheral Bus0x800000000x9FFFFFFFSlow Peripheral Bus0xA00000000xBFFFFFFFIRAM0xC00000000xDFFFFFFFDRAM Bank 00xE00000000xFFFFFFFFDRAM Bank 11ARM System-on-Chip Architecture, 2nd edn by Steve Furber.
Addison-WesleyProfessional.22HARDWARE FOR SYMBIAN OSThese large regions are then further sub-divided.With 32 MB of RAM installed in DRAM Bank 0, the remaining 480 MBof address space will contain aliases of the RAM contents if address bits25 to 28 are not decoded by the hardware, as is typical:0xC00000000xC1FFFFFF32 MB RAM0xC20000000xC3FFFFFF32 MB Alias 10xC40000000xC5FFFFFF32 MB Alias 2.........0xDE0000000xDFFFFFFF32 MB Alias FThe peripheral bus’s regions are sub-divided by their peripherals.
Thefast peripherals in the example SoC each have 64 KB of address for theirregister sets:0x600000000x6000FFFFNAND Interface0x600100000x6001FFFFIPC0x600200000x6002FFFFAudio0x600300000x6003FFFFUSB.........0x600x00000x7FFFFFFFEmpty SpaceIn practice, every ASSP will have a different physical address spaceand most of it will be unused or aliased. Reads and writes to unusedspace will produce a bus error.A good design will have a consistent memory map for all of the busmasters, removing the need for any physical address translation, andreducing the likelihood of errors.Normally the CPU will have access to every peripheral in the system,whereas the other masters will only have visibility of appropriate slaves.The LCD controller needs to pull frame data from memory, and the DMAengine will work between the fast peripherals and memory.The physical address map is used by the bootstrap code when configuring the MMU.
The DMA engine and the other bus masters will notcontain their own MMUs. They only understand physical addresses andSYSTEM-ON-CHIP (SoC)23software that programs these devices must translate virtual addresses backto their physical values before using them.2.2.2 Central Processing Unit (CPU)Symbian OS requires a 32-bit microprocessor that combines high performance with low power consumption. It must be little endian, with afull MMU, user and supervisor modes, interrupts and exceptions. ARMdesigns fit this bill exactly and when this book was written all Symbian OS phones had an ARM-based CPU, as did 80% of the world’smobile phones.To take these requirements in turn:High performance is a relative term for a battery-powered device.Symbian phones today have CPUs clocked between 100 and 200 MHz,which is more than an order of magnitude slower than an average 3 GHzPC – yet the power they consume is three orders of magnitude less.
Futureapplication demands will push the CPU speeds into the 300 to 400 MHzrange for peak performance.Low power consumption is a design requirement for all componentsin a Symbian OS phone. During the CPU design, engineering trade-offsare evaluated and features are added to produce the most power-efficientcore. Power saving comes from lean hardware design, the selectiveclocking of circuits and the addition of multiple low-power modes: Idle,Doze, Sleep, Deep Sleep and Off. I will discuss the mapping fromhardware into the software frameworks that Symbian OS provides forpower management in Chapter 15, Power Management.The MMU, with the user and supervisor modes the CPU provides,allow for the virtualization of the user memory.
EKA2 constructs a robustexecution environment for applications, each isolated from the otherswith its own protected memory space. Application code executes inuser mode with limitations and kernel code uses supervisor mode withfewer limitations, but even kernel code is still constrained by its virtualmemory map.
I describe the memory models that Symbian OS providesin Chapter 7, Memory Models.Exceptions are CPU events that change the instruction flow in thecore. Interrupt exceptions are generated by peripherals that are seekingattention. Software interrupts are used as a controlled switch from userto supervisor mode. The MMU will generate a data abort if code triesto access memory that is not mapped, and a prefetch abort if the CPUjumps to a code address that is not mapped. See Chapter 6, Interruptsand Exceptions, for more on interrupts and exceptions.2.2.3ARMARM have been designing RISC-based CPUs for over 20 years, and successfully licensing them to all of the world’s semiconductor manufacturers24HARDWARE FOR SYMBIAN OSfor inclusion into their own SoCs.
Intel has licensed version 5 of the ARMarchitecture to build the software-compatible XScale microprocessor.As ARM developed successive generations of CPUs, they have addednew instructions and features, and deprecated some rarely used oldfeatures. The ARM architectural version number, with some additionalletters, defines the feature set. It specifies the instruction set, the operationof the MMU, the caches and debugging.Symbian OS requires a CPU that supports ARM v5TE or greater.
ARMv5TE is the baseline instruction set for all Symbian software. To ensurecompatibility across multiple phones, application code should only usev5TE instructions. (The previous generation of EKA1 phones used theARM v4T architecture.)What does ARM v5TE actually mean? It is version 5 of the ARMarchitecture, with the THUMB instruction set and the Enhanced DSPinstructions. The definition of the ARM v5TE instruction set can be foundin the ARM Architecture Reference Manual.2ARM cores and SoCs that are currently compatible with Symbian OSphone projects include:CoreArchitectureSoCARM926v5TEPhilips Nexperia PNX4008ARM926v5TETexas Instruments OMAP 1623Xscalev5TEIntel XScale PXA260ARM1136v6Texas Instruments OMAP 2420THUMB was introduced in architecture v4T.
It is a 16-bit sub-set ofthe ARM instruction set, designed to resolve the common RISC issue ofpoor code density with instructions that are all 32 bits. By using a 16-bitencoding scheme, THUMB compiled code is approximately 70% of thesize of the ARM equivalent, but it needs 25% more instructions to do thesame task. THUMB and ARM code can inter-work on the same system,using the BLX instruction to switch mode.Most code in Symbian OS is compiled as THUMB, since the size of theROM is intimately linked to the cost of a Symbian OS phone. The kernel isbuilt for ARM for increased performance and it requires instructions whichare missing from THUMB, such as coprocessor instructions needed toaccess the MMU and CPU state control registers.
Application code can bebuilt for ARM by adding ALWAYS_BUILD_AS_ARM into the application’s2ARM Architecture Reference Manual, 2nd edn by David Seal. Addison-WesleyProfessional.SYSTEM-ON-CHIP (SoC)25MMP file. Symbian does this for algorithmic code, since, for example, theJPEG decoder runs 30% faster when compiled for ARM.The enhanced DSP instructions enable the more efficient implementation of 16-bit signal processing algorithms using an ARM CPU. Theseinstructions are not used in normal procedural code and have little impacton the execution of Symbian OS.2.2.4 Memory Management Unit (MMU)Symbian OS requires a full Memory Management Unit to co-ordinate andenforce the use of virtual memory within an open OS. I discuss the use ofthe MMU in Chapter 7, Memory Models.The MMU sits between the CPU and the system bus, translating virtualaddresses used by software into physical addresses understood by thehardware.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
