RISC-V Debug System Preliminary Poll Results

I believe 1) we should choose an interface that permits as wide a range of implementation options as possible, and 2) there hasn’t been sufficient justification for risking fragmentation in the RISC-V ecosystem. As such, the logical conclusion for me is to prefer a unified abstract interface. Although I don’t like the idea of risking fragmentation, two interfaces remains my second choice - I feel that’s preferable to restricting the choices available to RISC-V implementers, especially given the huge diversity of cores and requirements.

I would additionally point out that we can start with the unified abstract interface, and if the overhead of translating simple commands to simple instructions is found to be an issue it can always later move in the direction of the option of two interfaces option.

All of these will work, neither is a bad idea. With the exception of using instructions as abstract commands, that just gets ugly and convoluted. I still think we should provide a simple memory mapped interface for the base access and use instruction supply for the complex stuff.

We are doing a high performance RISC-V core, which is tight on critical path. A mux in front of the register set would impact the entire chip’s performance and/or cost. Yet the simplicity seems best for designs that don’t have such tight timing constraints. Hence, if the software can handle both methods, that seems the only approach that works for everyone.

although my company is foundation members, I’m only voting as an individual not for the company

The future-proof argument is the strongest in my opinion. Although it requires the debugger to be integrated with the RISC-V assembler and linker (at least during build), this option is the most versatile one. I would not provide both interfaces.

My preference for the Unified Abstract Interface is contingent on the final spec allowing very small/minimal implementations that still meet the spec. In other words, if the minimum mandatory requirements in the final spec require significant resources to implement, then my opinion might change.

I don’t like having both as optional interfaces; it creates unnecessary complexity.

We are strongly pro to instruction feeding as hardware / software interface in our own RISCV design But we also recognize that there’re other people who want to go to a different way in hardware implementation because of various reasons Based on above reasons, we feel that an unified abstract interface would be wiser

I’m most on favor of the option which results in most debug software supporting most implementations. I expect that message-based (direct access to the core, not instruction feeding) option will become the most prevalent for deeply embedded implementations, and instruction feeding will be for those who love it and those who need it like OoO cores. The abstract thing might be best actually but really I think the option is good.

Both approaches have their benefits, and I see the main differentiation in the HW implementation complexity. On this topic I think more implementation experience and measured data needs to be gathered to make a final judgment. I therefore propose to defer the standardization for now by making both approaches optional and let the two approaches compete in the real world. Revisit the issue if implementation experience has been gathered.

I think the basic state of the machine should be accessible without stopping it. This will allow for non-intrusive software such as profilers to be implemented. Beyond the basic state the instruction feeding method should be used for everything else. That is why I have ranked the above as I have.

Providing the choice of two is more like a political compromise. We should make the standard more technical instead of political. So, I wouldn’t vote for that. For the reason why I vote for Unified Abstract Interface, my philosophy is that the standard should be clean and should not be implementation-specific. Instruction feeding is only a simple way to implement, and if other company wants to implement a sophisticated way, the standard should not be a restriction. Moreover, debugging without halt the core is very attracting, and this is hard to achieved by instruction feeding. The execution should be separated with the observation. These are the reason why I vote for Unified approach. However, I achieve all the effort that both side put in. Thanks for your effort to make RISC-V better.

For deeply embedded systems, with real-time constraints, the Instruction Feeding approach does not allow state to be retrieved without stopping the core. Likewise, for trace-less profiling the profiler must access the machine state non-invasively.

As a second choice, small / embedded cores and large scale OoO cores could pick the right interface for their target market.