video call 8am PST Feb 8
Tim Newsome
Alex Bradbury
I had a few comments/questions:
### Halt and reset
* Why is haltsum optional?
* From my understanding, the haltsum bit in dmcontrol doesn't just indicate
whether haltsum is available, but also whether the halt registers at 0x40-0x5f
is accessible (again, why should this be optional?) This could be made
clearer. I came to this conclusion because table 2 states "if accessible" for
0x40-0x5f and I can't see anything else that would determine if they're
available.
* Section 8.2 indicates that when executing code from the program buffer, the
processor can be considered to be in halt mode. The halt bits at 0x40-0x5f are
described in table 2 as indicating "if the hart is ready for the DM to feed it
an instruction". This is a different condition to a bit being set in haltsum,
which indicates "which harts are halted". Is this intentional?
* I think the reference in the reading list for halt/resume to 8.1 should be
to
8.2 :)
### Abstract commands
* There really needs to be a cross-reference to 7.10.11 in 7.4/7.5 and
preferably a brief introduction of the autoexec functionality. Reading these
sections, you get the impression that you understand how it works (which is
good!), so when you flick through and see the autoexec stuff it comes as
something of a surprise.
* When can I expect the values in data to be preserved? e.g. do I consider
them nuked after a cmderr?
### Instruction supply
* It feels a bit odd to sometimes require ebreak and sometimes not. On the
other hand, a debugger that wants to work across all instruction supply
implementations can assume only ibuf0 and it just needs to be sure that if
progsize is > 1, then it writes ebreak to ibuf1 when it starts interacting
with a hart. After that, the code paths are identical.
* Thanks for the clear descriptions in appendix B, it really helped
Megan Wachs
--
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/CA%2BwH295DJFq_2eNmpVRYFBeL1K58ThdhOjnTFCh_6x4qoszSSw%40mail.gmail.com.
Megan Wachs
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/CA%2BwH295DJFq_2eNmpVRYFBeL1K58ThdhOjnTFCh_6x4qoszSSw%40mail.gmail.com.
--Megan A. WachsEngineer | SiFive, Inc300 Brannan St, Suite 403San Francisco, CA 94107
Tim Newsome
### Halt and reset
* Why is haltsum optional?
* From my understanding, the haltsum bit in dmcontrol doesn't just indicate
whether haltsum is available, but also whether the halt registers at 0x40-0x5f
is accessible (again, why should this be optional?) This could be made
clearer. I came to this conclusion because table 2 states "if accessible" for
0x40-0x5f and I can't see anything else that would determine if they're
available.
* Section 8.2 indicates that when executing code from the program buffer, the
processor can be considered to be in halt mode. The halt bits at 0x40-0x5f are
described in table 2 as indicating "if the hart is ready for the DM to feed it
an instruction". This is a different condition to a bit being set in haltsum,
which indicates "which harts are halted". Is this intentional?
* I think the reference in the reading list for halt/resume to 8.1 should be
to
8.2 :)
### Abstract commands
* There really needs to be a cross-reference to 7.10.11 in 7.4/7.5 and
preferably a brief introduction of the autoexec functionality. Reading these
sections, you get the impression that you understand how it works (which is
good!), so when you flick through and see the autoexec stuff it comes as
something of a surprise.
* When can I expect the values in data to be preserved? e.g. do I consider
them nuked after a cmderr?
### Instruction supply
* It feels a bit odd to sometimes require ebreak and sometimes not. On the
other hand, a debugger that wants to work across all instruction supply
implementations can assume only ibuf0 and it just needs to be sure that if
progsize is > 1, then it writes ebreak to ibuf1 when it starts interacting
with a hart. After that, the code paths are identical.
* Thanks for the clear descriptions in appendix B, it really helped
Tim Newsome
I'm confused by Table 3, "Use of Data Registers". What are examples of commands that use two args? I don't see any mention of "arg0" or "arg1" in the text.
Thanks,Megan
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/CA%2BwH295DJFq_2eNmpVRYFBeL1K58ThdhOjnTFCh_6x4qoszSSw%40mail.gmail.com.
Tim Newsome
Enumeration Questions:Are there functionalities, or combinations of functionalities, which are optional? Some examples are:1) Are prehalt/postresume required for all implementations? Or is this a "nice to have" optimization?
2) Are preexec/postexec meaningless when Program Buffer Size is 0?
3) If I only implement "read GPR" abstract command, is it required/assumed that I also have Program Buffer > 0?
Abstract Command Errors (abstractcs.cmderr):I'd like to name them and define what happens vs just "returns an error" or "fails". We could reduce the number or allow multiple error types from a given cause, but let's be specific.0) ERROR_NONE1) ERROR_BUSY: command or data registers were accessed while a command was executing (abstractcs.busy = 1)2) ERROR_HALT_RESUME: command was executed when hart was in the wrong state for it:- when hart was running, but this hart doesn't support the command unless it is halted- prehalt bit was set but hart was already halted- postresume bit was set but hart was already running (and pre-halt bit wasn't set)3) ERROR_NOT_SUPPORTED: Abstract command not supported. Causes include:- This Debug Module doesn't support that regno type (e.g. CSRs or FPRs) for this hart.- Debugger tried to use the wrong size to access registers for this hart (this is how to figure out XLEN). Note that if a pure instruction supply approach does this, it means it has to translate an exception into this error type.- Debugger tries to read a register that doesn't exist, e.g. not-implemented CSR. Pure instruction supply would have to translate an exception into this error type.4) ERROR_EXCEPTION: Exception encountered while executing Program Buffer (NOT while executing the abstract command)....7) ERROR_FAIL: everything else
What if debugger tries to debug a hart which doesn't exist? (assume this behavior is undefined).
Alex Bradbury
> On Tue, Feb 7, 2017 at 12:26 PM, Alex Bradbury <a...@asbradbury.org> wrote:
>>
>> ### Halt and reset
>> * Why is haltsum optional?
>
>
> It's not useful when there are fewer than 33 harts in the system. In that
> case the debugger can just read the first halt register directly. But maybe
> it's so cheap that it's simpler to require it?
>
>>
>> * From my understanding, the haltsum bit in dmcontrol doesn't just
>> indicate
>> whether haltsum is available, but also whether the halt registers at
>> 0x40-0x5f
>> is accessible (again, why should this be optional?) This could be made
>> clearer. I came to this conclusion because table 2 states "if accessible"
>> for
>> 0x40-0x5f and I can't see anything else that would determine if they're
>> available.
>
>
> That was not the intent. The halt registers are accessible if abits
> (dtmcontrol) is greater than 6 bits.
> It's optional so an implementation can save an address bit if it doesn't
> have many cores. But maybe that's not worth the extra requirements it puts
> on the debugger?
really feels it's going to add too much complexity for them to
implement. If the halt registers remain optional, I would suggest
editing table 2 so it says "If accessible (abits is >= 6) ...".
Does anyone feel strongly about the halt and haltsum registers?
>>
>> * Section 8.2 indicates that when executing code from the program buffer,
>> the
>> processor can be considered to be in halt mode. The halt bits at 0x40-0x5f
>> are
>> described in table 2 as indicating "if the hart is ready for the DM to
>> feed it
>>
>> an instruction". This is a different condition to a bit being set in
>> haltsum,
>>
>> which indicates "which harts are halted". Is this intentional?
>
>
> That's old language. Fixed.
>> * I think the reference in the reading list for halt/resume to 8.1 should
>> be
>> to
>> 8.2 :)
>
>
> 8.1 is important for selecting the hart you want to halt/resume.
> 8.2 really only applies if instructions are executed while halted, which is
> why I put it in the Instruction Supply section.
>
> I can still make the change if you think it's important.
>> ### Abstract commands
>> * There really needs to be a cross-reference to 7.10.11 in 7.4/7.5 and
>> preferably a brief introduction of the autoexec functionality. Reading
>> these
>> sections, you get the impression that you understand how it works (which
>> is
>> good!), so when you flick through and see the autoexec stuff it comes as
>> something of a surprise.
>
>
> Yeah. Does it make sense to put the actual commands (7.4.1) into the command
> register definition instead? Then you can have read the overall idea of both
> abstract commands and program buffer first. I agree some more general
> explanation is also needed.
description of abstractcs earlier in the spec would probably be
clearer.
>> ### Instruction supply
>> * It feels a bit odd to sometimes require ebreak and sometimes not. On the
>> other hand, a debugger that wants to work across all instruction supply
>> implementations can assume only ibuf0 and it just needs to be sure that if
>> progsize is > 1, then it writes ebreak to ibuf1 when it starts interacting
>> with a hart. After that, the code paths are identical.
>
>
> I agree, but requiring a bunch of extra logic just so a debugger can pretend
> there are always at least 2 ibuf registers seems unnecessary in this case.
> The debugger code change is truly minimal.
thinking on the matter. You could imagine saying that implementations
with only ibuf0 must allow silently discarded writes to ibuf1, but
then the number of writable ibuf registers doesn't match progsize and
that's weird.
Best,
Alex
Alex Bradbury
> On Tue, Feb 7, 2017 at 4:01 PM, Megan Wachs <me...@sifive.com> wrote:
>>
>>
>> Enumeration Questions:
>> Are there functionalities, or combinations of functionalities, which are
>> optional? Some examples are:
>>
>> 1) Are prehalt/postresume required for all implementations? Or is this a
>> "nice to have" optimization?
>
>
> I'm not even convinced I want it anymore. prehalt/postresume combined with
> executing a program buffer will clobber registers, unless there is some
> standard instructions the debugger can use to save/restore registers. Right
> now there aren't any.
accessing state via abstract commands?
Best,
Alex
Alex Bradbury
prehalt/postresume are primarily seen as useful optimisations if
you're doing some kind of sampling - for other uses you wouldn't
really expect much benefit right? Sampling has been brought up a few
times on list and in phone calls of course.
Best,
Alex
Megan Wachs
Tim Newsome
Megan Wachs
Notes from today's call. My connection was pretty bad so let me know if I missed/misquoted something important. Thanks to Stefan for taking notes at the end.
Megan
Debug Group Meeting
Newcomers: None (actually Jason Liu dropped in for a moment but didn’t get introduced).
Current Spec is still on Git/website, see slides for links.
Halt/Resume
Tim — Any questions? Select your hart and halt or resume it.
Alex — Haltsum — do we need it/ is it optional? We talked about it a little bit on the mailing list. Should it just be standardized so it’s the same for all debuggers?
Gadge — seems reasonable to have it optional. If you have a processor with less than 32, you wouldn’t need the overhead. It’s not onerous for the debugger to figure out whether it exists or not.
Stefan — so can it be probed if it is present? Or is it just a statement that if you have less than 32 harts, it should just be not present, so you don’t have to probe.
Also, Halt registers, are those optional? That seems like it can’t be optional (1 bit per hart).
Megan — I don’t get how halt registers can be optional.
Tim — well you could just look at the halt bit in DM Control (debugger walks through the loop itself)
Tim — Doesn’t seem that big a deal to require it, aren’t they cheap?
Vyacheslav — hierarchical approach — unify for halting as for status of halted. Can we apply to resetting lots of harts, resuming lots of harts at once. Wide vector something like a shadow register with interface… 2 32 bit registers. First is summary, second is lower-level focused on portion (similar to haltsum & halt).
Stefan — clarify, harts will halt/resume in parallel?
Vyacheslav — yes, as well resetting in parallel. Also, there are common resources in a core, and there are no specific registers for that.
Tim — if you want to do one thing on multiple harts all at the same time…. this is similar to cross-triggering. The hierarchical scheme could help you. But with this layout if you want to halt core 30 and 60 at the same time you can’t do that. I’ve always imagined this bits as status just so debugger can quickly do its main loop of determining who is halted.
Vyacheslav — but it’s 100% useful for harts to be resumed or resetted together.
Tim — but this doesn’t really solve the problem, can’t simultaneously do hart 30 and 60 for example
Different idea : Should we have “arm” bits in similar layout registers — when I give a command like halt/resume, apply to everyone who is armed.
Megan — this (parallel halt/resume) could make an implementation more complicated. Always assumed we were only debugging 1 hart at a time.
Tim — yes, but this does sound like useful functionality and we should probably support it, a cheap implementation can put the loop in the debug module vs. JTAG for more efficiency.
Add AI to spec this out. — Can Vyacheslav propose something?
Back to Q: Are halt and haltsum optional or mandatory? Right now they are optional.
Gadge — From debugger writer perspective, it’s better to have it not optional.
Alex — If there is no strong desire to make it not optional, it’s better to just make it required.
No one feels strongly enough about making it optional.
AI: So Tim will change spec to show it required.
Gadge agrees that “arming” is very useful. Can Vyacheslav write a proposal? Or eventually Tim will maybe get to it, but it’s good to have it in someone else’s TODO list.
Abstract Commands:
[There was an extensive Debate over how we are going to add more abstract command or not. My connection was terrible and I only heard half of what was said and eventually dropped off entirely]
Alex/Stefan — Should we define where additional abstract commands will go, e.g. for custom extensions and/or Standard extensions
Yunsup, Megan — I thought we agreed upon doing extensions with Instruction Feeding.
Gadge— we had agreed that we would handle extensions with Instruction feeding
Stefan — No, we didn’t, we voted on abstract commands… Debug spec is part of the ISA and ISA is not done yet.
Megan — Even if it is part of the ISA, it’s not like we go back to the “C” section because we added a vector extension. We shouldn’t have to keep revisiting the debug spec.
Yunsup — Tool vendor would have to keep updating their SW w/ new abstract commands
Stefan — How is it different in instruction feeding? Debug tool still needs to know what instructions to feed.
Yunsup — the debug module HW is the same, and the debug software’s job is to feed whatever the instructions are needed.
[Lots more debate]
Yunsup — Stefan, is your argument that we should leave part of the abstract command interface undefined / unallocated? Basically what is your actual suggestion?
Tim — So, should we just say these X bits are for more abstract commands, and when we run out of these bits, we can revisit.
Gadge/Yunsup — this is a really slippery slope.
Stefan — are we really writing a spec that can work for 50 years?
Yunsup — well, you’re making the reality that we will have to revisit
Stefan — we can’t because the standard extensions aren’t done. We have to revisit the spec and accordingly extend it with every standard extension that gets written.
Yunsup — I am suggesting a spec where that is *not* the case.
Someone mentioned trace, and we concluded trace should be discussed in the future, not part of this discussion.
Gadge — From a tool provider’s perspective, they want a simple way of getting into it. They don’t have to figure out what extensions are there and have everything be optional.
Stefan — But for instruction feeding you need instructions to give them to the host anyway.
Yunsup — I think the point of this spec is to help the tool vendors write software, not for the implementers to write their hardware.
Alex — (Couldn’t hear what he said)
Yunsup/Megan — Can we just say there are some bits for whatever abstract commands you want to make up, but it’s not like we’re going to revisit this spec every time to handle every standard RISC-V ISA extension.
So can we agree we are setting aside space for custom abstract commands for which people can do whatever they want, and that’s about it?
[Not sure that was actually the agreed conclusion].
Tim — inevitably, someone will bring this up in the future every time there is a new extension. Tim thinks that Stefan is saying someone will want to make the flexibility for the implementation. But, until someone comes in the future, there is no reason to talk about it more right now.
Ok, we’re agreed?
So we dont need to say something right now about potentially writing an abstract command for accessing vector extension?
[Again, not sure what the conclusion actually was there]
Yunsup — what about FP? Are those currently in abstract commands?
Tim — yes, those are in there currently (as optional).
[At this point, I dropped off the call, below notes are Courtesy of Stefan]
Vyacheslav): Asking about the pre- and post-flags
Tim: Explaining the approach of re-using the command or instruction
stream to repeat with different data.
Vyacheslav: A scratch register should exposed to the debug module
Tim: Write instruction to access csr to instruction buffer and write csr
Vyacheslav: Would it be better to have inbound and outbound data
registers decoupled? Data registers need to be aligned.
Tim: Don't understand about alignment. We are running out of time too,
can we maybe discuss it on the mailing list.
Vyacheslaw: We should make simple implementations lightweight on Muxes.
Tim: What are the next topics.
Stefan: Should only be two
Tim: I am good with keeping Reset out
Alex: The discussion around enumeration should be alive in parallel
Tim: Yeah, and people can bring up whatever they want, this is just the
focus for reading
--
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/CAGDihenmnuexPEzCGH7s%2BtpqsJN%2BTuUD3H%3D2cBk0X4SYBPyt6g%40mail.gmail.com.
Tim Newsome
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/CAGDihenmnuexPEzCGH7s%2BtpqsJN%2BTuUD3H%3D2cBk0X4SYBPyt6g%40mail.gmail.com.