home

products

partners

revisions

contact

Probing and Connection to the System Under Test

Podlet Information

The information following is of use when probing processors on a motherboard and designing connectors on the motherboard for attachment of the logic analyzer probes.

GENERAL PROBE-RELATED INFORMATION:

Two versions of logic analyzer probes exist: standard (P6417 and P6418) and high-density (Mictor [trademark: AMP, Inc.]) (P6434).

The standard probe connections exist in two versions: single channel podlets (such as for a clock input) and eight-channel podlets.

The P6417 and P6418 standard probes are similar to each other, except insofar as how the eight-channel podlets are constructed. In the P6417, eight individual single-channel podlets are grouped together and held together mechanically as a unit by a plastic clip. In the P6418, the eight-channel podlet is implemented as a single molded assembly.

For the standard probes, each signal connection has a corresponding ground connection. The pins of the through-hole header used to receive the probe signal and ground connections have a physical separation of 0.1 inches (0.1"; 0,25 cm).

The width of the single-channel podlet is approximately 0.4" (1,0 cm); the single-channel podlet thickness is just under 0.1" (0,25 cm).

The length of the eight-channel podlet is approximately 0.9" (2,3 cm); the eight-channel podlet width is approximately 0.4" (1,0 cm).

For the eight-channel podlet header, when looking down from above, the header pin connections are as follows:

    01234567
    GGGGGGGG

The "0" through "7" pin connections are signal connections for the probe (for example, for the C0 probe, they would be channels C0:0, C0:1, C0:2,... C0:7). The eight "G" connections are ground connections (please note that all probe ground connections should be connected to signal ground).

For information concerning the combination surface-mount and through-hole Mictor [trademark: AMP, Inc.] high-density connectors and the high-density logic analyzer probes used with them, please refer to documents posted on the FTP area of the Tektronix website.

After locating the "Logic Analyzer Files Area", and then the "TLA7xx Files Area", refer to file "p6434.pdf" for information regarding high-density probing for use with TLA7xx logic analyzers. Locate the "9200/DAS Files Area" and refer to file "dasmtif.pdf" for information regarding high-density probing for use with DAS9200 and TLA5xx logic analyzers,

Note that the files contain information concerning protective shrouds that can be optionally mounted on your PCB with the Mictor connectors to insure that the high-density probes remain securely plugged in.

SIGNAL CONNECTION INFORMATION --IMPORTANT--:

When designing connectors onto the motherboard, please note that the disassembler software expects the processor signals to be available on the logic analyzer probes in the order and manner it is designed to work with.

Since the front panel of the logic analyzer allows arbitrary naming of the signals the probes carry, it might be assumed that the hardware connection order can be virtually redefined. While this is true to some extent, the support software usually makes use of certain probes to perform specific functions in the acquisition process (e.g., clock and qualifier probes). The C2:3, C2:2, C2:1 and C2:0 probes (although not labeled as "qualifiers") may also be called upon to perform specific acquisition qualification functions.

Furthermore, in order that trigger programs be able to perform arithmetic range matching (to trigger when an address in the range of (for example) 1000 to 1500 occurs), the appropriate groups (such as the Address or SysAD group) must be connected to the probes in the proper (analyzer-defined) bit-significant manner.

For these various reasons it is important to provide for connection of the processor signals to the probes in the manner expected by the support software. It is understood however that often a motherboard may have already been designed using a non-optimal signal connection scheme, and that redesign of the PCB may be undesirable or impossible.

If standard P6417 probes are being used, one solution is to mechanically disassemble the eight-channel podlets as necessary into their individual single-channel podlets, and rearrange the connection of the podlets so that the required signal connections are made. Use of this brute-force solution, although inelequent, may be the most efficient course to follow in many situations.

If P6434 Mictor [trademark: AMP, Inc.] probes and connectors are being used, a possible help is to determine whether swapping the 17-signal connectors (two per Mictor probe) at the logic analyzer acquisition module might provide a useful rearrangement of signals.

Another alternative in the case of Mictor probes is to employ a "swizzle board", such as part# NEX-HDSWIZ, available from Nexus Technology (formerly New Wave PDG), another Tektronix third party developer. Note however that use of such devices may in some cases impact the processor signal loading and integrity due to the additional capacitances and inductances introduced.

If such re-connection alternatives cannot be employed, and even if the signal connections to the acquisition module are essentially arbitrary (from the point of view of the support software), it is likely that probing can still be carried out and the disassembler will still be able to function, although probably with some reduction in performance efficiency and/or user-friendliness.

Consider an extreme situation where none of the signals are present where the software expects them to be. The first order of business is to provide the system clock to the acqusition module so that synchronous clocking can be accomplished. As long as the clock is available on one of the CK probes present on the acquisition module (i.e., CK0, CK1, CK2 or CK3, in the case of a 136-channel module), synchronous clocking should be possible.

Now, the support software will expect the clock to be present on a particular probe when the software is loaded and Custom clocking is selected in the Setup window. If the clock is present on the expected probe, then Custom clocking acquisition can be utilized. If not, External clocking needs to be selected in the Setup window, and the proper selection made as to which probe will in fact provide the clock source (as well as which edge of the clock (usually the rising edge) should be used).

If Custom clocking is used, then the front-end of the logic analyzer acquisition module (the Clocking State Machine (CSM)) must be configured to not attempt to make use of any qualifier signals in directing the acquisition process. This is because all required bus control signals are not connected (by assumption) to the proper CK, Q and/or C2 probes of the acquisition module. This mode of acquisition is specified to the support software via the Setup window Custom clocking options selections (refer to the support product user manual for details). This results in acquisition of each and every bus cycle that occurs. (This is the automatic result when External clocking is selected, as no CSM function is then enabled.)

When an acquisition is made, much of memory will probably be filled with idle bus cycles. The disassembler can deal properly with such cycles, and can optionally suppress their display (refer to the support product user manual for details). It is clear however that acquisition memory may be used quite inefficiently. It may be less clear that the performance of the disassembler (i.e., the time it takes to display a screen of text) may be impacted, since the software may have to spend more time searching through acquisition memory in order to find (non-idle) acquisition samples to display.

Some of the functionality performed by the CSM may be realized through the use of a trigger program. This approach can be used regardless of whether Custom or External clocking is used. For example, a trigger program can be constructed to store all types of cycles except for idle cycles. Such a trigger program is relatively easy to implement and may go a long way to improve the efficiency of the acquisition.

More sophisticated trigger programs can also be considered. For example for MIPS processor probing support, the software may configure the CSM to function to maximize the acquisition efficiency by storing for each memory access only a single memory request cycle (in addition to non-storage of all idle cycles). This is of utility since the MIPS processor can repeat a memory access request an indefinite number of cycles until the memory system signals that it is ready to accept the read or write memory access request. A trigger program can be constructed (which in addition to not storing idle cycles) will store just a single memory access request cycle. (Note that it is probably simplest to store the first request cycle seen, rather than (more correctly per the MIPS protocol) the last access request.)

The downside of implementing CSM functionality in a trigger program is that any further, debug-related trigger functionality (e.g., to trigger on the 100th occurrence of an access to location x12359) would be added on top of that basic functionality, thereby resulting in a relatively more complex trigger program.

Note importantly that a "gap" is introduced into acquisition memory when one or more bus cycles are selectively not stored in acquisition memory by the action of a trigger program. The disassembler by default will interpret a gap as a disassembly boundary, and will not associate a request cycle with following data cycles if one (or more) gaps are present inbetween them. This default action must be overcome by setting Disassemble Across Gaps on the Disassembly Properties page (refer to the support product user manual for details).

All of the above is in addition to the redefinition that needs to be performed manually via the Setup window, where the support software signal names and channel group definitions must be changed to reflect the actual signal connections as relevant to your motherboard. The probe signal names should be changed to reflect what signals are actually present on what probes.

Since the disassembler uses the channel groups (only) in order to perform disassembly, it is important that the channel group definitions be modified as necessary and their accuracy ensured. This is particularly important since the support software may define some groups in terms of the probes expected to carry the signals of interest making up the group, and in other instances groups may be defined in terms of the named signals themselves. While the user manual provides a specification of what groups the support software has defined (and of those groups, what subset are required by the disassembler to be defined for its proper functioning), the manual lists the composition of the groups in terms both of the probes as well as the named signals (refer to the support product user manual for details). The support software may use either (or both) means in the definition of the channel groups, as visible in the Setup window. Redefinition of the groups may specify named signals, probes, or combinations thereof; the issue is simply to ensure that all groups' definitions are changed to be correct.

Redefinition of the probes' names (and channel groups) cannot however reassign probe-specific functionality. That is, only the CK probes can be used as clock sources for the acquisition module. Likewise, only the CK, Q and C2:3..0 probes can accept CSM acquisition qualification signals. And, trigger program arithmetic range matching requires that the signals to be arithmetically compared be brought in to the acquisition module in the proper order (per the acquisition modules' hardware implementation; refer to the support product user manual for details). Thus, even after providing the clock, and possibly constructing a trigger program, so that acquisitions can be performed and with good efficiency, it may not be possible to perform certain debug-related triggering actions (such as to trigger when an address in the range of (for example) 1000 to 1500 occurs).

