RISC-V debug video call, week of Jan 30

48 views
Skip to first unread message

Tim Newsome

unread,
Jan 25, 2017, 10:54:26 AM1/25/17
to RISC-V Debug Group
Please indicate which days work for you for a meeting at 8am PST: http://whenisgood.net/zzhmbpf

Thank you,
Tim

Tim Newsome

unread,
Jan 25, 2017, 1:59:57 PM1/25/17
to RISC-V Debug Group
New plan. At the meeting people suggested we just pick a day and stick with it. We decided on Wednesday since that usually works for everybody. Most of our past meetings have also been on Wednesday.

So no need to fill out the whenisgood link in the previous message.

Tim

Tim Newsome

unread,
Jan 31, 2017, 5:33:37 PM1/31/17
to RISC-V Debug Group
This meeting is tomorrow. Tentative slides are here: https://docs.google.com/presentation/d/1npb-thIWwbQP9IAiRNDmzmMoWOBgm5Tyo283zlDXQkg/edit?usp=sharing

They're very empty, because there hasn't been much going on on the mailing list this week. That's really the point I'd like to address. What can we do to keep the process moving along quickly?

Tim

Alex Bradbury

unread,
Feb 1, 2017, 4:02:58 AM2/1/17
to Tim Newsome, RISC-V Debug Group
On 31 January 2017 at 22:33, Tim Newsome <t...@sifive.com> wrote:
> This meeting is tomorrow. Tentative slides are here:
> https://docs.google.com/presentation/d/1npb-thIWwbQP9IAiRNDmzmMoWOBgm5Tyo283zlDXQkg/edit?usp=sharing
>
> They're very empty, because there hasn't been much going on on the mailing
> list this week. That's really the point I'd like to address. What can we do
> to keep the process moving along quickly?

I think part of the problem is the spec actually covers rather a lot
and although jumping in on an aspect of particular interest in an
ad-hoc manner can work, it may not always be the best way. Perhaps we
can agree as a group to work through the key parts of the spec in
turn, where we all carefully read them, share any concerns or ideas,
decide whether to modify, then move on to the next part. e.g.
enumeration+capability probing, instruction supply, command interface,
triggers, ... Does anybody else feel this might be helpful?

Best,

Alex

Richard Herveille

unread,
Feb 1, 2017, 4:48:03 AM2/1/17
to Alex Bradbury, Richard Herveille, Tim Newsome, RISC-V Debug Group
Currently lots of travel and customer meetings are taking place.
I won’t be able to attend all meetings and digesting the entire spec is too much now.
I’d prefer the step-by-step approach suggested by Alex.

Richard


ROA LOGIC
Design Services and Silicon Proven IP

Richard Herveille
Managing Director
Cell +31 (6) 5207 2230




--
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%2BwH295%2BAoEnSj45H5if542nQZHDArAmz_Y8W3hyRUWEjR_m8g%40mail.gmail.com.

黃柏瑋

unread,
Feb 1, 2017, 5:51:27 AM2/1/17
to Richard Herveille, Alex Bradbury, Tim Newsome, RISC-V Debug Group
Hi all,
I agree with Alex's plan. We could discuss the idea and use the spec or the chapters to converge.
Recently, I start to review the spec sentence by sentence, chapter by chapter and record all my thought in a document.
The temporary work is like this one:

So, we probably could divide the work to two parts.
Firstly, we assign each chapter with some guys and reviewing those chapters in a detailed way.
Then, we record the status and do something like regression. This will enable us to have a global view and help everyone catchup.
On the other hand, we could discuss idea like before and inject those ideas into the related section.
This method might be help.

Thanks,
Po-wei Huang


To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@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+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/B65E25AE-90F9-4E21-8CBF-C318566C80DB%40roalogic.com.

Tim Newsome

unread,
Feb 1, 2017, 10:46:34 AM2/1/17
to 黃柏瑋, Richard Herveille, Alex Bradbury, RISC-V Debug Group
Working through the spec in functional groups makes sense to me, although I would hope that at least somebody has the time to read the whole thing. Going chapter by chapter would also work, but that requires people to absorb a lot of stuff without seeing how it would be used. How is this order?
  • Halt/resume
  • Abstract register access
  • Instruction supply
  • JTAG Debug Transport Module
  • System Bus master
  • Reset
  • Security
  • Triggers
  • Serial Ports
If that works, I can make a list of sections that apply to the first few items, so people know what to read.

Tim

On Wed, Feb 1, 2017 at 2:51 AM, 黃柏瑋 <poweih...@gmail.com> wrote:
Hi all,
I agree with Alex's plan. We could discuss the idea and use the spec or the chapters to converge.
Recently, I start to review the spec sentence by sentence, chapter by chapter and record all my thought in a document.
The temporary work is like this one:

So, we probably could divide the work to two parts.
Firstly, we assign each chapter with some guys and reviewing those chapters in a detailed way.
Then, we record the status and do something like regression. This will enable us to have a global view and help everyone catchup.
On the other hand, we could discuss idea like before and inject those ideas into the related section.
This method might be help.

Thanks,
Po-wei Huang

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

Tim Newsome

unread,
Feb 1, 2017, 10:49:28 AM2/1/17
to 黃柏瑋, Richard Herveille, Alex Bradbury, RISC-V Debug Group

Megan Wachs

unread,
Feb 1, 2017, 12:45:14 PM2/1/17
to Tim Newsome, RISC-V Debug Group
Notes from Today's Meeting:

