On-chip debugger and Pipelining

Hi,

Hardware breakpoints in on-chip debuggers monitor the address bus to
check the execution context (and conditions) to break.

So here is a problem. Consider a CPU which has a pipelined
architecture. We have added a hardware breakpoint using a on-chip
debugger. Now if the hardware breakpoint monitors the address bus then
breakpoint hit will take place at the instruction fetch phase.

In a pipelined architecture, CPU fetches the instruction long before
the execution and also there is a possibility of not executing the
fetched instruction at all for a wrong branch prediction.

So if the CPU monitors only the ADDRESS BUS then there is a
possibility of breakpoint hit even when execution context does not
reach the breakpoint. My question is how does CPU handles it?

Regards,
Amitesh

amitesh.hati wrote:
> Hi,
>
> Hardware breakpoints in on-chip debuggers monitor the address bus to
> check the execution context (and conditions) to break.
>
> So here is a problem. Consider a CPU which has a pipelined
> architecture. We have added a hardware breakpoint using a on-chip
> debugger. Now if the hardware breakpoint monitors the address bus then
> breakpoint hit will take place at the instruction fetch phase.
>
> In a pipelined architecture, CPU fetches the instruction long before
> the execution and also there is a possibility of not executing the
> fetched instruction at all for a wrong branch prediction.
>
> So if the CPU monitors only the ADDRESS BUS then there is a
> possibility of breakpoint hit even when execution context does not
> reach the breakpoint. My question is how does CPU handles it?
>
> Regards,
> Amitesh

http://www.intel.com/products/processor/manuals/

"CHAPTER 18 DEBUGGING AND PERFORMANCE MONITORING"
http://download.intel.com/design/processor/manuals/253669.pdf

"These facilities allow a debugger to be called as a separate task or as a procedure in
the context of the current program or task. The following conditions can be used to
invoke the debugger:
* Task switch to a specific task.
* Execution of the breakpoint instruction.
* Execution of any instruction.
* Execution of an instruction at a specified address.
* Read or write of a byte, word, or doubleword at a specified memory address.
* Write to a byte, word, or doubleword at a specified memory address.
* Input of a byte, word, or doubleword at a specified I/O address.
* Output of a byte, word, or doubleword at a specified I/O address.
* Attempt to change the contents of a debug register."

The description says "execution", which means the debugger is tied to
more than the address bus. It also is tied to the state through the
pipeline, enough so to determine when execution has occurred.

The above are software facilities.

There are also hardware interfaces on a processor, to aid in the use of
a logic analyzer. The logic analyzer captures address and data from the
processor, but additional signals may be provided on the processor, to
improve the precision of the information collected. Otherwise, as you
note, tracing the external (prefetch) of instructions is not precise
enough on its own, to support a logic analyzer. It is possible, in fact,
that a lot of internal state information inside the processor can be
collected, such as scanning out the entire state of the processor (via JTAG
TAP scan chain). But details on this are not available for download. The details
are provided to Tektronix and Agilent, so they can design test equipment
for hardware developers to use. In typical usage, you connect a probe
head to the processor socket, then install the processor in the probe,
and by means of the logic analyzer pods, you can collect information
from the processor. The test equipment to do stuff like this is
pretty expensive. In addition to the analyzer, you also need to
buy the disassembler software package, that creates a traceback from the
hardware events seen on the outside of the processor.

http://cp.literature.agilent.com/litweb/pdf/5989-1552EN.pdf

Paul