Entering and leaving halt mode on Ebreak

[Neel Gala]

Hi everyone,

I am implementing a Debug system for one of our shakti riscv cores. Thanks for having this group and keeping the spec updated continuously. 

 I have some confusion on how the core enters the "tiny-self-loop".

Based on the Debug spec (v0.13 on the SiFive website) and some discussions on this group I understand that when a ebreak instruction is encountered (in machine mode) the following happens:

1. save pc of instruction (ebreak) in dpc
2. save cause in dcsr
3. update mepc and mcause as well (Should this happen?)
4. Jump to mtvec. (should I jump here or somewhere else?)

Now the trap_entry corresponding to mtvec would look like something below

0x00100     csrr t5, mcause; # trap_entry

0x00104     li t6, 3;

0x00108     beq t5, t6, 0x10000 # if the cause is that of breakpoint go to debug_trap_entry

...

...

...

0x10000:  fence.i # debug_trap_entry 
0x10004:  j 0x10000

My concern is that the trap entry changes the register t5 (and possibly others for a full fledged trap_entry code). I would then end up at a wrong context of registers when I halt.

So here are my questions:

1. Is there a different way to enter the debug_trap_entry? Should I be jumping to mtvec at all during a breakpoint/haltrep or should I jump to an "implementation defined" memory mapped address which contains the debug_entry only?
2. Also when I "resume" from halt state (probably using dret or resumereq from the debugger) I will be jumping back to the pc stored in dpc (which is that of the ebreak instruction). I would again enter the debug mode. Shouldn't the pc stored in dpc be that of ebreak+4?
3. Additionally also wanted to know for a single core with just one hart, while executing the ProgramBuffer should the "anyhalted" bit in the debug status register be kept raised?
4. What does hart unavailable mean in the dmstatus register? Can someone provide a naive example where this would be raised?

Thanks for the help.

[Tim Newsome]

Hi Neel,

Thanks for looking over the spec. It looks like there is some confusion about what the spec requires, and how that can be implemented. All your questions pertain to a specific implementation that sounds like what is described in Appendix A.2 (Execution Based), so with that in mind:

On Thu, Jul 13, 2017 at 11:13 PM, Neel Gala <neel...@gmail.com> wrote:

Based on the Debug spec (v0.13 on the SiFive website) and some discussions on this group I understand that when a ebreak instruction is encountered (in machine mode) the following happens:

1. save pc of instruction (ebreak) in dpc
2. save cause in dcsr
3. update mepc and mcause as well (Should this happen?)

mepc and mcause should not be touched when entering Debug Mode. 

1. Jump to mtvec. (should I jump here or somewhere else?)

