RISC-V Debug Spec Public Review

[Megan Wachs]

All,

 The Debug Task Group has been busy preparing the Debug Spec for ratification. We are encouraging the wider public to take a look at this time and comment during the 45-day public review period, starting now. The current PDF is attached, and can also be found at:

https://github.com/riscv/riscv-debug-spec/blob/master/riscv-debug-spec.pdf

Comments can reply to this isa-dev thread (or directly to me for private comments). For simple fixes/typos, GitHub Issues & PRs are also encouraged:

https://github.com/riscv/riscv-debug-spec/issues

https://github.com/riscv/riscv-debug-spec/pulls

Regards,

Megan

--

Megan A. Wachs

Engineer | SiFive, Inc 

1875 South Grant Street
Suite 600
San Mateo, CA 94402

me...@sifive.com

[Marc Gourjon]

Hi,
thanks for the good read ;)
Great to see that generic authentication mechanisms for external
debuggers are supported!

I wonder if it possible for the DM/DMI to signal if the Debug Module has
been locked down (e.g. from software or by fuses)?
It seems that the 'authenticated' register can be (mis)used for this,
but is there a more obvious way to tell that no debugging is allowed due
to configuration? In case of systems which support authenticated
debugging it might be difficult to differentiate whether authentication
failed or the DM is simply locked down. In such cases a 'locked'
register or some other form of signaling might be helpful for diagnostics.

Am I missing an aspect/information? Does this belong into the spec at all?

KR,
Marc

> me...@sifive.com <mailto:me...@sifive.com>
>
> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org
> <mailto:isa-dev+u...@groups.riscv.org>.
> To post to this group, send email to isa...@groups.riscv.org
> <mailto:isa...@groups.riscv.org>.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Megan Wachs]

Marc,

 Great question. The Debug Spec defines a generic communication mechanism (basically a serial interface) over which an arbitrary protocol can be transmitted. So, one could define a protocol that uses the authentication interface to querying the information that you mention (as a strawman example, simply reading the AUTH_DATA register could provide that information). 

The exact details of the authentication scheme are out of scope of the actual HW interface used to communicate them, so they aren't defined in the spec.

I would expect other documents to describe various protocols that could run over the authentication interface register, and what sequence of bytes would need to be sent/received, and their meaning.

Thanks for the question,

Megan

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org <mailto:isa-dev+unsubscribe@groups.riscv.org>.

To post to this group, send email to isa...@groups.riscv.org <mailto:isa...@groups.riscv.org>.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.

Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0e6c4a4f-6d33-ba38-3e0d-242143ddba25%40tuhh.de.

[Alex Bradbury]

On 21 February 2018 at 17:16, Megan Wachs <me...@sifive.com> wrote:
> All,
>
> The Debug Task Group has been busy preparing the Debug Spec for
> ratification. We are encouraging the wider public to take a look at this
> time and comment during the 45-day public review period, starting now. The
> current PDF is attached, and can also be found at:
>
> https://github.com/riscv/riscv-debug-spec/blob/master/riscv-debug-spec.pdf
>
> Comments can reply to this isa-dev thread (or directly to me for private
> comments). For simple fixes/typos, GitHub Issues & PRs are also encouraged:
>
> https://github.com/riscv/riscv-debug-spec/issues
> https://github.com/riscv/riscv-debug-spec/pulls

Congratulations on reaching this milestone - as I understand it this
is the first RISC-V specification effort to start to make its way
through the formal process defined in the RISC-V Foundation bylaws.

One procedural question: I can see that there are a number of proposed
changes or features that are still under discussion (e.g. hart
selection for >1024 harts). The RISC-V Foundation bylaws say that
"Committee Reports [presumably the debug spec is an example of this]
shall be made publicly available online via the RISC-V website
(www.riscv.org) for external comments and discussion for at least
forty-five (45) days before the Board votes on the Committee
Reports.". Does this mean that changes such as the >1024 hart support
can no longer be made in initial version of the debug spec without
restarting the review period, as the feature wouldn't get the required
level of public scrutiny?

