video call 8am PST Feb 15
Tim Newsome
黃柏瑋
--
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/CAGDihe%3DJ0qT1b2eg9sJp0kdc4nnOkQ4ztF%3Dr1S7ZNDvzfunp1Q%40mail.gmail.com.
Tim Newsome
hi,The slide is for last week.Is it wrong?Powei
2017/2/15 下午11:34，"Tim Newsome" <t...@sifive.com>寫道：
--
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.
Megan Wachs
Github Spec — It is changing quickly. Keep an eye on the repo or Tim’s emails. Mostly lots of clarifications.
Debug Transport Module:
Group agrees that TRST should be optional on header. Still an outstanding TODO item to figure one out and put it in the spec.
Should JTAG DTM Description be in the Appendix or the main spec?
Gadge — think it should be on an appendix
Tim — What does it mean to be “compliant” to the spec?
Megan — can we just allow people to say “we are compliant with the Debug Module and the Jtag DTM”
Po Wei — ARM they have SWD and also have JTAG. If we don’t have JTAG we could just use the SWD. Are we only going to use JTAG for RISC-V Debug?
Tim - no, JTAG is just the first transport, not the only. The Debug Module is the same in all implementations, but the DTM could be different. All the Debug Module just need simple R/W interface.
Gadge — there are lots of different kinds of debug transport. We’ll never get to spec-ing them all. JTAG should be an example of how to conform to the spec. So it should just be in an appendix.
Tim — but if you use the one in the spec, you can just use the OpenOCD that already exists. Maybe we just need to say something to that effect.
Gadge — At the end of the day, I’m not going to implement the JTAG DTM, hopefully there would just be one implementation.
Vyacheslav — I think JTAG DTM should be part of the specification. It should be part of the ecosystem inside the SoC. JTAG DTM should be made optional, but will return to that. But, we should designate or specify another type of Debug Module Interface, targeted for tiny cores. Especially for JTAG. Current internal side of JTAG DTM is “Debug Bus Master”. And all JTAG transactions would be a bit redundant in that sense. A different type of interface would be something like scan chain interface to debug module registers. Same basis as conventional tap controller actions, like input-output of scan chain, capture, etc.
Tim — what is the benefit of this?
Vyacheslav — less redundant transactions. No redundant hardware, to generate them on the debug bus, debug module. No intermediate transformation of information. Those are for tiny cores, that are just going to do JTAG. Just one DTM and one DM.
Gadge — I have to disagree with your thesis that we are specifying everything on the SOC. What we are doing here is specifying a small component on an overall SoC.
Vyacheslav — but Debug Module has essential interface to the external world. So it is necessary to specify them.
Tim — to me, it feels like you can remove a lot of the internal stuff between DTM and DM. There doesn’t need to be a bus. It’s a very simple interface.
Vyacheslav — For example, what about the Control and Status registers in DM?
Tim — you could use the addresses as IR registers, but is that actually any more efficient? I like the simple abstraction of the DMI.
Vyacheslav — This makes sense as a good example implementation. But in the “tiny cores” corner, we should propose something for that corner.
Tim — can you write a more specific proposal of what you want the JTAG interface to look like in that scenario?
Vyacheslav — it’s in the queue with my previous suggestion. Almost done that one (internal review), it should be sent today. (The proposal about simultaneous actions towards the hart array).
Megan — just to point out, the implementation we do have is a 1 DTM , 1 DM interface. We had to do synchronization across it, so the bus wasn’t that big a deal.
Vyacheslav — I’m insisting on this sort of JTAG DTM because we had already implemented both kinds (DTM as Debug Bus Master, and the one with scan chain interface). The latter one is less in hardware resources.
Tim — can you share how much less?
Vyacheslav — Those are for different architectures, but it’s also my feeling that this is common. It can be checked quickly. When we make our tiny core public, it could be done.
Tim — this seems like something we might want to do, but good to have something more specific to look at rather than imagining something.
Tim — anything else about Debug Transport?
Vyacheslav — remark about standard instructions (e.g. Boundary Scan, etc). Other than IDCODE, BYPASS should be designated as optional. If, for example, the core is just part of some internal JTAG chain, functionality of boundary scan are delegated to master TAP controller. This is the only one exposed.
Tim — I agree, the spec shouldn’t mandate them. We just put them in the spec so we know that there is space for whatever the usual JTAG instructions. Tim will clarify the spec. All the other ones are just basically reserving space.
Vyacheslav — those encodings should be reserved for them.
Tim — yes, we all agree. Just need to make it more clear in the spec.
Krste — just need to make sure you have enough bits for the IR.
System Bus Master —
Megan - I read it. It made sense. what about Stefan’s question on mailing list for dealing with multiple address spaces?
Tim — answered on mailing list, use a few address bits, seems reasonable.
Vyacheslav — is system bus master it mandatory or optional?
Tim — it is optional… not sure any one on this call is actually planning to do this right now.
Vyacheslav — In this spec Debug Module was defined not only for CPU parts, but also for the other associated debug modules, like system bus master. Maybe this is a subject for this sort of functionality. Maybe system bus master should be part of another Debug Module. … ?
Tim — Yes, it is separate functionality, you could split it out as a separate thing on the DMI. This is a perfectly valid implementation.
Vyacheslav — decoupling their functionality is the first thing that comes to mind.
Tim — what are you trying to accomplish by decoupling them?
Vyacheslav — modularity of the Debug System. You could allow combining the two, but really they are totally separate functionalities.
Krste — spec doesn’t say anything about how it is implemented, just how it needs to work.
Gadge — I agree.
Megan — is there something about the address space that makes it hard to divide them?
Tim — could add a few address bits to make their functionality disparate. But all registers are already separated by functionality. Same is true for serial. Spec allows you to split them up.
Vyacheslav — we should focus on core debug right now.
Tim — well, system bus master is pretty essential for folks who only want to do abstract commands. They need system bus mastering in order to access any memory.
Vyacheslav — sure. People can always add other Debug Modules too I guess.
Tim — Ok, done with System Bus Master.
Vyacheslav — Another note... want to future-proof the specification. Should we separate the groups of registers to leave some space for more things into new functional groups. Leave some room to future proof in each group so existing registers don't move around.
Tim — I think they are in groups,
Vyacheslav — yeah, but if we add more we need to keep them in the same place. Future evolution would be inside those groups and subspaces.
Tim — I’m fine with that. Right now we have space 0-2b, 0-3F. Plenty of space to organize and add padding. For example, if we want to add stuff to System Bus they’re pretty packed.
If you have specific suggestions on how to organize them and move the padding, happy to entertain them.
Krste — general strategy is to use address bits but leave a hole in the middle. Upper bits for sections, lower bits for offsets.
Tim — yeah, felt like premature optimization at the time
Megan — can do a pass over the address space usage.
Vyacheslav — add it to his queue of ideas to share.
Vyacheslav — another idea. General organization of registers. Separating control and status bits? Having them mixed together prevents us from some status manipulations (e.g. clearing status) which could be useful. Separating status and control allows some possibilities.
Status bits, it is useful to have them write-1-to-clear to have event clearing. It is useful and convenient.
Tim — some of them are like that. Does writing 0 or 1 make a difference?
Vyacheslav — subset of status bits indicating some event. You clear them one you've read them and taken them into account. Write to the same register the same bit mask what you read.
Tim — does it make a difference 0 or 1?
Vyacheslav — Writing what was read is a pretty common approach. Just an idea.
Tim — I have no problem with the idea. But don’t really care enough to change the spec myself… happy to review Pull Requests. Agree that writing 0 and having nothing change is nice.
Vyacheslav — will try to summarize and share in further emails.
Po Wei — Question about the spec -- When cmderr is set, we didn’t clarify what would happen. 7.5.1. “None of the remaining steps are executed”. Should we say something like “unpredictable” or “undefined”.
Tim -- will clarify in the spec.
Megan — Another point about errors (tried to address in latest PR), can only clear down error when it’s not busy. For example, getting an error because you tried to write a command when one was already running, the error really means the next one failed, the first one may or may not have completed.
Megan — how are we doing on enumeration?
Tim’s happy, we’re basically depending on Config String spec for everything else.
Next week's topics: Reset. Security
It’s fine if you want to want to read and comment on other things.
What about debugging multiple harts?
Likely to be Debug SW issue, but maybe there can be some HW support for it. But this is a subject for another big discussion.
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/CAGDihekxdykR%3Dh67STc7-%3Dvqmp85_Lv1ryr8wcNhzNkzQpXboA%40mail.gmail.com.