RISC-V run-control debug: summary, survey, and a proposal

[Alex Bradbury]

Hi all,

It seems a number of us have taken the Christmas/New Year break as an
opportunity to go through all the discussions and proposals for RISC-V
run-control debug. Stefan and I have collaborated to try to contribute
to moving the discussion forwards by way of:

* Providing a high-level overview of the options discussed so far
* Proposing a path forwards towards a unified specification
* Briefly surveying what other architectures and SoCs do for run-control debug

One aspect which I hope is made clear is the separation between the
external interface and the implementation. It’s completely sensible to
be in favour of exposing a memory-mapped interface but to also
advocate instruction feeding as an implementation technique.


Please read our slides at https://goo.gl/9abgZa.


Similar to Stefan’s previous proposal, we advocate providing a base
debug memory map for accessing GPRs etc, with an optional extension to
allow debugger-visible instruction feeding. If people feel that when
using instruction feeding as an implementation technique the overhead
is too high to store instruction sequences on-chip, then memory-mapped
registers could be made optional. The debug software would have to
detect which access method is supported.

As an appendix to the presentation we’ve provided a cursory survey of
what other architectures and SoCs have done for run-control debug.
We’d really appreciate any extra additions or corrections to this.

Hopefully this provides a good base for discussion in the meeting on
Thursday. In the meantime, we’d really welcome any feedback or
comments. You should have permissions to comment directly on the
presentation, or else of course just respond to this thread.

Best,

Alex and Stefan

[Tim Newsome]

Thanks for putting this together!

It's a good overview of everything we've talked about so far. Is there something specific you'd like added to the meeting agenda regarding this document?

Personally I'm still unsure what makes the abstract approach simpler than the instruction feeding approach. It's simpler for the debugger, maybe, but that doesn't seem that important to optimize for (unless it's hugely simpler). I don't think it's what people mean when they say simpler/less complex.

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/CA%2BwH294Q9HEEc_xAXkvmtbKN2bZZM3BOPMnp8GnVAG09rHeK_Q%40mail.gmail.com.

[Stefan Wallentowitz]

On 03.01.2017 22:09, Tim Newsome wrote:
> Thanks for putting this together!
>
> It's a good overview of everything we've talked about so far. Is there
> something specific you'd like added to the meeting agenda regarding this
> document?

I think it is more the general discussion about the options how to
proceed, we hope we made clear why we prefer the mixed approach on
several occasions. May we can also reiterate on the viability of
generating instruction macros on the target side for a minimal amount of
base functionalities.

> Personally I'm still unsure what makes the abstract approach simpler
> than the instruction feeding approach. It's simpler for the debugger,
> maybe, but that doesn't seem that important to optimize for (unless it's
> hugely simpler). I don't think it's what people mean when they say
> simpler/less complex.

A protocol that abstracts from implementation is IMHO always preferable
over a protocol that enforces implementation. So if I can have a simple
protocol that contains messages like "Halt", "Single-Step", "Read CSR
0x405" and leaves everything open to the implementation, that is
preferable. I don't think the argument for abstraction is about
complexity, but about clearness and freedom of implementation.

Anyhow, I think you made clear before that it is impossible for
instruction feeding to convert all abstract messages to instruction
macros. Hence we tend to the mix of a base debug interface in memory-map
with a large number of functionalities accessible either way.

Cheers,
Stefan

[Sober Liu]

+1 for the protocol definition.

@Tim, for confirmation, do u expect debugger to feed the instructions?
For me, I expect the debug module to receive cmd via the protocol and feed instructions for most common cmd like register/csr/memory access.


-----Original Message-----
From: Stefan Wallentowitz [mailto:ste...@wallentowitz.de]
Sent: Wednesday, January 04, 2017 2:32 PM
To: de...@groups.riscv.org
Subject: Re: [debug] RISC-V run-control debug: summary, survey, and a proposal

* PGP Signed by an unknown key

--
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/d666f554-b4cb-cc66-6b5a-cadf96434740%40wallentowitz.de.