Best,

Alex

[Megan Wachs]

My understanding is that changes can be made during and as a result of the public review commentary (otherwise, not much point to taking feedback!) without having to restart the 45-day period for every change.

FWIW, all outstanding proposed changes are being discussed in a public space (at the links in my email) and are additional features / backwards compatible changes.

That is my understanding, but I will certainly defer to the TC / Foundation on this procedural question.

Megan

[Alex Bradbury]

On 6 March 2018 at 21:33, Megan Wachs <me...@sifive.com> wrote:
> My understanding is that changes can be made during and as a result of the
> public review commentary (otherwise, not much point to taking feedback!)
> without having to restart the 45-day period for every change.
> FWIW, all outstanding proposed changes are being discussed in a public space
> (at the links in my email) and are additional features / backwards
> compatible changes.
>
> That is my understanding, but I will certainly defer to the TC / Foundation
> on this procedural question.

Thanks. There are obviously two extremes which make no sense:
* No modifications are allowed without restarting a 45-day review
period. As you suggest, this makes no sense as the process will never
complete.
* Arbitrarily large modifications are allowed without restarting a
45-day review period. This also makes no sense, as the wider community
have no longer had the opportunity to review the design prior to
standardisation.

Presumably the intent is somewhere in-between, in which case there
really needs to be guidance on how this is expected to work.

Best,

Alex

[Krste Asanovic]

Impossible to plan for all contingencies up front, so the guidance is for task group to gather data during review and to prepare a statement back to TC on proposed action to take.
The group can propose going through with minor changes incorporated and larger changes rejected, or ripping whole thing up and starting again.
Then TC votes to confirm decision,
Krste

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

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BwH295ALky5D7-Wb1r894yc8A7HLDSjiYjPHjp-szMukY6q6w%40mail.gmail.com.

[Alex Bradbury]

On 7 March 2018 at 07:49, Krste Asanovic <kr...@berkeley.edu> wrote:
> Impossible to plan for all contingencies up front, so the guidance is for task group to gather data during review and to prepare a statement back to TC on proposed action to take.
> The group can propose going through with minor changes incorporated and larger changes rejected, or ripping whole thing up and starting again.
> Then TC votes to confirm decision,

That makes sense, thanks. So is the next step that a ballot will be
held using Kavi for voting members of the technical committee to vote
for/against? Presumably this would go to the full technical committee
(i.e. foundation members with voting rights) rather than the workgroup
chairs/vice chairs invited to "technical committee monthly calls"?

I think adding a new page to riscv.org giving a brief overview of the
'lifecycle' of 1) a spec modification [bug fix / clarification / small
backwards compat change], and 2) a new specification would be really
useful.

Best,

Alex

[Peter Ashenden]

Hi Megan,

Thanks for the opportunity to review the latest Debug Spec. I have a question about non-maskable interrupts. The debug spec says that when a hart is in debug mode, all interrupts are masked. Does that apply to (what would otherwise be) non-maskable interrupts?

The issue is that the Privileged Architecture spec doesn't provide a way for code to see if an NMI is pending. The assumption is that there's no need, since when one is pending, the hart will take the interrupt and end up in the handler. If debug mode masks NMIs, then that assumption is broken, but debug code would have no way of detecting whether a hardware fault has occurred.

Is this a known issue, or one that needs to be addressed? Or are we all happy to leave it as is? Can you please include an explicit specification of whether non-maskable interrupts are included or excluded from making in debug mode?

Thanks, and cheers,

PA

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

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com.

-- 
Peter Ashenden, CTO IC Design, ASTC

[Peter Ashenden]

Actually, now that I think of it a bit more, a NMI should probably not be masked in debug mode. An NMI indicates a hardware error condition, so should probably be treated similarly to an exception arising in debug mode. If that's the case, should cmderr be set to 3 (exception), or 7 (other), or should one of the as-yet unused codes be used to indicate NMI during debug mode?

