Dismiss
There will be a system update on Friday, May 5th, 6 PM ET. You may experience a brief service interruption.
Browse Prior Art Database

MECHANISM FOR GENERATING COUNTED HARDWARE BREAKPOINTS UTILIZING AN EXTERNAL CPU PIPELINE MODEL

IP.com Disclosure Number: IPCOM000008446D
Original Publication Date: 1997-Dec-01
Included in the Prior Art Database: 2002-Jun-14
Document File: 3 page(s) / 159K

Publishing Venue

Motorola

Related People

Alex Iles: AUTHOR

Abstract

Microprocessor/microcontroller ln-circuit- Emulator (ICE) systems typically provide a hard- ware breakpoint mechanism in order to halt CPU operation to allow the user to perform intrusive interaction with their application. The CPU may be stopped in response to a user command or to detection of a specified system event.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 3

0

M

MOTOROLA Technical Developments

MECHANISM FOR GENERATING COUNTED HARDWARE BREAKPOINTS UTILIZING AN EXTERNAL CPU PIPELINE MODEL

by Alex lies

BACKGROUND

  Microprocessor/microcontroller ln-circuit- Emulator (ICE) systems typically provide a hard- ware breakpoint mechanism in order to halt CPU operation to allow the user to perform intrusive interaction with their application. The CPU may be stopped in response to a user command or to detection of a specified system event.

   The hardware breakpoint mechanism of the ICE will stop the processor via an individual signal (such as the BKPT signal of Background Debug Mode), if available, or by forcing the opcode of an instruction such as a software interrupt onto the processor's data bus during an appropriate instruc- tion fetch bus cycle.

  Often the ICE's breakpoint trigger is pro- grammed to detect an instruction fetch from a par- ticular memory address. In this case, it is desirable to break only when this instruction is executed.

  If the processor is pipelined, the breakpoint will be ignored if the "tagged" instruction is removed from the pipeline due to a change of program flow.

Thus, a breakpoint will not occur if the processor does not attempt to execute the particular instruc- tion. If the breakpoint event is again encountered by the processor, then the hardware breakpoint mecha- nism will engage as before. The process will continue until the processor executes the tagged instruction or software interrupt. Many processors provide real time indication of pipeline activity via pipe or opcode tracking signals which can be used to determine whether or not an instruction has been flushed from the pipeline.

  It is commonly desirable to break upon the Nth execution of an instruction, as in a particular itera- tion of a program loop. With a non-pipelined

processor, the mechanism to support this consists of an event detector, a programmable counter, and glue logic to gate the event detector output through to a hardware breakpoint generator which is triggered upon reaching a preprogrammed count of the desired processor event. However, with a pipelined processor, this trivial case mechanism is inadequate since it would be counting instruction prefetches (bus events) rather than actual executions of the desired instruction. If the pipeline is flushed (change of program flow) while containing an unexecuted breakpoint event, the trivial case counter will have counted only breakpoint event fetches and will not accurately reflect the number of breakpoint event executions.

  For instance, a problem will occur if the emula- tor user wishes to stop upon the tenth execution of a particular instruction in a loop, but upon the fifth loop iteration, that particular instruction has been prefetched and is in the CPU pipeline but gets flushed due to an interrupt. Subsequently, the instruction is re-prefetched upon return to normal program flow. Whereas prior to the exception the counter accurately reflected the...