* Unknown Key
* 0xB9F653DC

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

On Tue, Jan 3, 2017 at 10:32 PM, Stefan Wallentowitz <ste...@wallentowitz.de> wrote:

On 03.01.2017 22:09, Tim Newsome wrote:
> Thanks for putting this together!
>
> It's a good overview of everything we've talked about so far. Is there
> something specific you'd like added to the meeting agenda regarding this
> document?

I think it is more the general discussion about the options how to
proceed, we hope we made clear why we prefer the mixed approach on
several occasions. May we can also reiterate on the viability of
generating instruction macros on the target side for a minimal amount of
base functionalities.

OK. I was already planning to discuss the timeline (that I emailed out yesterday) tomorrow.

> Personally I'm still unsure what makes the abstract approach simpler
> than the instruction feeding approach. It's simpler for the debugger,
> maybe, but that doesn't seem that important to optimize for (unless it's
> hugely simpler). I don't think it's what people mean when they say
> simpler/less complex.

A protocol that abstracts from implementation is IMHO always preferable
over a protocol that enforces implementation. So if I can have a simple
protocol that contains messages like "Halt", "Single-Step", "Read CSR
0x405" and leaves everything open to the implementation, that is
preferable. I don't think the argument for abstraction is about
complexity, but about clearness and freedom of implementation.

OK, but your slide 13 lists as the first advantage of the memory map interface "Simplicity." Then separately it lists "Memory map interface allows multiple implementation approaches," which I agree with.

Note that the instruction feed protocol is also simple. Arguably it's simpler because it implements fewer operations.

Anyhow, I think you made clear before that it is impossible for
instruction feeding to convert all abstract messages to instruction
macros. Hence we tend to the mix of a base debug interface in memory-map
with a large number of functionalities accessible either way.

Until somebody can show me a case where instruction feeding is not a simple implementation, I'm not convinced that allowing multiple implementations is a clear benefit.

Tim

[Tim Newsome]

On Wed, Jan 4, 2017 at 1:25 AM, Sober Liu <sob...@nvidia.com> wrote:

@Tim, for confirmation, do u expect debugger to feed the instructions?
For me, I expect the debug module to receive cmd via the protocol and feed instructions for most common cmd like register/csr/memory access.

Yes, I would like the debugger to feed instructions. If that is the best implementation, I see no reason to hide that from the debugger.

Tim

 

-----Original Message-----
From: Stefan Wallentowitz [mailto:ste...@wallentowitz.de]
Sent: Wednesday, January 04, 2017 2:32 PM
To: de...@groups.riscv.org
Subject: Re: [debug] RISC-V run-control debug: summary, survey, and a proposal

* PGP Signed by an unknown key

On 03.01.2017 22:09, Tim Newsome wrote:
> Thanks for putting this together!
>
> It's a good overview of everything we've talked about so far. Is there
> something specific you'd like added to the meeting agenda regarding
> this document?

I think it is more the general discussion about the options how to proceed, we hope we made clear why we prefer the mixed approach on several occasions. May we can also reiterate on the viability of generating instruction macros on the target side for a minimal amount of base functionalities.

> Personally I'm still unsure what makes the abstract approach simpler
> than the instruction feeding approach. It's simpler for the debugger,
> maybe, but that doesn't seem that important to optimize for (unless
> it's hugely simpler). I don't think it's what people mean when they
> say simpler/less complex.

A protocol that abstracts from implementation is IMHO always preferable over a protocol that enforces implementation. So if I can have a simple protocol that contains messages like "Halt", "Single-Step", "Read CSR 0x405" and leaves everything open to the implementation, that is preferable. I don't think the argument for abstraction is about complexity, but about clearness and freedom of implementation.

Anyhow, I think you made clear before that it is impossible for instruction feeding to convert all abstract messages to instruction macros. Hence we tend to the mix of a base debug interface in memory-map with a large number of functionalities accessible either way.

Cheers,
Stefan


