November 2016 task group meeting notes

55 views
Skip to first unread message

Tim Newsome

unread,
Dec 4, 2016, 7:44:32 PM12/4/16
to RISC-V Debug Group
Hi all!

If you weren't able to attend the meeting, below are the notes that Rex McCrary took.
During the meeting I also updated the slides as points were brought up, which might be interesting reading as well: https://docs.google.com/presentation/d/1jOjG20-gwtcGybZg2Bu3StV6ljZZV9n2SQAEjKWQwDE/edit#slide=id.p

Debug Task Group Meeting Notes

Date: December 1, 2016
version , following Workshop 5

Attendees: See signup list.

Introduction

Tim Newsom, Chair of Debug Task Group (DTG), started out by setting the scope of the group as external debug and its deliverable as the External Debug Specification, scheduled to be release in Feb. 2017. He provided a short definition of the of the basic concepts of Run Control, External Debug, JTAG, Trace to ensure every one was using terms to mean the same thing.

Tim said that the primary obstacle for DTG to make progress toward a February 2017 specification release are two conflicting Debug Specifications currently being discussed, one from Tim Newsome and another from Richard Herveille.

The first set of questions were centered about Tim’s scope definition. Larry from Google asked about on "self hosting debug". This discussion included invasive and non-invasive debug mechanisms as well as processor profiling and real-time performance monitoring. Tim said the current scope focuses on external debug with invasive techniques. However, real-time profiling is within the spectrum of support. Performance counters should used and what we have today should be sufficient, though it was agreed that they need to be extended later.

It was mentioned that multicore should included "from day one". Tim agreed.

Security was also brought up as an important component and it was agreed that DTG would coordinate with Security Task Group.

Comparison Discussion

Tim provided a comparison of the two methods side-by-side. After some discussion of the definitions of terms he used, Tim asked for additional feedback on comparing the two. At the meeting the specification traditionally referred to as the "Lightweight Method" was referred to as the "one on the left" (OOTL) and the "Full Featured Method" was referred to as the "one on the right" (OOTR).

It was mentioned that all the OOTL needed was a set of muxes to pull out the required register state. However, further discussion revealed in a system using renaming this is not that simple and if not done through the processor which already accounts for all the renaming logic, the renaming logic would have to be replicated causing area, timing and verification complexities. It was agreed this was not the desired direction.

The two debug methods where the debugger takes over the stream and can insert instruction, replace instruction etc. versus one where an external block programs the processor externally. It was stated that the OOTL supported instruction insertion where the OOTR does not.

Tracing is important for initial hardware debug, but it was stated by Krste, and others, that trace support can be complex and is not the initial focus of the DTG.

Abstraction Level of Debug Specification Comparison

  • OOTL is described as a higher level of abstraction and therefore better matches the architectural level of there other published specs.

  • OOTR is described at a lower level including some microarchitecture, describing in some detail what the SiFive group implemented.

Area Requirements of Debug Specification Comparison

  • OOTL is described to be smaller and a better fit for very small designs. It requires no such RAMs and ROMs that the OOTR does.

  • OOTR will have a new release that does not require the RAM and ROM.

Miscellaneous Feature Support Comparison

  • OOTR was is designed to make adding new instructions more straight forward.

  • Register renaming was discussed again and it was stated the OOTR would to right thing with register renaming.

  • The OOTL is said to be "integrated with debug".

  • Krste said that the debug logic should support being turned off if not in use. It was mentioned that one has to be careful with the SRAMs that, depending on the implementation be powered off due to non-use. It was agreed that is true under certain designs where power is primarily driven by inactivity. However, it was generally agreed that the Debug Unit should be fully powered on or off, during use or non-use respectively.

  • GDB must work, LLDB is still under investigation.

  • Krste said the discussion is really around the definition of the Debug Bus the interface between DM and Transport.

Action Items

  1. Investigate CMSIS: Cortex Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer.

  2. Tim setup survey on to determine the best time for calls: Done

  3. Tim to setup conference call in the next week or so.

  4. Tim to post a request to get foundation member companies to get those with expertise in debug to be active participant: Done.

  5. Define a set of use cases that would further help clarify the differences between the two debug proposals.

Sober Liu

unread,
Dec 4, 2016, 11:02:40 PM12/4/16
to Tim Newsome, RISC-V Debug Group

Hi Tim,

