The RASSP Digest - Vol. 2, 4th. Qtr. 1995

The Standard Virtual Interface : An Interoperability Approach

by Jeff Pridmore

Abstract

To achieve the 4X time-to-market and life cycle cost improvement goals of the RASSP program, designers must focus not only on how they design, but on what they design as well. Lockheed Martin’s Advanced Technology Labs is developing a Model Year Architecture (MYA) that promotes design upgrades and reuse via standardized, open interfaces while leveraging state-of-the-art commercial technology developments. This article describes one element of the MYA that supports interoperability, the Standard Virtual Interface.

1. Model Year Architecture Overview

The basic framework for the Model Year Architecture was described in more detail in a previous article in the RASSP Digest (Vol. 2, 3Q95). Briefly, the MYA is a framework for reuse that provides a structured approach to ensure that designs incorporate the features required to promote upgradability. The basic elements that comprise the MYA are the Functional Architecture, Encapsulated Library Components, and Design Guidelines and Constraints, as shown in Figure 4 on page 24 of the last RASSP Digest (Vol. 2, 3rd Qtr.). Synergism between the Model Year Architecture Framework and the RASSP Methodology is required, as all areas of the methodology, including architecture development, hardware/software codesign, reuse library management, hardware synthesis, target software generation, and design for test are impacted by the MYA Framework. The Functional Architecture defines the necessary components, and their interfaces, to ensure that the design is upgradable and facilitates technology insertion. It is a starting point for developing solutions for an application-specific set of problems, not a detailed instantiation of an architecture.

2. Standard Virtual Interface

The Standard Virtual Interface (SVI) defines a concept to facilitate interoperability and upgradability of various architectural level reuse library elements (such as processor nodes and interface elements) by defining a standard interface encapsulation procedure. In the past, integration of a processor to a specific interconnect has been performed as a specialized implementation; this point-to-point integration approach can lead to a total of N**2 possible integrations for N processors and interconnects. The intent of the SVI is to provide a common functional interface for all of these integrations, greatly reducing the number of integrations required. Thus, once a processor has been integrated to the SVI standard, it can be integrated to any interconnect integrated to this standard. This approach provides a level of plug and play interoperability that has not been realized in the past. Additionally, the SVI is a functional, not physical, interface specification that supports technology independence - hence, the use of the term virtual in SVI.

Figure 1 illustrates an SVI implementation. In this example, a "PE" can be an element or cluster of elements connected as a single node to an interconnect. Examples of PEs include signal processors, vector processors, or shared memory. The term "interconnect" can be any interconnect fabric or network. Examples of interconnect fabrics include XBAR-based point-to-point interconnect networks, rings, and multidrop buses. Examples of networks include Ethernet, FDDI, Fiber Channel, 1553B, etc.

Each library element (processor or interface) includes a hardware wrapper (encapsulation) which implements the SVI functions. During the hardware implementation, the logic described within the encapsulations from both sides of the SVI is combined and optimized wherever possible. This process may cause some of the signals defined for the SVI to become implicit in the remaining logic. In addition, what remains of the SVI is expected to be embedded within an ASIC, gate array, or FPGA, and would not appear as explicit pins on a chip or interface connector.

The SVI definition is general enough to handle different interprocessor communication paradigms. Some interconnect networks support the message passing paradigm to communicate, while others support the global shared memory paradigm. Likewise, operation between a processor and interconnect can be synchronous or asynchronous. The SVI is defined to be synchronous. Support for asynchronous operation between a processor and interconnect must be defined separately from the SVI within the processor or interface library element.

Figure 2 illustrates an example of how the SVI can be used to create a bridge node between two interconnects, using a construct called the Reconfigurable Network Interface (RNI). The RNI is divided into three logical elements: a local interface, an external interface, and the bridge element. The local and external interfaces implement the protocols between the two interconnects using two SVI encapsulations. The bridge element is typically implemented using a programmable controller (processor or dedicated logic) and buffer memory. The buffer facilitates asynchronous coupling and flow control between the two networks, and the controller coordinates data transfers and implements higher level data formatting (packetization, etc.). The three logical elements of the RNI serve to isolate hardware and software changes that result from technology upgrades.

3. SVI Protocol and Commands

The SVI must be able to accommodate many different processing elements, interconnects, and interface standards. To allow for this, it must be as flexible as possible while minimally impacting the system’s performance and hardware characteristics. Therefore, the SVI is defined to be very simple. It is a FIFO or I/O type of interface that uses simple message passing to transfer data. The SVI is partitioned into the following components: Data Output Interface, Data Input Interface, Interrupt, System clock, System reset, and Test Interface. The data interfaces are the most interesting portion of the SVI. Each of the two data interfaces is implemented with a master/slave pair: an SVI master is a data source, while an SVI slave is a data sink. Thus, the encapsulation of a typical architectural element contains an SVI master/slave pair, as shown in Figure 3 . The Data Input Interface is synonymous with the SVI slave and the Data Output Interface is synonymous with the SVI master.

