Previous Page  
 Home  
 Contact Us  


Frequently Asked Questions - FS4200 IEEE-1394 Analysis Probe

This page provides answers on some of the more common questions we receive regarding our FS4200 IEEE-1394 Analysis Probe.

Q. How do I find out what are the latest versions of Agilent logic analyzer operating software?

A. Contact your nearest Agilent Call Center.

Q. How do I know which Agilent logic analyzer is best for my needs?

A. Click here.

Q. What is the IEEE-1394 Vendor ID code for FuturePlus Systems?

A. Our Vendor ID code is 00-50-30 (hex).

Q. Does the FS4200 work with the 16500 logic analyzer?

A. The FS4200 1394 Analysis Probe is supported by the 16500B with the following cards: the 16550A has 6 pods; the 16554A has 4 pods; the 16555A has 4 pods; the 16556A has 4 pods; the 16557A has 4 pods. For protocol decode, the FS4200 requires 4 logic analyzer pods. For simultaneous protocol decode and timing analysis, the FS4200 requires 6 logic analyzer pods. Based on this list you can see whether you have enough cards to do what you desire.

Q. How can I use the oscilloscope connections on the FS4200 to monitor the 1394 differential pair signals?

A. The maximum speed that the FS4200 can monitor is 400 MHZ. This will probably require a 1 GHZ BW scope (like an Agilent Infinium) to probe the signals. The user can use a cable that is a BNC to SMA with a 50 ohm load at the BNC connector. You will will need to set the input impedance of the scope to 50 ohms. One note of caution: probing at the SMA connector provides one load beyond the 1394 specification. A sample configuration is shown below:

  • FS4200
  • Agilent 54845A
  • Agilent 1250-1787 (SMAm-BNCm adapter)
  • Agilent 1250-0080 (BNCf-BNCf adapter)
  • Agilent 8120-1840 (BNC cable 112cm)

Q. Does the FS4200 support the backplane version of the 1394 spec?

A. The 1394 -1995 Specification Chapter 5 is devoted solely to the backplane version of the IEEE 1394 specification. To quote, " ...the backplane PHY specification does not include a description of the connectors or media. Such documentation is assumed to be part of a host backplane specification or to be included in the requirements for the application environment." Because of the lack of definition of a standard connection to the backplane, FuturePlus has chosen at this time to not support the backplane version. We talked about this early on and we concluded that the cable environment was the one we would address. If you would like to discuss this please contact us.

Q. Is the PHY chip you use compliant with the 1394 spec?

A. We are completely compliant with the 1394A spec with the PHY chip we are using.

Q. Is it possible to see protocol decode of PHY packets from another IEEE1394 node, like PHY configuration packets, link-on packets, self-ID packets, or extended PHY packets such as ping packet, remote access packets, etc?

A. The FS4200 shows all packets that it receives so it should show all the above packets from all nodes. The protocol decoder software shows the packet type and all the relevant fields.

Q. 3) Is it possible to set trigger event of errors such as CRC errors ? In the Users Manual page 20, error messages which can be detected by the analysis probe are described.

A. Yes it is possible to set a trigger on a CRC error. The user needs to set the trigger to a combination term of CRC = 1 and Error = 1. This will capture either a header or data CRC error.The error bit is set in the case of a bad CRC being detected.

Q. I find the ERROR bit at the 3rd bit of Pod1, Appendix A: Format Definitions page 27. If we set trigger on ERROR=1 and run, is it possible to trigger on one of the errors described as error messages in page 20, 21 ? If possible, in the future will we be able to focus and select the type of each error by the trigger setting?

A. Most of the errors mentioned on pages 20-22 are actually detected by the protocol decoder, so the error bit will not be set. The error bit (POD 1 bit 3) is set for the following conditions:

  • Header crc error. CRC bit (pod 1 bit 6 = 1) and error bit = 1
  • Data payload crc error. CRC bit (pod 1 bit 6 = 1) and error bit =1
  • Ack parity error. POD 1 (15:11) = 01100 and error bit = 1
  • Physical parity error POD 1 (15:11) = 01000 and error = 1

