I don't disagree, and make no claim that this list should simply be copied for tech-config.

This is just a catalog of (most of)  the architecturally valid options defined by the RISC-V privileged and unprivileged specs.

It's a menu that this group can pick and choose from, and was intended only to illustrate the available choices.

Which of these are needed in the config-struct will be decided by tech-config.

The first version of tech-config will be binary choices, (e.g. is this extension implemented or not...) but that won't last in all probability.

The exact evolution of which of the options are exposed by the config-struct is up to this group, not me.

Regarding version numbers:

This list was taken from the Imperas simulator originally (with their permission), 

My understanding is that ALL of these (including version numbers) were required to be able to test actual hardware that they've been asked to verify. 

The version numbers reflect the fact that vendors design (and ship) their HW before RISC-V specs have been frozen.

In essence, these version could be considered a custom extension that is mostly, but not completely, compatible. 

But they are (or will be) shipping, so there will be tools and SW that need to know this (at least, from those vendor's perspective).

It is up to tech-config to decide if there should be support for that in the config-struct. 

It's an interesting question, and I don't lean in any particular direction. 

From an ACT perspective, we will be testing only valid architectural options (until we're told otherwise). 

Note that some of the version numbers (specifically priv spec 1.11 and 1.12) have names, and therefore can be represented by binary choices

(though an ennumeration might be a better way to do it).

On Mon, Jul 18, 2022 at 11:49 AM Robert Chyla <Robert.Chyla@...> wrote:

Hi Allen.

This what you provided is very deeply elaborated and very valuable 'set' of data driven from practical use-cases of (different?) simulators in ACT's.

Nut my understanding was that we need to first define (simple?) 'yes/no' for all ratified (up to date ...) extensions.

Once this is 'settled', we should go deeper with dependencies/conditions and parameters .... needless to say some of these (say 'endian' ...) are of critical importance, so we cannot stop at allowing only yes/no to be 'ratified' as it will have no practical value.

PS. I am very skeptical about '???_version' fields. IMO these can/should be there for informative purposes ONLY and rather NOT used in code ... If there is a need for 'conditional' handling it should be rather defined as separated boolean/numeric parameter with well defined semantic.

Thanks,

/Robert

On 7/18/2022 11:17 AM, Allen Baum wrote:

My list is attached. I am quite sure it is not complete, and is not bug free.

It may be a bit cryptic; sheets 3&4 were used to construct the first sheet.

This is primarily derived from the Imperas simulator options, with additions and comments by myself. 

Note that when something is described as "can use CSR definition", that is specifically referring to the riscv-config schema, 

which can describe a CSR bit as RW/RO1/ROZ, and (for WARL fields) also describes the legal value ranges, and the mappings from illegal to legal ranges,

and any dependencies on other CSR fields which may affect which values are legal.

I'm not sure I agree with many of Robert's points above; The ACT's have a completely separate stage (riscv-config)

that does a sanity check on the YAML formatted file that describes what the core is doing.

Those sanity check rules need to be described (a different YAML formatted file IIRC) but that is an entirely separate schema, 

and is core independent, (e.g., it understands that D requires F (or D implies F), or Zicntr requires Zicsr (ditto), or F and Zfinx can't coexist)

Our thought is that the same approach should be taken for named profiles; 

i.e there are no profile tests, but there could be a sanity check that a hart implements: 

  - all mandatory extension, 

  - no incompatible extensions, 

  - conforms to any optional behavior ranges required by the profile.

It shouldn't need to care about optional extensions, whether supported or unsupported (which are probably everything not in the above categories)

On Mon, Jul 18, 2022 at 10:38 AM Robert Chyla <Robert.Chyla@...> wrote:

Hi,

I think it is important to do the following:

1. Identify all ratified (as of today) extensions

1.1. Consider 'tree-structure' of extensions

1.2. Consider fact that extension A may require extension B

1.3. Consider fact that extension A may EXCLUDE extension B (even in different tree branch ...)

1.4. Consider fact that some extensions have 'parameters' (like size of virtual address ...)

1.4.1.  These 'parameters' may be static (fixed) or dynamic (adjusted in run time) I assume

2. Identify all extensions to be ratified soon as we do not want to create 'a standard' which may need to change next day. Zc is good example from two reasons:

2.1. It may be ratified together with 'config-structure'

2.2. Some of Zc sub-extensions exclude double precision float extension ...).

IMO only after doing all above, we should be looking at a way (simple way ...) to encode/express/describe all of above in Schema (which I think is possible)

Each of profiles should be then considered as 'set of extensions' (all extensions listed for each profile must be fully supported by implementation).

-Robert Chyla
Sr. Staff Engineer, Debug and Trace
cell: 1-805-990-1511, www.sifive.com

On 7/18/2022 8:37 AM, Irma T Flores-Mendoza wrote:

Hi Allen, "I am preparing a list of the architectural options I know about.While many are identified by the architecture string (e.g. Zkne), there are many that are not, though some have been given SBI names (e.g whether WLRL trap on illegal values or not.)"

Please reply back to this email with the list you were preparing (details in your email forwarded below).  I will work on incorporating it to the Schema.  Many thanks in advance

Regards,

Irma T. Flores-Mendoza - #ProudToBeAnIBMer  System Z Firmware Engineer, RISC-V Processor Firmware

---

From: tech-config@... <tech-config@...> on behalf of Allen Baum <allen.baum@...>
Sent: Wednesday, May 25, 2022 5:49 AM
To: config <tech-config@...>
Subject: [EXTERNAL] [RISC-V] [tech-config] First steps

 

And, of course, I need to add some other thoughts. The configuration structure is intended for on-line use; boot code and debuggers can read it and use it to create data structures that the boot code, OSes and debuggers will use. There is another

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

And, of course, I need to add some other thoughts.

The configuration structure is intended for on-line use; boot code and debuggers can read it and use it to create data structures that the boot code, OSes and debuggers will use.

There is another configuration format which is intended for off-line use. 

While this was primarily developed for the architectural compatibility tests, it can also be used by toolchains to guide emulation, cross compilation and optimizations.

It is documented in the riscv-config github repo, and it is a YAML formatted schema that goes into great detail regarding not just the extensions supported, 

but all architectural options, many of which have no name and no current way of interrogating a system  to see which option is implemented

(besides trying something and seeing which result it gives, which could be a trap).

The majority of architectural op[tions can be determined by writing and reading CSRs  fields

 and seeing which bits can be written, and which bits are readonly and what their values are.

(e.g. reading MISA tells you which major extensions are supported; writing it will tell you which of those can be disabled).

Obviously, this only works for single bit fields; for wider fields it can be much, much more complicated)

The intent from the beginning was that there be a tool that can translate from one structure to the other, 

though config-struct doesn't need to support the details that riscv-config is intended to support.

(i.e. offline use cannot read and write CSRs to determine what is supported) It is not necessary that there is a 1:1 correspondence from one to the other; the will be definitions in one that the other doesn’t care about.

I am preparing a list of the architectural options I know about.

While many are identified by the architecture string (e.g. Zkne), there are many that are not, though some have been given SBI names (e.g whether WLRL trap on illegal values or not.)

On Mon, May 23, 2022 at 10:00 AM Philipp Tomsich <philipp.tomsich@...> wrote:

Mark,

Thank you for summarizing (+1) — I, unfortunately, have a standing conflict in the current tech-config timeslot.

Let me add a bit more color from a call I had with Irma last week…

The priorities of Unified Discovery need to be in defining and specifying the ground rules (referenced standards, referenced encodings, RISC-V specific encoding rules, guidance for groups on how they summarize their configurable items) and on the end-to-end flow.  Any Schema version's minutiae must be kept separate from the Specification itself, as we will not revise the specification for changes.  The PoC for the rat-plan shall be simple, focused on decoding and using the information to populate the higher-level discovery info (e.g. device-tree) for Linux.

The group must provide three outputs this year:

• The Unified Discovery specification document.
• Agreed-on parameter lists (that are then encoded per the specification) with all groups.
• Finally, but just as critical for our future success: a complete future plan/parking lot of issues to be worked on next (e.g. multi-socket, …).

Too many groups and efforts depend on this to let this slip out further.

Philipp.

On Mon, 23 May 2022 at 18:19, mark <markhimelstein@...> wrote:

I have talked with Irma today and promised to write down my guidance on goals and some context. This is only my guidance. It is not a law! If you think differently (or I got something wrong) after reading this email please speak up.

We have adopted a strong divide and conquer philosophy. It doesn't mean that we won't do follow-on work. We are just trying to not slow down ratifications.

The most important thing for me in discovery are to support bases, extensions, and profiles. There are two parts for me: existence and parameters.

Both bases and extensions define instructions, behavior and state. You are not really RISC-V unless you have a base.

Extensions may also include other extensions.

Profiles consist of a base and extensions.

You can look at bases and extensions and profiles as macros that expand

Compilers will eventually encourage developers to use profiles instead of long strings of extensions. Compilers with adorn ELF headers with the base and profiles and/or extensions it requires.

How an OS gets the discovery information is up to the software stack (direct, SBI calls, device tree, etc.).

Discovery is intended to provide a way for system level software to do its job including things like execute its own  appropriately, be able to decide whether the system can execute a binary (by comparing elf headers and discovery info), what state needs to be saved and restored on context switch, etc.

In my opinion, the most important things are to lay down the infrastructure (asn), provide libraries to digest it into an in memory data structure with lookup routines, and provide the key/value pairs for existence.

The second most important priority are the parameters for bases, extensions, and profiles (not clear to me if this applies to all 3 yet).

I suggest both tasks (task as in Task Group) be worked on immediately but the parameters should not stop the highest priority group discussed above.

If they both get ratified this year great. If the parameters get done early next year that is, in my opinion, better than waiting for both.

The Task Group's first responsibility is to define the strategy for these tasks and publish it and review it with a revised ratplan with chairs. This must include line of sight to getting the work done employing the governing committee, Dev Partners, and myself if necessary. This should be done in the next 4 weeks.

Since everyone is impacted by this, other committees and SIGs and TGs must get involved and interact with this TG. This can include identifying reps from each group to monitor the mailing list or join the TG meetings. I will bring this up at chairs.

Mark