Partitioning the data interface into two unidirectional data interfaces (input and output) is somewhat arbitrary; the advantage of the partitioning is that it will support architectures with independent, concurrent data passing in both directions across the SVI. A bidirectional data interface can be obtained by using both unidirectional data interfaces controlled by the SVI master and the SVI slave. Data transfer on the SVI can occur as a result of a read or a write. There is no distinction on the SVI interface if the operation is internal or external, other than the value of the SVI command.

A set of SVI Commands have been defined to implement the protocol. The SVI command is the first data word transferred across the SVI interface for each message. SVI data paths are implemented in byte increments, allowing encapsulations with different data-path widths. SVI commands occupy the least significant byte of the data bus, and transfer information across the SVI which will be needed by the receiving encapsulation. The address and data, along with any other necessary information, are contained in the data stream following the SVI command. It is the SVI Master’s responsibility to encode the data in the SVI message and the Slave’s responsibility to decode the message properly. Thus, the SVI message source must have knowledge of how its encapsulation will build the message and also of how the receiving SVI encapsulation will interpret the data words in the message. Typically, encoding of the data in the message is done in software on the originating processing element (PE). The existing commands include those functions needed to implement SVI encapsulations envisioned to date — more commands may be necessary in the future to support new interconnects with unusual multiprocessor or cache support requirements. Commands can easily be added, allowing previous encapsulations access to the new SVI commands.

SVI read and write commands include the following:

If the receiving encapsulation implements the command, the data transfer continues. If the encapsulation cannot implement the command the encapsulation must, as a minimum, flag the fact that it cannot implement the command. This can easily be done using an ASSERT statement. The encapsulation could also abort the message.

4. SVI Encapsulation Guidelines

While all SVI encapsulations must adhere to the SVI specification, it is extremely beneficial to follow several guidelines. First, an SVI encapsulation should be a minimal solution in terms of hardware and performance overhead. Second, an SVI encapsulation should be robust, allowing for interoperability with other SVI encapsulations. Reuse will occur only if SVI encapsulations are efficient, robust, and interchangeable. Third, an SVI encapsulation must be synthesizable. The logic necessary to implement an encapsulation should be capable of being targeted to an FPGA or ASIC with little or no modification. Fourth, SVI encapsulations should be implemented using good coding standards. This will allow for easier understanding of an encapsulation, aiding reuse, debugging, and modification, if needed. Finally, the encapsulation should be accompanied by application notes to ensure proper use.

Good structure will allow an encapsulation to be interoperable with other SVI encapsulations and be easily synthesized. SVI encapsulations will encompass many different interface standards and processing elements. These different entities will most likely run at different clock frequencies. Therefore, encapsulations must be able to operate with other encapsulations with different clock rates. If an encapsulation can only operate at one clock frequency, it will be less likely to be reused. However, this requirement will increase the amount of hardware needed to implement the SVI slave portion of the encapsulation. To avoid hardware overhead, the SVI master should be implemented to operate at the same clock frequency as the encapsulated entity.

Encapsulated entities will contain varying data-path widths. By requiring that the slave of the SVI encapsulation be capable of accepting different data-path widths for different applications, two benefits arise. First, logic to interface different data-path widths can be limited to the slave portion of the SVI encapsulation. Second, changing an encapsulation to accept different data-path widths will be made easier by substituting data-path width converters at the same location in the encapsulation. Data-path width converters will be available in the Model Year Architecture Reuse Library.

In addition to clock rates and data-path widths, an SVI encapsulation must alert the user when an unimplemented SVI command is received. As a minimum, the encapsulation must report this condition and fail using, for example, the VHDL ASSERT statement. A better solution is to report the condition and then abort the message and continue operating. This will help system designers identify incorrect use of an encapsulation.

Additional implementation issues should also be considered:

5. Status and Summary

VHDL templates for SVI encapsulations, representing “typical” encapsulations are being provided to supplement the signal / Timing / Protocol definition described above for team members to use in their modeling efforts. To date, several SVI encapsulations have been implemented on the program. They have demonstrated the ability to provide plug and play interconnect between different elements with minimal performance impact. The Standard Virtual Interface is a critical element of the RASSP Model Year Architecture that guides the user in developing architecture elements that can be easily reused and upgraded.

Jeff Pridmore
Lockheed Martin Advanced Technology Laboratories
One Federal Street, A&E-2W
Camden, NJ 08102
pridmore#m#_jeff@msgw.vf.mmc.com

The RASSP Digest - Vol. 2, 4th. Qtr. 1995 newsletter/html/95q4/news_3.html