Next: 4 Implementation of the Functional Architecture Standard Virtual Interface (SVI) and Reconfigurable Network Interface (RNI) Up: Appnotes Index Previous: 2 Introduction
Next: 4 Implementation of the Functional Architecture Standard Virtual Interface (SVI) and Reconfigurable Network Interface (RNI)
Up: Appnotes Index
Previous: 2 Introduction
The functional architecture does not specify the topology or configuration of the architecture, specific processor types, or system-level interface standards (external to the signal processor).
The functional architecture concept is based on the use of abstract architectural objects and standard functional interfaces at key points within a layered architecture, as shown in Figure 3 - 1. The key aspect of the functional architecture is ATL's approach to implementing the interfaces, particularly the various signal processor components (general-purpose processors, DSPs, special-purpose processors, and hardware accelerators), shared memories, sensors, and subsystem components (ancillary equipment, mass storage devices, etc.). The approach combines two concepts: The primary reason for using a layered approach is that it provides logical decomposition into smaller, more manageable, understandable, reusable, and maintainable parts. The layered approach minimizes and confines changes that are introduced as a result of modifications (e.g., upgrades). A technology-independent functional interface is one that remains at the logical level, specifying no physical or electrical characteristics.
At the hardware level, this is achieved by defining a VHDL encapsulation wrapper for each architectural reuse library element that implements a standard functional interface. An encapsulation wrapper is additional structure added to otherwise raw library elements to support the functional architecture and to ensure library element interoperability and technology independence to the maximum extent possible. The wrapper implements the hardware portion of the functional interface, called the Standard Virtual Interface (SVI), which is detailed in Section 4. It encapsulates the library element to hide implementation details, providing only an interface definition (the functional interface) to users.
The functional architecture includes both a software and hardware portion. The model-year software architecture simplifies developing high-performance, real-time DSP applications, allowing developers to easily describe, implement, and control signal processing applications for multi-processor implementations. As shown in Figure 3 - 2, it includes standard application programming interfaces (APIs) to the operating system and operating system services, and standard domain primitives for autocode software generation.
The signal processing algorithms are represented as Data Flow Graphs (DFGs) that drive the autocode generation to produce the executable code for each processor in the system This process is supported by a reusable primitive library. The command program is the control flow program that provides the overall control, as dictated by the received messages.
The reusable run-time system and its support for the API, represented by the Control and Data flow Interfaces is Figure 3 - 2, is the essential component of software encapsulation/interoperability for a processor object. It provides the reusable data flow control and graph management for the signal processor. It is built upon a set of operating system services provided by a real-time microkernel using a standard interface. This system is a set of run-time application programs that constitute a ‘virtual’ machine which performs all graph execution functions and all system interface, control, and monitoring functions. It is usable with any operating system microkernel that provides the necessary set of services.
The application layer of the software architecture consists of an interface to the world outside the signal processor in addition to a command program and data flow graphs. The outside "user" could either be an actual user, or more likely, it could be a higher-level system as part of an overall platform. The division of the application into two parts is similar in concept to the Processing Graph Method (PGM) developed by the Naval Research Laboratory. The first part of the application layer is the command program, which provides response to external control inputs, starts and stops data flow graphs, manages I/O devices, monitors flow graph execution and performance, starts other command programs, and sets flow graph parameters. The control interface provides services that implement these operations. The second part of the application layer is the DFGs, implemented using a tool such as Management Communication and Control, Inc. (MCCI's) autocode or the LM/ATL's Graphical Entry Distributed Application Environment (GEDAE ™). The DFGs represent the signal processing algorithms that must be applied for each operating mode of the signal processor. Services provided by the data flow graph interface, which are largely invisible to the developer, include managing graph queues, interprocessor communication, and scheduling.
The constructed flow graph is converted via autocode generation into a higher order language (HOL), such as C or ADA containing calls to a standard set of domain primitives. The domain primitives are then mapped to optimized primitives in the target processor’s library. Implementing the standard operating system APIs and standard domain primitive mapping via a Target Processor Map (TPM) forms the software encapsulation, which hides implementation details of the operating system, its services, and application libraries.
An important aspect of the functional architecture is that application-specific realizations of a signal processor are embodied in the proper definition and use of encapsulated library elements. Designers can use application notes in the reuse libraries to properly apply and aggregate individual hardware and software components into a final processor product. Implementing the object-oriented reuse libraries is described in Section 7.
The model-year architecture also provides a set of design guidelines and constraints to develop general architectures, such as how to properly use the functional architecture framework, general use of encapsulated libraries, and most importantly, procedures and templates to encapsulate new library components. The Model-Year Architecture Specification Volume II - Hardware Architecture Element Specification describes all elements of the functional architecture including the constraints.
While the hardware design tools to support the hardware functional architecture are already commercially available (i.e. QuickHDL, VisualHDL, Synopsys, etc.), LM/ATL's RASSP team has developed a full suite of architecture design tools to seamlessly support the high-level hardware-software partitioning, performance analysis and the software architecture. See the Hardware/Software Codesign application note for additional details. These architecture design tools are:
3.0 Model Year Functional Architecture Technology
The technology overview provides a brief description of the MYA and its components. The MYA terminology and components are introduced. 3.1 Model - Year Architecture Functional Architecture
The functional architecture defines the necessary components and their interfaces to ensure that users can easily and affordably upgrade designs and insert new technology. The functional architecture is a starting point for users to develop solutions for an application-specific set of problems, not a detailed instantiation of an architecture. The functional architecture specifies:
3.2 Model - Year Architecture Software Architecture
Next: 4 Implementation of the Functional Architecture Standard Virtual Interface (SVI) and Reconfigurable Network Interface (RNI)
Up: Appnotes Index
Previous: 2 Introduction