Archives | Feedback

The cabled serial bus technology with the IEEE number 1394 is well known in the consumer electonics industries as "i.Link," or as "Firewire" by Apple. What is not so well known is an implementation of the bus that does not use cables, but instead just two common conductor etch runs across industry standard backplanes or custom backplanes. This implementation has most of the features of the cable implementation including:

• High performance
• Isochronous delivery service support
• Packetized data delivery
• Memory-type architecture supporting direct memory access (DMA)
• Peer-to-peer architecture
• Card-in-slot backplane topology
• Most of the hardware and software created for a cable implementation is directly usable for a backplane implementation

IEEE 1394-1995 is an open industry standard that has been adopted by the consumer electronics and personal computer (PC) industries. The standard also calls out an industry standard way to implement a 1394 bus across several of the industry standard backplanes using just two pins on the backplace motherboard (two signals.)

This lessor known environment defined in IEEE 1394-1995 is typically the familiar "card-in-slot" card cage environment typified by euro-card VME card cages (see Fig. Backplane Environment) or the PCI slots in a personnel computer. Unlike the cable environment, this is a true multi-drop bus with every node connected to the same two electrical conductors. When originally defined the backplane environment used the standard backplane technologies of TTL, BTL, and ECL to define the timing and data rates possible. This resulted in the standard backplane rates of S25 or S50 (49.152 Mbit/s), slower than the cable rates. This was to accommodate the single-ended driver technologies used in the standard backplanes in use at the time of definition. Note that the backplane physical layer devices (PHY) from Texas Instruments allow the higher rate of S100 for those customers willing to verify timing is met on their backplane implementation at that rate.

Like cable implementations, backplane implementations may also be hot-pluggable, but depend on the design of the transceiver and connector chosen for this to function correctly. The protocols defined at all the higher levels in the 1394-1995 standard are the same between the backplane and cable environments, but differ at the physical layer, and the software processes that depend on the broadcast self-ID packets of the cable environment. In the backplane environment these self-ID packets do not exist. Instead of being reassigned each bus reset like in the cable environment, the node numbers in the backplane are typically chosen based on the geographic address assigned to the slot where the card is inserted.

The physical layer in the backplane environment is implemented in such a way as to have a fixed arbitration time and a fixed arbitration "gap" time regardless of the number of nodes on the bus. This may be done since the length of time for a signal to propogate from one "end" of a backplane to the other end is fixed since the size of the backplane is fixed. However the cable environment may have nodes added to it, changing its topology. The physical layer in the cable environment must be implemented in such a way as to depend on the time for a signal to travel from the two nodes furthest away from each other on the bus. The arbitration time and arbitration "gap" time therefore depend on how many "hops" (spanning cable connections) are in a bus. For this reason in the cable environment there is a decrease in efficiency as more hops are added to the bus (the gap times increase, affecting the asynchronous service.) The result of this is that while the backplane environment is compatible with the cable environment at the packet level (software and link hardware) it is not compatible at the arbitration level or speed rates. This means a backplane bus and a cable bus may not be electrically connected together, but must be bridged together through specialized hardware and/or software (see Fig. of Control Bus Application).

The isochronous delivery service for backplanes is similar to the cable environment, as is the packetized data delivery, and DMA supporting memory architecture with peer-to-peer support. Because of these similarities, and a very similar PHY-Link interface on both the backplane PHY and cable PHY implementations, the majority of both hardware and software created for one implementation may be used on the other. These likenesses allow for the economies of scale of the PC and consumer electronics industries and access to the cross-pollination effect of innovations created in other industries (there are currently over 70 specifications that exist or are being worked in the IEEE 1394 community.)

The first applications that have appeared for the backplane implementation have been as either as control bus or as a side-channel built-in test bus. For example, in the current wireless market there is an intense push to handle more calls, offer more coverage and provide more services, while making the transition to higher-frequency carriers (for third-generation services.) All this is leading to more pressure for more bandwidth across the main data pipe in a system while demanding lower costs to support more base stations. In analyzing the data flow across such a backplane, it is often the case that the control signals being sent across the big pipe of the parallel backplane take much more bandwidth than it would seem from the amount of bits being moved. The protocol overhead to send these typically small packets can chew up unforeseen bandwidth and introduce unwanted latency.

This problem was recognized when many of the standard backplanes were defined. The solution chosen was a side-channel serial bus that was allocated two lines in the standard (such as SERA and SERB in VME64 or SB0 & SB1 in FutureBus+). These lines can be used in existing backplanes by the backplane implementation of IEEE 1394 to carry the small payload size, relatively low bandwidth control signals. This control traffic is a good fit for the asynchronous service which will verify receipt of each packet. The bandwidth formerly used by the control signals on the main parallel data backplane bus may now be recaptured to provide more data bandwidth with less asynchronous latency. This back channel is also useful for the separate path it creates for built-in test purposes and redundancy within a card cage. The side-channel serial bus may be used to initiate a periodic built-in test. If a card fails, a redundant card may be switched in using the serial bus and the failing card switched out.

Expanding onto the serial bus has the additional benefit that much of the software and experience learned on the backplane version of 1394 will be directly applicable to a cable implementation of 1394. If it is determined in the future that the data rates across the backplane version are not sufficient for the next intended application, then much of the hardware and software down to the physical layer may still be used in a cable implementation with its greatly-expanded bandwidth.

Summary:

i.Link's architectural elegance, cost-effective high performance, and market acceptance make it a compelling technology. The architecture includes both guaranteed bandwidth (isochronous) and guaranteed packet delivery (asynchronous) services, peer-to-peer communication via DMA within either a backplane environment or cable environment. With only two conductors needed to implement the backplane serial bus it allows many possibilities for side-channel buses or redundancy within high reliability systems.

Texas Instruments offers a wide selection of cable PHYs, link layers, a backplane PHY, and software service and support.

Analog Main | Product of the Week | Columns | Editorial | Tech Notes

		Click here to get your listing up.