--
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/d666f554-b4cb-cc66-6b5a-cadf96434740%40wallentowitz.de.

[Alex Bradbury]

On 4 January 2017 at 18:23, Tim Newsome <t...@sifive.com> wrote:
> OK, but your slide 13 lists as the first advantage of the memory map
> interface "Simplicity." Then separately it lists "Memory map interface
> allows multiple implementation approaches," which I agree with.

I think we were being purposely nebulous with "simplicity".
Conceptually, it's hard to get simpler than read an address and get a
value. On simple core implementations, a direct implementation is also
straight-forward. I agree the fact it allows multiple implementation
approaches is more important. I have a personal opinion on which
implementation approach (direct vs instruction feeding) I might prefer
to use on processors at a couple of different design points, but don't
feel I could make that decision for all RISC-V implementers across
whatever class and style of design and area/budget/time constraints
they have.

I appreciate that an implementation of instruction feeding can also be
straight-forward, and I do sympathise with your frustrations in
attempting to persuade people. I don't think instruction feeding is
'bad' (indeed, the survey Stefan and I performed showed many
architectures use some variant of it). I can see it's been difficult
to get the message across, especially about how the proposal has
changed since the early versions which appeared more heavyweight. I
think part of the problem is that for a proposal that naturally limits
implementation freedom, there's a greater need to outline and explain
which implementation options _are_ available. This is something that
has been added to your spec more recently, and I also hope our
diagrams on page 11 help. I do wonder if a presentation that started
with an overview of the simplest possible implementation and then
described ways of making it more fully-featured and efficient would
have raised fewer concerns.

Best,

Alex

[Alex Bradbury]

On 3 January 2017 at 18:41, Alex Bradbury <a...@asbradbury.org> wrote:
> Hopefully this provides a good base for discussion in the meeting on
> Thursday. In the meantime, we’d really welcome any feedback or
> comments. You should have permissions to comment directly on the
> presentation, or else of course just respond to this thread.

After yesterday's meeting I thought I would try to concisely list what
I think are the main arguments in favour of providing a debug
interface that gives greater implementation flexibility (i.e. the
memory mapped or command/message approaches). If you haven't already,
please read our slides at https://goo.gl/9abgZa for background.

1) It allows the widest range of implementation approaches
(instruction feeding or a direct approach muxing register files). This
seems the sensible choice the huge range of RISC-V design points and a
lack of consensus that instruction feeding is always going to be the
preferred implementation approach.

2) It offers the opportunity to expose state as accessible without
stalling the processor (but the processor may access via CSR)

3) It offers more options for exposing state that wouldn't otherwise
be architecturally visible, i.e. has no defined instruction to
directly access it. It also gives the opportunity to abstract away how
this is done (e.g. CSRs, undocumented instructions).

Our proposal, as explained in the slide deck is that we decide upon a
common memory-mapped or message/command interface for basic register
access, with a standardised instruction feeding interface as an
optional extension. Having both interfaces optional is one potential
path forwards, but I would suggest that's something we can pursue as
an optimisation in the future if people find the overhead of providing
the abstract interface with an instruction feeding implementation is
high enough to justify providing multiple access methods to the
debugger.

As clarified in the meeting yesterday, everybody is in agreement that
having the debug controller as a bus master can be useful, but
shouldn't be a requirement.

Best,

Alex

[Tim Newsome]

On Wed, Jan 4, 2017 at 11:02 AM, Alex Bradbury <a...@asbradbury.org> wrote:

On 4 January 2017 at 18:23, Tim Newsome <t...@sifive.com> wrote:
> OK, but your slide 13 lists as the first advantage of the memory map
> interface "Simplicity." Then separately it lists "Memory map interface
> allows multiple implementation approaches," which I agree with.

I think we were being purposely nebulous with "simplicity".

I can understand that, but it makes it hard for me to make an argument that instruction feeding is just as simple if you can't explain what exactly is simple.

 

Conceptually, it's hard to get simpler than read an address and get a
value. On simple core implementations, a direct implementation is also
straight-forward.

 

