|
||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
|
|
By Allison Hicks, IEEE 1394 Applications Engineer, Texas Instruments, Inc. As the consumer electronics market converges with the PC market in the digital world, many applications will involve transmitting and receiving high-bandwidth time-critical data. Consumers want to be able to use their computer to control, edit, store, or transport their consumer applications, such as video. Applications such as video editing, set-top box control, and digital VCRs require the transmission and reception of high volumes of time-sensitive data. Several compression standards, such as MPEG-2, have come about just to solve this dilemma of too much data. However, the basic questions of how to physically transport high-performance data still exists. The IEEE 1394 standard provides a method for data transport over a high-performance serial bus. With speeds currently up to 400 Mbit/s, and planned speeds up to 3.2 Gbit/s, 1394 provides the necessary services and bandwidth for those time-critical data-intensive operations. There are two types of data transport on 1394: asynchronous and isochronous. Asynchronous transport is ideal for data that need guaranteed delivery. The delivery of asynchronous transactions is guaranteed and the sender receives an acknowledgment from the receiving node. Isochronous transport is ideal for data that need to be delivered on time. Since there is guaranteed bandwidth there is a calculable maximum latency and there is no acknowledgment sent by the receiving node. However, because isochronous data packets are transmitted every 125 ýs, on average, it is ideal for high-bandwidth, low-latency data streams and lends itself to many audio or video applications. Still, a problem exists: How does an application get data on the 1394 serial bus for transport? Industry groups, along with link-layer manufacturers, have tried to solve this problem. The first link-layer controllers only had an interface with the microprocessor and in a system where only a simple microcontroller has access to the link-layer device, data transport is slow. Only the amount of data on the microcontroller data bus can be transported in or out of the link-layer controller per microprocessor transaction. This can be a bottleneck for high-bandwidth data applications, such as video. Advances in link-layer design added extra isochronous ports which gave a direct path from the application to the bus. However, the early versions of these also had disadvantages, primarily not having the flexibility system designers were looking for. These ports were only for basic isochronous data and asynchronous data still had to be sent via the microprocessor interface. Since no special features were added to handle special types of isochronous data, these ports were too generic to give any benefit to formats such as MPEG-2 compression or DV digital video. In addition, these ports did not have direct access to internal FIFOs, which could queue data and the application had to be able to receive or transmit data at the speed of the bus. One answer to the dilemma of how to get high-speed, time-critical data from an application to the 1394 bus is the Bulky-Data Interface (BDIF), a pair of ports supported by audio-video link-layer controllers (such as the TI family of TSB12LV4x, see Fig. 1.) The BDIF is the physical medium by which autonomous streams of different types are piped between an application and an IEEE 1394 Link-Layer Controller. Instead of using the microprocessor to write and read registers for data transport, the BDIF allows the application to pour data directly to and from the internal FIFOs. Basic interface signals allow the application extensive control over data transfers to and from the link-layer controller. This interface between the BDIF and an application is very straightforward with the only signals required from the application being an output-enable, an input-enable, clocks, data lines, and data-format lines.
The BDIF has 8-bit output and bi-directional ports while future parts will have expanded 16-bit ports. Since the BDIF has two ports data can be full-duplex, when the bi-directional port configures as an input-only port. The link-layer controller can operate in full-duplex if both of these ports are used and each port has its own -- independent -- clock, format signals, and modes of operation. Since all manner of data can be received or transmitted using the BDIF, control signals mark if the data are asynchronous, isochronous, or a formatted-isochronous type, such as MPEG-2 or DV. A format bus, made up of 3 format signals that are bound to each of the two ports, identifies these stream types. The encoding on the format bus also frames packets within the stream with the link-layer controller steering the data to or from an appropriate internal FIFO, according to these format codes. The BDIF has several different configurations and this flexibility is one key feature to the BDIF and gives system designers more freedom when interfacing to 1394. The configurations can be broken down into four different considerations, which have to be taken into account for the BDIO (bi-directional port) and the BDO (the unidirectional output port) separately. The configuration choices are bi-directional or unidirectional, clock speed, clock source, and serial or parallel data. Allison Hicks is an Applications Engineer for Texas Instruments' 1394 products. Her prior experience at TI has included work with the ASIC group and in Failure Analysis. She earned a bachelor's degree in electrical engineering, cum laude from Texas A&M University in 1997. Analog Main | Product of the Week | Columns | Editorial | Tech Notes
|
|||||||||||||||||||||||||||||||||||
|
Copyright © 2003 ChipCenter-QuestLink About ChipCenter-Questlink |
||||||||||||||||||||||||||||||||||||