Notes from Debug Working Group 2016_12_07
Megan Wachs
Here are the notes (cleaned up a bit but still fairly free-form) from the meeting. These should probably be read in conjunction with Tim's slides.
Are all the slides/notes posted somewhere so we can see progress over time?
In other organizations I've been in, we "approve" the meeting minutes, so if I've misquoted you let me know.
Thanks all for the good discussion!
Megan
Intros and what brings you?
Tim : Task group chair, Works for SiFive, and SiFive wants debug spec to happen. We have some ideas on how it should be. The main reason to be at this meeting is working towards a common consensus.
Davide di Rossi — University of Bologne, technical leader of project at Bologna. Heard of meeting from Florian. Just wants to get an idea of what’s going on.
Florian — Similar to Davide. Andy Draper was involved in debug at ETH but he’s gone, and now we’re trying to ramp up on the Debug. Want to converge on one specification.
Gadge — His company (UltraSOC) provides debug and monitoring software
Megan — implementer of Debug Spec at SiFive
Richard — Wrote a debug interface for RISC-V used in PULP project. Takes a different approach from Tim's, want to come to a general agreement on which direction to take
Stefan — Mostly interested in trace debugging (LowRISC, OpenSOC). Standing on sidelines, don’t need convergency of ultimate goal, but sees RISC-V still as a research & in the beginning so immediate convergence is not critical
(Other people joined later)
Point — is our goal to get to a common spec? Seems like yes.
Tim Gave Definitions
Limiting scope — we’re talking about external debug, not something else
GOAL : Ratify spec by February 2017!
How can we achieve the goal?
Tim’s suggestion:
1. compile and agree on comparison document
2. followed by straw poll (silent majority?? maybe there is actually secret consensus and all this debate is unnecessary?)
3. Iterate until Debug Task Group agrees on a spec, then there is public comment, then the foundation votes on it.
Goal is for the Debug Task group to agree on the spec before getting lots of other feedback.
Public Review Period is 90 days (or is it 45 days?)
If we can get Debug Task Group agreement in February that’s probably good enough to meet our goal.
What ARE our goals for good debugger (see slides)?
Q about one of the goal — debugging systems which aren’t otherwise debuggable. Linux running a processes that you want to debug is not really one of the goals (because GDB can do that — we don’t want to worry about memory translation. It’s not a use case that GDB is good at (unless you hide all those details from GDB).
Added a goal : transport independent (shouldn’t be limited to JTAG)
Discussion of Security — should it be a goal at this time? We all agree security is important, but it is orthogonal to both specifications. So let’s not consider it for now and solve it independently of the proposal. We will revisit this in later meetings.
Ease of verification — how to we actually quantify that?
Verification should not just be hardware, it should apply to software verification too
Presentation of the two specifications:
Richard’s spec:
Each hart has a “Debug Unit”.
Then there is a “Debug Controller”. Translates external interface (e.g. JTAG) to an SRAM like interface. This talks to all the debug units.
The Hart Debug could be a slave on the System Bus as well, so other threads can be debugged by others.
Q from Rex in Orlando with AMD folks: In Rex’s SoC designs, there may be different taps for different blocks. Tim’s spec could be used to access different blocks. You can already access those registers outside of the processor by other means, so why would you duplicate that functionality? But you may want to see the view of the storage from the view of the processor. The duplication may come in handy. (I think the question was unclear)
Clarifying question — the debug block inside the processor is only accessing registers inside the processor, right?
Richard A: Right. Anything accessed external to the processor is done by the debug controller. But there is no reason you can’t go through the CPU’s data bus. But I didn’t do this intentionally because I didn’t want to hog the CPU’s data bus. And this means if the CPU is in a deadlock you can bypass it.
Q from Rex: — is Richard’s spec more “distributed”?
A — we’re not sure… maybe it’s actually less distributed. It’s purely doing CPU accesses.
Q -- If you want to access peripheral space you wouldn’t do it within the same module, you’d need another module to do it?
A — the Debug Module *inside* the CPU only access the CPU’s internals. If you want to access something outside of the CPU, it’s handled by the external debug controller.
The Debug Controller — talks to outside world over JTAG or USB. It is a System Bus master, can do burst accesses. It is a serial port.
In addition, the Debug Controller talks to the Debug Unit inside the CPU. NOT spec-ed is going through the processor’s data path to access memory.
Q: In a large SoC if you have lots of system type buses, would you have lots of these JTAG taps? Would this be part of some subsystem in the SoC?
A— so far is 8 core system hooked up to multiple buses. Using system interconnect to make sure debug controller can access all the different buses. (3 different buses in the system). If you hook up multiple CPUs, you have to hook up those CPUs debug buses together and give some address select.
Q/Statement : Another major feature — debug module can access memory even if the processor is stalled.
Tim’s Spec:
Requirements : A way to reset, interrupt processor, and feed instructions to processor from Debug Module. This is the minimum implementation.
Feeding instructions all the time is slow if you want to read a lot of memory. You’re running the same instructions over and over again. You can use an instruction buffer , scratch RAM, etc to make things more efficient.
Also, optional serial port, direct bus access. Similar to Richard’s spec.
Main point is that we do debug by feeding the processor instructions.
Can we agree that the main differences are:
- in Tim’s, you MUST feed instructions into the CPU instead of stalling it
- In Richard’s, there is a memory mapped CSR path. Access the data more directly.
Agreed to do 20 minutes over...
Q: If the fundamental difference is instructions or memory map, can we just abstract that up higher?
A: Tool vendors need some good abstraction. 10,000’ looking the same is not enough.
Richard — you could implement his spec by taking the memory mapped interface and feed instructions. You “read some GPR”. In the hardware, you directly access the register file, *or* translate the memory accessed read into instructions.
Stefan's proposal is this, to "support both" : We understand the point feeding snippets of instructions is a drawback of the implementation of the instruction stuffing. Is there some sort of hypothetical path of this, or they would both work.
Counter argument that more abstraction — feeding processor instructions while it’s halted is an essential part of the Debug Interface— people should be able to do arbitrary things because RISC-V is extensible.
once you have instruction stuffing requirement, you can use it to access the registers, rather than specifying a *different* way of accessing those registers.
In theory, you can implement a memory mapped interface through instruction stuffing. Stefan was suggesting that you could do both. But isn’t it better to just pick one design that does it all.
Richard’s counterargument — for really small designs, Tim’s spec is overkill (w/ all the RAMs and ROMs). Also, by specifying lots of implementation details, isn’t it counter to the RISC-V spec which is very abstract and high level. These are Richard’s two biggest objections.
Tim: Trying to address these issues (slashed RAM, ROM, CSRs. Should be much leaner and lightweight).
Gadge: Do you think that just running instructions is more amenable to the RISC-V model? Because it’s fully extensible?
A: In some implementations it may be hard to push instructions through the heirarchy. In that case, isn't it still possible to implement a debugger?
Q: Why is that so intrusive?
A: In Richard’s current implementation (a small system). It’s more difficult to feed in the instructions. If you hit the break, stall the pipeline and just access registers is easier
Q: (Megan): What is the abstraction?
“Go fetch me some register data or CSR, or Program Counter”
Q/Statement: Seems like it's all about muxing -- either we mux access to the register files or to the instruction pipeline.
Action Items
* Another call next week
* Add the software system — what does software do to get things done?
* Method sequence charts would be very helpful — for the outside view, what should the software do.
Email Tim if you want to edit the comparison doc and can't figure it out.
Megan A. Wachs
Tim Newsome
Are all the slides/notes posted somewhere so we can see progress over time?
In other organizations I've been in, we "approve" the meeting minutes, so if I've misquoted you let me know.
Alex Bradbury
> Public Review Period is 90 days (or is it 45 days?)
>
> If we can get Debug Task Group agreement in February that’s probably good
> enough to meet our goal.
* The debug working group will converge on (hopefully) one
specification, which is passed to the technical committee. If
necessary, I feel it would be sensible to send two specifications (and
reasoning for why we failed to converge) for consideration.
* The technical committee will consider the debug working group's
output, the formal voting mechanism (one vote per RISC-V member
organisation) takes place, and the outcome will be submitted to the
board of directors
* If the technical committee voted to accept a proposed debug
specification, it must be explicitly available for public comment for
45 days _from that point_ before the board vote on it, taking into
account any subsequent comments
If anybody understands differently, please correct me.
Best,
Alex
Alex Bradbury
> On Fri, Dec 9, 2016 at 9:34 AM, Megan Wachs <me...@sifive.com> wrote:
>>
>> Are all the slides/notes posted somewhere so we can see progress over
>> time?
>
> That's a good idea. I've uploaded all slides/notes so far to the kavi
> workspace site. I don't think I can make that public, but people who are
> interested can ask a group member to show them the slides/notes if they
> can't find it on the mailing list themselves.
Although there's no problem in this case, having people contact RISC-V
members for downloads from kavi is not a good precedent. I would
personally _strongly_ advocate that all other working groups follow
the debug group lead by operating out in the open, but that is a
choice they make individually. RISC-V Foundation members, in general,
are not able to share documents or group discussions unless they were
explicitly made public.
Best,
Alex
Tim Newsome
On 9 December 2016 at 18:48, Tim Newsome <t...@sifive.com> wrote:
> On Fri, Dec 9, 2016 at 9:34 AM, Megan Wachs <me...@sifive.com> wrote:
>>
>> Are all the slides/notes posted somewhere so we can see progress over
>> time?
>
> That's a good idea. I've uploaded all slides/notes so far to the kavi
> workspace site. I don't think I can make that public, but people who are
> interested can ask a group member to show them the slides/notes if they
> can't find it on the mailing list themselves.
Why don't we just link to them in your comparison/overview doc?
Although there's no problem in this case, having people contact RISC-V
members for downloads from kavi is not a good precedent. I would
personally _strongly_ advocate that all other working groups follow
the debug group lead by operating out in the open, but that is a
choice they make individually. RISC-V Foundation members, in general,
are not able to share documents or group discussions unless they were
explicitly made public.
Best,
Alex
--
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%2BwH296QmySU%3DrP8tkZ6tLWHe4m%2BZPRMp9S%3DU9R177ASLinBmQ%40mail.gmail.com.
Alex Bradbury
> On Fri, Dec 9, 2016 at 11:00 AM, Alex Bradbury <a...@asbradbury.org> wrote:
>>
>> Although there's no problem in this case, having people contact RISC-V
>> members for downloads from kavi is not a good precedent. I would
>> personally _strongly_ advocate that all other working groups follow
>> the debug group lead by operating out in the open, but that is a
>> choice they make individually. RISC-V Foundation members, in general,
>> are not able to share documents or group discussions unless they were
>> explicitly made public.
>
>
> The reason to use kavi is that it should provide a more official/permanent
> storage for the Foundation. The docs are already available in public (just
> search the mailing list), they're just not convenient right now. I'm not
> trying to hide anything from anybody, and notes and slides will always be
> shared with the mailing list AFAIC.
debug group activity is in the public (which as I say, is very much my
preference) I'm just suggesting it would be preferable to have a
publicly accessible listing of documents (if not your comparison doc,
then a public debug working group page) rather than encouraging people
to ask RISC-V members for documents extracted from Kavi. The reasoning
being that in the general case, RISC-V Foundation members are not able
to download documents from Kavi and share with non-members.
Best,
Alex
Tim Newsome
Best,
Alex
--
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/CA%2BwH296GUqAnxZF0781r2CeEzxDBmHCJYpPTAQxG_w24qkXevA%40mail.gmail.com.
Alex Bradbury
> I would love it if you keep a public mirror of those notes somewhere.
the goal of maintaining a links to current specification proposals,
and details on past and upcoming meetings. As the repo name suggests
I'd like to enable github pages for this, but I'll see if I can get
the repository transferred to the RISC-V GitHub organisation first.
Best,
Alex