1. Tech-Privileged
  2. Topics

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

Allen Baum
 

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).
Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?
I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth, 
as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.
The intent of this is to be able to configure the Sail model to implement the behavior they control.

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> 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.


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:38 PM Allen Baum <allen.baum@...> wrote:
I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example).
Who is the consumer of that identifier? Is this a value you would expect to be encoded in the config-struct of on-line discovery?
I am building a list of all architectural options that aren't controlled by CSR fields, for what it is worth, 
as well as all the named option value ranges, regardless of whether they're controlled by a CSR value or not.
The intent of this is to be able to configure the Sail model to implement the behavior they control.

Identifier in the sense of a short name/phrase that refers to these ideas. Consumers of that would be both software and day-to-day discussion as it's a succinct identifier that refers to an idea in prose.

Take the Zic64b "extension": it's a shortcut for "Cache blocks must be 64 bytes in size, naturally aligned in the address space." However, there are 3 different cache block operations. So while a Profile name could refer to the whole set of bold options/extensions, there are cases where a system doesn't adhere to a Profile. So how does one convey the cache block size (even if it's 32 bytes for all 3 cache block operations)? I think having a way to identify those architectural options can be very powerful.

FWIW, I completely thought of the the architectural test work you are doing, but I failed to directly mention it in my original email, Allen. Sorry about that.
 

On Fri, Jul 8, 2022 at 1:30 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> 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.


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 - 2 of 2