We are a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for us to earn fees by linking to Amazon.com and affiliated sites.

[nextpage title=”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.

 

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 https://grouper.ieee.org/groups/1394/1. So, some details shown here are subject to further revisions.

[nextpage title=”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.

• Bridge: it is the circuit capable of allowing the communication between two or more serial buses with independent operations.
• Bus_ID: it is a number of 10 bits that identifies, in a single way, one of the serial buses in a network topology made up of many buses.
• Portal: it is the circuit that physically connects a FireWire bridge to a bus. Each bridge should implement at least 2 portals, that is, allow the communication between 2 buses. In a generic network, a bridge can implement various portals, identified by 0, 1, …, N-1.
• Network: it is a group of interconnected buses and nodes, capable of being mutually addressed by transactions involving data packets.
• Local Node: Two nodes are said to be local if they are connected to the same bus, that is, with the same Bus_ID.
• Local Node ID: it is a number of 16 bits that will represent an address to the node (peripheral) connected to the bus.
• Network Cycle Master: it is a circuit elected to be the responsible for giving the clock that will synchronize the network. This way, many network events could happen synchronized by a single clock (isochronal way). But, the pattern IEEE 1394-1 also mentions an asynchronous communication.
• Physical ID: it is a number of 6 bits associated to each node, through auto-identification process that comes after the bus initialization.
• Remote Node: A node said to be remote in relation to another if they are connected to buses with different IDs.
• Virtual Node: A generic node.
• Virtual ID: it is a number of 6 bits that represents an address of a connected local node. The association of those Ids is made through the portal that generated the local bus.
• Virtual Node ID: it is a number of 16 bits that represents an address to a generic node that, to transaction packets with a determined portal, should go over at least one bridge.

[nextpage title=”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.

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.

[nextpage title=”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:

•  Writing Request;
•  Response to a writing request;
•  Reading request;
•  Response to a reading request;
•  Bus protection request;
•  Response to the bus protection request.

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:

•  Node "N1" transmits a request packet through FireWire of portal "b"
•  Portal "b", implemented in bridge "a-b", detects a request and verifies that it is needed to retransmit the packet through "a" portal for it to be able to reach its destination (inbound operation);
•  Packet travels through bridge "a-b" and arrives at portal "a";
•  Portal "a" retransmits the packet through the FireWire bus that unites "a" and "c" (outbound operation);
•  Portal "c", implemented on bridge "d-c-e", detects a request and verifies that it is need to retransmit the packet through portal "e", for it to be able to reach its destiny (inbound operation);
•  Packet travels over the bridge "c-e" and arrives at portal "e";
•  Portal "e" retransmits the packet through the FireWire bus, where node "N2" is connected (outbound operation);
•  Node "N2" receives packet;
•  Node "N2" starts the opposite process, that is, sends response packet to request. 

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

[nextpage title=”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.

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

As relevant Virtual FireWire operation characteristics, you have:

• It is allowed the concurrent transmission between multiple pairs of nodes connected to a Virtual FireWire, that is, the bus congesting characteristic is very reduced, that limits a lot the capacity of a communication network;
• Nodes not connected to the Virtual FireWire virtual (examples: “N1” or portal “d”, in Figure 4) can be seen or not by the other connected nodes;
• Isochronal packets are sent only to the nodes that have been listed by devices as possible packet source/destination;
• The routing way of nodes and portals in a virtual bus is very flexible; so, not every node connected to the virtual bus can communicate directly with one another; sometimes it will be necessary the use of an intermediate node to temporarily store the packets to retransmit them afterwards;
• The packets communicated in a Virtual FireWire Virtual can be segmented, if necessary;
• You can have the node simulation by software.

Besides, still in study, among many other characteristics:

• The existence of portal a
• Inclusion, in a configuration ROM, of topology and speed maps;
• Guarantee of precision in the distribution of clock frequency;
• Transmission of asynchronous blocks of, at least, 512 bytes;
• Support to size of packets that are allowed in buses of 100 Mb/s or more;
• Support to all kinds of serial bus packets.

[nextpage title=”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.