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