1. Background

IEEE 1394 is a serial bus standard that was collaboratively developed by Apple, Intel, Texas Instruments, Microsoft, Sun Microsystems, Compaq, and National Semiconductor. The term FireWire is a trademarked name used by Apple to market their 1394 based products. “FireWire” and 1394 will be used synonymously in this document.

“FireWire” was developed for the purpose of creating an inexpensive alternative to parallel buses. Some problems with parallel buses is that they are confined to a small physical area, do not have plug and play support, and do not support isochronous applications. Thus, the 1394 bus was engineered to solve these problems and present solutions to other bus issues.

2. High-Level Overview

IEEE 1394 is similar to the well-known Universal Serial Bus (USB) standard that is available in today’s personal computers, in that many of the devices one connects via USB today can also be connected via IEEE 1394 (provided the device supports IEEE 1394). However, because of the increased transfer rate (1394 supports transfer speeds up to 400 Mb/s, and even higher rates have been proposed for the next revision of the standard), many additional devices can be connected to a 1394 bus. These could include devices like hard drives, motion video recorders, sound mixers, and so forth.

In addition, 1394’s support for isochronous transactions is ideal for the connection of devices that send a fixed amount of data in each transaction, where the transactions are equally spaced apart. An example of such a device would be a security camera that captures a fixed number of pixels per n seconds.

There are many other benefits of the 1394 technology, such as the huge address space available (a theoretical address space of a whopping 16 exabytes, i.e. 16×10¹⁸ bytes), the limitless number of devices that can be connected to a single computer (1024 buses possible, with 64 devices possible per bus). These features, along with the scalability mechanisms to handle the huge numbers of devices (for example, autodetection/autodiscovery of connected and disconnected devices, “hot-swapping” capability of devices, etc.) make IEEE 1394 a very versatile standard.

3. Description of IEEE 1394’s Subsystems

Figure: IEEE 1394 Overview

The IEEE 1394 standard is a comprehensive system architecture description, describing not only the data communication protocols to be used across the bus, but also stipulating the number and type of control registers, the addressing mechanism and address space of each device and each bus in an IEEE 1394 system, and many other parameters. Although we will focus only on the data communications protocols, we will touch briefly on the other aspects as they relate to those protocols. The labelled elements in the figure above gives an illustration of the various parameters specified in the standard, and the arrows indicate their approximate “conceptual” location.

We begin by giving an overview of the various general parameters in an IEEE 1394 system, and then concentrate on describing the physical layer specifications and data transmission schemes.

3.1 Serial Bus Parameters

3.1.1 Bus Speed and Data Payload Size

Asynchronous		Isochronous
signalling speed	max. data payload (bytes)	signalling speed	max. data payload (bytes)
100 Mb/s	512	100 Mb/s	1024
200 Mb/s	1024	200 Mb/s	2048
400 Mb/s	2048	400 Mb/s	4096

3.1.2 Signalling Mechanisms

IEEE 1394 specifies two signalling mechanisms across the bus: common mode (DC) and differential. DC signalling means that a logical 1 is represented as a positive voltage, and a logical 0 is represented as zero voltage. In 1394, it is used for three purposes: device attachment and detection, speed signalling, and power management (suspend-resume). Differential signalling means that logic values are represented by the difference between two wires: if the voltage on one wire is greater than the next, then a logical 1 is represented, otherwise a logical 0 is represented. The advantage of this method is that power consumption is greatly reduced. As such, 1394 uses differential signalling for the majority of operations, such as bus reset, arbitration, configuration commands, and data packet transmission.

The actual signal encoding uses a scheme known as Data-Strobe bit-level encoding, developed by SGS Thompson. This encoding is a rather simple scheme — due to the high reliability of the IEEE 1394 cable links, more complicated encoding schemes are rendered unnecessary, and the only reason for using any encoding at all is that D-S encoding doubles the jitter tolerance on the signal lines.

3.2 Address Space and Bus Control

Figure: IEEE 1394 bus addressing scheme

The addressing space and control registers are worth mentioning. Parts of the 1394 standard are based on the IEEE 1212 standard, “Information Technology Microprocessor Systems Control and Status Registers (CSR) Architecture for Microprocessor Buses”. This standard’s main characteristics include standardized addressing and transactions. The CSR architecture handles both 32 and 64 bit addressing models. The 1394 bus supports only a 64 bit fixed addressing model. The bits are partitioned as follows: 10 bits for network IDs, 6 bits for node IDs, and the remaining 48 bits for memory addresses. As a result, 1023 networks of 63 nodes can be addressed. Each of these nodes have 281 terabytes of memory. (A node refers to a bus entity, or device) The total addressable space is therefore approximately 16 exabytes.

3.3 Protocol Model Overview

