toggle quoted messageShow quoted text
Ah, never mind. My version of the spreadsheet opens to sheet3, and that's what has the complete list. The other sheets were used to develop this one.
I will rename the sheet and put it in the front. and also move unratified extensions to another sheet
I'm not sure what you're referring to
Line 244 list Zihintpause
Lines 180-188 list Zvlsseg, Zvamo, Zvediv, Zvqmac, Zve32x, Zve32f, Zve64x, Zve64f, Zve64d
Lines 138-147 list Zba, Zbb, Zbc, Zbe, Zbf, Zbm, Zbp, Zbr, Zbs, Zbt (many of which are not yet ratified)
There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.
On Mon, 11 Jul 2022 at 22:16, Allen Baum <allen.baum@...> wrote:
> FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
> I know that this is very, very likely to be incomplete.
> This is written from the perspective of how to make our reference model model the behavior of a device under test.
> That's a very different use case than what is needed for ACPI, so I have no clue which of these options require a
> parameter to be supplied (as opposed to defining the parameter) and which are don't cares.
> Most of this was derived from the Imperas simulator options.
> Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
> (e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)
> The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.