Trigger Example 3: Looking for a specific data value. Adding a small amount of complexity to the trigger above enables the detection of a specific data value transferred to or from the address of interest. The example of an I/O write might help a user stop the analyzer on a specific POST code write, for instance. This could prove invaluable if a system continually locks up before or after a certain reading of that code. To gain this insight, alter the default storing to capture everything. Also, change the pre or post store depending on the location of the problem.
The IOQ requires responses to come back in order. So the fourth response-capture level, level 6, will always be the response associated with the initiating address. If not deferred, it also will contain the data for that address. Just add a data qualifier to this level to be able to trigger on this data. The modified level 6 (Fig. 6) shows a data value of 0xC7 qualified with the data ready (DRDY) signal. Even if this combination isn't found, exit on a response discovery so the second branch is added. The other levels remain the same, which helps to track on the I/O write of data value C7 to Port 80.
There's no "trigger" in the trigger examples for capturing only I/O writes. The only way to stop a sequence is with the stop button, as mentioned earlier. But if desired, a trigger can be added to any level.
The P6 family system bus can have 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 HP 16717A state and timing logic-analyzer module, for example, can trigger when the pipeline is up to four deep. In other words, the rcnt cannot go greater than four. If it does, the trigger will get stuck in level 2. On a fully utilized bus, these triggers begin to break down. But they still can capture on many hardware problems. The triggers assume that bus usage is low enough that the ADS# for a new transaction doesn't appear while the procedure is in the response-detector levels.
Inevitably, a time comes when the bus or sequence of events on the bus becomes too complex for a decent logic-analyzer trigger. In this case, the cross-triggering capability of modern logic analyzers is invaluable. A cross-trigger occurs when the trigger of one analyzer utilizes the "arm" input to the sequencer of another analyzer. This feature can be exploited to find elusive bugs on processor buses and many other system buses.
The example of capturing a POST write of specific data can be greatly simplified using cross-triggering. An algorithmic PCI analysis probe can easily find a write to a specific address with data. Using this event to cross trigger to the FSB analysis probe can produce a result very close to the one described in the complex trigger above. The endless combinations of similar cross triggers can find many problems.
There's no way that this article could cover everything one might find interesting on a highly utilized transaction-based bus. And many of the specifics described here aren't applicable to triggering and capturing on all buses. The concepts remain the same, however.
Understand the bus. Draw a picture to help locate the problem. Map a trigger strategy using a flowchart. Events that could happen during subsequent clock edges become the flowchart levels. The possible occurrences within the same clock edge evolve into the actions and branches within a level.
Using default storing can eliminate un-needed states or include all states. Utilize the memory depth of the analyzer and the definable trigger position to capture where the problem might be located. If the problem isn't found on a complex bus, cross-trigger from a simpler one.
The specific applications shown here are easily extendible to other sophisticated modern buses, since most build on the same foundations. A little understanding and planning can definitely help unravel the debug mystery.
Trigger Example 3: Looking for a specific data value. Adding a small amount of complexity to the trigger above enables the detection of a specific data value transferred to or from the address of interest. The example of an I/O write might help a user stop the analyzer on a specific POST code write, for instance. This could prove invaluable if a system continually locks up before or after a certain reading of that code. To gain this insight, alter the default storing to capture everything. Also, change the pre or post store depending on the location of the problem.
The IOQ requires responses to come back in order. So the fourth response-capture level, level 6, will always be the response associated with the initiating address. If not deferred, it also will contain the data for that address. Just add a data qualifier to this level to be able to trigger on this data. The modified level 6 (Fig. 6) shows a data value of 0xC7 qualified with the data ready (DRDY) signal. Even if this combination isn't found, exit on a response discovery so the second branch is added. The other levels remain the same, which helps to track on the I/O write of data value C7 to Port 80.
There's no "trigger" in the trigger examples for capturing only I/O writes. The only way to stop a sequence is with the stop button, as mentioned earlier. But if desired, a trigger can be added to any level.
The P6 family system bus can have 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 HP 16717A state and timing logic-analyzer module, for example, can trigger when the pipeline is up to four deep. In other words, the rcnt cannot go greater than four. If it does, the trigger will get stuck in level 2. On a fully utilized bus, these triggers begin to break down. But they still can capture on many hardware problems. The triggers assume that bus usage is low enough that the ADS# for a new transaction doesn't appear while the procedure is in the response-detector levels.
Inevitably, a time comes when the bus or sequence of events on the bus becomes too complex for a decent logic-analyzer trigger. In this case, the cross-triggering capability of modern logic analyzers is invaluable. A cross-trigger occurs when the trigger of one analyzer utilizes the "arm" input to the sequencer of another analyzer. This feature can be exploited to find elusive bugs on processor buses and many other system buses.
The example of capturing a POST write of specific data can be greatly simplified using cross-triggering. An algorithmic PCI analysis probe can easily find a write to a specific address with data. Using this event to cross trigger to the FSB analysis probe can produce a result very close to the one described in the complex trigger above. The endless combinations of similar cross triggers can find many problems.
There's no way that this article could cover everything one might find interesting on a highly utilized transaction-based bus. And many of the specifics described here aren't applicable to triggering and capturing on all buses. The concepts remain the same, however.
Understand the bus. Draw a picture to help locate the problem. Map a trigger strategy using a flowchart. Events that could happen during subsequent clock edges become the flowchart levels. The possible occurrences within the same clock edge evolve into the actions and branches within a level.
Using default storing can eliminate un-needed states or include all states. Utilize the memory depth of the analyzer and the definable trigger position to capture where the problem might be located. If the problem isn't found on a complex bus, cross-trigger from a simpler one.
The specific applications shown here are easily extendible to other sophisticated modern buses, since most build on the same foundations. A little understanding and planning can definitely help unravel the debug mystery.