video call, week of Jan 9
Tim Newsome
Tim Newsome
Tim Newsome
Tim Newsome
Tim Newsome
Megan Wachs
Debug Group Meeting
This week: decide as a group on the summary of the proposals…
Yunsup — quick sanity check on opinions. Last sentence that Alex wrote, “this gives greatest possible flexibility to designers...” So what do people think about whether it is beneficial to have SW to have one standard with common interface. Is it a benefit? That’s what I assumed everyone agreed and that’s why we are having a discussion. So what do people think?
Gadge— yes, it is important. We need a common interface.
Yunsup — because it seems like “everything optional” is on the table. Is that progress?
Stefan — If everything is optional, there is some way to enumerate or query what is available. SW can still be portable. There is some mandatory base register saying what is available. Maybe Device Tree at the extreme, or on the simpler end a few bits. But, still, we think that this is the *least* favorable approach. Seems like this is a fallback if there is no way to get everyone behind the other two
Alex — if the camps can’t be reconciled, “everything optional” has to be an alternative. Even ARM had multiple access methods. Maybe the needs of small cores and big cores means we don’t want to force a single approach. It’s a fallback in case we can’t find common ground. But there isn’t a huge amount of enthusiasm.
Richard — yes, that is the whole purpose of the discussions and task force to have the common base debug spec.
Alex — I don’t think it would be a complete failure on a *single* access method. If there were a few methods that were standardized, it would be a disappointment, but it would still work.
Yunsup — what do you mean by Access Method?
Alex — I mean OpenOCD, using JTAG, would have more than one way of accessing GPRs.
Yunsup — We’re not talking about the transport.
Everyone agrees.
Yunsup — how should the debug module and the core interact, that’s the biggest point of contention?
Stefan — no, I don’t agree. One proposal is an abstract interface memory mapped. Original proposal was halt debugging. That’s why we keep wondering if we can just store (in HW) little instruction snippetsBut, if we have the instruction feeding as the external interface, that's a different abstraction
Tim— The point of contention is the whether the interface exposed to the debugger is abstract or feeding instructions explicitly.
Yunsup — instruction feeding is still abstract. There are lots of different ways of feeding instructions into the pipeline.
Tim — in summary, we all want one spec, but general feeling is “two standard interfaces” might be better than no spec at all.
Proposal 1
Alex — think we’ve all read the summaries and proposals. Trying to summarize the structure of the argument. Can we state our assumptions and/or why we want it, for each. That way we sort of agree on what we disagree on.
Tim — you mean, what is the tradeoff that each proposal is making?
Alex — yes, I’m trying to repeat the arguments for people trying to understand the key tradeoffs.
Yunsup — can we add to what Alex wrote about instruction feeding. Benefits of instruction feeding approach is that it can interact well with non-standard extensions of RISC-V, and it’s future-proof in a sense.
Alex — not trying to just repeat pros and cons, want to explain the tradeoffs on a given approach
Stefan — it’s not an exclusive benefit of option 1.
Yunsup — make instruction feeding there, then if you want to expose processor state, you can do that too.
Stefan — all 3 options contain instruction feeding, so it’s not really a pro of the “instruction feeding only” approach.
Yunsup — if all things are optional, then people can’t build a common SW stack.
Gadge — let’s really avoid the "everything optional” approach.
Gadge — Tim made a comment of the advantage of running code to do debug tasks. But the advantage of the memory mapped stuff is to do tasks non intrusively, e.g. profilers. Like ARM, they have a subset where you can do memory mapped reads and writes to, and the instruction feeding allows for future cores.
We shouldn’t forget the SW side while we’re working on the HW perspective.
Vyacheslav — but there’s no strong contradiction between instruction feeding and abstraction interface, in my opinion. The composition is up to us and can be defined by us. We can introduce the 3 groups of debug functions to be very orthogonal to each other. You should list your supported functional groups. E.g. if you support instruction feeding, implement XYZ groups of debug functions. If you support Direct or Indirect access to internal resources, this is another functional group, and so on.
Yunsup —everything is optional, and we read and see how it works. Parallel analogy, We couldn’t agree on RISC-V ADD, so we decided to have two different kinds of adds and make the compiler figure it out?
Stefan — Debug tool vendors are pretty used to this situation. It has to work on different platforms and it’s a huge mess. I get your point, but the analogy is off
Gadge — I disagree that debug tools are messy (sorry I couldn't hear the rest)
Tim — let’s get back to enumerating what the exact things we are talking about are vs. debating pros and cons now.
Propsoal 2a.
Do we need to define it as memory map or commands?
Alex — no need to decide right now whether it is memory mapped or some abstract command.
Yunsup — expose abstract commands. Debug Module implementer will use memory map, or use instruction feeding, or whatever they want. So then, if you have to expose instruction feeding as an option, why is it an option, why is it not the base case?
Stefan — why is it mandatory if I don’t need if? If I have very simple RV32 core, why should I need instructions feeding if the base abstract commands do everything I need.
Yunsup — so is exposing it differently actually beneficial to the other designs?
Stefan — I’m just trying to formulate a compromise between to different camps, because it seems like we’ve been stalled for weeks.
Yunsup — I still want to hear the argument on why instruction feeding can’t be the only approach.
Tim — Let’s not stall, and agree on what we are debating. Once we have the list we can debate and discuss pros and cons. Let’s finish the list of approaches.
Do we need "Option 3" — HW *must* implement both and debugger has to pick one?
No one likes that. We don’t need this option.
Back to option 2a — Megan wants to know what *is* covered in the “base” abstract.
Alex/Richard — Basic idea is what’s in Richard’s spec.
(PC, GPRS, CSRS. FPRs are there, but would move the FPU into the instruction feeding and out of the “base” set). We want to keep everything XLEN sized.
Breakpoints — should they be CSRs or in Debug Module? Let’s talk about these later.
Proposal 2b
Yunsup -- , can we just kill this? Thought we wanted one spec.
Group — Let’s leave 2b on the table. If no one likes it, it will vanish.
Any other Proposals?
Vyacheslav — “Abstract approach with functional decomposition”. Any incremental additional functionality would be added in a functional group. Define the interface in such a way that instruction feeding will be integrated as one functional group.
Functionality should be divided into functional groups. For examples:
“instruction feeding access to core.”
"Direct accesses to internal resources"
“register reading only”
“register reading and writing”
If tomorrow someone proposes a brilliant idea of debug feature access, we can add it as different functional groups harmonically integrated into the spec (in future versions).
Tim — so is this sort of like 2b+?
V — Will try to explain this idea in more detail over email.
Tim — want to send out the list next Monday.
Any other proposals to add to the list?
Anything else people want to share or say what’s important to them?
Q — have these specs been implemented?
A — none of the specs have been implemented exactly, all have been implemented in some older version of the specs
Q — does the instruction feeding really work, can someone give some perspective?
A — Megan gave some perspective on implementing/using the current SiFive solution. The instruction fetching works, and good separation from a HW designers perspective. Gadge has implemented the SW to interface with it. Tim, from writing the OpenOCD debug support for it, the SW ends up more complicated because you want to minimize USB overhead. But this is a one-time cost for anyone who implements the interface. It does take more thinking than writing the debugger than just having an abstract approach. But it also gives you more options on some clever idea on how to get data out of your chip. Cyril — SiFive solution does work, and using it extensively. You don’t really know that it’s using instruction feeding as a user.
AIs —
Everyone who had a proposal edit and clarify to send to tim and the mailing list.
Everyone sign up for next weeks meeting.
--
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/CAGDihek-U2diijGJ7NLxy5tEjkbDW0a6TDExKvYNJftEKO6ydw%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/CAGDihek-U2diijGJ7NLxy5tEjkbDW0a6TDExKvYNJftEKO6ydw%40mail.gmail.com.