Cheers,

PA

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5b171303-43f6-1c97-4e04-b18637ee67fd%40astc-design.com.

[Peter Ashenden]

Hi Andrew,

The question here is what happens in debug mode. If NMIs are masked in
debug mode, setting a breakpoint on the handler won't work, since the
handler won't be invoked. So the error triggering the NMI would go
undetected. Alternatively, if NMIs are not masked in debug mode, they
would act like exceptions, which means the debug code would just stop
with a cmderr and not invoke the handler. At least in this case the
error is detected.

Cheers,

PA


On 9/03/2018 17:57, Andrew Waterman wrote:

> On Thu, Mar 8, 2018 at 3:01 PM, Peter Ashenden
> <peter.a...@astc-design.com> wrote:
>> Hi Megan,
>>
>> Thanks for the opportunity to review the latest Debug Spec. I have a
>> question about non-maskable interrupts. The debug spec says that when a hart
>> is in debug mode, all interrupts are masked. Does that apply to (what would
>> otherwise be) non-maskable interrupts?
>>
>> The issue is that the Privileged Architecture spec doesn't provide a way for
>> code to see if an NMI is pending. The assumption is that there's no need,
>> since when one is pending, the hart will take the interrupt and end up in
>> the handler. If debug mode masks NMIs, then that assumption is broken, but
>> debug code would have no way of detecting whether a hardware fault has
>> occurred.

> Can't you just set a breakpoint on the NMI handler if you want to
> intercept NMIs?

>> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/5b171303-43f6-1c97-4e04-b18637ee67fd%40astc-design.com.

[Alex Bradbury]

Just a ping on the above questions and suggestion.

The lifecycle as I understand it currently:
* RISC-V board establishes a taskgroup (or is it the technical
committee - if so, where do these discussions take place?)
* A taskgroup has a chair and vice-chair, and through a series of
meetings develops a proposed specification or specification
modification.
* Once the taskgroup is ready, it releases the specification for
public review for at least a 45 day period. This might be the first
time it is released publicly, but taskgroups could opt to release
earlier versions or public status updates.
* (?) After this review period, the committee will collate feedback
and submit to the technical committee for approval? Is there a TC
meeting? Or is this just a vote on Kavi? How long after the 45-day
review period does this take place?
* (?) Things then go up to the RISC-V board for final approval? Again,
how long is this expected to take?

I'd really appreciate any clarification here. It seems especially
important given that this is going to be the first time changes to the
specification are proposed and (hopefully) enacted through the RISC-V
Foundation.

Thanks,

Alex

[Peter Ashenden]

Hi Megan,

A comment re the reset value of dcsr.prv: The draft spec says this is 0 (user mode). The privileged architecture spec says that on reset, a hart starts in machine mode. It would be easier if dcsr.prv were reset to 3 (machine mode). That way, debug code after reset can simply do a dret to start the hart in machine mode.

Cheers,

PA

On 22/02/2018 03:46, Megan Wachs wrote:

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAKnTnFQs%2BaG9u%3DPG%3DbQK%3DACVNe06jtWf4dXELsAnd3yP_yQgcg%40mail.gmail.com.

[Alex Bradbury]

On 21 February 2018 at 17:16, Megan Wachs <me...@sifive.com> wrote:

> All,
>
> The Debug Task Group has been busy preparing the Debug Spec for
> ratification. We are encouraging the wider public to take a look at this
> time and comment during the 45-day public review period, starting now. The
> current PDF is attached, and can also be found at:

Maybe I'm missing it, but I don't think the current document clarifies
exactly which components of the spec must be implemented to be
considered compliant. If my hardware implements the debug core changes
and the debug module, but uses a non-standard debug transport module
(different JTAG interface, or a different transport altogether), then
how should it be described?