You should jump to somewhere else for exactly the problem you identified. There should be some ROM which contains the loop at an address that is only used for debugging. (It doesn't *have* to be a ROM, as long as your debug logic has some way of getting the appropriate loop instructions to the core.)

 

So here are my questions:

1. Is there a different way to enter the debug_trap_entry? Should I be jumping to mtvec at all during a breakpoint/haltrep or should I jump to an "implementation defined" memory mapped address which contains the debug_entry only?

Implementation-defined, as you say. 

Note that if you like you don't need a debug_trap_entry at all if you want to implement halt in a different way. For instance you could gate the clock or feed nops into the pipeline when halted. That leads to even more implementation-specific details. Personally I think the approach with a halt loop is simpler.

1. Also when I "resume" from halt state (probably using dret or resumereq from the debugger) I will be jumping back to the pc stored in dpc (which is that of the ebreak instruction). I would again enter the debug mode. Shouldn't the pc stored in dpc be that of ebreak+4?

No. The debugger (gdb) takes care of this. Eg. in the following code:

0: li x1, 1

4: li x2, 2

8: li x3, 3

If a user sets a breakpoint at 4, the debugger will read the current instruction at 4, and then place an ebreak instruction there. The hart will execute instructions until the ebreak and enter debug mode. The debugger will see the hart is halted because of that ebreak instruction, so when asked to continue what it really does is:

1. Put the original instruction back at address 4.

2. Perform a single step, having the hart execute just that one instruction.

3. Write ebreak to address 4.

4. Tell the hart to resume execution.

1. Additionally also wanted to know for a single core with just one hart, while executing the ProgramBuffer should the "anyhalted" bit in the debug status register be kept raised?

As far as the debugger is concerned, a "halted" means a hart is in Debug Mode, even while it's executing code. (That code could be a park loop, program buffer, or other implementation-specific things.) While executing the Program Buffer, anyhalted is high. busy is also high.

1. What does hart unavailable mean in the dmstatus register? Can someone provide a naive example where this would be raised?

Harts that are not present in the system, or maybe currently powered down, are unavailable.

So if the debugger requests to access such a hart using hartsel in dmcontrol or hawindowsel (if implemented) then the unavailable bits must be set.

Tim

 

Thanks for the help.

--
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/88c82bf0-7a6a-4382-af6c-c861cad7e433%40groups.riscv.org.

[Megan Wachs]

Neel,

 Tim's response is great, but I want to clarify one point.

What happens on EBREAK (in any of M/U/S) depends on the current state of DCSR.ebreak[m/u/s]. When those bits are 0, when ebreak is encountered, then a breakpoint exception is raised. What happens on breakpoint exception is described in the Privileged Spec, not the Debug Spec. 

In other words, "raising a breakpoint exception" is very different than "entering debug mode".

Megan

On Thu, Jul 13, 2017 at 11:13 PM, Neel Gala <neel...@gmail.com> wrote:

--

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/88c82bf0-7a6a-4382-af6c-c861cad7e433%40groups.riscv.org.

--

Megan A. Wachs

Engineer | SiFive, Inc 

300 Brannan St, Suite 403 

San Francisco, CA  94107 

me...@sifive.com

[Neel Gala]

Hi Tim and Megan,

Thanks a lot for the answers. Sure cleared up a lot of confusion. 

I was moving on to read the Triggers and Trace support. I realise that the TRACE Appendix has been removed earlier this month. Will debug spec no longer support Trace? Is there some version of the spec I can use to implement a basic Trace Module?

Couldn't find much on the group as well about Trace.

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/88c82bf0-7a6a-4382-af6c-c861cad7e433%40groups.riscv.org.

--

Megan A. Wachs

Engineer | SiFive, Inc 

300 Brannan St, Suite 403 

San Francisco, CA  94107 

me...@sifive.com

--

Neel Gala

Project Officer

RISE LAB, IIT-Madras

[Tim Newsome]

The current focus of the group is to get run control debug ratified. To keep that focus, we got rid of trace (which was only very roughly specified anyhow). AFAIK there is interest in trace, but nobody is actively working on it.

Tim

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/CAFrQjCFUZ-VGUuSDG22XXY%2B49crb%2BCcsERxmL5NWrnxRGih4Vw%40mail.gmail.com.

[kr...@berkeley.edu]

To be more specific, the charter of this task group was to standardize
run-halt debug. A later separate task group can work on standardizing
trace.

Krste

| 1. save pc of instruction (ebreak) in dpc
| 2. save cause in dcsr
| 3. update mepc and mcause as well (Should this happen?)
| 4. Jump to mtvec. (should I jump here or somewhere else?)

| Now the trap_entry corresponding to mtvec would look like something
| below

| 0x00100     csrr t5, mcause; # trap_entry
| 0x00104     li t6, 3;
| 0x00108     beq t5, t6, 0x10000 # if the cause is that of
| breakpoint go to debug_trap_entry
| ...
| ...
| ...
| 0x10000:  fence.i # debug_trap_entry 
| 0x10004:  j 0x10000

| My concern is that the trap entry changes the register t5 (and
| possibly others for a full fledged trap_entry code). I would then
| end up at a wrong context of registers when I halt.

| So here are my questions:

| 1. Is there a different way to enter the debug_trap_entry? Should

| I be jumping to mtvec at all during a breakpoint/haltrep or
| should I jump to an "implementation defined" memory mapped
| address which contains the debug_entry only?

| 2. Also when I "resume" from halt state (probably using dret or

| resumereq from the debugger) I will be jumping back to the pc
| stored in dpc (which is that of the ebreak instruction). I
| would again enter the debug mode. Shouldn't the pc stored in
| dpc be that of ebreak+4?

| 3. Additionally also wanted to know for a single core with just

| one hart, while executing the ProgramBuffer should the
| "anyhalted" bit in the debug status register be kept raised?

| 4. What does hart unavailable mean in the dmstatus register? Can

| groups.riscv.org/d/msgid/debug/CAFrQjCFUZ-VGUuSDG22XXY%2B49crb%
| 2BCcsERxmL5NWrnxRGih4Vw%40mail.gmail.com.

| --
| 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/

| CAGDihemnBhrHjYibtSSPzM2ZtNrWjfnpC0ob8U8%3D7s1F8diE%3DQ%40mail.gmail.com.

[Po-wei Huang]

Yeah. Ratification is very important. Otherwise, it’s hard to attract open source involvement.

There are a lot of versions going on everywhere. Priv 1.7, 1.9, 1.10.  For debug, things are even worse.

Fragmentation is now the biggest challenge for RISC-V , if we look at RISC-V from the side of ARM and x86.

So, it’s good and necessary that we focus on run-control debug. 

Po-wei

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/22892.38545.376569.864752%40KAMacBookAir2012.local.

[Dr Jonathan Kimmitt]

You may not have been privileged to see details of the ARM architecture but I don't think it is a secret that its debug model is also very fragmented and essentially needs a different FPGA image to talk to every different model of ARM at the debug infrastructure level. This is a big overhead given the number of ARM models out there.

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/A652ACBB-5542-49DA-ADA7-7122B408D4C6%40gmail.com.