I agree the fact it allows multiple implementation
approaches is more important. I have a personal opinion on which

implementation approach (direct vs instruction feeding) I might prefer
to use on processors at a couple of different design points, but don't
feel I could make that decision for all RISC-V implementers across
whatever class and style of design and area/budget/time constraints
they have.

Can you share your personal opinion on why you would not want to implement instruction feeding? I honestly think it's always simple. I've made large changes to my spec to accommodate concerns that I can understand (lower gate count, more flexibility in implementation) and I'd be happy to change things to address other concerns as well.

I appreciate that an implementation of instruction feeding can also be
straight-forward, and I do sympathise with your frustrations in
attempting to persuade people. I don't think instruction feeding is
'bad' (indeed, the survey Stefan and I performed showed many
architectures use some variant of it). I can see it's been difficult
to get the message across, especially about how the proposal has
changed since the early versions which appeared more heavyweight. I
think part of the problem is that for a proposal that naturally limits
implementation freedom, there's a greater need to outline and explain
which implementation options _are_ available. This is something that
has been added to your spec more recently, and I also hope our
diagrams on page 11 help. I do wonder if a presentation that started
with an overview of the simplest possible implementation and then
described ways of making it more fully-featured and efficient would
have raised fewer concerns.

You're right. My proposal has changed considerably even since the last workshop. Sometimes it does feel like people are still arguing against an older version (ie. whenever they talk about Debug RAM). I've just sent a mail to the list with an attempt of showing how simple it all is, which I've also posted at https://sifive.github.io/debug-mechanism-comparison/feed-implementation.html

Tim

 

Best,

Alex

[Michael Chapman]

On 06-Jan-17 10:09, Alex Bradbury wrote:
> After yesterday's meeting I thought I would try to concisely list what
> I think are the main arguments in favour of providing a debug
> interface that gives greater implementation flexibility (i.e. the
> memory mapped or command/message approaches). If you haven't already,
> please read our slides at https://goo.gl/9abgZa for background.
>
> 1) It allows the widest range of implementation approaches
> (instruction feeding or a direct approach muxing register files). This
> seems the sensible choice the huge range of RISC-V design points and a
> lack of consensus that instruction feeding is always going to be the
> preferred implementation approach.

All very well mux'ing the register file - but how are you going to find
the physical register which stores the programmers view of a particular
achitectural register at a specific point in the code?
BOOM (a full out of order machine) for instance will store the ra
register in any one of up to 512 physical registers (depending on
parameterization). The actual location is in given in a rename table.
But how are you going to choose the right version of the rename table to
provide the right index? This depends on which instructions can be
considered retired. Not which instructions have completed.

if you think finding ra in one of the 512 locations is complicated, then
consider how you will find the right PC when you have potentially
hundreds of instructions in flight. Some speculatively completed, some
not executed etc etc.

I.e. memory mapped access to RISC-V ISA registers seems very complicated
to do in the case of something like BOOM.

>
> 2) It offers the opportunity to expose state as accessible without
> stalling the processor (but the processor may access via CSR)

But that state is very complex to access - and needs to be accessed in
an atomic way to provide a meaningful result. I.e. the processor needs
to be stalled for the various stages of the lookup required in order to
get to a particular register. That process is very dependent on the CPU
uArchitecture.

>
> 3) It offers more options for exposing state that wouldn't otherwise
> be architecturally visible, i.e. has no defined instruction to
> directly access it. It also gives the opportunity to abstract away how
> this is done (e.g. CSRs, undocumented instructions).
>
> Our proposal, as explained in the slide deck is that we decide upon a
> common memory-mapped or message/command interface for basic register
> access, with a standardised instruction feeding interface as an
> optional extension. Having both interfaces optional is one potential
> path forwards, but I would suggest that's something we can pursue as
> an optimisation in the future if people find the overhead of providing
> the abstract interface with an instruction feeding implementation is
> high enough to justify providing multiple access methods to the
> debugger.
>
> As clarified in the meeting yesterday, everybody is in agreement that
> having the debug controller as a bus master can be useful, but
> shouldn't be a requirement.

