Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

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.

Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

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.

On Mon, Jul 11, 2022, 5:09 PM Allen Baum <allen.baum@...> wrote:

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)

Alan,

Given the recent troubles with people having taken extensions in the priv/unpriv spec documents as being official even though they are listed as unratified, I would suggest not listing extensions that have no active plan to be ratified nor any group actively or planning to actively pursue ratification - in particular the unratified bitmanip extensions.

Similarly, no dev effort should be spent on these possibly never to be ratified extension proposals.

Better to stick to ratified extensions, or clearly mark extensions that are working towards being ratified over the coming year.

Greg 

On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:

Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

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.

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)

On Mon, Jul 11, 2022 at 1:40 PM Philipp Tomsich <philipp.tomsich@...> wrote:

Allen,

There is no 'RVB'... and even the basic options on Zb[abcs] open up 16
possibilities.
Similarly 'V' is a not a single option, but multiple Zv* options.
Finally, Zihintpause is missing.

Cheers,
Philipp.

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.