Zero data registers and accessing GPRs

[atthec...@gmail.com]

The current version of the specification (0.13 CS fb0bdc60f3a5847fb3897df3ce1ba56870bc627e) indicates that a value of 0 is permitted in the datacount in abstractcs.

From what I can see at least one data register is required to read or write GPRs.

Section 2 indicates that "Abstract commands provide access to GPRs"; however, section 1.4 does not require this. Yet it does state that "While both the mechanism to execute arbitrary instructions and the system bus master are optional, at least one of them must be implemented. Otherwise there is no mechanism to access memory."; so presumably a mechanism to access memory is a requirement?

I am building a minimal debug interface for up to 64 harts on my RISC-V implementations.

Hence I now have a few questions:

1) Is it a bug in the spec, to say 0 is permitted in data count?

2) If it is not, then how are GPRs accessed by a debugger through the DM?

3) Is GPR access actually a requirement also in section 1.4?

--Gavin

[Gavin Stark]

Thanks Palmer; Tim also replied, but not on list given he is traveling.

The balance between architecture and implementation can sometimes be blurred; and RISC-V has an analogous blurring between ISA profile and platform.
It gets even trickier in the debug specification - which claims to be a standard architecture for debug, but which has to provide for more than that to be of any relevance.

My general kick inside my day job is that architecture is the bus interconnect specifications, protocols, and broad capabilities that this then supplies; this perhaps fits better with the debug spec than with an ISA spec.

My perspective on the debug spec is that it has to describe a basic implementation (or set thereof) that permits a developer of OpenOCD (or similar) to get something that works for gdb for _all_ platforms. That means, in the RISC-V parlance, perhaps, it must provide a selection of minimal platforms with possible extensions. The ‘architecture’ part of the spec has to describe the bits that the platform spec selects from.

FWIW, my program buffer is far to far away from the harts to be readable or writable by the CPU…

(to answer my questions - and I think my answers align with Tim’s - yes, it is a bug to say 0 is permitted in the count, as data0 is required; GPRs can be accessed through data0; GPR access should probably be a requirement.)

—Gavin


> On 7 Jun 2018, at 22:02, Palmer Dabbelt <pal...@sifive.com> wrote:

>
> On Mon, 04 Jun 2018 06:56:27 PDT (-0700), atthec...@gmail.com wrote:
>> The current version of the specification (0.13
>> CS fb0bdc60f3a5847fb3897df3ce1ba56870bc627e) indicates that a value of 0 is
>> permitted in the datacount in abstractcs.
>>
>> From what I can see at least one data register is required to read or write
>> GPRs.
>>
>> Section 2 indicates that "Abstract commands provide access to GPRs";
>> however, section 1.4 does not require this. Yet it does state that "While
>> both the mechanism to execute arbitrary instructions and the system bus
>> master are optional, at least one of them must be implemented. Otherwise
>> there is no mechanism to access memory."; so presumably a mechanism to
>> access memory is a requirement?
>>
>>
>> I am building a minimal debug interface for up to 64 harts on my RISC-V
>> implementations.
>>
>> Hence I now have a few questions:
>

> While I don't really do any debug spec work, I have read the spec a bunch of times to do some OpenOCD work and here's my take on things:

>
>> 1) Is it a bug in the spec, to say 0 is permitted in data count?
>

> My understanding is that it's not a bug, and that any abstract command that involves writing to or reading from a data word would fail -- so while the abstract command to access GPRs has no be there, there doesn't ever have to be a situation in which it will work. This is kind of like strtol() in POSIX: it has to exist, but it can return EINVAL for all inputs.

>
>> 2) If it is not, then how are GPRs accessed by a debugger through the DM?
>

> You can access the GPRs by executing a progbuf program that stores to an address in the progbuf.

>
>> 3) Is GPR access actually a requirement also in section 1.4?
>

> That's odd wording to be in an ISA spec. In general the ISA specifications are meant to have no restrictions on which subset is legal, with a platform specification then describing the particular subset of the ISA that is necessary to guarantee compatibility with a particular application.
>
> In other words, I'd expect to see something like "While both the mechanism to execute arbitrary instructions and the system bus master are optional, at least one of them must be implemented. Otherwise there is no mechanism to access memory." in a platform specification, not the debug spec. The debug spec still has some of this wording in it (I'd say all of 1.3, 1.4, and 2), but hopefully that will eventually get cleaned up.
>
> Of course, there is no platform specification and I didn't write the debug spec, so I could just be wrong here :)