To begin, we build on the simple level shown for finding a particular transaction type with a specific address. Level 1 of this complex trigger sequence is essentially the same as Figure 4. The difference is that the flow moves to Level 2 upon detecting the conditions. As this bus has multiple phases and pipelining, storing only the information found in Level 1 is not enough to complete a picture of the I/O writes. The trigger sequence must also determine the stage of the pipeline in which the I/O write occurs and how many states must be captured to get all of the phases in the transaction.

The P6-family system bus diagram (Figure 3) conveniently shows the queue depth, starting at zero. However, because the I/O write discovery in Level 1 is possible when the queue depth (RCNT) is at any value, the logic analyzer must determine RCNT to proceed. Level 2 uses a four-way branch to make this determination. The queue depth increments one clock after an ADS#, so it must be evaluated during Level 2. The next sequence level to be executed (3, 4, 5, or 6) depends on the value of RCNT. If RCNT is 4, three response phases must first occur before the logic analyzer can capture the desired (fourth) response. In this case, the fourth response is the one associated with the address and I/O write detected in Level 1. A similar capture is required for RCNTs of 3, 2, and 1.

Building four sequence levels after Level 2 that each look for one response allows capturing the appropriate number of responses based on the RCNT value. The following example explains movement through this structure:

If an I/O write to port 80 is found in Level 1, we move into Level 2. If the RCNT obtained in Level 2 is three, then we must capture two responses before the desired third response can be found. This third response is part of the I/O write transaction detected in Level 1. Thus, Level 2 sends us to Level 4. We remain in Level 4 capturing information until we find the first response. At this point, we move to Level 5 and wait until the second response is discovered. Finally, we move into Level 6, where we capture states until the third response appears. Then we move to the final level (Level 7).

The extra samples captured in Level 7 are necessary because for this bus, data transfer is not specifically designated to occur with the response signals. For most I/O writes, they will be coincident, but this is not required. Storing extra states after the response signals are discovered guards against this. Five extra states are used for this example, but experimentation is necessary to discover the right number for your bus. This step also assists the software in the logic analyzer, which needs the entire transfer to decode the states properly.

There is no trigger specified in the sequence described for capturing I/O writes; the only way to stop it is with the STOP button. However, a trigger can be added to any level.

Looking for a Specific Data Value
Adding a small amount of complexity to the trigger described earlier allows you to detect a specific data value transferred to or from the address of interest. The example of an I/O write might be used to stop the analyzer on a specific POST code write. This could prove invaluable if the system continually locks up before or after a specific reading on the POST card. To gather this information, we alter the default storing to capture everything. We might also change the pre- or post-store, depending on where the problem is.

Because the IOQ requires responses to come back in order, the response detected in Level 6 will always be the one associated with the initiating address. If the response is not deferred (I/O writes rarely are), it will also contain the data for that address. We can trigger on this data simply by adding a data qualifier to this level. Figure 6 shows a revised Level 6 (modified from the Level 6 of Figure 5). This level looks for a data value of 0xC7, qualified with the data-ready (DRDY) signal. If this value is not found, we still want to exit on a response discovery, so the second branch is added. The other levels remain the same for tracking an I/O write of data value C7 to Port 80.

Figure 6. A Revised Level 6 from Figure 5 to Look for a Specific Data Value

Trigger Notes
The P6-family system bus can have up to eight outstanding transactions. With a pipeline this deep, even the most advanced logic analyzer trigger system will have difficulty. The four-way branching of the Agilent Technologies 16717A state and timing logic analyzer module allows triggering when the pipeline is up to four deep (RCNT = 4). If the pipeline is more than four deep, the flow through the trigger sequence will get stuck in Level 2. On a fully utilized bus, these triggering methods begin to break down, but they still enable analysis of many hardware problems.

The trigger sequence assumes bus usage low enough that the ADS# for a new transaction does not appear while the logic analyzer is in the response-detector sequence levels. If this happens, the entry will be captured, but it will not be considered a transaction for tracking.

When the bus or sequence of events on the bus become too complex for a decent logic analyzer trigger, the cross-triggering capability of modern logic analyzers is invaluable. Cross-triggering is using the trigger of one analyzer as the arm input to the sequencer of another analyzer. With the dispersion of processor buses and many other system buses, this feature can be exploited to find elusive bugs everywhere. Capturing a POST write of specific data is greatly simplified using cross-triggering. An algorithmic PCI analysis probe easily finds a write to a specific address with data. Using this event to cross-trigger to the front-side bus analysis probe yields results very similar to those shown for the complex trigger discussed earlier. The endless combinations of similar cross-triggers enable detection of many problems.