Firewire Bus (IEEE 1394)
By Ricardo Zelenovsky e Alexandre Mendonça on October 27, 2004


Introduction

In this article, we will talk about what is most modern in terms of external bus: the FireWire. The FireWire is a very high performance serial bus that makes the connection of different kinds of equipment possible, using a flexible topology and providing very attractive price. Our goal is to show an idea regarding the innovatory characteristics of FireWire, such as concepts of portals, bridges, nodes, virtual connection, etc.. We apologize for having left some gaps, but it is difficult to get technical information about the subject. A good part of the documents available had controlled access, what did not allow us a deeper study.

The FireWire bus, created by Apple in the beginning of the 90's, was adapted, in 1995, and standardized by IEEE 1394 norm. Its communication capacity can reach up to 30 times the USB speed (Universal Serial Bus). Its idea is similar to the USB: it has a simple interface simples capable of receiving up to 63 devices, such as disk drives, digital cameras, digital television, computers, etc, as shown in Figure 1.

 

FireWire
Figure 1: Example of equipment arrangements with FireWire.

Sony, Panasonic, Sharp, Canon and JVC were the first companies to release products with FireWire (around 7 million digital video coders - MPEG). The computer market is also supplied with models by Apple, Compaq, Sony and NEC. We also have been waiting for the availability of other models by other leading companies. Nowadays, Castlewood Systems develops a disk drive that directly receives the mass of data from a digital camera, that promises to eliminate the use of tapes in a high quality video studio.

As you can see, the FireWire is not a computer-only bus, since the video applications were the first to be benefited. However, the companies have gradually been adding, in the newer models, FireWire connectors in computers, as it is made for the USB. As in the USB, it is not necessary to initialize the machine to detect the FireWire connected devices, since they are also detected at the time of its physical connection, in application execution time.

The present FireWire products can operate in a rate of 400 Mbps (50 MB/s), against 12 Mbps (1.5 MB/s) of USB. Despite the USB specification revisions allow higher rates (USB 2.0 runs at 480 Mbps or 60 MB/s), the FireWire will not stop there: it should soon reach, with the aid of special fibers or wireless communications, speeds from 800 to 3.200 Mbps. Actually, it can run at 800 Mbps (100 MB/s) under the new IEEE1394b specification.

FireWire is, then, a nickname for a serial bus specified by IEEE, receiving the official name of IEEE 1394. An example of PCI, two or more electrically isolated FireWire buses can be connected by a special circuit, called bridge. Historically, its creation was in 1995 and it was introduced to society in February of 1996, when Peter Johansson, of Congruent Software, presented a work called "Serial Bus to Serial Bus Bridges" to a group of representatives of the big leading companies on the market, such as Phillips, Apple, NEC, Seagate, Sony, Sun, Samsung and Texas. This happening started a series of meetings to discuss technical questions not only to define the IEEE 1394-1 pattern (bridge between FireWire buses), but also to specify bridges to be responsible for the interface of the bus being studied with other buses. Those meetings also started to count, afterwards, with representatives of Intel, Microsoft, Canon, Compaq and Panasonic, among others. Although those specifications are not finished yet, the group always keeps a draft of the situation on the site http://grouper.ieee.org/groups/1394/1. So, some details shown here are subject to further revisions.

Definitions

With the new FireWire revisions working to make it a serial bus with better performance each day, the communication rate implemented by a bridge is flexibly programmable to be between S100 (100 Mb/s) and S3200 (3200 Mb/s), with accessible cost either to connect computer peripherals or appliances. According to the 1394 committee, other devices, such as digital video transmission, are still limited by an architecture and a definition of protocol to bridges that are incomplete nowadays. In fact, the bus physical specification was very simple. The most complex is to define the bridge patterns, what is being done by IEEE 1394-1 proposition.

To start a description of 1394-1 proposition, some definitions will be shown.

Firewire Bridge and Virtual Node ID

Figure 2 illustrates a very simple bridge model. As you can see, the 2 portals represented can exchange information synchronized by a single clock (notice the synchronism clock and the isochronal queues) or in asynchronous way (notice the request and response queues). Also by Figure 2, it is clear that the transactions of packets can occur bi-directionally, that is, from 0 to portal 1 or vice-versa. The choosing of the kind of communication (isochronal or asynchronous), as well as the communication rate, it is made by data structures contained on the Routing Control Table.

