Convergence, or the merging of applications, features, and functions, has been an ongoing trend in consumer electronics and PCs. Such convergence is most notable at the system interface. One interface in particular—1394 (pronounced "thirteen ninety four")—has been very successful in bridging the gap between interface flexibility/capability and ease-of-use.
Otherwise known as Firewire or iLink, 1394 has been shipping for years in camcorders with DV capability. It's the standard plug-and-play interface for transferring DV-formatted A/V streams between digital camcorders and PCs, bringing a host of ease-of-use features and flexible capabilities to DV editing platforms.
Now, 1394 promises to bring these same features and capabilities right into everyone's living room through DTV and the DSTB. Care must be taken during the product definition and design phases to implement the 1394 interface correctly from both hardware and software perspectives.
System designers must know the relevant and appropriate standards impacting Firewire in DTV and DSTB. They also need to know what features and functionality to look for when selecting 1394 devices for their products.
The demand for digital-ready set-top boxes and TVs has grown rapidly with the advent of DTV content broadcasting from satellite and, more recently, cable and terrestrial sources. Digital A/V content is most often formatted in MPEG-2 or a derivative of it. The DirecTV system transport is a slightly modified version of the DVB system format.
As broadcast source material has evolved from analog to digital form, the front end of the receiving nodes has changed accordingly. But the I/O connections between the set-top-box receiver and the TV have largely re-mained analog, with high-end boxes simply moving from analog S-video to analog YUV component video. Firewire enables the transition from these classic point-to-point analog interfaces that only support analog A/V streams to an all-digital, networked interface capable of supporting digital A/V streams, as well as asynchronous data types, like computer file transfers.
DSTB architecture: 1394 can fit into the system architecture of a DSTB, serving as both a digital output and a digital input (Fig. 1). The output connection can go to digital recording devices, such as digital VHS decks or personal video recorders. Firewire also can serve as an input from those same digital recording devices, or even from popular digital video camcorders, provided that the set-top box can decode DV streams.
With the inherent ability to run multiple protocols across 1394 and support up to 64 nodes on a single 1394 bus, it's possible to network a DTV and DSTB with other popular consumer items, like a DVD player and an A/V receiver. For example, when receiving a movie with DTS or AC-3 encoded audio, this high-quality audio (in its native digital format) can be sent directly to an A/V receiver for surroundsound decoding, while the video in native MPEG format goes directly to a DTV for decoding—all across the same 1394 cables. Moreover, 1394's plug-and-play capability makes hooking all this equipment together, which has been a perennial nightmare for the average consumer, much easier.
The 1394 set-top box of Figure 1 shows an MPEG decoder that's really optional. Integrated DTVs (those with built-in digital tuner/demodulator capability) will have an MPEG decoder for receiving terrestrial ATSC broadcasts. So, including 1394 in the digital satellite/cable STB eliminates the need for an MPEG decoder in those boxes. Of course, during the transition from analog TVs to digital TVs, the MPEG decoder in the STB will be required in order to interface to legacy TVs.
An area of overlapped capabilities between DSTB and DTV, at least during the age of legacy connections to analog-only TVs, will be viewer control of channel selection, plus generating and controlling the program guide via OSD. The CEA standard, EIA-775-A, specifies the requirements of the 1394 interface between DSTB and DTV. This standard identifies two cases for service selection. With one, the source (the set-top box) controls the navigation and selection of program material. With the other, the DTV controls it.
When 1394 is used for the connection and the source device controls program navigation and selection, the CEA requires the DSTB to provide a single program transport stream to the DTV. DSTB designers should be sure the MPEG-2 demultiplexer/decoder has this ability when designing 1394 into the system.
DTV architecture: 1394 could be integrated into a general DTV system architecture (Fig. 2). In this case, 1394 is used as an input for both digital A/V streams and OSD, or for interactive graphics from an A/V source device, like DSTB. When a digital tuner is integrated into the DTV, the 1394 interface can also serve as an output to A/V media recording or data storage devices, or even to a digital A/V receiver.
There has been an ongoing debate in the consumer industry over whether to choose DVI or 1394 as the interface between equipment like digital cable, satellite set-top boxes, DTVs, DVD players, and digital VHS decks. Despite the debate, 1394 and DVI shouldn't be regarded as mutually exclusive interface options.
Firewire offers several features that complement DVI. One of the most important is 1394's ability to record digital A/V content to today's digital VHS decks, as well as the DVD-R/W decks soon to be available. (The DVI content protection standard and license agreement doesn't allow copies to be made from a DVI interface.) Firewire can also support the creation of a network of various electronic equipment in the home. With the addition of HAVi to the end equipment's software, all 1394 equipment can speak the same language, making a truly universal remote a reality. Table 1 lists some of the pertinent CEA/EIA 1394 DTV interface requirements.
One of the first issues DTV designers must address is which input data formats must be supported. Will the TV accept both DV and MPEG-2, or MPEG-2 only? If the latter, will it support reception of both DVB- and DirecTV-formatted MPEG-2 streams, or only DVB? Will the TV be able to receive and decode Dolby Digital streams and/or output Dolby Digital audio to an external decoder? The answers to these questions will drive the functionality required for the 1394 chip set in the DSTB, because each data format differs in how it's packetized and delivered to the receiver.
As A/V data types proliferate, there's an ongoing need to support newly defined types of data. Therefore, the designer should select a 1394 chip set that offers flexibility as to the types of isochronous data that it can carry. The CEA/EIA-849 standard defines several application profiles for DTV. Each profile has standard requirements for the digital transport methods and encoding formats to be supported.
PHY-layer selection issues: With the features and capabilities of 1394 in mind, designers must address basic design concerns regarding which Physical and Link layers best fit their intended product and application(s). The 1394 PHY layer should support the minimum number of nodes or ports re-quired by the end product. Having only one port limits the end product to being a "leaf" node, unable to support multiple devices connecting to the bus. Thus, it becomes a "dead end" on the bus. Having two ports permits spanning to other devices on the bus, basically just daisy-chaining them together. Three or more nodes enables branching, or hub, capabilities.
In most cases, a minimum of two nodes are preferable for DTV and DSTB applications. That's because these products can provide more power (being ac, or "wall" powered) to the bus, and designers will want to support as many peripheral devices as possible. Note that a span, or daisy chain, of devices will suffer longer gap-count latency. The gap count determines the time spent in both the arbitration reset and subaction gaps on the 1394 bus. The lower the gap count, the less time will be spent in these idle states. Therefore, a daisy chain will have lower bandwidth efficiency than the same number of nodes configured as a "tree" topology, which can only be realized when using nodes with three or more ports.
Designers should also be aware of whether or not the end product will need dc isolation at the 1394 interface. The 1394 cable doesn't provide a dc-isolated path from node to node. In cases where there's a possibility for the various equipment connected across 1394 to be at different ground potentials or different power domains, the grounds might need to be isolated from each other.
The 1394 cable isn't designed to handle the power levels that may be present between disparate power do-mains. Without dc isolation in such a case, excessive current could form on the 1394 cable ground and shield wires. This current, as well as any noise caused by connecting the two power domains via 1394, can result in loss of data and connection integrity, or even damaged cables. By dc-isolating the 1394 cable ground and shield from the system ground, or chassis ground at each node, these currents and noise will be avoided.
All 1394 PHY-layer devices present on the bus must be referenced to the same ground potential. Therefore, the ground signal on the 1394 cable must not be dc-isolated from the PHY power-distribution ground plane. Thus when dc isolation between units is required at the 1394 interface, it is most often performed at the PHY- and Link-layer interfaces.
To obtain dc isolation, system de-signers should look for 1394 silicon that supports isolation at the 1394 PHY-Link layer interface—often through the use of special I/O cells that allow for capacitive coupling of the PHY-Link signals. (Note: the 1394a-2000 specification removed the requirement imposed by the 1394-1995 specification, clause 22.214.171.124.8, for ac coupling of the cable shield.)
While the EIA-775 specification requires a minimum speed of 200 Mbits/s at the 1394 interface, using 400-Mbit/s PHYs is recommended. Slower nodes present on the bus can be a source of speed traps. Depending on how users connect their equipment to the DTV or DSTB, a 200-Mbit/s node can wind up between two 400-Mbit/s nodes, slowing down peer-to-peer traffic through it.
Firewire offers a number of critical power-management functions, like the suspend/resume feature of the PHY layer addressed in the 1394a-2000 specification. This feature lets two currently inactive ports achieve low-power states while maintaining their connection status. It also permits them to quickly resume operation as soon as they detect an applied port bias voltage.
Other power-management features include the ability to enter low-power states when the at-tached Link isn't powered, as signalled through the LPS input. PHY layers that are fully 1394a compliant, along with the suspend/resume feature, bring such key advantages as arbitration enhancements, connection debounce, and gap-count tuning via "ping" packets for better bus efficiency.
Link-layer selection issues: Different types of A/V data require different formatting and transmission methods on 1394. Specifically identifying which types of A/V data must be supported is fundamental to choosing the right 1394 chip set for the DSTB or DTV design.
Standards define how to carry MPEG-2 transport streams in both DVB format and in DirecTV format, also known as ITU-R BO.1294 System B. These two types of transport streams have different 1394 packetization schemes, so the system designer should understand if both types must be supported, and if so, which 1394 Link layers support both.
Another A/V data type is digital video, as found on current digital camcorders and used for home video editing. It too has a specified packetized format across 1394. Playback of DV direct to the DTV, or via a DSTB to a legacy TV, can be a source of differentiation for these products.
System designers should look for a 1394 interface chip set that automates these format-specific packetizations. This feature will alleviate the need for any special handling of the compressed A/V stream prior to transmission across 1394, or the equivalent need at the receiver's 1394 interface.
Another useful feature in the 1394 interface controller is the ability to filter the actual PIDs in the MPEG transport stream. Depending on the type of MPEG-2 decoder/demultiplexer used, the transport stream that's output from an auxiliary interface of these parts to the 1394 controller for interbox transport may not be able to be demultiplexed yet. Or in cases where the MPEG-2 chip set doesn't have an auxiliary stream output, the transport stream may need to be input to the 1394 interface controller directly from the demodulator.
In either case, the stream that's output to the 1394 interface will contain the full contents of the transport stream, instead of only those PIDs related to the desired program for display at the DTV, as selected by the user. Selecting a 1394 Link layer device that can filter out only those desired PIDs from a full transport stream as directed by the STB processor can preserve 1394 bus bandwidth and save the headache and cost of demultiplexing the stream manually prior to the 1394 chip set.
Along with PID filtering, the ability to insert packets into the outgoing transport stream from the 1394 Link layer is important. In cases where particular PIDs are removed from a transport stream, the fundamental MPEG-2 PAT and PMT must be updated to correctly identify the now-modified MPEG-2 transport stream. These new PAT and PMT packets are best inserted at that point when the 1394 interface does the filtering.
The allowable number of isochronous and asynchronous streams simultaneously supported by the Link layer is yet another feature that should be considered. Advanced features in the DSTB may require the ability to simultaneously support up to three isochronous streams, as well as asynchronous streams to and from peripherals connected to the 1394 network. Figure 3 illustrates one such scenario involving the support of multiple simultaneous streams. Here, both time-shifting (pausing live TV) and the recording of a separate channel for later viewing are being performed concurrently.
For a set-top box to output a time-shifted program from a disk recorder to the TV while also recording a separate program to the same disk recorder or a digital VHS/DVD-R/W, it would require at least three streams supported by a single Link layer. This example assumes a DSTB supports legacy analog TV connections. In Figure 3, three separate isochronous channels are active on the bus, and the Link in the set-top box and the recorder must be able to handle this.
Another aspect of the Link layer that should be considered is the amount of data-buffer memory supported. Typically, the more bandwidth an application requires, or the more simultaneous isochronous/asynchronous traffic that needs to be supported, the larger the buffer memories must be.
Per the IEC 61883-4 specification for MPEG-2 transmission, the minimum amount of buffer memory necessary in a 1394 receiver is 3264 bytes—based on a single 60-Mbit/s transport stream. Figure 4 gives the details on how this buffer size is derived. The buffer is needed to remove the jitter induced by the 1394 transmitter due to variable delays in bus arbitration and access-grant, variable amounts of 1394 traffic on the bus, and the lack of sync be-tween the MPEG stream input rate and the 1394 cycle timer.
As the number of simultaneous isochronous channels present goes up, or the bit rate of an individual stream increases, this receive buffer needs to be larger. System designers should analyze the various applications that require support to determine both the maximum MPEG bit rate and maximum number of isochronous channels to be simultaneously present. Then, designers can select a 1394 Link layer to best meet the receive-buffer memory requirements.
The IEC 61883-4 and ITU-R BO.1294 over 1394 specifications cover additional buffer requirements for smoothing of MPEG network jitter. This buffer amount should be considered too, especially in cases where a full transport stream will be decimated to a single program transport stream either at the 1394 transmit node prior to being transmitted or at the 1394 receiving node at reception.
Copy protection: The proliferation of digital media has created a need to safeguard the rights of content owners with regard to protected A/V data (movies on DVD, movies purchased via pay per view, and so on). Basically, all digital I/O types will require some form of copy protection technology for these media.
The 1394 protection method, titled Digital Transmission Content Protection (DTCP), is sometimes referred to as "5C" for the originating five companies' merged proposals. DTCP requires data to be encrypted prior to transmission. Only authorized equipment can successfully participate in any DTCP transaction. DTCP requires that nodes encrypt outgoing data and decrypt incoming data via a special cipher, called "M6."
Designers should select 1394 silicon that provides support for DTCP authentication and key exchange algorithms and encrypt/decrypt functions. The chip set should additionally support as many individual decrypt/encrypt ciphers as the maximum number of simultaneous isochronous channels required to be supported.
In the offing: Anyone interested in 1394 applications in consumer electronics should watch certain areas closely, including digital audio, content protection, SBP-3 ongoing work, and DVD Forum actions.
Firewire is a natural for digital audio. As DVD and CD players move to DVD-Audio and Super-Audio CD playback capability, support for carrying high-quality, multichannel audio across a networked digital interface will drive future requirements into the 1394 interface. The DVD Forum has developed a draft specification aimed at defining the 1394 interface for DVD players, specifying the format and transport protocols for both audio and video output.
SBP-3 work has begun inside Technical Committee T10 of the NCITS. This ongoing work seeks, among other things, to add isochronous services to the already robust asynchronous support in SBP-2.
The recent licensing agreement be-tween the DTCP and Sony and Warner Brothers is an important milestone, paving the way for these two content owners to begin supplying digital content to 5C-enabled digital consumer equipment. Look for other content owners to license this technology soon. Additionally, designers should be aware of the "robustness" rules as dictated by the DTCP license agreement.
Table 2 provides a list of those standards and specifications that deal with 1394 and its use in consumer electronics applications. Standards listed but not freely available at the indicated Web site can be purchased from Global Engineering Documents at http://global.ihs.com.