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.
|
