[Product Innovation]
Switch-Fabric Architecture Targets Next-Generation Communications Platforms
By using paired links and bridge and star devices running full duplex at 622 Mbits/s, 2.5-Gbit bandwidth is realized with low implementation costs.
Bus systems based on standards like PCI or H.110 are widely deployed in communications equipment. But such architectures will eventually run out of gas. It's true that PCI-based bus systems have progressively moved toward higher bandwidths—from 32-bit, 33-MHz systems at 133 Mbytes/s to 64-bit, 133-MHz systems at 1.066 Gbytes/s. With each of these advances, though, devices remain connected to a bus that, by its very nature, is shared. So, each device must wait its turn. This calls for some kind of arbitration because only one device can talk at once. Also, bus systems just don't meet next-generation requirements for converged data, voice, or video networks.
Fortunately, there's an alternative to simply cranking up the clock further or widening the bus beyond 64 bits. StarGen is introducing a switched, point-to-point approach that overcomes many limitations of the bus-based architectures. To boot, the new architecture preserves compatibility with older bus-based systems.
The StarGen switch fabric fulfills a role that's roughly coincident with the backplane (Fig. 1). Furthermore, it provides a compatible migration path from existing bus-based standards. Applications for the StarGen switch fabric include DSL access multiplexers (DSLAMs), voice-over-IP (VoIP) gateways, and edge-routers/switches. The switch fabric may find other applications in cable head-end systems, wireless base stations, and computer telephony platforms.
A star and a PCI fabric bridge are being introduced as basic building blocks of the StarGen switch fabric. These devices comprise the first phase in fulfilling StarGen's objective of establishing an open, widely adopted interconnect standard. By providing open access to the technology specification, third parties will be able to develop complementary products and expand market coverage.
The PCI fabric bridge interfaces 64- or 32-bit PCI buses operating at 66 or 33 MHz to the StarGen switch fabric (Fig. 2). Designated as the SG 2010, it converts the PCI protocol into the StarGen protocol, creating frames that are essentially packetized transactions. Those frames are routed out over one of the two serial links on the bridge. The links can be used either independently or bundled. When used independently, they provide two independent connections in a fabric. When bundled, they operate as a single, fast link to achieve 5-Gbit/s, full-duplex communication (see "8B/10B Encoding,").
The 2.5-Gbit/s, full-duplex links comprise four aggregated 622-Mbit/s LVDS pairs. A serializer/deserializer (SERDES) is used on each link to convert a parallel, on-chip data stream to the transmitted serial stream off chip. The SERDES reverses the process to receive the incoming serial data stream, recovering the embedded clock and converting it back into a parallel data stream. Power consumption is approximately 2 W.
The PCI fabric bridge performs two principal functions. It supports legacy-address-routed traffic, which provides 100% compatibility with existing PCI software. It also provides a fabric-native path and multicast routing capability. Plus, the PCI bridge fabric can isolate address ranges and perform address translations. It's 5-V tolerant and compliant with the PCI local bus, rev 2.2 specification.
The PCI fabric bridge supports both "transparent" and "nontransparent" bridge functions. As a transparent bridge, it adheres to the PCI-to-PCI Bridge Architecture Bus Specification of the PCI Special Interest Group. As a nontransparent bridge, it can be used to distribute processors around a PCI hierarchy with each processor assigned an independent local address space.
The PCI fabric bridge can connect to local bus interrupts and transport those interrupts across the fabric. When they arrive at another bridge at the other edge of the fabric, these interrupts can be converted to interrupt assertions at that local bus.
The PCI fabric bridge interfaces to the star fabric through two 2.5-Gbit/s, full-duplex serial links. The SERDES converts the serial data streams to parallel streams and passes them to the link buffers. The star protocol frames are converted to PCI traffic and transferred to the PCI buffers, and then on to the PCI bus through the PCI interface. For traffic flowing from the PCI to the fabric, the process occurs in reversed order. The bridge also interfaces to an SROM to preload configuration registers, and an EPROM interface capable of providing BIOS code.
The star performs the switching function within StarGen's switch fabric (Fig. 3). Designated the SG 1010, it provides six serial links. Each link comprises four aggregated 622-Mbit/s, LVDS differential pairs. Each is capable of 2.5-Gbit/s, full-duplex communication, for an aggregate bandwidth of 5 Gbits/s per link. Two of these links can be bundled to create a 5-Gbit/s, full-duplex link to another device.
Every link has a SERDES for converting the serial data streams to parallel form for on-chip transport. Separate buffer queues are maintained at each outgoing port for each incoming port and each class of service. This design prevents head-of-line blocking. Multicast tables are maintained in the switch for sending single data streams to many destinations. Traffic other than multicasting uses source-based routing and doesn't require routing tables within the star. Initialization is supported through the SROM interface.
The switch is nonblocking and can simultaneously transmit and receive on all links. In other words, traffic on one port doesn't block traffic on another port. Power consumption is approximately 2.5 W.
The StarGen switch fabric can free telecommunication systems from the need for independent buses to handle voice and data buses, as is the case with H.110 and PCI. Voice traffic is eight deterministic bits of data every 125 µs, something not particularly demanding from a bandwidth point of view. But when someone tries to move a 100-Mbit file, you don't want that to hinder voice delivery. The challenge then is to deliver real-time data traffic in the presence of asynchronous, best-effort, delivery traffic that's so common in the computing/data-networking world. You want deterministic delivery of this isochronous traffic (voice) even though some devices in the system are trying to use every bit of bandwidth.
Reprints
