What should wfi do when stepping?

[Peter Ashenden]

I have a question on the behaviour of a wfi instruction when stepping.
If you step and execute a wfi, should it act as a nop, or actually wait
for a pending interrupt before returning to debug mode?

I can envisage a scenario where you're debugging interrupt handling and
have stepie set to 1. In that case, you'd want wfi to actually wait.

However, in the case of stepie cleared to 0, waiting would deadlock. So
should wfi act as a nop when stepie is 0?

Cheers,

PA

--
Peter Ashenden, CTO IC Design, ASTC

[Tommy Murphy]

The draft v0.13 debug spec says that it should act as a nop.

[Peter Ashenden]

Hi Tommy,

Thanks for responding.

My understanding is that the spec in Section 4.1 says a wfi acts as a
nop if executed in debug mode. However, my question is about execution
of a wfi in non-debug mode when single stepping. The spec appears to be
silent on this.

PA

On 25/09/2018 17:47, Tommy Murphy wrote:
> The draft v0.13 debug spec says that it should act as a nop.
>
>
>

[Tommy Murphy]

What precisely do you mean by "in debug mode"?

I would assume this to mean when dmactive is asserted.

In which case as long as dmactive is asserted the wfi will degrade to a nop?

[Tommy Murphy]

Actually re-reading the spec the issue of wfi degrading to nop only seems to apply when abstract commands are being executed for debugging purposes from the debug module program buffer. Otherwise the spec says nothing about wfi in which case I presume that it acts normally when single stepping or resuming execution. Apologies for the mixed messages! :-)

[Peter Ashenden]

From Section 4.1:

Debug Mode is a special processor mode used only when a hart is halted for external debugging.

When stepping an instruction, the processor is not in debug mode, since the special behaviour listed in Section 4.1 does not apply to the single instruction that is executed.

Moreover, Section 4.3 says:

A debugger can cause a halted hart to execute a single instruction and then re-enter Debug Mode by setting step before setting resumereq.

The implication is that the single instruction is executed not in debug mode, since debug mode is re-entered after the instruction.

Does this clarify?

Cheers,

PA

--
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/DM5PR2201MB1036B478C919E5CB45C928BCF9160%40DM5PR2201MB1036.namprd22.prod.outlook.com.

[Peter Ashenden]

No probs. I just replied saying basically the same thing.

So back to my question, do we want to allow deadlocking by clearing
dcsr.stepie and then stepping onto a wfi? I'm kind of inclined not to.

PA

[Megan Wachs]

Forget single-stepping for a moment... you want a halt request to interrupt a core which is doing a WFI (or you may wait forever for the core to come under control of the debugger).

Extendeding that, I'd say that if you single-step over a WFI you'd better treat it as if it were a nop.

And keep in mind that wfi completion should not even in the normal case depend on whether interrupts are enabled (aka dcsr.stepie or mstatus.MIE). WFI completes when mip & mie register is non zero (interrupt is pending), it does NOT depend on mstatus.MIE (interrupt should actually be taken).

Make sense?

Megan

--
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/9912545a-bf99-cd69-8d8f-8e2a3e6fe172%40astc-design.com.

--

Megan A. Wachs

Engineer | SiFive, Inc 

1875 South Grant Street
Suite 600
San Mateo, CA 94402

me...@sifive.com

[Tim Newsome]

I think everybody is agreeing that WFI should act as NOP when being stepped over. Did I read closely enough? If so, I'll clarify that in the spec.

Tim

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAKnTnFT4-69TeadLe_b%2BUfRAgtqvbWOOC849_Px61hDRyjaF8w%40mail.gmail.com.

[Tim Newsome]

I've created this PR: https://github.com/riscv/riscv-debug-spec/pull/368

Please take a look.

Tim

[Mark Hill]

Hi Tim,

Yes this looks good. I think the key point is that WFI should always be viewed purely as a power saving optimisation and software must never rely on its blocking properties to get correct functionality.

Regards, 

Mark

[Peter Ashenden]

Thanks Tim. Agreed.

PA