Next: 6 Model Year Software Architecture Up: Appnotes Index Previous:4 Implementation of the Functional Architecture Standard Virtual Interface (SVI) and Reconfigurable Network Interface (RNI)

RASSP Model Year Architecture (MYA) Appnote

5.0 Emerging Interface Standards Overview

5.1 Interface Standards

Open interface standards should be used within systems wherever possible to further ensure interoperability between components. Using commercially accepted and non-proprietary standards may preclude the necessity of functional interface encapsulations in some cases. This is bedause COTS fabric interface components may allow direct communication between architectural elements and the selected standard interface. Confining designs to open interface standards will:

ensure multiple sources and reasonable costs for compatible components
eliminate dependence on sole source proprietary components
ensure a well-understood and problem-free interconnect technology due to its acceptance and proliferation elsewhere in the military and/or industry.

It was the intention at the time of the writing of the RASSP MYA Working Document that the scope of the Model Year Architecture would include the maintenance of a set of approved RASSP accepted and recommended open interface standards. Upon further consideration it was determined to be impractical and inappropriate for RASSP to attempt to qualify interface standards, but to instead provide a recommended methodology for selecting appropriate interface standards. There are several factors mitigating against RASSP-accepted interface standards. The primary issue is that there can be several applicable standards for a particular signal processing system application, one of which may be more appropriate for a particular application than another. It is not in the best interest - or the intention - of RASSP to dictate which standard is most appropriate. In addition, organizations such as the Navy's Next Generation Computer Resources (NGCR) and the Air Force Joint Integrated Avionics Working Group (JIAWG) have expended a great deal of time and effort in evaluating and selecting standards applicable to their respective application domains. There is little value added for RASSP to reinvent the results of these organizations. Finally, not all interfaces are under complete control of the signal processor design. For example, subsystem interfaces used to interface RASSP signal processors to a large amount of ancillary equipment and subsystems previously designed may be outside the control of the designer.

The RASSP Model Year Architecture Specification - v1.0 , Section 7, describes a process which may be used to systematically select the optimum interconnect approach for a particular design from among open interface standards. In addition, the VSIA is developing a standard way of documenting performance and physical information about standard buses. Used in conjunction with the RASSP process, this will provide a very useful tool for comparing interconnect standards.

Of all the standard interfaces, the test interface required extra consideration. During RASSP a Design-for-Test (DFT) Methodology was developed. This methodology requires the use of standard test interfaces. However, there are only a handful of standard test interfaces available, as described in the RASSP Model Year Architecture Specification - v1.0 , Section 7, and they are widely accepted and non-overlapping. Therefore, it did not make sense to specify a particular hardware functional test interface.

Another aspect of the test interface which was considered was the test Application Program Interface (API). That is, the programming interface to the test structures. In contrast to the functional hardware test interface, there is currently no standard test API. The reason is, the APIs that many vendors are supplying with their boards are very hardware specific. It is unclear whether a standard test API could be developed that would be efficient enough to be useful. The benefit of such an API is clear. As portions of the system are upgraded, the top level test software would not have to be completely rewritten, although it might be expanded or reduced depending on the capability of the upgrade. In order to fully support the RASSP architectural process, the API would have to be implementation independent. The new hardware or software would have to supply appropriate results to the API calls.

Approved for Public Release; Distribution Unlimited Dennis Basara