toggle quoted message
Show quoted text
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)
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
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
Sr. Staff Engineer, Debug and Trace
cell: 1-805-990-1511, www.sifive.com
On 7/18/2022 8:37 AM, Irma T
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
T. Flores-Mendoza - #ProudToBeAnIBMer
System Z Firmware Engineer, RISC-V
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
This Message Is From an External Sender
This message came from outside your organization.
course, I need to add some other thoughts.
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.
another configuration format which is intended for off-line
this was primarily developed for the
architectural compatibility tests, it can also be used by
toolchains to guide emulation, cross compilation and
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,
architectural options, many of which have no name and no
current way of interrogating a system to see which option
trying something and seeing which result it gives, which
could be a trap).
majority of architectural op[tions can be determined by
writing and reading CSRs fields
seeing which bits can be written, and which bits are
readonly and what their values are.
reading MISA tells you which major extensions are supported;
writing it will tell you which of those can be disabled).
this only works for single bit fields; for wider fields it
can be much, much more complicated)
intent from the beginning was that there be a tool that can
translate from one structure to the other,
config-struct doesn't need to support the details that
riscv-config is intended to support.
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.
preparing a list of the architectural options I know about.
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.)
Thank you for summarizing (+1) — I, unfortunately,
have a standing conflict in the current tech-config
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.
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
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,
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
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
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
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.