A new reference design from AMIRIX Systems and Xilinx
allows aggregation of multiple Gigabit Ethernet ports to SPI-4.2, with frame-mapped GFP.

Although the existing transport network infrastructure was built for carrying voice, it now carries other types of traffic, such as video, data, and storage. Network services like asynchronous transfer mode (ATM) carry this traffic with varying degrees of overhead and impact on performance.

The Generic Framing Procedure (GFP) – as defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T) Recommendation G.7041 – offers another solution. GFP defines framing methods for mapping different traffic types directly to the octet-synchronous optical network (SONET) infrastructure.

GFP comprises two stages: client-specific mapping of different protocols into frames, and common procedures to adapt frames to an octet stream. The flexibility of FPGAs makes them a natural solution for the first stage, in which supporting a variety of different interfaces is necessary. A multiplexer can then aggregate the resulting GFP frames and send them to a framer for adaptation to SONET. Framing and aggregation of Gigabit Ethernet frames to a SPI-4.2 interface, as shown in Figure 1, will be a very common building block.

The Xilinx Virtex-II Pro™ FPGA offers a very powerful platform on which to build such a system. The Gigabit Ethernet and SPI-4.2 interfaces can be driven directly by MGT and LVDS I/O, respectively, and proven IP cores for these functions exist.

Using the programmable array for framing and multiplexing allows a great deal of flexibility, which you can use to support different algorithms for application-specific functions such as mapping, scheduling, and flow control. You can also include a control plane subsystem in the same device using the embedded PowerPC™. Such a solution has been developed and tested by AMIRIX™ Systems, which Xilinx now offers as a free reference design.

Architecture and Data Flow
The basic architecture of the Ethernet Aggregation Reference Design (EARD) is shown in Figure 2. Although the architecture shown in the figure is for a four-port system, the EARD can also be configured for eight ports. In the egress direction, frames arriving at the Ethernet ports are multiplexed and segmented into the SPI-4.2 interface. Segments are de-multiplexed and reassembled in the ingress direction.

Egress access to the SPI-4.2 interface is scheduled according to a simple round-robin algorithm, with a one-to-one mapping of Gigabit Ethernet ports to SPI-4.2 channels. We should note that EARD traffic directions (ingress and egress) are defined from the point of view of a SONET framer. The opposite sense is used in the GFP standard.

GFP/Pass-Through/Loopback Modes
When in GFP mode, the EARD supports frame-mapped GFP for Ethernet medium access control (MAC) payloads, as defined in Section 7.1 of the GFP standard. The EARD adds headers in the egress path and strips them in the ingress path; header contents are set using compile parameters. To correctly encode the length during GFP encapsulation, an entire frame must be buffered before forwarding. This store-and-forward approach is used in both egress and ingress directions when GFP framing is enabled.

When GFP framing is disabled (passthrough mode), a lower latency approach is used. Forwarding begins upon receipt of an entire SPI-4.2 segment during egress, or when reaching a programmable threshold during ingress.

The EARD can also be configured in loopback mode, in which traffic at each port is fed back to itself. The SPI-4.2 sink client interface is connected directly to the SPI-4.2 source, and Gigabit Ethernet traffic is looped back through the egress and ingress FIFOs.

Interfaces
Both the Gigabit Ethernet and SPI-4.2 interfaces are implemented using Xilinx IP cores. Features of these interfaces include:

Gigabit Ethernet

• Core – Xilinx Gigabit Ethernet MAC revision 3.0
• Physical Interface – Built-in physical layer device (physical coding sublayer [PCS]/physical medium attachment [PMA]) using MGT
• Frame Size – Support for jumbo frames
• Flow Control – Support for incoming and outgoing pause frames; pause frames have fixed delay (compile parameters) triggered by a programmable egress FIFO threshold
• Statistics – Traffic statistics maintained by the MACs, accessible through the management interface.

SPI-4.2

• Core – Xilinx SPI-4.2 revision 6.0
• Phase Alignment – Dynamic phase alignment
• Flow Control – Sink status (ingress path) is reported based on programmable ingress FIFO thresholds; source status is not used.

Control Plane
EARD control plane software runs on an embedded PowerPC, clocked at 250 MHz. It manages system initialization and provides an external management interface. This management interface is based on a simple serial port, which is useful for demonstration purposes. In an actual application, a more sophisticated interface such as PCI or RapidIO would be more useful.

To facilitate porting to different physical interfaces, the management interface software is based on a generic message passing protocol. You can support changes to the physical interface by modifying a few lowlevel routines.

Because the control plane is a relatively small part of the system, we preferred an ISE-centric design flow. Thus, the control plane was built using EDK, but is exported as a sub-module and integrated into the EARD as a core.

Validation
We performed all EARD validation in a Xilinx XC2VP50 device. The four-port version should fit in an XC2VP30, and with some customization (such as running control plane software directly from cache), we expect that the eight-port version can fit in an XC2VP40. Table 1 shows the approximate resource usage.

Table 1 – EARD resource usage

	Block RAM	4LUT	FF	DCM	GCLK	MGT	GPIO
Four-Port	123	18500	18100	5	11	4	96
Eight-Port	215	29800	27300	5	11	8	96

The EARD was tested through a combination of simulation and hardware validation. The various configurations were subjected to extended heavy traffic, as well as tests focused on exercising segmentation and reassembly, scheduling, and error handling.

We performed hardware validation using a Xilinx ML324 board, as shown in Figure 3. LVDS headers were used to loop back the SPI-4.2 interface, and the Gigabit Ethernet ports were daisy-chained. We used an optical network interface card (NIC) in a Linux™ host computer, as well as laboratory network analysis equipment, to generate and check traffic. The EARD carried hundreds of millions of Ethernet frames of varying sizes at data rates well over 900 Mbps on all ports.

Conclusion
The Ethernet Aggregation Reference Design makes an excellent starting point for designs requiring Gigabit Ethernet aggregation, particularly those involving GFP framing. This reference design is described in Xilinx Application Note XAPP695 and can be downloaded from the Xilinx website at www.xilinx.com/esp/networks_telecom/optical/xlnx_net/eard_download.htm.

Using the EARD in real applications will likely involve some degree of customization to meet system needs. Examples include:

• Changing SPI-4.2 configuration options to comply with PCB requirements and SONET framer specifics
• Replacing the management interface with something more suitable for an embedded system, such as PCI or RapidIO
• Modifying the algorithms used for scheduling, mapping, and flow control.

Printable PDF version of this article with graphics.  (3/10/04) 218 KB