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.
Total Throughput
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.
Reprints
