MIPS MIPS32 74K Series, Programming Manual

Page: 118 / 156

8.1 EJTAG on-chip debug unit
Programming the MIPS32® 74K™ Core Family, Revision 02.14 118
2. the address generated by the program for instruction fetch, load or store matches those bits of the break-
point’s address register
IBAn / DBAn for which the corresponding address-mask register bits in IBAn / DBAn are
zero.
3. either IBCn[ASIDuse] / DBCn[ASIDuse] is zero (so we don’t care what address space we’re matching against),
OR the address-space ID of the running program, i.e. EntryHi[ASID] , is equal to the value in IBASIDn /
DBASIDn .
That’s all for instruction breakpoints, but for data-side breakpoints also:
• Data compare break conditions (not value related): both the following must be true:
4. It’s a load and DBCn[NoLB] is zero, or it’s a store and DBCn[NoSB] is zero.
5. The load or the store touches at least one byte-within-doubleword for which the corresponding DBCn[BAI]
bit is zero.
If you didn’t want to compare the load/store value then DBCn[BLM] will be all-ones, and you’re done. But if you
also want to consider the value:
• Data value compare break conditions:
6. the data loaded or stored, as it would appear on the system bus, matches the 64-bit contents of DBVHin with
DBVn in each of those 8-bit groups for which the corresponding bit in DBCn[BLM] is zero.
That’s it.
8.1.13 Imprecise debug breaks
Instruction breakpoints, and data breakpoints filtering only on address conditions are precise; that means that:
1. DEPC will point at the fetched or load/store instruction itself (except if it’s in a branch delay slot, will point at the
branch instruction);
2. The instruction will not have caused any side effects; in particular, the load/store will not reach the cache or
memory.
Most exceptions in MIPS architecture CPUs are precise. But because of the way the 74K core optimizes loads and
stores by permitting the CPU to run on at least until it needs to use the data from a load, data breakpoints which filter
on the data value are imprecise. The debug exception will happen to whatever instruction (typically later in the
instruction stream) is running when the hardware detects the match, and not necessarily to the same TC. The debug-
ging software must cope.
8.1.14 PC Sampling with EJTAG
A valuable trick available with recent revisions of the EJTAG specification and probes, “PC sampling” provides a
non-intrusive way to collect statistical information about the activity of a running system. You can tell whether PC
sampling is enabled by looking at
DCR[PCS] , as shown in Figure 7-5 above.
The hardware snapshots the “current PC” periodically, and stores that value where it can be retrieved by a debug
probe. It’s then up to software to construct a histogram of samples over a period of time, which (statistically) allows a
programmer to see where the CPU has spent most cycles. Not only is this useful, but it’s also familiar: systems have