At this juncture it is useful to further elaborate upon the two types of transfers that IEEE 1394 supports: asynchronous and isochronous. An asynchronous transaction guarantees data delivery. These transfers do not require a constant bus bandwidth and thus do not require regular use of the bus. Essentially, reliability takes precedence over timing with asynchronous transactions. As a result, retransmissions are allowed. There are three basic types of asynchronous transactions: read, write, and lock. Since data delivery is paramount for asynchronous transactions, the bus protocol is complex. A transaction begins with a request signal from a requester node. This request signal is received by a responder node which then sends back a response signal to complete the transaction.

Conversely, isochronous transactions require data delivery at constant intervals. As a result, regular bus access is required. Thus, confirmation of data delivery is not necessary. These facts lead to the simpler bus protocol. The requester node merely sends a request signal to the responder at a regular interval. The responder does not send any sort of acknowledgement back to the receiver.

The difference between asynchronous and isochronous transactions can be likened to the differences between TCP and UDP signalling in the IP network architecture. Like TCP, 1394’s asynchronous transactions are request-reply based and have some quality of service guarantees (packet acknowledgements, retries, etc.). On the other hand, isochronous transactions are more like UDP – they are request-only, and neither the initiator nor the receiver of the transaction really cares that much if the data is lost. The idea is that the number of successful isochronous transactions will greatly outweigh the number of unsuccessful ones.

3.3.1 Layers in Protocol Model

There are a number of layers in the 1394 protocol model, and although, as data communications engineers, we are primarily concerned with the physical layers, it is useful to have some knowledge of the other layers, because they interact heavily with the physical layer. The physical layer interacts heavily with the link layer, which is responsible for setting up the software driver requests into valid 1394 packets to be sent across the wire. In addition, the bus management layer depends heavily on the physical layer for correct operation: this layer is responsible for assembling bus arbitration packets to detect and prevent multiple users on the bus, for tuning the bus speed, and for controller isochronous transfer times.

The physical layer describes the electrical interface for the IEEE 1394 standard. The actual medium used in the physical layer is a six-pin twisted-pair crossover-type cable, such that the four data lines are paired off into “A” and “B” pairs, suitable for differential signalling use. The 1394 standard also specifies signal pair attenuation parameters for different signalling speeds, as follows:

speed	attenuation (dB)
100 MHz	< 2.3 dB
200 MHz	< 3.2 dB
400 MHz	< 5.8 dB

These figures are given for a typical cable length, which is 4.5 m long.

The cabling diagram is as follows:

Figure: IEEE 1394 cabling crossover diagram.

3.4 Physical Layer Description and Data Types

The physical (PHY) layer itself consists of physical signalling circuits and logic. This circuitry is responsible for power-on initialization, bus arbitration, reset-sensing and data signalling. Each device is also required to keep its PHY circuits powered up at all times even when the device is not in use, to ensure that the “repeater” function of the standard is met.

In addition to the regular data packets, there are several “special” PHY packets to deal with configuration and arbitration information passing. These packets are grouped into four categories: the self-ID packet, the link on packet, the PHY configuration packet and the extended PHY packets. We describe these packets briefly here. We then describe the transmission of normal, data payload-bearing PHY packets.

3.4.1 Self-Identification Packet

The PHY unit sends these packets during the self-ID phase of arbitration, or when other devices on the bus send a “ping” packet. Up to three self-ID packets may be sent in response – the exact number is implementation dependent. Along with other parameters, the self-ID packet(s) contain information about the maximum communication speed supported by this device, the port connection status, and power consumption characteristics.

3.4.2 Link-On Packet

The purpose of the link-on packet is to inform the recipient PHY that it should expect to receive additional packets. As such, the link-on packet consists only of the recipient’s PHY number. The packet is broadcast to every node on the bus, and the recipient whose PHY number matches the number specified in the packet is required to set its internal state to LINK_ON.

3.4.3 PHY Configuration Packet

The PHY configuration packet is used to configure various parameters of the bus in order to improve performance. The parameters that are configurable are the “gap count” (i.e. delay between isochronous packets) and the setting of the “root” node of the bus.

3.4.4 Extended PHY Packets

The purpose of the extended PHY packets are for other nodes on the bus to query the status of the target node, by means of sending these packets. The “ping” packet described earlier is an example of an extended PHY packet; the recipient node sends a self-ID packet, with the response time field in this packet filled in. Another useful extended PHY packet is the remote access packet, which lets a remote node read any of the target PHY’s status registers — these are reported back to the initiator PHY by means of another extended PHY packet, the remote reply packet.

Remote nodes are also permitted to ask a node to execute one of five operations (commands) by sending a remote command packet. The permitted operations are: disable and enable port, enable and disable suspend mode, and clear faults. Naturally, the recipient node sends a remote confirmation packet to indicate to the initiator when the requested command has completed.