As somewhat of a footnote, it may be noted that techniques can be employed to permit acquisition of MIPS processor initialization information as normally clocked in by the ModeClock signal, even in the face of arbitrary signal assignments to the acquisition module probes. The usual approach would be to provide ModeClock on a clock probe of the acquisition module so that an acquisition could be done on each rising edge of the signal. This may be supported through the support software (in which case the Custom clocking acquisition would provide a setting for such use of ModeClock); else, External clocking could be utilized.

An alternative approach, suitable no matter what signal mis-assignments are the case, is to utilize Internal clocking, with a clocking period of e.g., 4 ns selected. Then, a trigger program can be constructed which emulates rising edge synchronous clocking, by looking for each low-to-high change in the ModeClock signal and performing a selective store of the ModeData signal at each edge seen.

In fact, a similar technique can be employed in the case the main processor clock signal (SysClk) itself does not exist on a clock probe. The use of such a trigger program as the underlying clocking means may result of course in relatively complex trigger programs when idle cycle non-storage and higher-level debug triggering functions (as discussed above) all need to be present and functionally integrated into one trigger program.

To reiterate, it is important to provide for connection of the processor signals to the probes in the manner expected by the support software. Please contact technical support with any questions regarding this issue.

Friday, 15-Dec-2017 02:05:22 CST    

Copyright  ©  Crescent Heart Software 2003
www.c-h-s.com