Muxing register files only works for very simple implementations. In
sophisticated implementations several CSR's may well be renamed as well
as for processor registers. I.e. could have many potential locations.

For debugging an OS, the access to memory should go through the MMU.
Instruction feeding is quite a good approach for doing that.

For SOC bring up, you want to be able to do direct accesses to memory
with no address translation or MMU getting in the way. This is useful
and is a different use. It might be worth providing an optional debug
extension to enable this for SOC debug. I.e. if you want to have this
feature for SOC debug, then there is a standard way to do it. But this
is not normally what you want to use when debugging software running on
the CPU.

Memory mapping processor state is not all that simple.

Best regards,
Mike

[kr...@berkeley.edu]

I think the name "instruction feeding" should be changed to
"instruction fetching" as that is really what it is and in either case
doesn't need to change the processor core except for the case where
the core had only a single source of instructions with no address
decode mux (i.e., ROM or RAM but not both).

On the call, we also came to conclusion that the memory-mapped
solution is not sufficient in general once new extensions and
additional processor state are added, as it would require this level
of spec to be continually revisited to dole out memory space to
alternative extensions. So, debug by instruction fetching has to be
supported as at least an optional component.

There are some more details to work out in Tim's scheme, for example,
we need to provide mechanism to handle >32b instructions by providing
multiple 32b registers in DM and way to launch an instruction fetch
atomically.

I also wonder about having a CSR per hart mapped to a shared memory
location. A straight memory store might be easier/simpler with same
caveats as for instruction fetch (very simple core might only have one
data RAM - but this is much rarer than single instruction memory as
even simple cores usually have some memory-mapped IO).

Krste

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

| CAGDihek961oaVBLoyZj76puJekW0ie5NmjpvcxGhuaHcDafhbQ%40mail.gmail.com.

[kr...@berkeley.edu]

I think the name "instruction feeding" should be changed to
"instruction fetching" as that is really what it is and in either case
doesn't need to change the processor core except for the case where
the core had only a single source of instructions with no address
decode mux (i.e., ROM or RAM but not both).

On the call, we also came to conclusion that the memory-mapped
solution is not sufficient in general once new extensions and
additional processor state are added, as it would require this level
of spec to be continually revisited to dole out memory space to
alternative extensions. So, debug by instruction fetching has to be
supported as at least an optional component.

There are some more details to work out in Tim's scheme, for example,
we need to provide mechanism to handle >32b instructions by providing
multiple 32b registers in DM and way to launch an instruction fetch
atomically.

I also wonder about having a CSR per hart mapped to a shared memory
location. A straight memory store might be easier/simpler with same
caveats as for instruction fetch (very simple core might only have one
data RAM - but this is much rarer than single instruction memory as
even simple cores usually have some memory-mapped IO).

Krste


>>>>> On Mon, 9 Jan 2017 10:40:18 -0800, Tim Newsome <t...@sifive.com> said:

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

| CAGDihek961oaVBLoyZj76puJekW0ie5NmjpvcxGhuaHcDafhbQ%40mail.gmail.com.

[Julius Baxter]

On Tue, Jan 10, 2017 at 11:23 AM, <kr...@berkeley.edu> wrote:

I think the name "instruction feeding" should be changed to
"instruction fetching" as that is really what it is and in either case
doesn't need to change the processor core except for the case where
the core had only a single source of instructions with no address
decode mux (i.e., ROM or RAM but not both).

On the call, we also came to conclusion that the memory-mapped
solution is not sufficient in general once new extensions and
additional processor state are added, as it would require this level
of spec to be continually revisited to dole out memory space to
alternative extensions. So, debug by instruction fetching has to be
supported as at least an optional component.

There are some more details to work out in Tim's scheme, for example,
we need to provide mechanism to handle >32b instructions by providing
multiple 32b registers in DM and way to launch an instruction fetch
atomically.