For profiling topic, when you say “Performance counters should used and what we have today should be sufficient” do u mean HW counters or soft counters in memory?

Maybe I miss some points in spec, but I don’t find counters for general configurable events except for cycle, insn and timer.

So in our profiling design, we define additional 8 HW counters to be increased when combined event occurred.

 

Thanks

Action Items

1.      Investigate CMSIS: Cortex Microcontroller Software Interface Standard (CMSIS) is a vendor-independent hardware abstraction layer.

2.      Tim setup survey on to determine the best time for calls: Done

3.      Tim to setup conference call in the next week or so.

4.      Tim to post a request to get foundation member companies to get those with expertise in debug to be active participant: Done.

5.      Define a set of use cases that would further help clarify the differences between the two debug proposals.

--
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/CAGDihenF3wD92v7t8gehQ8rDvSKYwOwPLmY4TOmQ7eXy_3oPig%40mail.gmail.com.

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

rex...@gmail.com

unread,
Dec 4, 2016, 11:36:03 PM12/4/16
to Sober Liu, Tim Newsome, RISC-V Debug Group
I believe the reference was regarding the architecture and that it supports profiling, not that the current set of counters are sufficient for all cases. This perspective is in agreement with your description of what you did. 

Rex

Sent from my phone

Tim Newsome

unread,
Dec 5, 2016, 1:15:52 PM12/5/16
to rex...@gmail.com, Sober Liu, RISC-V Debug Group
From what I remember, somebody brought up the issue of performance counters, and somebody else responded that all we have is the existing counters you found. They can be useful.

None of that precludes adding custom counters, or adding different counters to the debug spec. What kinds of things are you counting? I wonder if it's sensible to allow hardware triggers to increment a counter instead of acting as a breakpoint.

Tim

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

--
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.

Sober Liu

unread,
Dec 5, 2016, 8:35:13 PM12/5/16
to Tim Newsome, rex...@gmail.com, RISC-V Debug Group

Related the question “What kinds of things are you counting?”

For each counter, it can be configured to counter following event groups for us:

1.       Instret;

2.       Cycles;

3.       Load/store event;

4.       CSR access;

5.       Exception occurrence;

6.       Interrupt occurrence;

7.       Cache hit/miss details;

8.       Branch predict details;

9.       Etc.

 

For some event groups, there are more configure bits to select enabled events. E.g., for load/store, we can select to count load and/or store with one counter.

And we keep instret/cycle here to avoid calculate delta/sum value from mcycles/minstret. To enable/disable related counter is easier to use mcycles/minstret.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

--
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.

 

--

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/.

Alex Bradbury

unread,
Dec 6, 2016, 6:33:18 AM12/6/16
to Tim Newsome, rex...@gmail.com, Sober Liu, RISC-V Debug Group
On 5 December 2016 at 18:15, Tim Newsome <t...@sifive.com> wrote:
> From what I remember, somebody brought up the issue of performance counters,
> and somebody else responded that all we have is the existing counters you
> found. They can be useful.
>
> None of that precludes adding custom counters, or adding different counters
> to the debug spec. What kinds of things are you counting? I wonder if it's
> sensible to allow hardware triggers to increment a counter instead of acting
> as a breakpoint.

Yes, that was me. In general I think performance counters aren't very
relevant to the initial run-control debug work, but once we get to
trace debug I think there's a lot of overlap between the communities
wanting to collect detailed trace events and those who want to perform
non-intrusive performance analysis.

Alex

Sober Liu

unread,
Dec 6, 2016, 7:49:08 AM12/6/16
to Alex Bradbury, Tim Newsome, rex...@gmail.com, RISC-V Debug Group
Yes, I agree that profiling and debug are not very relevant indeed. And yes there are still overlap thus in debug spec we have icount field in trigger module.
Anyway for me it's OK. If there are defined counters, I will try to use it to avoid deviation. If not, I will define them as non-standard CSRs.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Tim Newsome

unread,
Dec 6, 2016, 12:23:23 PM12/6/16
to Sober Liu, Alex Bradbury, rex...@gmail.com, RISC-V Debug Group
The list you made above seems like it might be generally interested. Let's revisit this once run control is figured out.
Or if you prefer you can start a thread to figure out which counters are truly interesting to many parties vs the ones only you care about.

Tim

--
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/0ddee91d2f934c548826b3d9f999aea1%40HKMAIL101.nvidia.com.

Reply all
Reply to author
Forward
0 new messages