single step with debugger

[Deepak Panwar]

Hi,

When the step bit in dcsr is set, core will enter the debug mode after each instruction. Debugger is supposed to resume the core by setting resumereq in dmcontrol register.  Below is the description of resumereq in the debug spec.

resumereq	Writes the resume request bit for all currently se- lected harts. When set to 1, each selected hart will resume if it is currently halted. The resume request bit is ignored while the halt request bit is set. Writes apply to the new value of hartsel and hasel.

Debugger should reset the resumereq bit after core comes out of debug/halt state. However, since debugger is connected via JTAG it's going to take hundred of cycles for it to reset the resumereq bit. Since core is in single step mode it is going to enter the debug mode pretty quickly (much faster than JTAG can reset the resumereq bit). Since the resumereq bit is already high, it will resume right away. It's not clear to me from the spec how we are going to handle this scenario. Right now, we are planning to resume only "if resumereq bit is set and dmcontrol register is written" but not sure if that's the right way to go.

Thanks,

Deepak Panwar 

[Tim Newsome]

The intent of resumereq is to cause resume at most once for every time it is written as 1. I agree that the language doesn't quite say that. Does https://github.com/riscv/riscv-debug-spec/pull/321 make this more clear?

Thank you,

Tim 

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/5e4bad05-08ad-4b40-9a40-806f0d729df7%40groups.riscv.org.

[Deepak Panwar]

Hi Tim,

Right now, we initiate a resume only if this bit is written 1 (even if the previous value is 1). I think that's consistent with your statement above. However, I think the better way will be to say "The intent of resumereq is to cause resume every time the bit transition from 0 to 1". This will make sure software always need to deassert the bit if it want to initiate another resume.

Thanks,

Deepak 

On Mon, Jul 30, 2018 at 7:05 PM Tim Newsome <t...@sifive.com> wrote:

The intent of resumereq is to cause resume at most once for every time it is written as 1. I agree that the language doesn't quite say that. Does https://github.com/riscv/riscv-debug-spec/pull/321 make this more clear?

Thank you,

Tim 

On Mon, Jul 23, 2018 at 12:03 PM, Deepak Panwar <panwar...@gmail.com> wrote:

Hi,

When the step bit in dcsr is set, core will enter the debug mode after each instruction. Debugger is supposed to resume the core by setting resumereq in dmcontrol register.  Below is the description of resumereq in the debug spec.

resumereq	Writes the resume request bit for all currently se- lected harts. When set to 1, each selected hart will resume if it is currently halted. The resume request bit is ignored while the halt request bit is set. Writes apply to the new value of hartsel and hasel.

Debugger should reset the resumereq bit after core comes out of debug/halt state. However, since debugger is connected via JTAG it's going to take hundred of cycles for it to reset the resumereq bit. Since core is in single step mode it is going to enter the debug mode pretty quickly (much faster than JTAG can reset the resumereq bit). Since the resumereq bit is already high, it will resume right away. It's not clear to me from the spec how we are going to handle this scenario. Right now, we are planning to resume only "if resumereq bit is set and dmcontrol register is written" but not sure if that's the right way to go.

Thanks,

Deepak Panwar 

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

[Tim Newsome]

On Tue, Jul 31, 2018 at 7:24 AM, Deepak Panwar <panwar...@gmail.com> wrote:

Right now, we initiate a resume only if this bit is written 1 (even if the previous value is 1). I think that's consistent with your statement above.

I agree.

 

However, I think the better way will be to say "The intent of resumereq is to cause resume every time the bit transition from 0 to 1". This will make sure software always need to deassert the bit if it want to initiate another resume.

I'm not sure about that. Is there a benefit to forcing the software to deassert the bit? Just saying "the intent is" doesn't help a hardware implementer, since it still allows a debugger to not deassert it. 

Tim

[Megan Wachs]

If it’s a write only register then there shouldn’t be any requirement on the hardware to track the transition. I think any time the bit is written 1 the action should take effect.

--

You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDiheka%3D5kSqgaS8VpF3gJ5FRvCw00WN93YqQqwXCoqh3wzLQ%40mail.gmail.com.

--

Megan A. Wachs

Engineer | SiFive, Inc 

1875 South Grant Street
Suite 600
San Mateo, CA 94402

me...@sifive.com