The final type of extended PHY packet permitted is a resume packet — there is no reply packet associated with this command, however. The purpose of the packet as the name suggests is to instruct the recipient to resume from suspend mode.

3.4.5 Data PHY Packets

3.4.5.1 Asynchronous Packets

Figure: An example of asynchronous packets (in this case, a split write transaction is shown).

As described above, asynchronous transactions are the more complex of the two transaction types supported by IEEE 1394. As can be seen from the figure above, the data payload consists of a very small portion of the physical layer packet; the bulk of the packet contains arbitration and transaction type information.

The various fields aside from the payload are:

• destination address – consisting of target bus, node, and device within that node
• source address – consisting of the source bus and node address
• transaction type – type of packet being sent. There are twelve packet types possible, but a discussion of them is beyond the scope of this document.
• transaction label – allows matching of requests and acknowledgements (like a sequence number
• response code – part of a packet sent in response to a request for “completion status”.
• CRC – standard error-checking checksum for a request or response packet.
• acknowledge code – returned by the receive of a packet to verify receipt.
• acknowledge parity – a simple parity bit for the acknowledge code packet, since full CRC would be too expensive for a simple acknowledge code.

3.4.5.2 Isochronous Packets

Figure: The packet used during isochronous transactions. There is no acknowledgement or response permitted in isochronous transfers.

As can be seen in the figure, isochronous packets do not require a response from or acknowledgements from the receiver, so the packet format is simple. The various fields in the packet are:

• channel number – since isochronous transactions are permitted to be multicast, isochronous senders and receivers use a shared channel number, so that each participating node does not need to keep a list of all other participants.
• transaction type – identification code as isochronous packet (fixed at 0xA)
• data
• CRC – standard checksum for validation of header and data

Since isochronous transactions are of fixed duration in time, this permits different packet sizes depending on the bus speed. In particular, for every additional 100Mb/s increase in bus speed, the data packet can be expanded by an extra 1024 bytes.

It should be noted that although conceptually the checksum forms a single field in the data packet, in reality the checksum is sent in two parts. A header CRC is computed first and sent before the data but after the header, and a data CRC checksum is computed later and sent after the data.

4. Design Choice Justifications

Each of the collaborating groups responsible for developing FireWire had reasons for the choices made in designing the protocol. Consequently, there are too many for the scope of this document. However, some of the main justifications, namely fairness and cost-effective scalability are worth discussion.

Fairness refers to the scheme where all devices connected to the 1394 bus are equally able to access the bus. In other words, all nodes on the bus are able to arbitrate within a bounded time period such that no “starvation” (a node is prevented from accessing the bus), occurs. The order in which the bus is granted to the devices is arbitrary, but each node is given fair access.

Despite the fact that FireWire would provide a high-speed serial bus and thus improve performance of peripherals, the standard had to be practical. Consequently, scalability is cost-effective. Some buses require that all devices using the bus must be connected to an interface card in the computer which itself has a limited number of ports. FireWire devices can be plugged into the computer via an interface card, or they can be connected to a second port on another 1394 device. The second port on the already connected device can be configured as a repeater thus making this possible.

5. Further Information

5.1 IEEE 1394 (FireWire) Applications

Initially, a majority of the peripherals that supported FireWire were consumer electronics namely, the digital camcorder. As a result, home users are now able to edit and produce digital video (DV) clips on their own computer rather than hiring a service. Of course, this is presuming the user has the proper software installed in addition to supporting 1394. At this time, 1394 could be implemented on a computer by installing a 1394 interface card into a PCI slot.

Recently, 1394 has been integrated into computer motherboards and thus provide 1394 support for other hardware and peripherals such as hard drives, CD-ROM/DVD-ROM drives, scanners, printers, etc. A current example of a 1394-integrated computer is Apple’s new G4 system. Other manufacturers have also released systems that have 1394 integrated into the motherboard.

However, the applications of FireWire extend beyond the home computer. Aside from computers and peripherals, FireWire is currently being used in home electronics/audio-visual equipment, automotive applications, and in telecom/networking to name just a few. Clearly, 1394’s scalability and bandwidth capabilities are appealing attributes that many different technologies are tapping to create new generation devices which are more efficient than their predecessors.

5.2 Standards Documents

There are a number of editions of the IEEE 1394 standard. The original standard was IEEE Std 1394-1995 but it had many deficiencies and ambiguities, many of which were known at time of publication, but the decision was made to publish the standard and then later release an amendment to it. As such, the recently released IEEE Std 1394a-2000, IEEE Standard for a High Performance Serial Bus—Amendment 1, published in March 2000, addresses most of these issues.

6. Resources Used

Anderson, Don. FireWire System Architecture. Addison-Wesley, 1999.