Browse Prior Art Database

Efficient Mechanism for Multiple Debug Modes

IP.com Disclosure Number: IPCOM000116775D
Original Publication Date: 1995-Nov-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 184K

Publishing Venue

IBM

Related People

Bridges, JT: AUTHOR [+7]

Abstract

Disclosed is a technique for providing, as part of a microprocessor design, a robust set of system debug functions that can operate in any one of three different modes. The technique disclosed uses a very small amount of logic over and above the microprocessor itself, thereby minimizing the cost associated with providing this necessary set of debug functions and modes. Moreover, the debug capabilities provided using the disclosed technique are particularly extensive, allowing a debug tool to perform virtually any operation that can normally be performed by the processor itself.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 30% of the total text.

Efficient Mechanism for Multiple Debug Modes

      Disclosed is a technique for providing, as part of a
microprocessor design, a robust set of system debug functions that
can operate in any one of three different modes.  The technique
disclosed uses a very small amount of logic over and above the
microprocessor itself, thereby minimizing the cost associated with
providing this necessary set of debug functions and modes.  Moreover,
the debug capabilities provided using the disclosed technique are
particularly extensive, allowing a debug tool to perform virtually
any operation that can normally be performed by the processor itself.

      As microprocessor designs become more and more complex, it
becomes increasingly difficult to effectively and efficiently debug
the software which runs on them.  Furthermore, this software debug
capability is required on roughly three levels.  First, the low-level
system software (e.g., the Initial Program Load (IPL) code and the
Operating System (OS)) needs to be debugged.  Next, the application
code, which runs "on top" of the OS, must be debugged.  These two
types of software debug require different mechanisms to enable the
debugging tool to communicate with the microprocessor system.
Finally, for both types of software debug, it is sometimes necessary
to "non-invasively" (i.e., without affecting the speed of execution
nor the program flow) TRACE the sequence of instruction execution,
for later, non-real time analysis.  These three types of debug are
referred to as External Mode Debug, Internal Mode Debug, and Trace
Mode Debug, respectively.

      The first level of debug must be accomplished without any
assistance from code that is actually running within the
microprocessor system.  This is because the system is not yet
sufficiently robust to allow this assistance code to run.  The debug
tool for this kind of software debug is a hardware system that is
connected to the microprocessor via some interface which can
manipulate the debug mechanisms inside the microprocessor.  Among
other things, these mechanisms must provide a means for the debug
tool to:
  1.  Stop instruction execution
  2.  Query and/or modify any and all processor resources
  3.  Single-step the execution of the instructions in the system
code
       being debugged
  4.  Set instruction or data "breakpoints" to cause the processor to
       again stop instruction execution when these addresses are
       accessed
  5.  Resume instruction execution

      This mode of debugging a microprocessor system, using an
external debug tool and without the assistance of code running in the
system, is referred to as External Mode Debug.

      Debugging of application code requires similar operations, but
the mechanism that provides these operations is different.  Instead
of a debug tool actually "stopping" the execution of instructions,
debug events (such as hitting a breakpoint) cause the ex...