toggle quoted message
Show quoted text
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.
On 7/18/2022 11:17 AM, Allen Baum
My list is
attached. I am quite sure it is not complete, and is not bug
It may be a
bit cryptic; sheets 3&4 were used to construct the first
primarily derived from the Imperas simulator options, with
additions and comments by myself.
when something is described as "can use CSR definition", that
is specifically referring to the riscv-config schema,
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,
dependencies on other CSR fields which may affect which values
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.
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
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
to any optional behavior ranges required by the profile.
need to care about optional extensions, whether supported or
unsupported (which are probably everything not in the above
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
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).
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
T. Flores-Mendoza -
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 another
This Message Is From an External Sender
This message came from outside your organization.
And, of course, I need to
add some other thoughts.
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
There is another
configuration format which is intended for off-line
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
(besides trying something
and seeing which result it gives, which could be a
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,
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
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.)
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)
The group must provide three outputs this
- The Unified Discovery specification
- Agreed-on parameter lists (that are then
encoded per the specification) with all
- 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 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
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
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
If they both get ratified this year great.
If the parameters get done early next year
that is, in my opinion, better than waiting
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.