I also wonder about having a CSR per hart mapped to a shared memory
location.  A straight memory store might be easier/simpler with same
caveats as for instruction fetch (very simple core might only have one
data RAM - but this is much rarer than single instruction memory as
even simple cores usually have some memory-mapped IO).

Krste

Interesting discussion so far.

I like the look of instruction fetching/feeding, it's pretty neat, but it obviously relies on a working core. How do you propose debugging the hardware, for example getting the state of something which is architecturally invisible, as Alex suggests? For something like an OoO core, I'm guessing there is a great deal of architecturally-invisible state that would be of interest to help tune software and compilers. Is it the remit of this group to consider this admittedly more hardware-oriented debug capability?

Cheers,

Julius

 

| 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/
| CAGDihek961oaVBLoyZj76puJekW0ie5NmjpvcxGhuaHcDafhbQ%40mail.gmail.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+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/22644.10618.217130.16099%40KAMacBookAir2012.local.

[Alex Bradbury]

On 9 January 2017 at 18:40, Tim Newsome <t...@sifive.com> wrote:
> On Wed, Jan 4, 2017 at 11:02 AM, Alex Bradbury <a...@asbradbury.org> wrote:
>>
>> On 4 January 2017 at 18:23, Tim Newsome <t...@sifive.com> wrote:
>> > OK, but your slide 13 lists as the first advantage of the memory map
>> > interface "Simplicity." Then separately it lists "Memory map interface
>> > allows multiple implementation approaches," which I agree with.
>>
>> I think we were being purposely nebulous with "simplicity".
>
>
> I can understand that, but it makes it hard for me to make an argument that
> instruction feeding is just as simple if you can't explain what exactly is
> simple.

As I said, the fact it allows multiple implementation approaches is
more important. As I explain below, the interface is conceptually
simple - the simplicity of the implementation is not an important
argument:

>
> Can you share your personal opinion on why you would not want to implement
> instruction feeding? I honestly think it's always simple. I've made large
> changes to my spec to accommodate concerns that I can understand (lower gate
> count, more flexibility in implementation) and I'd be happy to change things
> to address other concerns as well.

The recent post from Michael Gautschi discusses some reasons PULP have
preferred a different implementation approach. Fundamentally, my
concern is that by only exposing an instruction feeding interface
rather than a more abstract approach, you have to make the argument
this is a better approach for every processor design point and every
design team.

Best,

Alex

[Alex Bradbury]

On 9 January 2017 at 19:01, Michael Chapman

Hi Mike. You've given strong arguments for preferring an instruction
feeding implementation in complex cores, but this thread is about the
interface which is exposed to the debugger and the minimal interface
implementers should provide. As I said in the first post in this
thread "

One aspect which I hope is made clear is the separation between the
external interface and the implementation. It’s completely sensible to
be in favour of exposing a memory-mapped interface but to also
advocate instruction feeding as an implementation technique."

Best,

Alex

[Alex Bradbury]

On 10 January 2017 at 00:23, <kr...@berkeley.edu> wrote:
>
> I think the name "instruction feeding" should be changed to
> "instruction fetching" as that is really what it is and in either case
> doesn't need to change the processor core except for the case where
> the core had only a single source of instructions with no address
> decode mux (i.e., ROM or RAM but not both).

It's not an ideal name, but one of the points of confusion in this
discussion has been about differentiating between the chosen
implementation approach and the interface exposed to the debugger. The
'instruction feeding' description does have the advantage of
highlighting how instructions are 'fed' to the core by a remote debug
program. This helps to differentiate it from proposals from
implementers who would like to implement debug by executing
instructions in the core pipeline, but would rather expose a
command/message or memory-mapped interface.

> On the call, we also came to conclusion that the memory-mapped
> solution is not sufficient in general once new extensions and
> additional processor state are added, as it would require this level
> of spec to be continually revisited to dole out memory space to
> alternative extensions. So, debug by instruction fetching has to be
> supported as at least an optional component.