Additional errors are :

  • If a primary packet that should be acknowledged is not acknowledged, then this error condition is indicated by the Missing Ack bit POD 2 bit 3
  • If a packet has a non integral number of quadlets in it then this is indicated by the Non quadlet bit being set POD 1 bit 4 = 1
  • All other errors indicated on pages 20-22 are detected by the protocol decoder by post processing the packet information and displaying any errors detected

Q. Do you have any a future upgrade plan to support new implementations of IEEE1394 such as IEEE1394B ?

A. We have determined that the FS4200 will not be upgradeable to support the IEEE1394B specification. We do not have current plans to support 1394B but would consider it if the business opportunity was favorable.

Q. Do you have any plan to support the AV protocol which includes CIP header and AV data for isochronous packets?

A. To support these protocols would require the use of additional tools which the customer would need to purchase. We have no immediate plans at present to develop these tools but would certainly evaluate doing so if the market size justified it.

Q. I would like to know the benefit to do timing analysis of the PHY-Link interface of the analysis probe itself. Do you have any good examples about the merit of doing timing analysis of this interface?

A. There are two main reasons to look at the PHY-LINK interface: First, the user can determine approximately how long has elapsed between the node gaining the bus and actually sending the speed signaling. The interface will have the receive code on the CTL lines and FF on the data lines and then it will change to the speed code and then data. Secondly, if a customer has problems in his/her design, then they can use the timing interface on the FS4200 as a reference to check against their own design.

Q. We were considering purchasing a 1671G or 1672G analyzer and the FS4200. How much memory would you recommend for general bus analysis? Since the analysis probe requires 4 pods for power, I assume that no other circuitry can be analyzed at the same time with the 4 pod 1672G, and a 1671G would be required. Is this true? How many of the 68 channels are actually used? Your users manual shows only 16 of the physical link signals assigned to pod headers.

A. Your question about memory is difficult to answer as the optimum size is very much dependant upon the system you are testing (type of traffic, system throughput etc). The FS4200 passes a quadlet (32 bit word) of an IEEE1394 packet on each state clock. State clocks are only generated for packet quadlets therefore each line of memory will hold a quadlet. In this way the FS4200 reduces the amount of memory required to view the serial bus. In addition data and header information is clocked on separate clocks so you choose to only capture the header information (again saving memory). This and other features that can be used to reduce memory usage are described in the Users Manual in the section on State Analysis.

The 1671G and 1672G analyzers have 64K of memory as standard. If your application transports large amounts of data and you may want to see it, or if your application sends frequent packets of information, or if you need to observe traffic across other busses, we recommend purchasing one of the larger memory options, such as 256K or 2M.

The primary function of the FS4200 is a "state analyzer" which uses the 4 pods to send IEEE1394 packet information to the Agilent analyzer. The 16 lines of PHY interface can be considered "optional" in that you don't need to see them to observe bus traffic. These show what is happening on the PHY interface inside the FS4200 as this may provide additional insight into how the bus is operating. However, in general you can observe the activity on the IEEE1394 bus with just the 4 state pods. You are correct that no other circuitry can be monitored with a 4 pod 1672G. If you wish to monitor other circuitry then you would need at least the 102 channel 1671G.

Q. How do you set a trigger on PING packets? Are they decoded correctlly? Also, how do you set a trigger on Disable packets?

A. To support the extended PHY packets you need Revision B of the FS4200. so please verify eck that your analysis probe is this version (the revision should be on the label on the underside of the FS4200). For your information Revision B uses a new PHY that supports extended PHY packets. The earlier revision used a PHY that was developed prior to the addition of the extended PHY packets.

The current analyzer configuration files do not have symbols for the extended PHY packets but the FS4200 Inverse Assembler does decode these packets. We will be releasing a new version of the configuration files with symbols for extended PHY packets. However, in case you need to do this quickly here is a way that can be used to trigger on the extended PHY packets.

Define a trigger term that triggers on the following combination (the exact syntax will depend upon the analyzer you are using):

PHYPKT = PHY_CONFIG AND
DATA = 00XX XXXX 00tt ttXX XXXX XXXX XXXX XXXX (binary)

Where tttt is the TYPE value for the extended PHY packet (bits 21:18). For example if you wish to trigger on a PING packet then TYPE is 0000 so the trigger would be:

PHYPKT = PHY_CONFIG AND
DATA = 00XX XXXX 0000 00XX XXXX XXXX XXXX XXXX (binary)

Similarly for a DISABLE port packet the TYPE is 1000 (specifying a remote command packet). However, in this case you also need to specify the command field which is bits 2:0 in the data field. For DISABLE port the command field has the value 001 and the trigger would be:

PHYPKT = PHY_CONFIG AND
DATA = 00XX XXXX 0010 00XX XXXX XXXX XXXX X001 (binary)

Q. Are Self-ID packets one and two decoded correctly if there are more than 6 ports?

A. Yes, the FS4200 correctly decodes all SELF_ID packets (both SELF_ID packet #0 and SELF_ID packets #1, #2, and #3. Please note that in the listing window you will not see the SELF_ID packets generated by the FS4200 but you will see all the others.

Q. How do you set a trigger on a specific PHY ID in a Self-ID packet?

A.To trigger on a specific PHY_ID set up the following trigger term:

PHYPKT = SELF_ID AND
DATA = 10PP PPPP XXXX XXXX XXXX XXXX XXXX XXXX (binary)

Where PPPPPP is the required PHY_ID.

Q. Does the FS4200 support IEEE specification P1394-A Rev.2.0?

A. IEEE P1394-A Rev 2.0. failed its ballot and was never approved, so it never became a standard to which we could design. However, we use an IBM PHY which was designed to the proposed P1394-A supplement. We believe that the FS4200 has all the features that were proposed for the PHY for REV 2.0 version.

In addition, the IEEE has just had a ballot on P1394-A Rev 3.0, and we understand this has been approved. It is important to stress that many of the changes in P1394-A pertain to such things as arbitration acceleration, which have no affect on the FS4200. The FS4200 is essentially in listening mode. We will phase in any new PHY that comes on line from IBM.

Q. Is it possible to see protocol decode from another IEEE1394 node of PHY packets like the following?

  • phy configuration packet
  • link-on packet
  • self-ID packet
  • extended phy packet such as ping packet, remote access packet...

ANSWER: The FS4200 shows all packets that it receives, so it should show all the above packets from all nodes. The protocol decoder displays the packet type and all the relevant fields.

Q. Is it possible to set a trigger event on errors such as CRC errors?

ANSWER: Yes it is possible to set a trigger on a CRC error. The user needs to set the trigger to a combination term of CRC = 1 and Error = 1. This will capture either a header or data CRC error. The error bit is set when a bad CRC is detected.

Q. I find the bit of ERROR at 3bit of Pod1, Appendix A: Format Definitions page27. If we set the trigger on ERROR=1 and run, is it possible to trigger when one of the errors occurs described as error messages in page 20,21? As a suggestion for a future revision, can we focus on and select the type of each error by setting the trigger?

ANSWER: Most of the errors mentioned on pages 20-22 are actually detected by the IA, so the error bit will not be set. The error bit (POD 1 bit 3) is set for the following conditions.

  • Header crc error. CRC bit (pod 1 bit 6 = 1) and error bit = 1
  • Data payload crc error. CRC bit (pod 1 bit 6 = 1) and error bit =1
  • Ack parity error. POD 1 (15:11) = 01100 and error bit = 1
  • Physical parity error POD 1 (15:11) = 01000 and error = 1.

Additional errors are :

  • If a primary packet that should be acknowledged is not acknowledged, then this error condition is indicated by the Missing Ack bit POD 2 bit 3
  • If a packet has a non integral number of quadlets in it, then this is indicated by the Non quadlet bit being set POD 1 bit 4 = 1.
  • All other errors indicated on pages 20-22 are detected by the IA post-processing the packet information and displaying any errors detected.

Have a question you don't see answered? Contact Technical Support for a prompt answer.