1. Tech-Privileged
  2. Topics

[RISC-V] [tech-unprivileged] Direction of Identifying Extensions

Allen Baum
 

Unfortunately, I don't a have single term that would adequately convey the idea. 
Greg and I were batting around some invented words
(e.g. "poption" as a portmanteau of profile-option was my first attempt. It did get better, but that's a low bar)  
but nothing that you'd find in any dictionary.

On Mon, Jul 11, 2022 at 6:48 AM Aaron Durbin <adurbin@...> wrote:


On Fri, Jul 8, 2022 at 2:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions' and 'options' within the current proposal for these newly coined names.
 

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron
Aaron Durbin
 



On Fri, Jul 8, 2022 at 2:30 PM Allen Baum <allen.baum@...> wrote:
If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions' and 'options' within the current proposal for these newly coined names.
 

On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron
Allen Baum
 

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense.
They are names for the values of architectural options of extensions that already exist
 (which often,  but not always, are the legal set of values of a WARL CSR field which must be implemented). 
So these are constraints on the spec'ed options that are required to run SW on the platform.


On Fri, Jul 8, 2022 at 6:41 AM Aaron Durbin <adurbin@...> wrote:
Hi All,

First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted.  We can convene on a single list once it's identified.

The current Profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) proposal has coined quite a few new extension names to describe behaviors in the specifications that do not have formal names in the existing specifications. This particular topic came up during our discussion on ACPI bindings for AIA. However, userland, kernel, and firmware specifications are all impacted by this topic so settling on a well understood future direction will reap rewards across the ecosystem.

1. Is this the path we see RISC-V taking for the future? Assigning an identifier to behaviors (and related parameters) within the specifications?
2. If so, where will the official lists of extensions be maintained? Will there be a single source of extension identifiers? Or do people need to look at every potential specification to determine the identifiers?
3. There are some extensions that require parameters besides a binary presence. e.g. Zic64b in the Profile proposal indicates 64 byte cache block sizes for all cache block management, prefetch, and zero operations. That's fine for the Profile, but an implementation that may use different size(s) would need to encode the size in such an identifier. Therefore, I think that we should incorporate these notions more formally when defining identifiers for extension parameters.

I'd love to hear people's thoughts on this topic as it is very important, and I think it could be a good way in formalizing identifiers to all these concepts that can be used throughout the RISC-V ecosystem.

Thank you.

-Aaron

1 - 3 of 3