Here it is, folks! Please take the time to read the summary of proposals, then fill out the poll below.

Introduction

The purpose of this poll is to determine the key trade-off the debug specification should make. After that decision is made, the debug taskgroup can move forwards in working out the finer details of a complete proposed specification that meets the chosen criteria.

Procedure

The poll will go live some time on Tuesday, January 17, and closes on Friday, January 20.

Everybody who votes must read and understand the proposals below. If they aren’t clear, read the links or ask on the mailing list. If they’re still not clear, don’t vote.

Each company gets one vote. If you also want to vote on behalf of yourself, go ahead and vote again using your name as the company name. Please make my life easier by not submitting more than one vote per company.

The results of this poll will be made public.

The first group of results we’ll look at is the companies that are Foundation members. The other set we’ll look at is the overall result.

Proposals

None of these proposals are final, but the results of this poll will limit the direction that we’ll pursue.

If you have questions about any of these, use the mailing list.

Instruction Feeding

The debugger can to perform the following operations on a hart: 1. Halt/resume 2. Cause an instruction to be executed 3. Read/write a shared data register There are instructions that access the shared data register.

This provides access to all resources that the hart has access to and is future-proof.

By having "halting" act as a normal exception (start fetching instructions from the debug module), core changes are kept to a minimum.

Optional extensions provide direct access to the system bus and to internal hart state.

More abstract approaches would enable more implementations, but instruction feeding is the best approach for most designs. Forcing extra abstraction on everybody hurts more than it helps.

Detailed proposal: https://dev.sifive.com/documentation/risc-v-external-debug-support/

Unified Abstract Interface

The external interface allows external access to state through abstract commands. Instruction feeding of arbitrary instructions should be exposed as an optional extension. If necessary, the message encoding could even match RISC-V instruction encoding to minimise translation overhead.

Abstracting away from the debug implementation mechanism allows greater freedom for system implementers and more flexibility for exposing state, including the possibility of accessing some state without halting the core. Implementers choose whether to expose state for custom extensions via instruction feeding or messages.

The benefits of allowing this greater flexibility and ensuring a single baseline interface outweigh any disadvantage for implementers needing to add a small amount of extra logic to translate the abstract interface to instruction feeding.

Provide the choice of two interfaces

Two optional external interfaces are provided: access state by transferring RISC-V instructions or through an abstract (command or memory map) interface. Implementers are able to choose to provide only one of these interface.

This gives the greatest possible flexibility to RISC-V implementers and avoids any hardware cost for translating messages or memory accesses. This benefit outweighs the cost of debug software having to support multiple access methods for the same state.

Poll

Please take the poll below (requires loading unauthenticated JavaScript) or at the polljunkie website.