[RISC-V] [tech-chairs] Architecture extension proposal for ConfigPtr CSR to "Unified RISC-V Discovery Method" config structure


Greg Favor
 

On Mon, Jun 28, 2021 at 2:06 PM Philipp Tomsich <philipp.tomsich@...> wrote:
Note that in an earlier discussion with Greg, I had proposed all-ones as the escape, as a single-byte message can not be valid.

In any case (and reversing an earlier response I made to Tim), since this extension is not specifying an overall discovery method and is just specifying one small generic ISA hook, any special added semantics around the content of the CSR is left to be specified by a discovery method.

Greg
 
On Mon 28. Jun 2021 at 23:01, Robert Chyla <Robert.Chyla@...> wrote:
I think we can extend meaning of that CSR register (for future) by allowing write of some 'keyed/secret' value into it.
Keeping it 'clean address' is IMO better for now.

/Robert


Philipp Tomsich <philipp.tomsich@...>
 

Note that in an earlier discussion with Greg, I had proposed all-ones as the escape, as a single-byte message can not be valid.

On Mon 28. Jun 2021 at 23:01, Robert Chyla <Robert.Chyla@...> wrote:
I think we can extend meaning of that CSR register (for future) by allowing write of some 'keyed/secret' value into it.
Keeping it 'clean address' is IMO better for now.

/Robert

On 6/28/2021 1:54 PM, Philipp Tomsich wrote:


On Mon 28. Jun 2021 at 22:40, Greg Favor <gfavor@...> wrote:
On Mon, Jun 28, 2021 at 1:29 PM Tim Newsome <tim@...> wrote:
One addition:
If the CSR contains 0, software should assume there is no configuration structure.

Agreed.
 
I'd also like to require the pointer be 4-byte aligned, meaning software should ignore the low 2 bits. This will give us 2 extra bits should we need them in the future.

That's OK.  The extension would then define the low two bits as "00" and as "Reserved for future standard use".

In consideration of low-end systems that may point into some memory-mapped serial storage, I would rather avoid this.

It’s also going to cause eventual discussions, once the first devices with errata slip through and cause issues with software ghat assumes this constraint to always hold.

Philipp.


--
Regards,
Robert Chyla, Lead Engineer, Debug and Trace Probe Software
IAR Systems
1211 Flynn Rd, Unit 104
Camarillo, CA  93012 USA
Office: +1 805 383 3682 x104
E-mail: Robert.Chyla@... Website: www.iar.com