DESIGN VIEW is the summary of the complete DESIGN SOLUTION contributed article, which begins on Page 2.
Greater computing power coupled with lower-cost, higher-pixel-count imaging sensors have fostered a new set of advanced industrial applications. These applications—such as vision systems, robotics, motion control, and wafer inspection/repair—make significant demands on the total computing system.
Aside from throughput, other key requirements for these applications include quality-of-service (QoS), connection distance, connection robustness, and data latency. Connection options include standard high-speed digital connections for Windows, Mac OS, and Linux machines: 100BaseT Ethernet, 1000BaseT Ethernet (GigE), IEEE-1394 (FireWire), i.Link, DTVLink, and SB1394.
Many of the industrial applications require high throughput or distances greater than five meters and can benefit from true isochronous, peer-to-peer operation with broadcast capability. On top of that, they need optical interconnects and top-notch operating-system support. For these, FireWire is an excellent choice.
FireWire has guaranteed, truly isochronous bandwidth allocated every 125 µs for data that can be termed "latency-critical." Each isochronous-capable node has its own 32-bit clock incrementing at 24.576 MHz (the cycle timer), which is updated to the cycle-master node's clock every 125 µs. The same packet that updates the node clock starts the isochronous "frame."
This article compares and contrasts FireWire's max cable length, optical implementations in harsh environments, broadcast write capability, and peer-to-peer communication with that of Ethernet and USB 2.0. In addition, a FireWire implementation used in Point Grey Research's 800-Mbit/s industrial camera is reviewed.
|Total Throughput||The means of arbitration or deciding which node transmits next can significantly impact raw bit speed, as well as the coding of the data. For instance, FireWire's 1394b configuration has a raw throughput of 1 Gbit/s, but the data coding drops that rate down to 800 Mbits/s.|
|Connection Distance||IEEE 1394b extended FireWire's cable length by allowing more types of media. Specifically, it permits glass optic fiber (GOF) up to 100 m at any speed per cable connection.|
|Connection Robustness||If an industrial installation's cabling is in a dense electromagnetic-interference environment, optical connections might be preferred. GOF transceivers are too sensitive to EMI, though, so plastic optic fiber (POF) may be a good compromise.|
|Peer-To-Peer, True Isochronous Transport||FireWire allows peer-to-peer communication, meaning traffic may be sent directly to the node that requires data.|
|Broadcast Write Ability||FireWire features a broadcast write mechanism and address space. This is used for the cycle start message to update each node's cycle timer register (common time base).|
Full article begins on Page 2.
Greater computing power coupled with lower-cost, higher-pixel-count imaging sensors have fostered a new set of advanced industrial applications. These applications—such as vision systems, robotics, motion control, and wafer inspection/repair—make significant demands on the total computing system. For example, the I/O throughput from remotely located sensors is raising bandwidth requirements for a typical interconnection between the main computing element (such as an industrial desktop computer) and a separate external imaging machine (like an industrial imaging camera).
Aside from throughput, other key requirements for these applications include quality-of-service (QoS), connection distance, connection robustness, and data latency. Connection options include standard high-speed digital connections for Windows, Mac OS, and Linux machines: 100BaseT Ethernet, 1000BaseT Ethernet (GigE), USB 2.0, and IEEE-1394 (known as FireWire, i.Link, DTVLink, SB1394, etc.). Table 1 lists basic file-transfer tests using a PC’s built-in FireWire interface plus its GigE, and 100BaseT Ethernet ports. The hardware included two 1.7-GHz Pentium 4 machines with 512 Mbytes of RAM and a 600-Gbyte hard-disk drive.
A greater number of these industrial applications also require high throughput or distances greater than five meters and can benefit from true isochronous, peer-to-peer operation with broadcast capability. On top of that, they need optical interconnects and top-notch operating-system support. For these, FireWire is an excellent choice.
In applications where Internet Protocol (IP) transport is a critical requirement, but latency or isochronous data transport isn’t important, either Ethernet or FireWire may be used. For lower throughput requirements that don’t need true isochronous capability and can be limited to under 5 m, plus don’t need peer-to-peer support, a USB 2.0 high-speed implementation may be a candidate. USB 2.0 also can be employed in some applications where latency is less crucial. A review of the basic parameters demonstrates the ability of each in these applications.
While throughput is primarily a function of raw bit speed, the means of arbitration or deciding which node transmits next can significantly impact these numbers, as well as the coding of the data. FireWire’s 1394b configuration has a raw throughput of 1 Gbit/s, but the data coding (a modification of IBM 8B10B) drops that rate down to 800 Mbits/s. When transporting data between two 1394b nodes, the 1394b Bus Owner Supervisor Selector (BOSS) arbitration enables arbitration in parallel with data transfer, bus grants to be made as part of the packet end symbol, and optimized packet formats to decrease overhead. This has allowed measured throughput of more than 712 Mbits/s.
Coding 100BaseT Ethernet using 4B5B data at a raw rate of 125 Mbits/s will yield a throughput of 100 Mbits/s. However, it uses the same collision-detection-based arbitration as earlier Ethernet. If no other nodes exist in the arbitration domain, this can be efficient. But the more traffic in the arbitration domain, the lower the efficiency and the greater the potential latency. The IP headers and coding also introduce an overhead burden on Ethernet that causes throughput to drop.
To code 1000BaseT Ethernet, 8B10B data is employed at a raw rate of 1.25 Gbits/s for a throughput of 1 Gbit/s. It has the same limitations as 100BaseT Ethernet. Because raw throughput is 10 times greater, the arbitration has a proportionally larger impact. Moreover, the IP coding puts a heavier burden on the CPU, because more packets can arrive in the same amount of time.
USB 2.0 high-speed has a raw throughput of 480 Mbits/s. The largest impact on this throughput is the implementation of the host hardware and software. There’s no arbitration. All transactions are scheduled in the host software stack, with all transactions coming from or going to the host. Therefore, throughput depends heavily on the host computing load and the destination of the data. Data not from the host and not destined for the host will appear on the bus twice, once in a transfer from the source to the host, and another time in a transfer from the host to the destination. A heavily loaded CPU also will affect the throughput of a USB system.
Quality Of Service
FireWire has guaranteed, truly isochronous bandwidth allocated every 125 ms for data that can be termed “latency-critical.” Each isochronous-capable node has its own 32-bit clock incrementing at 24.576 MHz (the cycle timer), which is updated to the cycle-master node’s clock every 125 ms. The same packet that updates the node clock starts the isochronous “frame.” This allows for distribution of data at low, deterministic latencies. The isochronous mechanisms are implemented in the hardware, with software controlling setup and allocation.
Ethernet lacks this isochronous mechanism. The IEEE standards call out a means of prioritizing individual packets, but it’s not universally implemented in end equipment, switches, and hubs. The priority is only a way to rank which node wins in any collision detected during arbitration. It doesn’t prevent contention or guarantee bandwidth or latency. Because Ethernet lacks isochronous transports, it also won’t have a common time base, such as the FireWire cycle timer.
USB has a less robust isochronous implementation because it depends on the host software to implement all aspects of the isochronous mechanism. As long as the host isn’t overly burdened by heavy processing or high-priority processing at the wrong time, the isochronous mechanism can keep up. But if the computing load is heavy or a high-priority process occurs at a bad time, the timing of the isochronous transfer can degrade. Individual USB peripherals don’t possess a common time base like isochronous-capable 1394 nodes. A USB peripheral outputs data only when requested by the host, and there’s no common timer like the FireWire cycle timer. The result is that accounting for latencies is more difficult.
FireWire in its initial implementations (1394-1995, 1394a-2000) had a suggested maximum cable length of 4.5 m. Though not a requirement, this limitation was recommended if you went with the diameter of wire, shielding, and connectors listed in the standard. For better cables that still met the electrical requirements, cables could be longer than 4.5 m. However, better cables are nonstandard and are more expensive. IEEE 1394b extended the cable length by allowing more types of media. Specifically, it permits glass optical fiber (GOF) up to 100 m at any speed per cable connection (check with the transceiver manufacturer for superseding limitations), 50 m of plastic optical fiber (check with the transceiver manufacturer for speed/distance limitations), and 100 m of unshielded twisted pair (UTP) Category 5 at 100 Mbits/s.
USB 2.0’s cable distance limit is 5 m for up to 480 Mbits/s. Ethernet offers a connection distance of up to 100 m across CAT-5 cable. The 1000BaseX implementation of Gigabit Ethernet also uses IBM 8B10B coding and can be transmitted across GOF. However, this implementation isn’t as popular as the 1000BaseT CAT5e implementation. The 1000BaseT implementation works across Category 5 enhanced UTP cable. CAT5E is more popular than GOF these days because it costs much less. It’s coded in five-level pulse amplitude modulation (PAM5) at 1 Gbit/s.
Industrial implementations can be installed in harsh electromechanical environments and maintained by locally trained technicians. If the installation’s cabling is in a dense electromagnetic-interference (EMI) environment, optical connections might be preferred for their immunity to such interference. Yet GOF transceivers are sensitive to electromagnetic noise as well. GOF cable also can be a challenge to ensure good splices and connector mating because the diameter of the fiber can be small.
Plastic optical fiber (POF) can be a good compromise. The fiber size is relatively large, the cable relatively robust, and transceivers up to 500 Mbits/s are available, though there’s a speed/distance tradeoff with POF and hard polymer clad fiber (HPCF), which is discussed later. Glass is good to 100 m at any speed (Table 2).
It’s easy to apply 1394b FireWire across optics. For Ethernet, it must be with the 8B10B binary-coded implementations. USB doesn’t work across optical connections. Both FireWire and USB 2.0 high-speed use shielded-twisted-pair (STP) cables of up to 4.5 and 5 m, respectively, and are coded in a binary differential code. As for 100BaseT, it normally uses unshielded cable and has a three-amplitude-level code. With no shielding and three levels to distinguish, it may be more susceptible to EMI. UTP cable is typically used with 1000BaseT too. The difference is that 1000BaseT is coded with a five-amplitude-level code at a higher frequency that 100BaseT.
FireWire 1394b hardware will automatically disable a loop in a topology during the initialization process of a bus reset. Because this process is repeated with every bus reset, this mechanism will automatically enable redundant connections if the primary connection is removed. The removal will cause a bus reset, which will then find the redundant connection (see the figure).
In other words, a topology can be configured with multiple redundant connections, and the hardware will disable those connections at power-up. If an enabled redundant connection is removed, the removal will cause a bus reset. During the bus reset, the redundant connection that had been disabled will be discovered and enabled, if it’s now the only path between two nodes. The pleasing consequence is that the hardware detects redundancies, disables them when not needed, and enables them when they are needed automatically with no software intervention.
The use of Ethernet switches can limit the Ethernet arbitration domain size, and the IP latency is helped by hardware IP acceleration (such as has been proposed for iSCSI). However, both of these add to the implementation cost. Even with the switches, Ethernet latency is larger than FireWire latency. Plus, due to the common time base kept by the cycle timers and cycle start packets, the latency introduced can be determined in a FireWire network. USB falls between these two, closer to 1394.
All of these technologies have excellent integration with the current most popular operating systems. Worth noting is FireWire’s protocol for transporting IP data, which is implemented in all operating systems. Consequently, FireWire can carry IP data as well, and sometimes faster, than Ethernet.
Other Advantages: Peer-To-Peer, True Isochronous Transport
FireWire allows peer-to-peer communication, meaning traffic may be sent directly to the node that requires data. There’s no need for it to be routed through a host. This means any node may initiate a transaction with any other node without going through a master node. This is in contrast to a USB connection. On a USB bus, every transaction either goes to or comes from the master.
For example, if a sensor node attempts to send data to another node that’s not the central computing element using 1394, the node only addresses the data directly to the other node. The data appears on the bus once. But for USB, this same data must be sent first to the host. The host then sends it to the other node. So in the USB connection, the data appears on the bus twice, taking twice the bandwidth and doubling the chance for an error in transport. USB also allows only one host on the bus, so USB can’t be used to network more than one PC. Ethernet can be configured to be peer-to-peer using the Internet-protocol software stack (IP SW stack) to decode the IP address.
As mentioned earlier, FireWire has true guaranteed bandwidth allocated every 125 ms for latency-critical data. Each isochronous-capable node also has its own 32-bit clock, incrementing at 24.576 MHz, that’s updated to the cycle-master node’s clock every 125 ms. The same packet that updates the node clocks will start the isochronous “frame.” This allows for low-latency data distribution and enables the latency of that data to be deterministic. The isochronous mechanisms are implemented in the hardware, with software controlling the setup and allocation. As noted, Ethernet doesn’t have an isochronous mechanism, and USB has a less robust isochronous implementation.
Broadcast Write Capability
FireWire features a broadcast write mechanism and address space. This is used for the cycle start message to update each node’s cycle timer register (common time base). This same mechanism also can be employed for other synchronization messages, safety messages, etc.
IEEE 1394b has all of those same advantages in addition to others that are unique to 1394b. There’s no need to give up anything from 1394a to implement 1394b. Ports on 1394b physical layers (PHYs) may be backward-compatible. That is, they will communicate with 1394a signaling when plugged in to a 1394a node, and communicate with 1394b signaling when plugged into a 1394b node.
A single 1394b PHY will translate from 1394a to 1394b if one port is plugged into 1394a and the other is plugged into 1394b. This is called “bilingual.” If the 1394b PHY is bilingual, then any port may be used to talk to either a 1394a device or a 1394b device. Thus, it can interact with any existing 1394 device at the hardware level. However, if the port is connected to an S800-capable port, it will connect at the full speed of 1394b.
Now, 1394b operates at up to 800 Mbits/s. The IEEE standard defines everything that’s required to move to 1.6 Gbits/s and has defined media up to 3.2 Gbits/s. Silicon that implements 800-Mbit/s 1394b is available from Texas Instruments, Oxford Semiconductor, Initio, and BridgeCo. Several implementations of a 1394b link layer in FPGA technology have been successful. They were used both as prototypes for ASICs and as the final end equipment for lower-volume equipment.
FireWire 1394b employs a modified form of IBM 8B10B encoding. As a result, 1394b can be used with optical transceivers and with special transceivers for UTP cables. Depending on the type of transceiver and media chosen, the cable distance can be up to 100 m per hop, though with a more limited number of hops. This can be extended to approximately 400 m under special circumstances, but the network can’t be extensive.
In addition, 1394b can take advantage of POF cabling at a variety of speeds and distances. For example, with the Toshiba TODX2404, it can transmit at 400 Mbits/s up to 10 m, 200Mbits/s up to 20 m, and 100 Mbits/s up to 50 m of standard cable available from Mitsubishi Rayon. GOF can be used at speeds of 400 Mbits/s and higher.
UTP Category 5 may be used with a 1394b PHY provided there’s a special transceiver. With the special transceiver, 1394b could transmit up to 100 Mbits/s over 100 m of CAT-5 cable. The dc-balanced 8B10B encoding allows for galvanic isolation at the cable, or the optical connection choices will bring the ultimate in isolation.
TI tested UTP5 at 100 Mbits/s; POF at 100 Mbits/s, 200 Mbits/s, and 400 Mbits/s; GOF at 400 and 800 Mbits/s; and finally, 4.5-m shielded twisted pair cables from 100 to 800 Mbits/s. The hardware results are good, with very good bit-error-rate performance and interoperability between 1394a and 1394b devices. One issue that sometimes arose was software compatibility. At the higher 1394b data rates of 400 and 800 Mbits/s, everything worked well. Sometimes, though, at the lower 1394b data rates of 100 or 200 Mbits/s, depending on the particular end equipment’s software implementation, a piece of older 1394 end equipment might atempt to send packets at a higher rate (400 Mbits/s) than is possible with the 1394b media connection.
FireWire 1394b BOSS arbitration eliminates arbitration idle delays for asynchronous transport, as well as arbitration time for isochronous transport. It does this by using the dual-simplex property of 1394b to do arbitration and data transport in parallel. It also allows bus “grants” to be included in the final codes of a packet being sent, which achieves very low overhead for arbitration.
One application that uses a FireWire implementation is Point Grey Research’s 800-Mbit/s industrial camera. This high-performance camera required excellent video resolution and quality. To keep development costs in line, it also needed a standard that was supported inside the target operating system. The true isochronous nature of FireWire benefited this application by allowing a simpler hardware implementation to send the digital pixels in a raw video format directly to a computer for processing. The 1394 Trade Association published a standard for this type of camera (DCAM1.3), and the industrial working group continues to update it in the eventuality of higher-throughput PHYs.
Point Grey had already implemented FireWire cameras for lower-throughput 1394a-2000 systems. So when the 800-Mbit/s implementation of FireWire became available, it met the need for the increased resolution craved by customers. Approximately 80% of the total available bandwidth is available for isochronous data, delivering a throughput of 640 Mbits/s. However, this limit was set to allow S100 1394-1995 nodes to operate correctly. At S100, 20% of the bandwidth is 20 Mbits/s; at S800, 20% is 160 Mbits/s. This, along with the more efficient BOSS arbitration, allow the 80% to be pushed higher in a primarily isochronous 1394b-only network.
Another limit on the throughput is that the maximum-sized packet only lasts for approximately 83.3 ms. This is a limit of the 1394 PHY design, yet it’s required by the standard. Longer packets than this may lose the end bits of a packet, causing CRC errors. The standard limits the size of isochronous packets to 1024, 2048, 4096, and 8192 bytes, respectively, for S100, S200, S400, and S800 packets. To circumvent this, a node can send more than one isochronous packet per isochronous frame, as long as the bandwidth is allocated for such a procedure.