I fully agree that debug by instruction feeding should, at a minimum,
but a defined optional component. I feel that if the memory map for
extension state is described by a per-chip machine-readable
description there's no particular barrier to exposing that state or
managing the memory map. With the defined optional instruction feeding
support, system implementers have the option of choosing which
approach makes most sense for their them when adding new extensions.

Best,

Alex

[Tim Newsome]

On Mon, Jan 9, 2017 at 11:50 PM, Alex Bradbury <a...@asbradbury.org> wrote:

On 9 January 2017 at 18:40, Tim Newsome <t...@sifive.com> wrote:
> On Wed, Jan 4, 2017 at 11:02 AM, Alex Bradbury <a...@asbradbury.org> wrote:
>>
>> On 4 January 2017 at 18:23, Tim Newsome <t...@sifive.com> wrote:
>> > OK, but your slide 13 lists as the first advantage of the memory map
>> > interface "Simplicity." Then separately it lists "Memory map interface
>> > allows multiple implementation approaches," which I agree with.
>>
>> I think we were being purposely nebulous with "simplicity".
>
>
> I can understand that, but it makes it hard for me to make an argument that
> instruction feeding is just as simple if you can't explain what exactly is
> simple.

As I said, the fact it allows multiple implementation approaches is
more important. As I explain below, the interface is conceptually
simple - the simplicity of the implementation is not an important
argument:

The abstract interface is definitely simpler to understand. But the alternatives aren't not much less simple.

Simplicity of implementation is among the most important arguments. RISC-V encourages everybody to do their own implementation if they like. Making it simple to implement supports that goal. There will be more hardware implementations than software implementations, so making implementing hardware simple is important here, too.

But if you don't think simplicity is an important argument, then please don't mention it as a benefit of the abstract implementation.

> Can you share your personal opinion on why you would not want to implement
> instruction feeding? I honestly think it's always simple. I've made large
> changes to my spec to accommodate concerns that I can understand (lower gate
> count, more flexibility in implementation) and I'd be happy to change things
> to address other concerns as well.

The recent post from Michael Gautschi discusses some reasons PULP have
preferred a different implementation approach. Fundamentally, my
concern is that by only exposing an instruction feeding interface
rather than a more abstract approach, you have to make the argument
this is a better approach for every processor design point and every
design team.

I'd refine your statement a little. We need to make the argument that any cost of instruction-feeding-only is not a big deal. There may be some design points where abstract would be a little bit better, but that can be balanced by having a single interface which means more consistent software support.

People already agree that for complex cores instruction feeding is the better approach. What I'm trying to convince people of is that it's a straightforward solution for small cores also.

So far the only argument against instruction feeding that really resonates with me is that an abstract approach allows you to inspect the processor while it's running. That's not a common use case, though. Having unlimited flexibility is more important.

I'm still waiting for somebody to describe in detail that they have a design where instruction feeding is just not practical. (Eg. people have described in detail why the direct implementation is too hard for complex cores.) I'll respond to Michael Gautschi's e-mail separately, but it mostly looks like I need to clarify exactly what I mean.

Tim

[Stefan Wallentowitz]

On 10.01.2017 19:04, Tim Newsome wrote:
> On Mon, Jan 9, 2017 at 11:50 PM, Alex Bradbury <a...@asbradbury.org
> <mailto:a...@asbradbury.org>> wrote:
>
> On 9 January 2017 at 18:40, Tim Newsome <t...@sifive.com

> <mailto:t...@sifive.com>> wrote:
> > On Wed, Jan 4, 2017 at 11:02 AM, Alex Bradbury <a...@asbradbury.org <mailto:a...@asbradbury.org>> wrote:

> >>
> >> On 4 January 2017 at 18:23, Tim Newsome <t...@sifive.com <mailto:t...@sifive.com>> wrote:
> >> > OK, but your slide 13 lists as the first advantage of the memory map
> >> > interface "Simplicity." Then separately it lists "Memory map interface
> >> > allows multiple implementation approaches," which I agree with.
> >>
> >> I think we were being purposely nebulous with "simplicity".
> >
> >
> > I can understand that, but it makes it hard for me to make an argument that
> > instruction feeding is just as simple if you can't explain what exactly is
> > simple.
>
> As I said, the fact it allows multiple implementation approaches is
> more important. As I explain below, the interface is conceptually
> simple - the simplicity of the implementation is not an important
> argument:
>
>
> The abstract interface is definitely simpler to understand. But the
> alternatives aren't not much less simple.
>
> Simplicity of implementation is among the most important arguments.
> RISC-V encourages everybody to do their own implementation if they like.
> Making it simple to implement supports that goal. There will be more
> hardware implementations than software implementations, so making
> implementing hardware simple is important here, too.
>
> But if you don't think simplicity is an important argument, then please
> don't mention it as a benefit of the abstract implementation.

I think it was clarified that this was not meant and we shouldn't go in
circles about that. I hope the formulation in the slides now better
reflects the argument.

Cheers,
Stefan

[Tim Newsome]

On Tue, Jan 10, 2017 at 10:31 AM, Stefan Wallentowitz <ste...@wallentowitz.de> wrote:

> The abstract interface is definitely simpler to understand. But the
> alternatives aren't not much less simple.
>
> Simplicity of implementation is among the most important arguments.
> RISC-V encourages everybody to do their own implementation if they like.
> Making it simple to implement supports that goal. There will be more
> hardware implementations than software implementations, so making
> implementing hardware simple is important here, too.
>
> But if you don't think simplicity is an important argument, then please
> don't mention it as a benefit of the abstract implementation.

I think it was clarified that this was not meant and we shouldn't go in
circles about that. I hope the formulation in the slides now better
reflects the argument.

I hadn't noticed that the slides were updated. This is better. Thank you.

Tim

[Alex Bradbury]

On 10 January 2017 at 18:04, Tim Newsome <t...@sifive.com> wrote:
> On Mon, Jan 9, 2017 at 11:50 PM, Alex Bradbury <a...@asbradbury.org> wrote:
>> The recent post from Michael Gautschi discusses some reasons PULP have
>> preferred a different implementation approach. Fundamentally, my
>> concern is that by only exposing an instruction feeding interface
>> rather than a more abstract approach, you have to make the argument
>> this is a better approach for every processor design point and every
>> design team.
>
>
> I'd refine your statement a little. We need to make the argument that any
> cost of instruction-feeding-only is not a big deal. There may be some design
> points where abstract would be a little bit better, but that can be balanced
> by having a single interface which means more consistent software support.

You're right, the statement was overly strong. Either
instruction-feeding is better for every process design point and every
design team, or we make the judgement that whatever disadvantages it
poses for the subset of the community who would prefer something else
are outweighed by the advantages to others and having a single
interface for software to support.

Best,

Alex

[Gajinder Panesar]

I don't agree with the statement that inspecting the processor state while it is running is not common. Profilers do just that - I am talking about profiling non-instrumented code without any intrusion. This is why I am of the view that we should have a simple memory mapped approach for that basic, simple stuff such as processor state (e.g. PC) and control which would stay the same for all RISC-V cores but for for more complex stuff such as vectors, sw break points etc you execute code as you have already specified.

[Tim Newsome]

On Wed, Jan 11, 2017 at 5:17 AM, Gajinder Panesar <gajinder...@gmail.com> wrote:

I don't agree with the statement that inspecting the processor state while it is running is not common. Profilers do just that - I am talking about profiling non-instrumented code without any intrusion. This is why I am of the view that we should have a simple memory mapped approach for that basic, simple stuff such as processor state (e.g. PC) and control which would stay the same for all RISC-V cores but for for more complex stuff such as vectors, sw break points etc you execute code as you have already specified.

That's a good point. For profiling I think it makes sense to be able to sample the PC. Does it make sense to be able to sample GPRs/CSRs also? I don't think we would want to make it mandatory to be able to sample them while the hart is running, but it might be a nice option if there is a use case.

Tim