by Dr. Kurt Böhringer

When developing products based on complex bus systems, use of the correct development tools is the crucial factor in achieving quality and reducing time to market. FireSpy400 is such a tool and its abilities go way beyond those of a pure IEEE1394 analyzer. Using FireSpy400 as an example, the requirements for an IEEE1394 development tool and the options such a tool can offer a developer are explained in this article.

Firewire’s Burning Impact

Nearly all embedded products communicate in some way with a PC or a network. Serial and parallel interfaces that were popular yesterday have been known for some time to be inadequate in supporting this type of communication. Instead, a multitude of standardized bus systems are available, each with vastly diverse characteristics and possible applications. The advantages of basing a design on one of these standards is that a developer can make use of readily available chips, existing know-how and even software packages (protocol stacks) as well as test and development tools. One of these bus systems has developed surprisingly fast into a popular, regularly used standard - Firewire™. Formerly known as i.Link™, this standard was once the only solution for video applications such as camcorders, DVD players and set-top boxes. The IEEE1394 Trade Association further developed the standard and it is now known as IEEE1394. Up to now, the available data transfer rates have been limited to 100, 200 and 400 MBits per second covering ranges of typically 10 meters. However, the new specification, IEEE1394b, offers an increased transfer rate of 800 MBits per second and using fiber optic cable, it’s possible to bridge distances of up to 100 meters. Automobiles are also set to make use of the IEEE1394 bus, which will further enhance the standard by addressing vehicle specific requirements. IEEE1394 is already a regular name in the PC world and its use is set to increase in this area. Up to now, IEEE1394 hardware has mostly been in the form of plug in cards (PCI or PCMCIA), however the bus is already integrated into many motherboards. IEEE1394 is also plug & play supported by Windows operating systems from Windows 2000 onwards.

Working with Firewire Chips
Semiconductor manufacturers such as Texas Instruments, Philips and Sony provide chips on which Firewire hardware developments can be based. A Phy Chip forms the interface to the bus system, known as the physical layer. It generates and detects hardware signals including the NRZI coding and decoding, and its main function is to configure and arbitrate the bus. If several ports exist, the physical layer is also responsible for replication at these ports. The physical layer is attached to the link layer, which is responsible for the generation and monitoring of checksums as well as the transmission and monitoring of acknowledge messages. Data to be transmitted and received is held in FIFOs which can be written to or read from by the application.

Although these chips play a large part in adhering to the protocol, it is nevertheless essential that they be programmed with software that is zero defect. To guarantee trouble free interaction in a universal bus system, every participant device is required to strictly conform to the protocol specification.

Nearly every developer has had the negative experience of developing a product to the best of his or her ability only to find that when it is switched on, it doesn’t work at all. When such initial hurdles are overcome, it’s then necessary to ensure that the system will continue to function correctly, even under the most exceptional circumstances. This would prevent an error from first occurring when the product is in use by a customer, thus preventing high costs that could be incurred and any damage to the company’s reputation. The only way to achieve this objective is to use a good test and development tool that is able to satisfy certain requirements incurred by the use of IEEE1394.

What to Look for in a Firewire Tool
As already mentioned, in Firewire, part of the protocol generation and monitoring takes place in hardware. Since various protocol levels exist in both hardware and software, pure software tools are unsuitable for protocol analysis. When introducing new hardware to a Firewire System, it is essential to be able to monitor exactly what’s happening on the bus. FireSpy400 provides four separate tools in one box that can be used simultaneously – a Monitor, Commander, Recorder and Generator. Using FireSpy400 as an example, the requirements and uses of a sophisticated IEEE1394 development tool are now revealed.

One of the first wishes of a developer working on a Firewire system would most likely be to have a clear and concise overview of the entire bus system. FireSpy400’s Monitor provides just that and it is able to answer questions such as, "which packets were transmitted," "how high is the bus voltage," and "how many errors occurred?" Frequencies of occurrence are sorted and displayed according to packet and error types and transaction speed. It’s possible to instantly see how many bus resets have been performed since recording started, what packet types are currently being transmitted and how many have already been transmitted.

The next step would then be to obtain a more detailed view of the Firewire System. FireSpy400’s Commander provides a detailed depiction of the complete system in its Topology View. The user can select the degree of detail to be shown and it’s possible to display SelfIDs and Bus Information Blocks for each device connected to the bus. The Commander’s Phy Register View aids correct programming of the Phy chip by not only displaying all register fields but also allowing their values to be edited. Information shown is displayed in "plain text," which means the significance of bit fields in registers is clearly indicated and appropriate values can be set by the user. Hence there’s no need to pick out individual bits and interpret their meaning with the help of a handbook. In the Commander’s Memory View, it’s possible to observe and modify the complete address space of every Firewire participant and Packet View allows individual packets to be transmitted and received. All in all, the Commander with its various views facilitates the displaying and corrective editing of the internal parameters of every Firewire device connected to the bus.

Figure 1: Topology of the IEEE1394 System, showing details of the configuration ROM of the device with ID 2

If the device being tested has reached the stage of development where it is already able to communicate over the bus, FireSpy’s Recorder can be put to use. This tool is able to record everything transmitted over the Firewire bus. The high data transfer rates used place specific requirements on the Recorder. To be able to record data traffic for a suitable amount of time and save whatever data is necessary to localize an error, an adequate memory depth is needed. Furthermore, without an efficient and straightforward user interface, the large amounts of data recorded would result in awkward user navigation through the data stream. However, the user interface in FireSpy400 allows the user to navigate through the data stream with ease by offering various views in the Recorder. Time View provides an overview by displaying packets in different shapes and colors according to their type and speed. Various zoom settings allow the time scale to be expanded or compressed as required.

Efficient search features allow the detection of sought after packet types or bus states. Both Packet and Transaction Views enable packets to be observed in greater detail. The greatest level of detail is provided in Data View, which goes as far as displaying the contents of data. By correlating these different views, the user is able to quickly locate any desired area of the data stream. Furthermore, it’s possible to control and filter the recording of data using triggers. This is achieved by the inclusion of sophisticated, yet easy to use hardware that not only triggers on the occurrence of any packet type or packet attribute but also enables triggers to be linked sequentially.

A further stage in the analysis of bus data traffic is the examination of data contents in higher-level protocols. To be able to get a good overview, the protocol should preferably also be displayed in plain text, as in the FireSpy400. Protocols currently supported by FireSpy400 are AV/C and SPB2, where AV/C is used for audio and video data, and SPB2 for SCSI devices. This protocol support goes as far as allowing audio data streams to be listened to and video data streams to be viewed as movies.

Figure 2: View of the AV/C protocol

In order to prepare a device for all possible events that could occur, it’s necessary to confront it with stress tests and with tests involving corrupt data on the IEEE1394 bus. This kind of testing requires a development tool that is able to transmit any packet, including corrupt packets. The Generator in FireSpy400 is provided for this very purpose. It allows straightforward editing of both isochronous as well as asynchronous data streams. It is also possible to modify previously recorded data streams that were saved using the Recorder and use them as Generator inputs. For a test to be worthwhile, it’s also necessary to have a variable reaction to the responses of the device being tested.

The greatest benefit of using a development tool occurs when the tool is able to support a product throughout all its stages of development. Using an IEEE1394 development tool such as FireSpy400 will enable easy realization of all market desired product features and a fast time to market, thus assuring a company the maximum competitive ability in their target market.