Debug Group Call:

Tim : Need feedback on the spec. To make it more manageable, as suggested on mailing list, let’s work through piece by piece. Proposed a list of subjects and and order.Tim will propose the ones we will absorb and discuss each week.

How many per week? Something like 3.

We can look ahead and do several per week, and once we resolve something is done we don’t have to go back and revisit it.

First Week will be :

Halt/Resume

Abstract Proposal

Instruction Supply


Stefan requested overview of Instruction Supply

  • Uses abstract commands (Command & Data Registers)
  • Write arguments to data, and write command and it gets executed.
  • there is a program buffer register that holds up to 8 “registers”, where registers is an abstract term that could be in RAM, or flops in debug module, or elsewhere.
  • Question — why up to 8 instructions?
    • A: round number, can do everything necessary in 2-4
  • Question — how to make a hart immediately jump to the program buffer?
    • A: you don’t generally do that. Harts halt, then go to program buffer when instructed by debugger.
  • Q: How to make the harts jump into the program buffer?
    • A: Implementation specific
  • Q: Megan — is auto exec to make the program execute the Program Buffer without a debugger?
    • A: No.
  • Q: Richard — how to handle simultaneous debug of targets?
    • Tim — assuming only one debugger and only one hart at a time
    • Multiple harts can be halted at a time, but everything else is under control of debugger
    • You cannot change the currently selected hart while there is an abstract command in progress
  • Q: What If the program buffer is used for triggers? 
    • Tim — no. Program buffer is not used for triggers.
    • Program buffer is for custom extension, Floating Point 
  • When a breakpoint is encountered by multiple harts, they just halt. They have to wait for the debugger.
  • Program buffer is not automatically executed.


Stefan — Question, back to number 8. Is it up to 8, or 8 exactly? What does the debugger get to expect? Should there just be a set number. If everyone agrees that 8 is reasonable, it’s easier for the debugger?

Gadge, Richard, — Let’s just say it’s 8. Not Up to 8.

Krste — Just one reason we went down the long discussion of the original Debug RAM proposal. And we now agreed this is OK?

Vyacheslav — Can we have a one-instruction implementation? (Back to the direct feeding vs fetching). Good option for tiny cores.

Tim — Ok, but then we must also define what to do for instructions less than 32 bits.

Krste — we’re asking a question that has already been asked before. We need to support less than 8 registers because people already complained about too much area with “Debug RAM”.

Megan — for single-instruction buffer where to put the break?

Krste - can we just say that there will always be an ebreak without debugger having to write it?

Tim - this is too messy if the debug RAM is somewhere else, variable size, etc. Which is why the debugger has to write the ebreak. Richard agrees, debugger should always write the break.

Krste — if you have a single instruction register, the debugger can write ebreak after it and then it will just get ignored.

Gadge — how to know how many of these registers do we have?

Tim — we just read some bits in Debug Module.

Richard —or should we just write random values and read them back?

Tim — yes they are R/W. And if a processor is faking the ebreak, then we should read that back.


Question from PoWei — How to indicate the hart we want to debug?

Tim explains the halt summary registers.


Megan — can you explain autoexec bits?

Tim — Explains them. (They are to accelerate things like copying data into memory, debugger just has to write the data and the command to copy it into memory will just happen)


Po — what do I have to implement? Do I have to do instruction fetching?

Tim — abstract command is all that is necessary


Megan — spec implies one implementation to distinguish between harts is to give each a unique jump-to-on-halt address. Doesn’t that require lots of memory space?

Tim — does some math, need at most 64kB for 1024 harts

Megan — is 64kB address space reasonable for 1024 harts? (no one objects offhand)

Krste — if anyone is debugging more than 1024 harts they may do something totally different anyway and have self-hosted debug.


Someone at the workshop does have 16000 cores!


Action Items:

  • Do this weeks’ read-and-discuss on mailing list:
    • Run/Halt
    • Abstract Commands
    • Instruction Supply


  • Tim to update spec with details we discussed.


PoWei — what to do about the “TODO” in the spec? Can we go through them in the meeting or on the mailing list?

Tim — going to search for the TODO and fix them. But if you’re reading the spec and find a TODO that you think is important, introduce it to the mailing list.


Vyacheslav — contributing to the spec, how to contribute? What’s the best way? Present in slides or branch on the github repo and provide the actual description? 

Tim — if it’s a small proposal, a github Pull Request is convenient because it forces you to be detailed. It’s a lot of work to write it up, so it may be good to make some slides to the mailing list to see if it’s worth adding to the spec.

Vyacheslav — small corrections, best way is to make a PR to the repository?

Tim — yes.

Megan — working model was to make concrete proposal as PR, then ask questions on the mailing list to shape the spec (as more people are reading mailing list than spec right now)


--
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%3Dy0z1pVV30dY7qubJr7yW5k%3Ds2CKuJjGZNF05hR0eT2w%40mail.gmail.com.



--
Megan A. Wachs
Engineer | SiFive, Inc 
300 Brannan St, Suite 403 
San Francisco, CA  94107 

Tim Newsome

unread,
Feb 1, 2017, 2:38:35 PM2/1/17
to Megan Wachs, RISC-V Debug Group
Thank you for taking notes again, Megan!

Tim

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/CAGDihe%3Dy0z1pVV30dY7qubJr7yW5k%3Ds2CKuJjGZNF05hR0eT2w%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages