Date 1 - 2 of 2
[RISC-V] [tech-unprivileged] Direction of Identifying Extensions
toggle quoted message Show quoted text
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:
On Fri, Jul 8, 2022 at 2:38 PM Allen Baum <allen.baum@...> wrote:
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.
|1 - 2 of 2|