This is i960.info, produced by makeinfo version 4.3 from i960.texi. INFO-DIR-SECTION RTEMS Target Supplements START-INFO-DIR-ENTRY * RTEMS Intel i960 Applications Supplement: (i960). END-INFO-DIR-ENTRY  File: i960.info, Node: Preface, Next: CPU Model Dependent Features, Prev: Top, Up: Top Preface ******* The Real Time Executive for Multiprocessor Systems (RTEMS) is designed to be portable across multiple processor architectures. However, the nature of real-time systems makes it essential that the application designer understand certain processor dependent implementation details. These processor dependencies include calling convention, board support package issues, interrupt processing, exact RTEMS memory requirements, performance data, header files, and the assembly language interface to the executive. For information on the i960CA and the i960 processor family in general, refer to the following documents: * `80960CA User's Manual, Intel, Order No. 270710'. * `32-Bit Embedded Controller Handbook, Intel, Order No. 270647'. * `Glenford J. Meyers and David L. Budde. The 80960 Microprocessor Architecture. Wiley. New York. 1988'. It is highly recommended that the i960CA RTEMS application developer obtain and become familiar with Intel's i960CA User's Manual.  File: i960.info, Node: CPU Model Dependent Features, Next: CPU Model Dependent Features Introduction, Prev: Preface, Up: Top CPU Model Dependent Features **************************** * Menu: * CPU Model Dependent Features Introduction:: * CPU Model Dependent Features CPU Model Name:: * CPU Model Dependent Features Floating Point Unit::  File: i960.info, Node: CPU Model Dependent Features Introduction, Next: CPU Model Dependent Features CPU Model Name, Prev: CPU Model Dependent Features, Up: CPU Model Dependent Features Introduction ============ Microprocessors are generally classified into families with a variety of CPU models or implementations within that family. Within a processor family, there is a high level of binary compatibility. This family may be based on either an architectural specification or on maintaining compatibility with a popular processor. Recent microprocessor families such as the SPARC or PA-RISC are based on an architectural specification which is independent or any particular CPU model or implementation. Older families such as the M68xxx and the iX86 evolved as the manufacturer strived to produce higher performance processor models which maintained binary compatibility with older models. RTEMS takes advantage of the similarity of the various models within a CPU family. Although the models do vary in significant ways, the high level of compatibility makes it possible to share the bulk of the CPU dependent executive code across the entire family. Each processor family supported by RTEMS has a list of features which vary between CPU models within a family. For example, the most common model dependent feature regardless of CPU family is the presence or absence of a floating point unit or coprocessor. When defining the list of features present on a particular CPU model, one simply notes that floating point hardware is or is not present and defines a single constant appropriately. Conditional compilation is utilized to include the appropriate source code for this CPU model's feature set. It is important to note that this means that RTEMS is thus compiled using the appropriate feature set and compilation flags optimal for this CPU model used. The alternative would be to generate a binary which would execute on all family members using only the features which were always present. This chapter presents the set of features which vary across i960 implementations and are of importance to RTEMS. The set of CPU model feature macros are defined in the file c/src/exec/score/cpu/i960/i960.h based upon the particular CPU model defined on the compilation command line.  File: i960.info, Node: CPU Model Dependent Features CPU Model Name, Next: CPU Model Dependent Features Floating Point Unit, Prev: CPU Model Dependent Features Introduction, Up: CPU Model Dependent Features CPU Model Name ============== The macro CPU_MODEL_NAME is a string which designates the name of this CPU model. For example, for the Intel i960CA, this macro is set to the string "i960ca".  File: i960.info, Node: CPU Model Dependent Features Floating Point Unit, Next: Calling Conventions, Prev: CPU Model Dependent Features CPU Model Name, Up: CPU Model Dependent Features Floating Point Unit =================== The macro I960_HAS_FPU is set to 1 to indicate that this CPU model has a hardware floating point unit and 0 otherwise.  File: i960.info, Node: Calling Conventions, Next: Calling Conventions Introduction, Prev: CPU Model Dependent Features Floating Point Unit, Up: Top Calling Conventions ******************* * Menu: * Calling Conventions Introduction:: * Calling Conventions Processor Background:: * Calling Conventions Calling Mechanism:: * Calling Conventions Register Usage:: * Calling Conventions Parameter Passing:: * Calling Conventions User-Provided Routines:: * Calling Conventions Leaf Procedures::  File: i960.info, Node: Calling Conventions Introduction, Next: Calling Conventions Processor Background, Prev: Calling Conventions, Up: Calling Conventions Introduction ============ Each high-level language compiler generates subroutine entry and exit code based upon a set of rules known as the compiler's calling convention. These rules address the following issues: * register preservation and usage * parameter passing * call and return mechanism A compiler's calling convention is of importance when interfacing to subroutines written in another language either assembly or high-level. Even when the high-level language and target processor are the same, different compilers may use different calling conventions. As a result, calling conventions are both processor and compiler dependent.  File: i960.info, Node: Calling Conventions Processor Background, Next: Calling Conventions Calling Mechanism, Prev: Calling Conventions Introduction, Up: Calling Conventions Processor Background ==================== All members of the i960 architecture family support two methods for performing procedure calls: a RISC-style branch-and-link and an integrated call and return mechanism. On a branch-and-link, the processor branches to the invoked procedure and saves the return address in a register, `G14'. Typically, the invoked procedure will not invoke another procedure and is referred to as a leaf procedure. Many high-level language compilers for the i960 family recognize leaf procedures and automatically optimize them to utilize the branch-and-link mechanism. Branch-and-link procedures are invoked using the `bal' and `balx' instructions and return control via the `bx' instruction. By convention, `G14' is zero when not in a leaf procedure. It is the responsibility of the leaf procedure to clear `G14' before returning. The integrated call and return mechanism also branches to the invoked procedure and saves the return address as did the branch and link mechanism. However, the important difference is that the `call', `callx', and `calls' instructions save the local register set (`R0' through `R15') before transferring control to the invoked procedure. The `ret' instruction automatically restores the previous local register set. The i960CA provides a register cache which can be configured to retain the last five to sixteen recent register caches. When the register cache is full, the oldest cached register set is written to the stack.  File: i960.info, Node: Calling Conventions Calling Mechanism, Next: Calling Conventions Register Usage, Prev: Calling Conventions Processor Background, Up: Calling Conventions Calling Mechanism ================= All RTEMS directives are invoked using either a `call' or `callx' instruction and return to the user via the `ret' instruction.  File: i960.info, Node: Calling Conventions Register Usage, Next: Calling Conventions Parameter Passing, Prev: Calling Conventions Calling Mechanism, Up: Calling Conventions Register Usage ============== As discussed above, the `call' and `callx' instructions automatically save the current contents of the local register set (`R0' through `R15'). The contents of the local registers will be restored as part of returning to the application. The contents of global registers `G0' through `G7' are not preserved by RTEMS directives.  File: i960.info, Node: Calling Conventions Parameter Passing, Next: Calling Conventions User-Provided Routines, Prev: Calling Conventions Register Usage, Up: Calling Conventions Parameter Passing ================= RTEMS uses the standard i960 family C parameter passing mechanism in which `G0' contains the first parameter, `G1' the second, and so on for the remaining parameters. No RTEMS directive requires more than six parameters.  File: i960.info, Node: Calling Conventions User-Provided Routines, Next: Calling Conventions Leaf Procedures, Prev: Calling Conventions Parameter Passing, Up: Calling Conventions User-Provided Routines ====================== All user-provided routines invoked by RTEMS, such as user extensions, device drivers, and MPCI routines, must also adhere to these calling conventions.  File: i960.info, Node: Calling Conventions Leaf Procedures, Next: Memory Model, Prev: Calling Conventions User-Provided Routines, Up: Calling Conventions Leaf Procedures =============== RTEMS utilizes leaf procedures internally to improve performance. This improves execution speed as well as reducing stack usage and the number of register sets which must be cached.  File: i960.info, Node: Memory Model, Next: Memory Model Introduction, Prev: Calling Conventions Leaf Procedures, Up: Top Memory Model ************ * Menu: * Memory Model Introduction:: * Memory Model Flat Memory Model::  File: i960.info, Node: Memory Model Introduction, Next: Memory Model Flat Memory Model, Prev: Memory Model, Up: Memory Model Introduction ============ A processor may support any combination of memory models ranging from pure physical addressing to complex demand paged virtual memory systems. RTEMS supports a flat memory model which ranges contiguously over the processor's allowable address space. RTEMS does not support segmentation or virtual memory of any kind. The appropriate memory model for RTEMS provided by the targeted processor and related characteristics of that model are described in this chapter.  File: i960.info, Node: Memory Model Flat Memory Model, Next: Interrupt Processing, Prev: Memory Model Introduction, Up: Memory Model Flat Memory Model ================= The i960CA supports a flat 32-bit address space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Although the i960CA reserves portions of this address space, application code and data may be placed in any non-reserved areas. Each address is represented by a 32-bit value and is byte addressable. The address may be used to reference a single byte, half-word (2-bytes), word (4 bytes), double-word (8 bytes), triple-word (12 bytes) or quad-word (16 bytes). The i960CA does not support virtual memory or segmentation. The i960CA allows the memory space to be partitioned into sixteen regions which may be configured individually as big or little endian. RTEMS assumes that the memory regions in which its code, data, and the RTEMS Workspace reside are configured as little endian.  File: i960.info, Node: Interrupt Processing, Next: Interrupt Processing Introduction, Prev: Memory Model Flat Memory Model, Up: Top Interrupt Processing ******************** * Menu: * Interrupt Processing Introduction:: * Interrupt Processing Vectoring of Interrupt Handler:: * Interrupt Processing Interrupt Record:: * Interrupt Processing Interrupt Levels:: * Interrupt Processing Disabling of Interrupts by RTEMS:: * Interrupt Processing Register Cache Flushing:: * Interrupt Processing Interrupt Stack::  File: i960.info, Node: Interrupt Processing Introduction, Next: Interrupt Processing Vectoring of Interrupt Handler, Prev: Interrupt Processing, Up: Interrupt Processing Introduction ============ Different types of processors respond to the occurrence of an interrupt in its own unique fashion. In addition, each processor type provides a control mechanism to allow the proper handling of an interrupt. The processor dependent response to the interrupt which modifies the execution state and results in the modification of the execution stream. This modification usually requires that an interrupt handler utilize the provided control mechanisms to return to the normal processing stream. Although RTEMS hides many of the processor dependent details of interrupt processing, it is important to understand how the RTEMS interrupt manager is mapped onto the processor's unique architecture. Discussed in this chapter are the the processor's response and control mechanisms as they pertain to RTEMS.  File: i960.info, Node: Interrupt Processing Vectoring of Interrupt Handler, Next: Interrupt Processing Interrupt Record, Prev: Interrupt Processing Introduction, Up: Interrupt Processing Vectoring of Interrupt Handler ============================== Upon receipt of an interrupt the i960CA automatically performs the following actions: * saves the local register set, * sets the Frame Pointer (FP) to point to the interrupt stack, * increments the FP by sixteen (16) to make room for the Interrupt Record, * saves the current values of the arithmetic-controls (AC) register, the process-controls (PC) register, and the interrupt vector number are saved in the Interrupt Record, * the CPU sets the Instruction Pointer (IP) to the address of the first instruction in the interrupt handler, * the return-status field of the Previous Frame Pointer (PFP or R0) register is set to interrupt return, * sets the PC state bit to interrupted, * sets the current interrupt disable level in the PC to the level of the current interrupt, and * disables tracing. A nested interrupt is processed similarly by the i960CA with the exception that the Frame Pointer (FP) already points to the interrupt stack. This means that the FP is NOT overwritten before space for the Interrupt Record is allocated. The state flag bit of the saved PC register in the Interrupt Record is examined by RTEMS to determine when an outer most interrupt is being exited. Therefore, the user application code MUST NOT modify this bit.  File: i960.info, Node: Interrupt Processing Interrupt Record, Next: Interrupt Processing Interrupt Levels, Prev: Interrupt Processing Vectoring of Interrupt Handler, Up: Interrupt Processing Interrupt Record ================ The structure of the Interrupt Record for the i960CA which is placed on the interrupt stack by the processor in response to an interrupt is as follows: +---------------------------+ | Saved Process Controls | NFP-16 +---------------------------+ | Saved Arithmetic Controls | NFP-12 +---------------------------+ | UNUSED | NFP-8 +---------------------------+ | UNUSED | NFP-4 +---------------------------+  File: i960.info, Node: Interrupt Processing Interrupt Levels, Next: Interrupt Processing Disabling of Interrupts by RTEMS, Prev: Interrupt Processing Interrupt Record, Up: Interrupt Processing Interrupt Levels ================ Thirty-two levels (0-31) of interrupt priorities are supported by the i960CA microprocessor with level thirty-one (31) being the highest priority. Level zero (0) indicates that interrupts are fully enabled. Interrupt requests for interrupts with priorities less than or equal to the current interrupt mask level are ignored. Although RTEMS supports 256 interrupt levels, the i960CA only supports thirty-two. RTEMS interrupt levels 0 through 31 directly correspond to i960CA interrupt levels. All other RTEMS interrupt levels are undefined and their behavior is unpredictable.  File: i960.info, Node: Interrupt Processing Disabling of Interrupts by RTEMS, Next: Interrupt Processing Register Cache Flushing, Prev: Interrupt Processing Interrupt Levels, Up: Interrupt Processing Disabling of Interrupts by RTEMS ================================ During the execution of directive calls, critical sections of code may be executed. When these sections are encountered, RTEMS disables interrupts to level thirty-one (31) before the execution of this section and restores them to the previous level upon completion of the section. RTEMS has been optimized to insure that interrupts are disabled for less than 2.5 microseconds on a 33 Mhz i960CA with zero wait states. These numbers will vary based the number of wait states and processor speed present on the target board. [NOTE: This calculation was most recently performed for Release 3.2.1.] Non-maskable interrupts (NMI) cannot be disabled, and ISRs which execute at this level MUST NEVER issue RTEMS system calls. If a directive is invoked, unpredictable results may occur due to the inability of RTEMS to protect its critical sections. However, ISRs that make no system calls may safely execute as non-maskable interrupts.  File: i960.info, Node: Interrupt Processing Register Cache Flushing, Next: Interrupt Processing Interrupt Stack, Prev: Interrupt Processing Disabling of Interrupts by RTEMS, Up: Interrupt Processing Register Cache Flushing ======================= The i960CA version of the RTEMS interrupt manager is optimized to insure that the flushreg instruction is only executed when a context switch is necessary. The flushreg instruction flushes the i960CA register set cache and takes (14 + 23 * number of sets flushed) cycles to execute. As the i960CA supports caching of from five to sixteen register sets, this instruction takes from 129 to 382 cycles (3.90 to 11.57 microseconds at 33 Mhz) to execute given no wait state memory. RTEMS flushes the register set cache only at the conclusion of the outermost ISR when a context switch is necessary. The register set cache will not be flushed as part of processing a nested interrupt or when a context switch is not necessary. This optimization is essential to providing high-performance interrupt management on the i960CA.  File: i960.info, Node: Interrupt Processing Interrupt Stack, Next: Default Fatal Error Processing, Prev: Interrupt Processing Register Cache Flushing, Up: Interrupt Processing Interrupt Stack =============== On the i960CA, RTEMS allocates the interrupt stack from the Workspace Area. The amount of memory allocated for the interrupt stack is determined by the interrupt_stack_size field in the CPU Configuration Table. During the initialization process, RTEMS will install its interrupt stack.  File: i960.info, Node: Default Fatal Error Processing, Next: Default Fatal Error Processing Introduction, Prev: Interrupt Processing Interrupt Stack, Up: Top Default Fatal Error Processing ****************************** * Menu: * Default Fatal Error Processing Introduction:: * Default Fatal Error Processing Default Fatal Error Handler Operations::  File: i960.info, Node: Default Fatal Error Processing Introduction, Next: Default Fatal Error Processing Default Fatal Error Handler Operations, Prev: Default Fatal Error Processing, Up: Default Fatal Error Processing Introduction ============ Upon detection of a fatal error by either the application or RTEMS the fatal error manager is invoked. The fatal error manager will invoke the user-supplied fatal error handlers. If no user-supplied handlers is configured, the RTEMS provided default fatal error handler is invoked. If the user-supplied fatal error handlers return to the executive the default fatal error handler is then invoked. This chapter describes the precise operations of the default fatal error handler.  File: i960.info, Node: Default Fatal Error Processing Default Fatal Error Handler Operations, Next: Board Support Packages, Prev: Default Fatal Error Processing Introduction, Up: Default Fatal Error Processing Default Fatal Error Handler Operations ====================================== The default fatal error handler which is invoked by the fatal_error_occurred directive when there is no user handler configured or the user handler returns control to RTEMS. The default fatal error handler disables processor interrupts to level 31, places the error code in G0, and executes a branch to self instruction to simulate a halt processor instruction.  File: i960.info, Node: Board Support Packages, Next: Board Support Packages Introduction, Prev: Default Fatal Error Processing Default Fatal Error Handler Operations, Up: Top Board Support Packages ********************** * Menu: * Board Support Packages Introduction:: * Board Support Packages System Reset:: * Board Support Packages Processor Initialization::  File: i960.info, Node: Board Support Packages Introduction, Next: Board Support Packages System Reset, Prev: Board Support Packages, Up: Board Support Packages Introduction ============ An RTEMS Board Support Package (BSP) must be designed to support a particular processor and target board combination. This chapter presents a discussion of i960CA specific BSP issues. For more information on developing a BSP, refer to the chapter titled Board Support Packages in the RTEMS Applications User's Guide.  File: i960.info, Node: Board Support Packages System Reset, Next: Board Support Packages Processor Initialization, Prev: Board Support Packages Introduction, Up: Board Support Packages System Reset ============ An RTEMS based application is initiated when the i960CA processor is reset. When the i960CA is reset, the processor reads an Initial Memory Image (IMI) to establish its state. The IMI consists of the Initialization Boot Record (IBR) and the Process Control Block (PRCB) from an Initial Memory Image (IMI) at location 0xFFFFFF00. The IBR contains the initial bus configuration data, the address of the first instruction to execute after reset, the address of the PRCB, and the checksum used by the processor's self-test.  File: i960.info, Node: Board Support Packages Processor Initialization, Next: Processor Dependent Information Table, Prev: Board Support Packages System Reset, Up: Board Support Packages Processor Initialization ======================== The PRCB contains the base addresses for system data structures, and initial configuration information for the core and integrated peripherals. In particular, the PRCB contains the initial contents of the Arithmetic Control (AC) Register as well as the base addresses of the Interrupt Vector Table, System Procedure Entry Table, Fault Entry Table, and the Control Table. In addition, the PRCB is used to configure the depth of the instruction and register caches and the actions when certain types of faults are encountered. The Process Controls (PC) Register is initialized to 0xC01F2002 which sets the i960CA's interrupt level to 0x1F (31 decimal). In addition, the Interrupt Mask (IMSK) Register (alternately referred to as Special Function Register 1 or sf1) is set to 0x00000000 to mask all external and DMA interrupt sources. Thus, all interrupts are disabled when the first instruction is executed. For more information regarding the i960CA's data structures and their contents, refer to Intel's i960CA User's Manual.  File: i960.info, Node: Processor Dependent Information Table, Next: Processor Dependent Information Table Introduction, Prev: Board Support Packages Processor Initialization, Up: Top Processor Dependent Information Table ************************************* * Menu: * Processor Dependent Information Table Introduction:: * Processor Dependent Information Table CPU Dependent Information Table::  File: i960.info, Node: Processor Dependent Information Table Introduction, Next: Processor Dependent Information Table CPU Dependent Information Table, Prev: Processor Dependent Information Table, Up: Processor Dependent Information Table Introduction ============ Any highly processor dependent information required to describe a processor to RTEMS is provided in the CPU Dependent Information Table. This table is not required for all processors supported by RTEMS. This chapter describes the contents, if any, for a particular processor type.  File: i960.info, Node: Processor Dependent Information Table CPU Dependent Information Table, Next: Memory Requirements, Prev: Processor Dependent Information Table Introduction, Up: Processor Dependent Information Table CPU Dependent Information Table =============================== The i960CA version of the RTEMS CPU Dependent Information Table contains the information required to interface a Board Support Package and RTEMS on the i960CA. This information is provided to allow RTEMS to interoperate effectively with the BSP. The C structure definition is given here: typedef struct { void (*pretasking_hook)( void ); void (*predriver_hook)( void ); void (*postdriver_hook)( void ); void (*idle_task)( void ); boolean do_zero_of_workspace; unsigned32 idle_task_stack_size; unsigned32 interrupt_stack_size; unsigned32 extra_mpci_receive_server_stack; void (*stack_free_hook)( void* ); /* end of fields required on all CPUs */ i960_PRCB *Prcb; } rtems_cpu_table; The contents of the i960 Processor Control Block are discussed in the User's Manual for the particular i960 model being used. Structure definitions for the i960CA and i960HA PRCB and Control Table are provided by including the file `rtems.h'. `pretasking_hook' is the address of the user provided routine which is invoked once RTEMS APIs are initialized. This routine will be invoked before any system tasks are created. Interrupts are disabled. This field may be NULL to indicate that the hook is not utilized. `predriver_hook' is the address of the user provided routine that is invoked immediately before the the device drivers and MPCI are initialized. RTEMS initialization is complete but interrupts and tasking are disabled. This field may be NULL to indicate that the hook is not utilized. `postdriver_hook' is the address of the user provided routine that is invoked immediately after the the device drivers and MPCI are initialized. RTEMS initialization is complete but interrupts and tasking are disabled. This field may be NULL to indicate that the hook is not utilized. `idle_task' is the address of the optional user provided routine which is used as the system's IDLE task. If this field is not NULL, then the RTEMS default IDLE task is not used. This field may be NULL to indicate that the default IDLE is to be used. `do_zero_of_workspace' indicates whether RTEMS should zero the Workspace as part of its initialization. If set to TRUE, the Workspace is zeroed. Otherwise, it is not. `idle_task_stack_size' is the size of the RTEMS idle task stack in bytes. If this number is less than MINIMUM_STACK_SIZE, then the idle task's stack will be MINIMUM_STACK_SIZE in byte. `interrupt_stack_size' is the size of the RTEMS allocated interrupt stack in bytes. This value must be at least as large as MINIMUM_STACK_SIZE. `extra_mpci_receive_server_stack' is the extra stack space allocated for the RTEMS MPCI receive server task in bytes. The MPCI receive server may invoke nearly all directives and may require extra stack space on some targets. `stack_allocate_hook' is the address of the optional user provided routine which allocates memory for task stacks. If this hook is not NULL, then a stack_free_hook must be provided as well. `stack_free_hook' is the address of the optional user provided routine which frees memory for task stacks. If this hook is not NULL, then a stack_allocate_hook must be provided as well. `Prcb' is the base address of the Processor Control Block. It is primarily used by RTEMS to install interrupt handlers.  File: i960.info, Node: Memory Requirements, Next: Memory Requirements Introduction, Prev: Processor Dependent Information Table CPU Dependent Information Table, Up: Top Memory Requirements ******************* * Menu: * Memory Requirements Introduction:: * Memory Requirements Data Space Requirements:: * Memory Requirements Minimum and Maximum Code Space Requirements:: * Memory Requirements RTEMS Code Space Worksheet:: * Memory Requirements RTEMS RAM Workspace Worksheet::  File: i960.info, Node: Memory Requirements Introduction, Next: Memory Requirements Data Space Requirements, Prev: Memory Requirements, Up: Memory Requirements Introduction ============ Memory is typically a limited resource in real-time embedded systems, therefore, RTEMS can be configured to utilize the minimum amount of memory while meeting all of the applications requirements. Worksheets are provided which allow the RTEMS application developer to determine the amount of RTEMS code and RAM workspace which is required by the particular configuration. Also provided are the minimum code space, maximum code space, and the constant data space required by RTEMS.  File: i960.info, Node: Memory Requirements Data Space Requirements, Next: Memory Requirements Minimum and Maximum Code Space Requirements, Prev: Memory Requirements Introduction, Up: Memory Requirements Data Space Requirements ======================= RTEMS requires a small amount of memory for its private variables. This data area must be in RAM and is separate from the RTEMS RAM Workspace. The following illustrates the data space required for all configurations of RTEMS: * Data Space: 128  File: i960.info, Node: Memory Requirements Minimum and Maximum Code Space Requirements, Next: Memory Requirements RTEMS Code Space Worksheet, Prev: Memory Requirements Data Space Requirements, Up: Memory Requirements Minimum and Maximum Code Space Requirements =========================================== A maximum configuration of RTEMS includes the core and all managers, including the multiprocessing manager. Conversely, a minimum configuration of RTEMS includes only the core and the following managers: initialization, task, interrupt and fatal error. The following illustrates the code space required by these configurations of RTEMS: * Minimum Configuration: xx,129 * Maximum Configuration: xx,130  File: i960.info, Node: Memory Requirements RTEMS Code Space Worksheet, Next: Memory Requirements RTEMS RAM Workspace Worksheet, Prev: Memory Requirements Minimum and Maximum Code Space Requirements, Up: Memory Requirements RTEMS Code Space Worksheet ========================== The RTEMS Code Space Worksheet is a tool provided to aid the RTEMS application designer to accurately calculate the memory required by the RTEMS run-time environment. RTEMS allows the custom configuration of the executive by optionally excluding managers which are not required by a particular application. This worksheet provides the included and excluded size of each manager in tabular form allowing for the quick calculation of any custom configuration of RTEMS. The RTEMS Code Space Worksheet is below: RTEMS Code Space Worksheet The following is a list of the components of the RTEMS code space. The first number in parentheses is the size when the component is included, while the second number indicates its size when not included. If the second number is "NA", then the component must always be included. * Core (x,131, NA) * Initialization (x,132, NA) * Task (x,133, NA) * Interrupt (x,134, NA) * Clock (x,135, NA) * Timer (x,136, 148) * Semaphore (x,137, 149) * Message (x,138, 150) * Event (x,139, 151) * Signal (x,140, 152) * Partition (x,141, 153) * Region (x,142, 154) * Dual Ported Memory (x,143, 155) * I/O (x,144, 156) * Fatal Error (x,145, NA) * Rate Monotonic (x,146, 157) * Multiprocessing (x,147, 158)  File: i960.info, Node: Memory Requirements RTEMS RAM Workspace Worksheet, Next: Timing Specification, Prev: Memory Requirements RTEMS Code Space Worksheet, Up: Memory Requirements RTEMS RAM Workspace Worksheet ============================= The RTEMS RAM Workspace Worksheet is a tool provided to aid the RTEMS application designer to accurately calculate the minimum memory block to be reserved for RTEMS use. This worksheet provides equations for calculating the amount of memory required based upon the number of objects configured, whether for single or multiple processor versions of the executive. This information is presented in tabular form, along with the fixed system requirements, allowing for quick calculation of any application defined configuration of RTEMS. The RTEMS RAM Workspace Worksheet is provided below: RTEMS RAM Workspace Worksheet The total RTEMS RAM Workspace required is the sum of the following: * maximum_tasks * 159 * maximum_timers * 160 * maximum_semaphores * 161 * maximum_message_queues * 162 * maximum_regions * 163 * maximum_partitions * 164 * maximum_ports * 165 * maximum_periods * 166 * maximum_extensions * 167 * Floating Point Tasks * 168 * Task Stacks * maximum_nodes * 169 * maximum_global_objects * 170 * maximum_proxies * 171 * Fixed System Requirements of x,172  File: i960.info, Node: Timing Specification, Next: Timing Specification Introduction, Prev: Memory Requirements RTEMS RAM Workspace Worksheet, Up: Top Timing Specification ******************** * Menu: * Timing Specification Introduction:: * Timing Specification Philosophy:: * Timing Specification Methodology::  File: i960.info, Node: Timing Specification Introduction, Next: Timing Specification Philosophy, Prev: Timing Specification, Up: Timing Specification Introduction ============ This chapter provides information pertaining to the measurement of the performance of RTEMS, the methods of gathering the timing data, and the usefulness of the data. Also discussed are other time critical aspects of RTEMS that affect an applications design and ultimate throughput. These aspects include determinancy, interrupt latency and context switch times.  File: i960.info, Node: Timing Specification Philosophy, Next: Timing Specification Determinancy, Prev: Timing Specification Introduction, Up: Timing Specification Philosophy ========== * Menu: * Timing Specification Determinancy:: * Timing Specification Interrupt Latency:: * Timing Specification Context Switch Time:: * Timing Specification Directive Times:: Benchmarks are commonly used to evaluate the performance of software and hardware. Benchmarks can be an effective tool when comparing systems. Unfortunately, benchmarks can also be manipulated to justify virtually any claim. Benchmarks of real-time executives are difficult to evaluate for a variety of reasons. Executives vary in the robustness of features and options provided. Even when executives compare favorably in functionality, it is quite likely that different methodologies were used to obtain the timing data. Another problem is that some executives provide times for only a small subset of directives, This is typically justified by claiming that these are the only time-critical directives. The performance of some executives is also very sensitive to the number of objects in the system. To obtain any measure of usefulness, the performance information provided for an executive should address each of these issues. When evaluating the performance of a real-time executive, one typically considers the following areas: determinancy, directive times, worst case interrupt latency, and context switch time. Unfortunately, these areas do not have standard measurement methodologies. This allows vendors to manipulate the results such that their product is favorably represented. We have attempted to provide useful and meaningful timing information for RTEMS. To insure the usefulness of our data, the methodology and definitions used to obtain and describe the data are also documented.  File: i960.info, Node: Timing Specification Determinancy, Next: Timing Specification Interrupt Latency, Prev: Timing Specification Philosophy, Up: Timing Specification Philosophy Determinancy ------------ The correctness of data in a real-time system must always be judged by its timeliness. In many real-time systems, obtaining the correct answer does not necessarily solve the problem. For example, in a nuclear reactor it is not enough to determine that the core is overheating. This situation must be detected and acknowledged early enough that corrective action can be taken and a meltdown avoided. Consequently, a system designer must be able to predict the worst-case behavior of the application running under the selected executive. In this light, it is important that a real-time system perform consistently regardless of the number of tasks, semaphores, or other resources allocated. An important design goal of a real-time executive is that all internal algorithms be fixed-cost. Unfortunately, this goal is difficult to completely meet without sacrificing the robustness of the executive's feature set. Many executives use the term deterministic to mean that the execution times of their services can be predicted. However, they often provide formulas to modify execution times based upon the number of objects in the system. This usage is in sharp contrast to the notion of deterministic meaning fixed cost. Almost all RTEMS directives execute in a fixed amount of time regardless of the number of objects present in the system. The primary exception occurs when a task blocks while acquiring a resource and specifies a non-zero timeout interval. Other exceptions are message queue broadcast, obtaining a variable length memory block, object name to ID translation, and deleting a resource upon which tasks are waiting. In addition, the time required to service a clock tick interrupt is based upon the number of timeouts and other "events" which must be processed at that tick. This second group is composed primarily of capabilities which are inherently non-deterministic but are infrequently used in time critical situations. The major exception is that of servicing a clock tick. However, most applications have a very small number of timeouts which expire at exactly the same millisecond (usually none, but occasionally two or three).  File: i960.info, Node: Timing Specification Interrupt Latency, Next: Timing Specification Context Switch Time, Prev: Timing Specification Determinancy, Up: Timing Specification Philosophy Interrupt Latency ----------------- Interrupt latency is the delay between the CPU's receipt of an interrupt request and the execution of the first application-specific instruction in an interrupt service routine. Interrupts are a critical component of most real-time applications and it is critical that they be acted upon as quickly as possible. Knowledge of the worst case interrupt latency of an executive aids the application designer in determining the maximum period of time between the generation of an interrupt and an interrupt handler responding to that interrupt. The interrupt latency of an system is the greater of the executive's and the applications's interrupt latency. If the application disables interrupts longer than the executive, then the application's interrupt latency is the system's worst case interrupt disable period. The worst case interrupt latency for a real-time executive is based upon the following components: * the longest period of time interrupts are disabled by the executive, * the overhead required by the executive at the beginning of each ISR, * the time required for the CPU to vector the interrupt, and * for some microprocessors, the length of the longest instruction. The first component is irrelevant if an interrupt occurs when interrupts are enabled, although it must be included in a worst case analysis. The third and fourth components are particular to a CPU implementation and are not dependent on the executive. The fourth component is ignored by this document because most applications use only a subset of a microprocessor's instruction set. Because of this the longest instruction actually executed is application dependent. The worst case interrupt latency of an executive is typically defined as the sum of components (1) and (2). The second component includes the time necessry for RTEMS to save registers and vector to the user-defined handler. RTEMS includes the third component, the time required for the CPU to vector the interrupt, because it is a required part of any interrupt. Many executives report the maximum interrupt disable period as their interrupt latency and ignore the other components. This results in very low worst-case interrupt latency times which are not indicative of actual application performance. The definition used by RTEMS results in a higher interrupt latency being reported, but accurately reflects the longest delay between the CPU's receipt of an interrupt request and the execution of the first application-specific instruction in an interrupt service routine. The actual interrupt latency times are reported in the Timing Data chapter of this supplement.  File: i960.info, Node: Timing Specification Context Switch Time, Next: Timing Specification Directive Times, Prev: Timing Specification Interrupt Latency, Up: Timing Specification Philosophy Context Switch Time ------------------- An RTEMS context switch is defined as the act of taking the CPU from the currently executing task and giving it to another task. This process involves the following components: * Saving the hardware state of the current task. * Optionally, invoking the TASK_SWITCH user extension. * Restoring the hardware state of the new task. RTEMS defines the hardware state of a task to include the CPU's data registers, address registers, and, optionally, floating point registers. Context switch time is often touted as a performance measure of real-time executives. However, a context switch is performed as part of a directive's actions and should be viewed as such when designing an application. For example, if a task is unable to acquire a semaphore and blocks, a context switch is required to transfer control from the blocking task to a new task. From the application's perspective, the context switch is a direct result of not acquiring the semaphore. In this light, the context switch time is no more relevant than the performance of any other of the executive's subroutines which are not directly accessible by the application. In spite of the inappropriateness of using the context switch time as a performance metric, RTEMS context switch times for floating point and non-floating points tasks are provided for comparison purposes. Of the executives which actually support floating point operations, many do not report context switch times for floating point context switch time. This results in a reported context switch time which is meaningless for an application with floating point tasks. The actual context switch times are reported in the Timing Data chapter of this supplement.  File: i960.info, Node: Timing Specification Directive Times, Next: Timing Specification Methodology, Prev: Timing Specification Context Switch Time, Up: Timing Specification Philosophy Directive Times --------------- Directives are the application's interface to the executive, and as such their execution times are critical in determining the performance of the application. For example, an application using a semaphore to protect a critical data structure should be aware of the time required to acquire and release a semaphore. In addition, the application designer can utilize the directive execution times to evaluate the performance of different synchronization and communication mechanisms. The actual directive execution times are reported in the Timing Data chapter of this supplement.  File: i960.info, Node: Timing Specification Methodology, Next: Timing Specification Software Platform, Prev: Timing Specification Directive Times, Up: Timing Specification Methodology =========== * Menu: * Timing Specification Software Platform:: * Timing Specification Hardware Platform:: * Timing Specification What is measured?:: * Timing Specification What is not measured?:: * Timing Specification Terminology::  File: i960.info, Node: Timing Specification Software Platform, Next: Timing Specification Hardware Platform, Prev: Timing Specification Methodology, Up: Timing Specification Methodology Software Platform ----------------- The RTEMS timing suite is written in C. The overhead of passing arguments to RTEMS by C is not timed. The times reported represent the amount of time from entering to exiting RTEMS. The tests are based upon one of two execution models: (1) single invocation times, and (2) average times of repeated invocations. Single invocation times are provided for directives which cannot easily be invoked multiple times in the same scenario. For example, the times reported for entering and exiting an interrupt service routine are single invocation times. The second model is used for directives which can easily be invoked multiple times in the same scenario. For example, the times reported for semaphore obtain and semaphore release are averages of multiple invocations. At least 100 invocations are used to obtain the average.  File: i960.info, Node: Timing Specification Hardware Platform, Next: Timing Specification What is measured?, Prev: Timing Specification Software Platform, Up: Timing Specification Methodology Hardware Platform ----------------- Since RTEMS supports a variety of processors, the hardware platform used to gather the benchmark times must also vary. Therefore, for each processor supported the hardware platform must be defined. Each definition will include a brief description of the target hardware platform including the clock speed, memory wait states encountered, and any other pertinent information. This definition may be found in the processor dependent timing data chapter within this supplement.  File: i960.info, Node: Timing Specification What is measured?, Next: Timing Specification What is not measured?, Prev: Timing Specification Hardware Platform, Up: Timing Specification Methodology What is measured? ----------------- An effort was made to provide execution times for a large portion of RTEMS. Times were provided for most directives regardless of whether or not they are typically used in time critical code. For example, execution times are provided for all object create and delete directives, even though these are typically part of application initialization. The times include all RTEMS actions necessary in a particular scenario. For example, all times for blocking directives include the context switch necessary to transfer control to a new task. Under no circumstances is it necessary to add context switch time to the reported times. The following list describes the objects created by the timing suite: * All tasks are non-floating point. * All tasks are created as local objects. * No timeouts are used on blocking directives. * All tasks wait for objects in FIFO order. In addition, no user extensions are configured.  File: i960.info, Node: Timing Specification What is not measured?, Next: Timing Specification Terminology, Prev: Timing Specification What is measured?, Up: Timing Specification Methodology What is not measured? --------------------- The times presented in this document are not intended to represent best or worst case times, nor are all directives included. For example, no times are provided for the initialize executive and fatal_error_occurred directives. Other than the exceptions detailed in the Determinancy section, all directives will execute in the fixed length of time given. Other than entering and exiting an interrupt service routine, all directives were executed from tasks and not from interrupt service routines. Directives invoked from ISRs, when allowable, will execute in slightly less time than when invoked from a task because rescheduling is delayed until the interrupt exits.