The FireWire protocol, developed in 1995 by Apple, is now supported by other device manufacturers, including Sony. In this article, Larry Loeb gives you the scoop on this bus/hardware protocol.
Apple Computer has included FireWire ports on all its computers since the introduction of the Blue and White G3. FireWire is a bus/hardware protocol designed for the high-speed transmission of data between two peer-to-peer devices. It serves as a digital link between the connected devices, which allows for better overall quality of transmission at the high speeds at which it operates. Apple originally developed FireWire in 1995, and several revisions later other device manufacturers, such as Sony, now support the protocol. In this article, I'll take a look at this protocol.
High-quality multimedia sources require a high-bandwidth bus for transport. FireWire (or IEEE 1394, its generic title) is just such a special-purpose bus. IEEE 1394 is a hardware standard as well as a software standard for transporting data at 100, 200, or 400 Mbps. Let's take a quick look at some typical multimedia bandwidth requirements by deriving what each of them requires in bits per second:
- · High-Quality Video Digital Data = (30 frames / second) (640 x 480 pels)
- · (24-bit color / pel) = 221 Mbps
- · Reduced-Quality Video Digital Data = (15 frames / second) (320 x 240 pels)
- · (16-bit color / pel) = 18 Mbps
- · High-Quality Audio Digital Data = (44,100 audio samples / sec) (16-bit audio samples) (2 audio channels for stereo) = 1.4 Mbps
- · Reduced-Quality Audio Digital Data = (11,050 audio samples / sec)
(8-bit audio samples) (1 audio channel for monaural) = 0.1 Mbps
It's easy to see that the current incarnation of Universal Serial Bus (USB), topping out as it does at 12 Mbps, won't work for even reduced-quality video. The need for an alternative bus was evident in 1995 when Apple first developed FireWire. The 1394 protocol is very scalable and offers the following features:
- · Provides for both asynchronous and isochronous applications
- · Allows access to vast amounts of memory-mapped address space
- · Allows peer-to-peer (hostless) communication
A 1394 cable contains two power conductors along with two twisted pairs for data signaling. Each signal pair is shielded; the entire cable is also shielded. The two twisted pairs used for signaling, called TPA and TPB in the formal protocol definitions, are bidirectional. TPA is used to transmit the strobe signal and receive data, while TPB is used to receive the strobe signal and transmit data.
The 1394 protocol is a peer-to-peer network with a point-to-point signaling environment. Each node on the bus may have several ports within it. A port acts as a repeater, retransmitting any packets received by other ports within the node. Because 1394 is a peer-to-peer protocol, a specific host isn't required. (USB, on the other hand, must have a host.)
As I mentioned earlier, the 1394 protocol supports both asynchronous and isochronous data transfers. Isochronous transfers are always broadcast in a one-to-one or one-to-many fashion. No error correction or retransmission is available for isochronous transfers. By design, up to 80 percent of the bus bandwidth can be used for isochronous transfers. Bandwidth is tracked by a node on the bus that has the role of isochronous resource manager. The maximum amount of bandwidth an isochronous device can obtain is limited only by the number of other isochronous devices that have already obtained bandwidth.
Asynchronous transfers are targeted to a specific node with an explicit address. They aren’t guaranteed a specific amount of bandwidth on the bus, but they can obtain arbitrated access to the bus (when the bus is in asynchronous mode). The maximum data block size for an asynchronous packet is determined by the transfer rate of the device. Asynchronous transfers are acknowledged and responded to, unlike isochronous transfers. Since acknowledgment is performed in asynchronous transfers (with isochronous, the data is just pumped out there), it’s possible to have an error-correcting protocol inserted at the acknowledgment step.
The take-home message of all this is very simple: If the data being sent is time-critical and error-tolerant (like a video or audio stream), then choose isochronous mode to transfer the data. If the data being sent isn’t time-critical and error-tolerant, then asynchronous mode—with the ability to include error correction—is the way to go.
The 1394 specification defines four protocol layers:
- · The physical layer
- · The link layer
- · The transaction layer
- · The serial bus management layer
The physical layer of the protocol includes the electrical signaling, the mechanical connectors and cabling, the arbitration mechanisms, and the serial coding and decoding of the data. Electrical power in the cable is specified at 8 VDC to 40 VDC (at up to 1.5 amps) .The cable itself is used to maintain a device's physical layer continuity when the device powers down or malfunctions. Keeping a good electrical contact is critical for a serial topology’s stability. The cable is also used to provide power for devices connected to the bus.
Configuration consists of bus reset and initialization, tree identification, and self-identification. Configuration of the bus occurs automatically whenever a new device is plugged in. Configuration proceeds from leaf nodes (those with only one other device attached to them) up through the branch nodes. Reset is signaled by a node driving both TPA and TPB to logical 1 (the “on” state).
After reset, all leaf nodes present a Parent_Notify signaling state on their data and strobe pairs. This is the start of the tree-identification phase. Until this phase is completed, the network is nonhierarchical and resembles the physical layout of the cables. When a branch node receives the Parent_Notify signal, it marks that port as containing a child and outputs a Child_Notify signaling state on that port's data and strobe pairs. Upon detecting this state, the leaf node marks its port as a parent port and removes the signaling, confirming that the leaf node has accepted the child designation.
Two nodes can be in contention for root node status at the end of the process. If that happens, a random timer is used to settle on a root node. Also, a node can force itself to become root node by delaying its participation in the tree-identification process.
Once the tree topology has been settled, the self-identification phase begins. Self-identification consists of the following:
- · Assigning physical IDs to each node on the bus
- · Having neighboring nodes exchange transmission-speed capabilities
- · Making all the nodes on the bus aware of the topology
The self-identification phase begins with the root node sending an arbitration grant signal to its lowest numbered port. That port will assign itself ID 0 and propagate a self-ID packet up the chain to the root node. As it does, each node updates its internal ID counter by 1. After getting the ID, the root node will then continue to signal an Arbitration Grant signal to the currently lowest numbered port, and the process repeats itself. It continues until all ports on the root node have indicated a self-ID done condition. The root node then assigns itself a physical ID number 1 higher than the last number issued, always making itself the highest numbered device on the bus. During the self-ID process, parent and children nodes exchange their maximum speed capabilities.
The link layer is the interface between the physical layer and the transaction layer. This layer is responsible for checking received Cyclic Redundancy Checks (CRC), as well as calculating and appending CRCs to transmitted packets. Since isochronous transfers don’t use the transaction layer, the link layer is directly responsible for sending and receiving isochronous data. The link layer also examines the packet header information and determines the type of transaction in progress, passing the information up to the transaction layer.
The transaction layer is used for asynchronous transactions. Asynchronous packets have a standard header format, along with an optional data block. The packets are assembled and disassembled by the link layer controller. The 1394 protocol uses a request-response mechanism, with confirmations typically generated within each phase. Several types of transactions are allowed:
- · Simple quadlet (four-byte) read
- · Simple quadlet write
- · Variable-length read
- · Variable-length write
- · Lock
A bus manager has several functions, including publishing the topology and speed maps, managing power, and optimizing bus traffic. The topology map may be used by nodes with a sophisticated user interface that could instruct the end user on the optimum connection topology to enable the highest throughput between nodes. The speed map is used by a node to determine the speed it can use to communicate with other nodes.
In the five years since FireWire has become an IEEE standard, there have been various attempts to implement it. Not all efforts have been successful, leading to compatibility problems. It has taken a revision of the written standard and the further delineation of specifics for types of hardware to make FireWire a true standard. It has probably been only in the last year that FireWire has become a consumer-ready standard with occasional interoperability problems.
Learn more about it
If you want to learn more about FireWire, visit these sites:
- · ”IEEE 1394: A Ubiquitous Bus,” by Gary Hoffman and Daniel Moore
- · Embedded Systems’ “Fundamentals of FireWire”
- · Texas Instruments’ Technical Overview of 1394 High Performance Serial Bus