My view is that a sentence should be added to the debug transport
module chapter that encourages people to implement a standard DTM if
possible, but clarifies that custom DTMs can still be used while
retaining compliance with the debug spec. In my ideal world, vendors
would specifically advertise this. e.g. "Product x implements the
RISC-V Debug Spec v1.0 with a standard JTAG Debug Transport Module"
and "Product y implements the RISC-V Debug Spec v1.0 with a
non-standard JTAG Debug Transport Module".

Best,

Alex

[Tim Newsome]

dcsr.prv is overwritten whenever a hart enters Debug Mode, even straight out of reset, so its reset value is irrelevant. I suppose spec'ing it as 3 might save an implementation from getting this wrong. I'll make a PR.

Tim

[Allen J. Baum]

Ahem - putting my (new) compliance hat on:
One of the big questions I have is non-ISA compliance; how do you even test for it ? This is platform compliance, not ISA compliance, and its one of the questions that the compliance TG is going to have to wrestle with.
Mud will be involved.

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

>To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BwH295cCm20f0FtFs5xCC4pu6Atvp8MRW0Na%3DWe0CRsHKqS3Q%40mail.gmail.com.


--
**************************************************
* Allen Baum tel. (908)BIT-BAUM *
* 248-2286 *
**************************************************

[Alex Bradbury]

Does the debug task group have any view on the above?

Thanks,

Alex

[lkcl .]

On Wed, Mar 7, 2018 at 7:49 AM, Krste Asanovic <kr...@berkeley.edu> wrote:
> Impossible to plan for all contingencies up front, so the guidance is for task group to gather data during review and to prepare a statement back to TC on proposed action to take.
> The group can propose going through with minor changes incorporated and larger changes rejected, or ripping whole thing up and starting again.
> Then TC votes to confirm decision,

is that "mob-rule" (majority) voting or "unanimous" voting? majority
/ mob-rule voting basically completely ignores the input of the
minority, regardless of consequences. unanimous voting *requires*
that the majority actually listen to the minority and either take into
consideration what they have to say, or keep at it until they have
satisfactorily explained *to* the minority why the majority are saying
what they are saying.

whilst unanimous voting can be a pain in the neck for this reason
(that votes "stall"), long-term studies show that ultimately it
results in higher productivity [for group sizes no larger than 8].

i appreciate that mob-rule (majority) voting is the norm in the west:
very few people living in democracies would even question its use.
however the long-term studies show that it is one of *the* least
effective, least productive methods of team decision-making, resulting
in members simply "giving up because there's no point... because
they're the MINORITY".

so.

what type of voting is being deployed by the TC?

l.

[lkcl .]

On Wed, Mar 7, 2018 at 8:46 AM, Alex Bradbury <a...@asbradbury.org> wrote:

> That makes sense, thanks. So is the next step that a ballot will be
> held using Kavi for voting members of the technical committee to vote
> for/against? Presumably this would go to the full technical committee
> (i.e. foundation members with voting rights) rather than the workgroup
> chairs/vice chairs invited to "technical committee monthly calls"?
>
> I think adding a new page to riscv.org giving a brief overview of the
> 'lifecycle' of 1) a spec modification [bug fix / clarification / small
> backwards compat change], and 2) a new specification would be really
> useful.

i would like to see documented what type of voting methodology is
being deployed, as well as the rationale behind the decision-making on
what voting methodology was chosen. this is reasonable to have
documented, similar to how Debian fully document their voting
methodology as part of their Charter.

l.

[Megan Wachs]

Peter, Vyacheslav, Ben, Alex,  & all,

 Thanks for your great feedback. I'm aggregating it a here and pointing out some issues which were already addressed/ or are being tracked. Also I am attaching the current "latest" which incorporates the feedback already received, in case someone wants to start reading and not encounter the same issues.

From Peter:

How do NMI & Debug Mode Interact -- It's a good question, and one to which there isn't an immediate answer. My instinct is that it should be handled like any exception encounter in Debug Mode, but alternatives include still jumping to NMI handler. At any rate, the issue remains open here:https://github.com/riscv/riscv-debug-spec/issues/229

From Ben:

3.6: How does software know if the implementation clobbers the dpc when executing the program buffer?

