Comparison of Exception Hardware & Software in ARM Cortex-M3 & Altera Nios II Embedded Processors - Report Example

?AR 845398 Digital Signal Processing Exceptions Hardware & Software 5 May Comparison of Exception Hardware & Software In ARM Cortex-M3 & Altera Nios II Embedded Processors This Report discusses the types of Exceptions and their hardware and software processing as they have been implemented in the ARM Cortex-M3 as compared with how they have been implemented in The Altera Nios II embedded processor. Description of ARM Cortex-M3 Processor The Error handling software procedures for the ARM Cortex-M3 are described within the appropriate Developer’s Instructions within the ARM Information Center. Available:- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203h/Cihbbbc1.html The ARM Cortex-M3 Embedded Signal Processing microprocessor handles it's exceptions in the same way as other standard-architecture microprocessors, in that, during the normal flow of execution through a program, the program counter (PC) increases sequentially through the executable instruction sequence, obeying the specified branches to nearby entry points or branches to subroutines. Exceptions occur when this normal flow of execution is diverted, to enable the processor to handle events generated by internal or external sources. Three good examples of such events are as follows. Externally generated interrupts - these are the most common function requiring the developer to write (and test!) their own exception handling routine, as such externally generated interrupts will be a part of the embedded signal processing application for which the ARM Cortex-M3 is being used. Standard exception handling code to prevent such access will have been incorporated into the Cortex-M3 standard 'system' software environment supplied by ARM, to deal with both:- An attempt by the processor to execute an undefined instruction, which most likely have been the results of a coding error made by the developer. Therefore, the developer will most certainly need to carefully code and test their software within the 'development' environment before applying it to the 'production' Cortex-M3 memory store. Accessing privileged (forbidden to 'developed' software) operating system instructions, that is to say, a developed application trying to access the privileged instruction set will generate an exception. When an exception occurs, program execution branches to an address in the vector table. The particular exception being taken determines the location in the vector table of the address used. However, unlike the other ARM microprocessors use for signal conditioning, the vector table of a Cortex-M3 processor contains addresses, not instructions. It will therefore be necessary for the developer using the Cortex-M3 in an embedded signal processing application to implement both the software and hardware procedures required to preserve the previous processor status when in exception handling mode, so that execution of the program that was running when the exception occurred can resume when the appropriate exception routine has completed. Part of the saving process is done automatically by hardware on Cortex-M3 processors. Because the CPSR and AAPCS corruptible registers are saved automatically, most exception handlers may be written in either C or C++, and a low level handler in assembly language is not usually required. The latter is important, as Assembly Language programming is very much a specialised skill, and skilled practitioners are very few and far between! The Cortex-M3 processor is based on the ARM v7-M architecture. However, It will only execute Thumb-2 instructions and does not support the standard ARM microprocessor instruction set. All exception handling code will therefore run in the 'Thumb' configuration. The recommended method for developing an exception handling routine for the ARM Cortex-M3 is as follows. The developer's top-level exception handling routine must save the processor status and any required registers on the stack. The developer must then proceed to write the exception handler in Thumb-2 code. This Thumb-2 code will need to perform the following basic function. Perform a Branch and exchange (BX) from an ARM code top-level handler to a Thumb-2 code exception handler routine, which must then use Thumb-2 code in order to return from the exception, because the Thumb-1 instruction set does not have the instructions required to restore the CPSR register from the SPSR. Description Of Exception Handling of Altera Nios II Processor The Exception Handling for the Altera Nios II Embedded Processor is also done chiefly through software, with some hardware configuration being required when one of the processors is being incorporated within a specific signal processing application. The material cited below has been taken from the Altera Nios II Embedded Processor. Software Developer’s Guide. Chapter 8 : Exception Handling. No Attribution. (Current Date). (Online). Available : http://www.altera.co.uk/literature/hb/nios2/n2sw_nii52006.pdf The Nios II processor works along similar lines as the ARM unit, as both are descended from the industry standard microprocessor architecture establishes in the 1970s. The Nios II processor provides the following types of exception, that must be catered for either by error handling routines developed by the team producing the signal processing application in question, or by standard routines provided by Altera to handle, for example, illegal instructions and attempts by the ‘developed’ application to access the Nios II’s privileged instruction set. Nios II exceptions fall into two general categories. Firstly, there are hardware interrupts. These are typically generated by other items of signal processing equipment incorporated into the specific application that wish to utilise the Nios II processor, usually to condition signals for transfer to other items of equipment. The Nios II deals with exceptions from two specific types of hardware interrupt, as opposed to the one type (external) dealt with by the ARM unit : the internal interrupt controller (IIC) and the external interrupt controller (EIC) interface. Nios II internal interrupt exception handling is implemented in classic Reduced Instruction Set Computing (RISC) fashion. All exception types, including hardware interrupts, are dispatched through a single top-level exception interface. This means that all exceptions (hardware and software) are handled by code residing at a single location, the exception address. The Nios II IIC is an industry-standard, non-vectored hardware interrupt controller. Upon receipt of an interrupt request, the IIC transfers control to the general exception address. The hardware indicates which interrupt level is has been generated, and hence will allow software developed by the user to mask individual interrupts where appropriate to the application or which a Nios II is being used. The EIC interface enables the Nios II processor to work with a separate external interrupt controller component, which may be a unit incorporated by the development team, or may be the vectored interrupt controller (VIC) supplied by Altera as standard, With an EIC, hardware interrupts are handled separately from software exceptions. Hardware interrupts have separate vectors and interfaces. Each interrupt can have its own handler, or handlers can be shared. Software exception handling is the same as with the IIC. The EIC interface provides extensive capabilities for developer-customised interrupt hardware. This allows for the design, connection and configuration of an interrupt controller specific for the signal processing application being developed. When an external hardware interrupt occurs, the Nios II processor transfers control to an individual vector address, which can be unique for each interrupt. The Nios II hardware abstraction layer registers all Interrupt service routines, sets up the interrupt vector table, and transfers control from the vector table to the team’s custom interrupt service routine Software exceptions, which fall into three categories: unimplemented instructions, software traps, and miscellaneous exceptions. Software exceptions within the Nios II processor are dealt with by the hardware abstraction layer software exception handling interface. Within the Nios II, software exceptions are accorded a lower priority than hardware interrupts, which, should this be likely to cause problems within the signal processing application being developed, would have to be catered for when the Nios II implementation was being designed. Software exception handling within the Nios II depends on options selected at the processor board configuration stage (as defined by Altera in their Nios II configuration documentation). should the team wishes to enable unimplemented instruction emulation, the software exception interface first checks whether an unimplemented instruction caused the exception. If so, it emulates the instruction. Otherwise, it handles traps and miscellaneous exceptions. This is not a facility provided by the ARM Cortex-M3 unit. The Nios II also offers the option to incorporate a specific unimplemented instruction exception handler, which will provide a more flexible way of handling such exceptions that the ARM unit. Altera state that such a facility will not normally be required, as the standard Nios II run-time software libraries incorporate standard Altera code to cater for unimplemented instructions. However, such a tool would be useful with the more complicated signal processing algorithms. Altera provide a specific warning that all Nios II exception handlers incorporated into the overall software ’build must never execute an unimplemented instruction. Also the Nios II software exception handling system does not support nested software exceptions, which must therefore be carefully avoided when the software is being developed and tested within the ‘source’ software development environment. Another software exception facility that must be catered for over and above the three basic categories cited above is the instruction-related exception, where an uncorrected coded instruction, which should have been dealt with at the development stage within the ‘source’ environment, causes what is generally known in software development circles as a run-time error, that is to say, the instruction format has passed the ‘compiler’ but nonetheless is incorrect, and may, for example, lead to the access of a privileged instruction. This is a more sophisticated facility than is provided by the ARM unit, and again will prove most useful when implementing more sophisticated signal processing applications. The Nios II deals with instruction-related software exceptions through the instruction-related exception handler, which is checked after the unimplemented instruction ’check’ has been made by the processor’s operating system. The instruction-related exception handler is a standard Altera utility, and must be specifically ‘built’ into the executable file to be run on the Nios II for this utility to be used. Otherwise, a softer exception caused by an incorrect instruction (or a ‘run-time error’) will be dealt with as a so-called ‘software trap. Good software practice dictates that such an instruction-related exception handler be incorporated, as it will provide much better diagnostics when debugging a Nios II software executable file - preferably in the ‘source’ environment, but also in the ‘target’ environment the problem is particularly obscure. The Nios II run-time environment provides for a choice between an instruction- related software exception handler and what Altera refer to as a software trap handler. It should be borne in mind that either one or the other is incorporated within the Nios II executable file, but not both. The software trap handler works in the following way. The Nios II hardware abstraction layer software exception interface will check for a trap instruction. If the exception has been caused by a trap instruction, the trap exception handler will execute a break instruction. The break instruction will transfer control to the hardware debug facility, which should have been incorporated into the Nios II configuration being used. If the exception has not been caused by a trap instruction, it is treated as a miscellaneous exception, which is handled in the following way. The miscellaneous exception handler chiefly comes into play as the default software exception handler, if neither of the two types cited above have been incorporated into the Nios II executable file being used. However, good software practice dictates that both of these specific software exception handlers must be incorporated into the Nios II executable file. The Nios II miscellaneous exception handler must be incorporated into the Nios II executable file to ‘catch’ the following two categories of miscellaneous exception, which will not be ‘caught’ by the previous types of software exception handler. Advanced exceptions, for the memory protection unit (MPU), or the memory management unit (MMU) are implemented in the Nios II processor core. To handle advanced and MPU exceptions, the Nios II Instruction-Related Exception Handler is required. To handle MMU exceptions, it will be necessary to implement a full-featured operating system, as well as the unimplemented instruction handler, as explained above. A peripheral is generating Spurious hardware interrupts generated by a peripheral, which is a manifestation of a serious hardware problem. A peripheral might generate spurious hardware interrupts if it de-asserts its interrupt output before an interrupt service routine has explicitly serviced it. Comparison of ARM Cortex-M3 With Altera Nios II Processors When considering the way both processors handle interrupts, the main difference is that the ARM unit uses hardware facilities (most likely embedded ‘firmware’ rather than logic gate configurations) as well as software supplied by ARM to deal with exceptions. Set against this, the Altera unit uses much more extensive software facilities to process exceptions, and also permit’s the development team to specify which Altera run-time library facilities may be incorporated into the specific software ‘build’ being applied to the embedded processor being used to ‘power’ the signal processing application under development. The ARM unit, on the other hand, does not appear to allow this, only allowing a ‘one size fit’s all’ set of ARM-supplied exception handling software to be incorporated into the development team’s ‘build’. Also, the ARM unit requires that development team members use ARM’s proprietary Thumb-2 software to implement the error handling procedures, and also may require Assembly language skills as well. In everyday practical industrial terms, this may impose extra cost and risk on the project, which may not be justified, particularly in terms of the effort that will be required to develop the software applications for the signal processing equipment being developed. Having examined the available facilities for both processors, it is clear, at least to the author, that the user-configurable interrupt handlers, run-time library options and wide-ranging internal and external interrupt handlers available with the Altera unit are greatly superior to the ARM unit, and therefore, given the choice, the author would use the Altera unit in preference to the ARM unit when designing and producing an embedded signal processing unit. A further ‘plus point’ for the Altera unit is that Nios II incorporates specific facilities to handle internally-generated interrupts along with the exceptions that they generate, which appear to be superior to the ARM unit. This makes the Altera unit a much ‘safer’ unit in an industrial (such as telecommunications) or military signal processing application, as the development team will have a much greater level of control over the internal interrupt handling, and consequent flexibility in the number and scope of the interrupt handling routines that may be incorporated into the software ‘build’. This makes the Altera unit a much ‘safer’ processor to use, as there is much less risk of an internal interrupt being generated that cannot be ‘handled’, hence causing a failure. Set against this is the significantly greater programming effort that will be required - which, if the author has interpreted the Altera documentation correctly, will be in either ‘C’ of ‘C++’, both of which are used by a large number of software practitioners within the industry - certainly much more than Assembler and ARM’s proprietary language. The decisive advantage of the Altera unit, form a practical industrial perspective, is the much more sophisticated external interrupt handling facilities offered by the Nios II. The ARM unit appears, judging from the ARM user guide, to offer only a basic facility for the handling of exceptions generated by external interrupts. On the other hand, as described above, the Altera unit has a very highly developed external interrupt controller supplied, which can be configured to handle a wide variety of exceptions caused by externally generated interrupts. This again, makes the Nios II unit much ‘safer’ in high-security embedded signal processing equipment. References ARM Information Center for the Cortex-M3 Processor. ARM Website No Attribution (Current Date) (Online) Available : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203h/Cihbbbc1.html Altera Nios II Embedded Processor Software Developer’s Guide Chapter 8 : Exception Handling No Attribution (Current Date) (Online) Available : http://www.altera.co.uk/literature/hb/nios2/n2sw_nii52006.pdf Read More