RASSP Model Year Architecture (MYA) Appnote

4.1 Model-Year Hardware Interoperability

This section describes the levels of interoperability offered within the Model Year Architecture framework, and introduces the concept of encapsulation. Figure 4 - 1 shows the two specific levels of interoperable interfaces that are supported by the model year hardware functional architecture:

• internal node-to-internal interconnect fabric or node-level
• internal interconnect fabric -to-external interconnect fabric or interconnect-level. This interconnect-level may be simple, such as a connection between a slave peripheral and a system. It may also be quite complex, requiring protocol translation and data formatting services, such as a connection between heterogeneous networks.

Users implement node-level interfaces by encapsulating elements using the SVI. The SVI encapsulation is a VHDL wrapper that ports processor or processor bus interfaces to a common functional interface. The SVI specification was developed as part of the RASSP model-year effort, and interoperability experiments were run by porting several processors to various buses. Discussions of these experiments are included in Section 4.4 with additional details linked in the references.

Interconnect-level interoperability is provided using a bridge node between internal and external interconnect fabrics called the Reconfigurable Network Interface node (RNI). An RNI node is constructed from two SVI encapsulations interconnected by a logical layer that ties the two interfaces together. These nodes are usually implemented using a dual-port memory or FIFO and programmable processor or embedded controller. The SVI and RNI are described in more detail in the following two subsections.

Figure 4 - 2 illustrates how the SVI is used to encapsulate elements of the functional architecture. An internal node can be a single processing element or cluster of elements connected as a single node to a processor bus. Examples of internal nodes include signal processors, vector processors, or shared memory. An interconnect fabric can be any type of interconnect. 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 (node or fabric interface) includes a VHDL wrapper that implements the SVI encapsulation logic. During the hardware implementation, the logic described within the encapsulations from both sides of the SVI is combined and optimized using synthesis tools to the greatest extent possible, This process may cause some of the signals defined for the SVI to become implicit in the remaining logic. What remains of the SVI is 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 designed to be general enough to handle different interprocessor communication paradigms. Some interconnect networks support a message passing paradigm to interprocessor communication, while others support a global shared memory paradigm. In some cases there is synchronous operation between the internal node and the interconnect fabric, while in other cases the internal node and the interconnect fabric operate asynchronously. The SVI is by definition synchronous; that is, each word of SVI data is transferred synchronously with the SVI clock. Support for asynchronous operation between an internal node and the fabric interface must be handled by the SVI encapsulation logic.

As shown in Figure 4 - 3, the data interface is partitioned into two unidirectional data interfaces: the Data Input Interface which receives incoming SVI messages, and the Data Output Interface which transmits outgoing SVI messages. The data interfaces are implemented with a master/slave pair: the SVI master is a data source to the SVI Data Output Interface, while the SVI slave is a data sink to the Data Input Interface. The encapsulation of a typical architectural element therefore contains an SVI master/slave pair. The advantage of partitioning the data path in this way is that it supports interface architectures with independent, concurrent data passing in both directions across the SVI. A bi-directional data interface can be obtained by using both unidirectional data interfaces controlled by the SVI master and the SVI slave.

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. This allows encapsulations with different data-path widths. SVI commands occupy the least significant byte of the data bus, and transfer information across the SVI that will be needed by the receiving encapsulation. The address and data, along with any other necessary information, are in the data stream following the SVI command. The SVI master encodes the data in the SVI message and the slave decodes the message properly. The SVI message source must know how its encapsulation will build the message and also know how the receiving SVI encapsulation will interpret the data words in the message.

Typically, users encode the data in the message in software on the originating processing element. However, for low-latency operation, the message building can be done in hardware. 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 multi-processor or cache support requirements. Users can easily add commands, providing previous encapsulations with access to the new SVI commands.

To supplement the signal/timing/protocol definition and support end users" modeling efforts, the appendix to this application note contains VHDL code templates for SVI encapsulations. These templates include the entities and architectures a designer would typically need to code an encapsulation. In section 4.4, links to the VHDL code for several of the encapsulations performed as part of the verification study are provided. The code provided for the HOTLink encapsulation and the encapsulated RNI bridge are executable provided the reader has access to the Synopsys Logic Modeling's Smart Model library. To date, LM/ATL has implemented several SVI encapsulations. An interoperability demonstration has been developed in which two processing elements, a custom vector processor and several interconnect fabrics (PCI, RACEway, Myrinet and one sensor interface (HOTLink)) were encapsulated. Several combinations of the processing elements and interconnects were then mixed and matched to demonstrate interoperability. The results, as shown in Figure 4 - 4 for an SVI encapsulated PCI bus versus a custom interface, demonstrate the ability to provide plug and play interconnect between different elements with minimal performance impact. In this configuration, for data transfers of more than 256 elements, the performance impact is less than 5% of peak bandwidth.

In summary, the SVI is a critical element of the RASSP model-year architecture; it guides users in developing architecture elements that can be easily reused and upgraded. It must be used prudently, balancing the immediate performance impact against the future ability to upgrade to a new processing node, internal or external interconnect fabric.

The RNI consists of 2 encapsulated fabric interfaces on either side of an encapsulated bridge element. The fabric interfaces implement the two specific interfaces to the interconnect fabrics. The bridge may be between an internal and an external interconnect fabric or a it may be between two external interconnect fabrics. The actual bridging function is performed by the RNI bridge element, which consists of a buffer memory to facilitate asynchronous coupling between the two interfaces, and a controller which coordinates data transfers and provides flow control. The bridge element can be implemented via custom logic (e.g. FPGA, ASIC) or a programmable processor.

4.4.1 Introduction

Several encapsulations were done for the Model Year Architecture Hardware Verification effort. These include encapsulations of internal nodes, multidrop buses, sensors and networks. First, how to determine which architectural interfaces to encapsulate will be discussed. Following that there is a short description of the encapsulations which have been performed at LM/ATL. At the end of each description is a link to the complete application note for each encapsulation.

To apply the Model Year Architecture, the designer performs the following steps:

• Select the high payoff interfaces for encapsulation
• Research existing encapsulations to find examples that are similar to new design
• If a similar design is found, modify it to meet new requirements. If not, start with templates.
• Develop and validate a virtual prototype

There are basically three places to look for upgradeable interfaces as shown in Figure 4 - 6.

• an internal node or its associated internal interconnect fabric
• an external interconnect fabric
• an external device (peripheral)

4.4.2.3 Use of templates

• Visual HDL - to capture the VHDL
• QuickVHDL - to simulate and validate the design
• Synopsys - to synthesize the design implementation
• Various other hardware tools to support FPGA or ASIC - based implementation (Refer to the CAD System Description document for the complete list of tools used in the RASSP program)

The savings comes when the internal node or the fabric interface is upgraded, which is the second aspect of the development time. For example, assume there exists an encapsulated internal node and an encapsulated fabric interface, and that the designer is upgrading the internal node. The encapsulated fabric interface remains essentially the same, and the new node is encapsulated. It is anticipated that this will take less time than doing another custom interface because it is not necessary to write new drivers for the fabric interface. It is also not necessary to learn the protocol of the fabric interface. Furthermore, once the new internal node is encapsulated, it can be interfaced to any other encapsulated fabric interface. If there are 10 encapsulated interfaces, one needs only to encapsulate the internal module once to interface it to all of the fabric interfaces. If all of the interfaces were custom interfaces, one would need to design 10 different custom interfaces to achieve the same result. Clearly, this reduction in the number of integrations required from the order of N² to N equates to a significant savings in development time.