Clarifying Issue Opened: https://github.com/riscv/riscv-debug-spec/issues/233

3.11.7: abstractcs – when is cmderr 4 used rather than 2? The reference to unsupported/supported when halted is confusing.

Clarifying issue Opened/Resolved: https://github.com/riscv/riscv-debug-spec/issues/234

 

How does the hasel behave when using abstract commands? Does it need to be 0 so that it is unambiguous which hart the command will run on? If not then the use of dmstatus.allhalted in Figure 3.1 seems wrong.

A: Abstract commands always apply to the single hart selected by hartsel. The figure is consistent in that if you halt/resume  a set of harts, they will remain halted throughout. The important thing in the portion related to Abstract Command execution is the blue part, where it is really the abstractcs.busy bit which is relevant. But you do raise a good point, and the ERROR states seem somewhat confusing. See https://github.com/riscv/riscv-debug-spec/issues/239

3.9: Quick access would be more useful if you could use it for an action to do on a break point. Possibly, a bit to say execute on next halt.

Could you provide a use case for this feature?

 

4.2 :Does this possibility of no forward progress for lr/sc pairs mean that in some implementations you won’t be able to single step throught code using these instructions?

We've tried to clarify this: https://github.com/riscv/riscv-debug-spec/pull/231

 

Future Ideas, 5 and 9 are already mentioned in the main part of the spec.

We've cleaned this up and moved this whole section to a seperate document: https://github.com/riscv/riscv-debug-spec/pull/230/files

 

The language in the spec seems a bit changeable. It talks about ‘halting the processor’ sometimes rather than halting a hart.

 Cleaned up in https://github.com/riscv/riscv-debug-spec/pull/238 and https://github.com/riscv/riscv-debug-spec/pull/237

From Vyacheslav:

1. Instructions in D-MODE are executed only with M-MODE privilege level...

Opened https://github.com/riscv/riscv-debug-spec/issues/240

2. When an instruction is executed in D-MODE and an exception is asserted, there is no detectable indication in the architectural state and, therefore, it is impossible to obtain additional details (e.g., cause, address).

Opened https://github.com/riscv/riscv-debug-spec/issues/241

3. There is ambiguity in the status of the Debug CSRs in relation to the HART(s). I.e. Debug CSRs reaction to the HART reset should be clearly defined in the spec... 

I think the main place this relevant is in when/if these CSRs are reset. This is generally related to how to debug out of reset when Debugger is not controlling the reset. I opened a more general issue here: https://github.com/riscv/riscv-debug-spec/issues/242

4. Major pieces of the Debug Mode description are missing - i.e. explicit description of its state machine would eliminate those ambiguities....

Can you be more specific what is missing?

5. ... We propose to generalize Debug Mode and treat it as a special mode...

I think we need more information to really understand the differences you propose here.

Debug Mode redirection: 

This is being tracked, "redirection" is probably a better name than "undelegate":https://github.com/riscv/riscv-debug-spec/issues/187

Program Buffer Only (no Abstract Command for GPRs):

This is an interesting proposal which goes back to the origins of the "common" spec. In a system with only a program buffer, several other requirements must be introduced so that the debugger can actually access registers, and none of these requirements are currently part of the spec. The abstract command access for GPRs was introduced to make it possible to do this "bootstrapping" in a general way. What do you propose to standardize in order to allow debugger to always access GPRs given only a Program Buffer?

From Alex:

...If my hardware implements the debug core changes and the debug module, but uses a non-standard debug transport module  (different JTAG interface, or a different transport altogether), then how should it be described?...

I think your analysis/phrasing is correct. The intention of the spec was to allow for different debug transports in addition to the standard JTAG DTM, but the idea is that those would also be standardized to allow for more common tools. I am also curious what kind of language the compliance task group will use given the proliferation of optionality in the  ISA spec. I think there the platform specifications/profiles serve a similar purpose: of all the optionality, clarifying what is necessary for  a platform.

Megan