Hey !

I'm almost done with implementation of HW breakpoints and before I commit
the RTL into the cvs I want to resolve the following issues:

1) Let say an insn should cause breakpoint. Does the insn execute first and
breakpoint exception (trap exception)
happen later, or is insn preceeded with breakpoint first? Example if
load/store insn that
should cause a breakpoint, doesn't complete successfully but
instead with an exception, does hw breakpoint happen?

2) DMR1[ETE] is not implemented. Instead DMR2[WGB] should be used to enable
breakpoint (trap exception). DMR1[ETE] will be removed, OK?

3) DCRx[CC]. What is not specified currently with regard to Compare
Condition and how
should we specify it: Iaddr/LSdata/LSEA CC DVRx; or DVRx CC
Iaddr/LSdata/LSEA. For ex:
LSEA >= DVR1 or DVR1 >= LSEA?

4) There is currently no register to indicate which watchpoint caused a
breakpoint. Should we add something?

regards,
Damjan

I believe that the trap should happen before the insn is executed. That
would be common sense, since every debugger handles it that way.



OK.



We should make the comparision logical from a programmers point of view.
When you set a matchpoint, you think "Break if address is greater that
X." So it would be LSEA > DVR1.



That would be most helpful once people start using watchpoints. So I'd
say yes.

Heiko

My 2 cents. Instruction break points typically happen on (preceeding) the Fetch of an instruction who's virtual address is in the bounds of the instruction break register(s). Data breakpoints typically happen after the instruction completes that meets the requirements of the data break point registers. The above methods are compatible with the break causing a processor trap (interrupt) and then for the break point handling code to be executed by the processor itself. An alternate way to handle breaks is for the break condition to stop the CPU clock prior to the reference of the trigger. The state of the processor and memory would then be observed and/or modified and the programmer would have the ability to single step the clock, single step the instruction, continue the exicution, alter the break conditions, etc... i.e. the debugger functions are external to the operation of the CPU. (uPU). BTW - it is difficult for a pipelined implementation to have an external HW debugger. Some of the HW debuggers I've experenced permitted breakpoints not only of CPU activity but other HW activity as well such as disk DMA writes to memory. Jim Dempsey ----- Original Message ----- From: "Damjan Lampret" lampret@opencores.org> To: openrisc@opencores.org> Sent: Sunday, February 08, 2004 7:53 PM Subject: [openrisc] HW Breakpoints in debug
and

enable