RASSP Model Year Architecture (MYA) Appnote

6.1 Model-Year Software Architecture

The model-year software architecture and interoperability relies heavily on a standard API and services supplied by the run-time system, which encapsulates the operating system and the primitive libraries. The model-year software architecture is shown in Figure 6 - 1, along with the associated elements users need to automatically generate software. The intent on RASSP is to drive toward graph-based autocode generation using data flow graphs (DFGs) to represent application (algorithm) code and state machine diagram graphs to represent command/control code to the maximum extent. In the event of a processor upgrade, the graph-based representation provides the common definition of operation and service requirements even though the underlying processor hardware, operating system, and libraries have changed. The same holds true if a primitive library or operating system for a given processor type is upgraded.

The model-year software application layer is divided into two parts: the command program and the application's data flow graphs. The command program does the following:

• responds to external control inputs
• starts and stops data flow graphs
• manages I/O devices
• monitors flow graph execution and performance
• starts other command programs
• sets flow graph parameters

Support for the Application Program Interface (API) is through a run-time system, which provides the services required to control and execute multiple graphs on a multi-processor system. The run-time system relies on support from the underlying operating system (microkernel and support services). The data flow graph approach proposed as a signal processing API does not imply that the associated scheduling and execution paradigms implemented by previous PGM run-time systems must also be used for the RASSP implementation.

The operating system services must support the run-time system. Both GEDAE™ and MCCI provide run-time systems that satisfy the RASSP requirements. As shown in Figure 6 - 2, the run-time system interfaces directly with the operating system for some required services. The interface is isolated to a low level to simplify portability; users can customize it for a particular operating system. The term operating system includes the microkernel itself, plus any external services not implemented directly within the microkernel that are needed to support the run-time system.

The operating system services must also provide guaranteed performance limits on the microkernel services. Five categories of service requirements must be provided:

• Task control using processes and threads
• Interrupt handling
• Memory management
• Interprocessor communication
• I/O services.

Table 6 - 1 details these service requirements and the primary performance and interface issues associated with each. These required services must be used to evaluate and select suitable microkernels for RASSP signal processors.

Requirements Category	Services Provided
1. Tasks control using processes and threads	- context witch time (process and thread) - take/give semaphore time (intra- and inter- process) - thread control: spawn, suspend, reume, terminate, priority - multiprocessor thread support
2. Interrupt Handling	- Interrupt response time affected by: - Kernel overhead in handling interrupt - Kernel disabling of interrupts for time T off
3. Memory Management	- Performance of alloc and free - Class of memory - onchip, SRAM, cache, etc.
4. Interprocessor Communication	- Shared Memory - Transparent, i.e. shared globals - Explicit: interface for copying to/from shared memory - Point-to-point Communication - Buffer sizes/types - Amount of data copying required - Heterogeneous Processort (data translation standards) - XDR, Format description , etc. - Scalability
5. I/O	- Ability to add new device drivers - Ability to suport BIT and performance monitoring

The capabilities provided by these services must support typical embedded multiprocessor applications. These applications will be comprised of host and target processes, all running as peers, grouped on multiple processors. Multiple processes grouped on any single processor must be able to run in parallel. Since a group of processors may physically reside on the same or different boards, a common method of memory addressing is needed to eliminate memory overlaps and address ambiguity between processors. The operating system must have the characteristics of a distributed, preemptive, multi-processor, multi-tasking operating system, while also supporting the high-performance throughput capabilities of tightly coupled processes. The operating system will provide a kernel-level interface to the multi-tasking preemptive kernel. This interface will include allocation and control functions for local memory, functions to connect and control interrupt handlers, and functions to manipulate programmable hardware that may be on various processor systems, such as DMA controllers and timers.

The RASSP approach can accommodate signal processor designs that include COTS products with a proprietary operating system as long as the operating system meets the service requirements defined for RASSP, and as long as it provides an open interface on which the run-time system and API(s) can be ported. The important issue, as with all RASSP designs, is to ensure that implementing the underlying operating system, its services, and API is transparent to the application software to make it easier to insert model year upgrades of hardware and system-level software.