|
|
|
|
|
|
06 October 2008
|
|
|
Feature
|
The Firewire Connection
With the deluge of products based on IEEE 1394,
there is a proliferation of specifications, standards, architectures, and guidelines for these products. This article is intended to be a guidebook to those various documents, with an emphasis on how they should be applied to designing products.
By Michael Teener and Colin Whitby-Strevens
|
In 1986, a small group of engineers from a diverse group of Silicon Valley organizations (including the Stanford Linear
Accelerator Center, Hewlett Packard, Intel, National Semiconductor) met for the first time to define a "high-performance serial bus." This was the first meeting of the IEEE p1394 working group, and it had the charter to develop a single serial bus, that was to be architecturally compatible with all of the various 32-bit parallel buses being standardized by the IEEE. Published in 1987, the first draft of p1394 only specified 2- and 8-Mbps speeds, and used a passively-tapped single twisted pair. It did not
support isochronous transport.
1394 (Firewire or iLink, depending on your "religious" preferences) has certainly come a long way since then. For the user, it's easy to use, and has great real performance. For the designer, it provides a lower system cost and a longer product life.
There are many reasons why 1394 is easy to use, among the more important reasons are:
Small, ergonomically designed connectors that are extremely rugged, along with a
thin, easy-to-handle cable. The 6-circuit connector preferred by PC vendors is particularly good. One under-appreciated attribute is that the moving parts of the connector are on the cable side, not the system side; when the connector begins to show some wear and tear, the cable is thrown away, not the PC (or printer, or disk drive, or camera).
Hot plugging, dynamic configuration with extensive self-initialization capabilities built into the hardware (it's not
necessary to wait for Windows or the Mac OS to notice that things have changed). The resulting systems are plug-and-play. The software that supports 1394 allows devices to identify themselves with great robustness. Many of the Universal Plug and Play (UPnP)-type protocols needed for other interconnects are already provided in the basic 1394 stack.
Firewire benefits
1394 is based on the idea that performance is a total system issue, not just a bit-rate advertising number. As such, it provides true end-to-end performance. For example, using the serial bus protocol, version 2 (SBP-2) in 1394 disk drives, a good 40-Mbps average information rate can be maintained.
The magic in 1394 is that it is really a memory bus architecture, just like PCI. 1394 maps well to the processing model of computers; it's easy to give peripherals a high level of control
at a low cost.
The final major performance advantage of 1394 is its fundamental support for peer-to-peer isochronous communication. This means that bandwidth is guaranteed (as is latency), and that latency is very low (less than 250 ýs worst case). High-bandwidth streaming video is directly supported at low cost and
with high quality. This is one of
the primary reasons 1394 has been adopted so overwhelmingly by the consumer electronics industry.
Table 1
gives a brief overview of the various 1394-related specs, and
Figure 1
gives an overview of the specification structure.
Lower system cost
Designers are always looking for a lower total system cost, and 1394 has
no competition in this arena; various alternatives are not really comparable. FibreChannel
requires too much hardware, too much software, and does not provide isochronous transport. USB is too slow and is not peer-to-peer.
Given 1394's combination of high speed, high peer-to-peer connectivity, and isochronous transport, a large degree of I/O integration is possible in PCs. Currently, PCs and consumer electronic systems have entirely too many connections. There is no need for a separate LAN, printer, mass storage, video, or audio connections. It is possible to replace slot cards in most systems
because 1394 already provides bandwidth better than most I/O cards need.
1394 will provide the designer (and consumer) a very long architectural lifetime. 400 Mbps implementations are now shipping in high volume (all Macs, all Compaq PCs with 1394 are "S400" designs). New p1394b 800-Mbps designs have been demonstrated, and the 1.6-Gbps version should be in production by 2001. This scaleability is built into the architecture; existing designs need only small changes at the higher levels.
Specification summary
The primary specification for 1394 is the original IEEE 1394-1995 document. This document specifies the architecture and fundamental transport services, along with a host of lower-level details including physical specifications of the standard 6-pin connector, test specifications, detailed timing and signal levels, and bus management. This
document is over 400 pages long, and is largely self-contained. The one exception is the addressing and common register architecture, which is ISO/ IEC 13213 (but largely known by its previous name, IEEE 1212-1991). Some of the 1394 concepts depend on 1212, particularly the addressing and configuration ROM (used by bus management) architecture.
These two documents were the basis of the first actual implementations, but a number of shortcomings and inconsistencies were discovered in both (particularly in
1212). Therefore, a small number of follow-on projects were started shortly after 1394 became an official standard in 1995.
1394a is a supplement to the original (1995) document, with both improvements and corrections. The improvements include:
Arbitration accelerations which greatly improve efficiency of the bus, particularly in smaller systems (those with fewer than 63 nodes).
Reset improvements which greatly
reduce the disruption caused when nodes are added and removed from the bus.
Support for fine-grained power
management, which is particularly useful in portable computing
applications.
A number of other important changes are part of the 1394a document, including specification of the 4-pin connector and vastly improved specification of the PHY-to-link interface. (Most 1394 implementations have separate PHY and link ICs. Interoperability between PHYs and
links of different vendors was viewed as an important feature).
The IEEE has finished balloting on the 1394a specification and has started final document preparation – the document will be known as IEEE 1394a-2000 when officially published.
P1394b: new technology
Shortly after the 1394a project started, a number of companies in both the
consumer and PC space stated their desire to improve both the speed and reach of a 1394 interconnect. The P1394b (P refers to project, not an approved standard) working group was formed to address those requirements. The IEEE P1394b committee has completed the necessary specifications to extend both the speed and the reach of 1394. The result will enable the consumer to use 1394 as a very high performance computer peripheral bus as well as a home network, with no discernible difference from the way it is
currently used in the consumer electronics cluster.
The current specification for 1394 (IEEE 1394-1995) is intended to support data transmission speeds of 100 to 400 Mbps. Most consumer electronic devices support 100 or 100/200 Mbps, so there is still plenty of headroom in the specification. However, as more devices are added to a system, and as the quality of the audio/video data improves (more pixels, more bits per pixel), the need for more bandwidth will inevitably develop.
In addition, PC disk
drives are approaching a 400-Mbps true data rate already, and will be needing 600-800 Mbps in the near future. To keep the peripheral bus from becoming the bottleneck, the speed of 1394 must be increased to keep pace.
Higher speeds
The existing standards call for a base data rate of 98.304 Mbps, as well as twice and four times that speed (S100, S200, and
S400, respectively). The new work adds 8x and 16x speeds (S800 and S1600). To do this, a new physical layer mode has been added, beta mode, which uses a clever modification of
the IBM 8B/10B encoding used by Fibre Channel and Gigabit Ethernet. This modification, invented by Alistair Coles, technical lead at Hewlett Packard Bristol Labs, adds a number of new control codes robustly encoded to be easily separated from the data. The new PHY mode scrambles both the data and control signals before encoding them.
This results in a system that easily passes the radiated emissions tests required by the FCC and other national standards and regulatory organizations.
Because the data and clock information are now encoded on a single differential pair with no dc-level signaling, there is much lower intersymbol interference, allowing the same shielded twisted-pair media specified in the 1394-1995 standard to carry a 1.6-Gbps signal for the same 4.5 meters. Furthermore, a new connector capable of 3.2 Gbps operation
has been defined that
is significantly smaller than the existing 6-pin version, yet still maintains the power pins and great ruggedness preferred by PC vendors.
Because the signal only requires a single pair, the beta mode connection between two PHYs is full duplex. P1394b takes advantage of this by running the arbitration protocol in parallel with data transmission. This arbitration scheme (called "BOSS" mode by its inventors, Jerry Hauck of Zayante and David LaFollette of Intel) reduces arbitration
overhead dramatically. The authors of this article also contributed major enhancements to the BOSS scheme so that almost all of the arbitration enhancements added by the 1394a standard are not needed in beta mode.
The coding and arbitration enhancements of beta mode also allow P1394b to support the transmission of 1394 data over distances of up to 100 meters (328 feet) on Category 5 unshielded twisted pair (UTP-5) wiring, plastic optical fiber (POF), and 50-micrometer multimode fiber (MMF).
The UTP-5 specification supports transmission at 100 Mbps, and the POF specification at 100 or 200 Mbps. This allows home networking in the short term using installed wiring, or using the very low cost POF technology. Home network costs are, however, dominated by the cost of installation, and so a medium is needed which will survive several generations of consumer equipment. The committee selected 50 micrometer MMF which will support transmission rates of up to 3,200 Mbps. The latest generation of vertical
cavity surface emitting laser (VCSEL) technology makes transmission at the higher rates highly affordable.
Improved manageability
Based on experience gained with the existing standard, the 1394 community now wants faster reconfiguration of the bus after resets. To do this, a number of backwards-compatible changes to the management registers can make the
number of required bus transactions both smaller and deterministic.
A useful byproduct of the beta mode operation is the ability to work correctly even if the user accidentally creates a loop in the bus. In the existing standard, the best that can be done is for bus management software to inform the user that the condition exists. If the loop involves connections between beta mode devices, then it can be automatically avoided.
Status
The current draft of the document has been forwarded to the IEEE for balloting with the expectation that the balloting and approval process will be finished in late 2000 or early 2001. The most recent draft of the P1394b proposal can be downloaded from the committee's web site (www.zayante.com/ p1394b) along with a large number of supporting documents and presentations. There are already a number of highly sophisticated
test implementations. Lucent has demonstrated a bilingual PHY at 800 Mbps (bilingual in that it will connect both in the existing data-strobe signaling method used in the existing specs and in the beta mode signaling method invented for P1394b). Omneon Video Networks has demonstrated a 300-meter, 800-Mbps connection using multimode glass fiber; NEC has shown a plastic optical fiber system. Near-production-ready systems will be demonstrated in 2000, with full production of both home-network-based S100 and S200
systems and professional 800-Mbps and 1.6-Gbps versions by 2001.
Another in the series of fundamental specification upgrades is P1394.1, which specifies the connection between multiple 1394 buses. This allows more than 63 nodes to be communicating with each other, and also allows high-bandwidth subnets to cluster together without affecting the performance of the overall interconnect. Another nice attribute of P1394.1 is that bus resets and other management traffic tend to be isolated within a single
bus.
The basic model for P1394.1 is a two-portal bridge, where multiport bridges appear to be multiple two-portal bridges from a protocol point of view.
There is a lot of work left to do on P1394.1, so stability is not expected to be achieved until at least mid-2000.
P1212r: fixing the foundation
One of the major difficulties with building a
1394-based product using existing standards is that the 1212 document is wrong in some details and, more importantly, conflicts with both IEEE 1394-1995 and existing practice. This has led to a number of misinterpretations, slowing the introduction of several products, including 1394 support for major computer platforms. To address these concerns, the IEEE reconstituted the 1212 working group to revise that document. Revisions include:
Configuration ROM updates
with improved functional descriptions, using feature and instance directories and extended keys. These allow many of
the application-based specifications to extend the configuration ROM formats without confusion. The configuration ROM descriptions have also been vastly improved for readability.
Many of the specifications for standardized registers have been updated to match existing practice, both in the various 1394x drafts and products in the field.
Application-based specs
The other broad category of specifications are those that are particular to a single application area. In 1394, there are two major applications: consumer electronics and computers.
The initial high volume applications of 1394 were in consumer digital video, and most of the consumer-based specifications can be traced back to the
original DVC blue book, which defined how the first DV camcorders were controlled using 1394, and how the format of the data packets was transmitted on 1394. This large group of specifications is known as the "audio/video compatibility" (AV/C) specs.
Finally, there are attempts to unify all of the consumer devices in a true distributed processing system. The Home Audio Video interoperability (HAVi) and UPnP initiatives fall into this category.
In the AV/C world, there are 30 specs so far, and
the end is nowhere in sight. Most of this is due to the vast number of 1394 consumer devices in the works, but this is still an extremely large number. How are all of these devices going to be tested for interoperability?
Fortunately, some work is being done on device class convergence. For example, all of the various camcorders and VCRs are being combined into a tape recorder class, along with future audio recorders. The various mass storage devices such as CDs, DVDs, and hard disks have been
combined into a disk class.
All this is a good start with a simple fundamental design and some promising future directions, particularly the general object descriptors defined in the latest master spec: "AV/C General 3.0." These provide universal ways to describe both static and dynamic characteristics and controls of devices. Unfortunately, the descriptors are not well described, and there is considerable confusion about exactly how they are used. This has the effect of different AV/C working groups
selecting
different (and not entirely compatible) ways to use the descriptors. (And this
is even leading the camera group to propose an entirely different way to provide a directory. This is believed
to be a temporary condition, as the leaders of the AV/C community are aware of the problem and are beginning to address it.)
HAVi and UPnP
One of the more
promising developments is the effort to create a lightweight distributed object system appropriate for consumer electronics. There are two primary efforts: HAVi and UpnP.
HAVi is led by eight consumer
electronics companies: Grundig, Hitachi, Matsushita, Philips, Sharp, Sony, Thomson, and Toshiba. They have defined a set of APIs and associated protocols, which have the potential of providing a fair amount of "future proofing" for consumer devices. Recently, the HAVi consortium has teamed with Sun's Jini
for a fully dynamically-bound distributed object system.
Microsoft's UPnP, on the other hand, does not necessarily define APIs. Instead, it defines a set of protocols based on existing and proposed Internet Engineering Task Force (IETF) standards. The current versions of the specification only have details for IP-based networks (requiring
all participating devices to support an Internet protocol stack), but direct 1394 versions are likely in the near future.
HAVi and UPnP have sometimes
been seen as competitors. In some ways, they are – they use wildly different registration, discovery, and messaging protocols, and UPnP doesn't provide a Java-based universal driver scheme. However, they do serve different markets and have different goals. It is likely that there can be bridging between the two, and the creation of the bridging technology may be co-operative between the two sponsoring organizations.
Regardless of which distributed system is implemented, it is going to be a huge
job to get it working, but once it's done, support for new devices becomes much easier and much more "future-proof."
Michael D. Johas Teener
is chief technical officer, and Colin Whitby-Strevens is director of product marketing and architecture at Zayante, Inc.
Teener has a BS from Caltech and an MS from the University of California at Los Angeles. He can be reached at
mike@zayante.com
.
Colin Whitby-Strevens
has a PhD from Cambridge University, England. He can be reached at
colin@zayante.com
.
|
|
|
|
Return to
Multimedia Supplement
Return to:
Communication Systems Design
Send comments to the:
">Webmaster
All material on this site Copyright © 2000 CMP Media Inc. All rights reserved.
|
|
|
|
|
|
|
|
|
|
Puzzled by a network processing design issue?
