poll results

[Tim Newsome]

Good afternoon!

I'm calling the poll officially over as of noon today.

You can see in-depth results, including comments from quite a few voters, at https://sifive.github.io/debug-mechanism-comparison/poll-results/results.html

If that's not enough detail for you, you can see raw data and the script that I used to compile results at https://github.com/sifive/debug-mechanism-comparison/tree/master/poll-results

The summary is that there isn't a clear winner. Every option got quite a few votes, but none so many that I'm comfortable declaring one as the clear path forward.

So what do we do?

We write a combined spec that includes both an abstract interface and instruction feeding. Right now there isn't a single abstract interface that we all agree is the one. We need to decide all the details. For the instruction supply part I assume we can use most of SiFive's proposal, at least as a starting point.

For the sake of having a concrete goal, I suggest we write the spec to follow the Unified Abstract Interface, but keeping in mind that we might change it to two optional interfaces in the future. After we work out the details, we can decide what parts of our comprehensive spec will be required and which parts will be optional.

Does that plan work for you?

Tim

[Stefan Wallentowitz]

Hi Tim,

On 20.01.2017 21:36, Tim Newsome wrote:
> Good afternoon!
>
> I'm calling the poll officially over as of noon today.
>
> You can see in-depth results, including comments from quite a few
> voters,
> at https://sifive.github.io/debug-mechanism-comparison/poll-results/results.html
> If that's not enough detail for you, you can see raw data and the script
> that I used to compile results at
> https://github.com/sifive/debug-mechanism-comparison/tree/master/poll-results

first of all thank you very much for that nicely conducted poll
(technically and community-wise), great work! I think it is important to
highlight that the role of the chair in such a process is not always fun
and that you are handling it excellently.

> The summary is that there isn't a clear winner. Every option got quite a
> few votes, but none so many that I'm comfortable declaring one as the
> clear path forward.
>
> So what do we do?
>
> We write a combined spec that includes both an abstract interface and
> instruction feeding. Right now there isn't a single abstract interface
> that we all agree is the one. We need to decide all the details. For the
> instruction supply part I assume we can use most of SiFive's proposal,
> at least as a starting point.
>
> For the sake of having a concrete goal, I suggest we write the spec to
> follow the Unified Abstract Interface, but keeping in mind that we might
> change it to two optional interfaces in the future. After we work out
> the details, we can decide what parts of our comprehensive spec will be
> required and which parts will be optional.
>
> Does that plan work for you?

That sounds like a good plan. Actually the difference between unified
and optional can be really narrowed down to a single bit in the
info/capabilities register:

- with both optional it signals if the base command interface is present
or not
- with the unified interface it is just not there and the base command
interface is always implemented

Deciding over that bit can be done if we maybe have some data points of
people prototyping the command->instruction translation or after a (this
time more) brief discussion.

So, fully agree, lets get this going forward!

Cheers,
Stefan

[Alex Bradbury]

On 20 January 2017 at 21:18, Stefan Wallentowitz <ste...@wallentowitz.de> wrote:
> Hi Tim,
>
> On 20.01.2017 21:36, Tim Newsome wrote:
>> Good afternoon!
>>
>> I'm calling the poll officially over as of noon today.
>>
>> You can see in-depth results, including comments from quite a few
>> voters,
>> at https://sifive.github.io/debug-mechanism-comparison/poll-results/results.html
>> If that's not enough detail for you, you can see raw data and the script
>> that I used to compile results at
>> https://github.com/sifive/debug-mechanism-comparison/tree/master/poll-results
>
> first of all thank you very much for that nicely conducted poll
> (technically and community-wise), great work! I think it is important to
> highlight that the role of the chair in such a process is not always fun
> and that you are handling it excellently.

I'd like to second that - thanks Tim!

I fully agree with the planned path forwards. Stefan and I termed
these two options "2a" and "2b" for a reason - from a specification
perspective they're very minor variants of each other.

Best,

Alex