FireWire bridge
Figure 2: Simplified model of FireWire bridge, with only 2 portals.
 

Virtual Node ID

In a FireWire bus network, the node (connected devices) IDs have some interesting characteristics. One of them is stability in reset operation in the buses and stability in the path (it depends on the topology of the bus connection) used by the information packet. One and only one portal (called a) portal is the responsible for managing the designation of virtual nodes. Portal A is chosen, during a bus auto-identification phase (on the network initialization), as being, by simplicity, the one that has higher physical ID value. The auto-identification process works like this: each portal transmits at least 2 packets with information about itself to the other portals, including the physical ID used to choose a.So, after this process, all the portals can easily calculate the topology of the implemented network and internally keep registrations of this topology's information.

When a node is removed or added in some bus, a bus reset process is automatically initiated, starting a new bus and node auto-identification procedure. Connected devices easily detect the adding or removal of nodes, just by comparing the topology calculated after this reset with the topology calculated after the previous reset. There is also a periodical operation that serves to update the topological IDs, that is called refresh.

The Asynchronous Operation

FireWire bridges are considered inbound portals, due to the fact that they examine the bus to detect primary asynchronous packets (that start the protocol of a communication) sent by other buses. But the portal that transmits the primary packet is called outbound portal. Basically, there are 6 types of primary packets:

On an inbound operation, the bridges are constantly monitoring the bus searching for primary packets. At the moment that it finds a primary packet, the bridge examines the virtual node ID contained in the packet and verifies, on the network topology calculated after the reset, if the destination node of the transaction is "hanging" on one of the bridges' portal buses. If that happens, the destination portal receives the packet and starts an outbound operation to retransmit the detected primary packet to the buses hierarchically connected to it.

As an example, we take the topology shown in Figure 3. Five portals are represented in it, with the references "a", "b", "c", "d" and "e". The portal "α" in question is the "a". We suppose that N1 node wants to communicate with N2 node. Observing the figure, we conclude that the following steps are taken:

FireWire asynchronous operation

Figure 3: Example of topology with FireWire buses, portals, bridges and nodes.

Virtual 1394 Bus

In February of 1999 Subrata Banerjee, from Phillips, presented a study about how to connect portals without using wires. A FireWire with this characteristic receives the denomination "Wireless FireWire", Virtual FireWire or Virtual IEEE 1394.

First, the Virtual FireWire was motivated by the limitation of the specification 1394-1, where a bus can unite only 2 portals. In its virtual configuration, you can have a topology with a bus uniting multiple portals, as shown in Figure 4.

FireWire

Figure 4: Example of topology with a Virtual FireWire uniting the portals "a", "c" and "e".

As relevant Virtual FireWire operation characteristics, you have:

Besides, still in study, among many other characteristics:

Conclusion

A lot is being said about the FireWire. The first thing is its acceptability on the market. In fact, that is not a polemic point, due to the fact that its creation has practically happened by industry order", mainly the appliances and great performance computers. However, when we mention the question of the use of FireWire in PCs, we remember the example of the USB (Universal Serial Bus), that has taken some years until it was consolidated. Even today, the availability of USB peripherals is not so wide, what makes us conclude that there still is a great resistance against the elimination of standard peripherals and boards to connections in slots. Besides that, in most recent revision, the USB shows very attractive performance characteristics, if compared to the FireWire, what gives advantage to the USB, for longer offered. But we should not shut our eyes to the great innovation that came along with the IEEE 1394 specification.

Originally at http://www.hardwaresecrets.com/article/Firewire-Bus-IEEE-1394/57


© 2004-14, Hardware Secrets, LLC. All Rights Reserved.

Total or partial reproduction of the contents of this site, as well as that of the texts available for downloading, be this in the electronic media, in print, or any other form of distribution, is expressly forbidden. Those who do not comply with these copyright laws will be indicted and punished according to the International Copyrights Law.

We do not take responsibility for material damage of any kind caused by the use of information contained in Hardware Secrets.