• add mtimecmp to platform yaml
• mimpid is not generated in the checked yaml - defaults might be missing

on pull request #136 I attempted to run bumpversion and follow directions in CONTRIBUTING.rst. but github would not authenticate.
@neelgala , any ideas? add more details to CONTRIBUTING.rst?

Following is the list of checks that need to be implemented:

• isa shuold not have conflicting extensions
• misa reset value check
• reset values should not cross max xlen supported
• reset value should be within the readonly values
• delegation of certain exceptions/interrupts not allowed for both m.
• sxl/uxl reset values
• checks on mstatus fields
• supported xlens should be cross validated with the ISA
• default values of implemented to be fixed correctly
• Generic warl dependency checks
• Valid set of values for the extension field.

Even though the mode field is warl, the spec lists various constraints on the allowed behavior of the various fields in satp register. These checks aren't implemented right now.

• Behaviour of writes when satp.mode is written with an illegal value. The spec says the following:

    if satp is written with an unsupported MODE, the entire write has no effect; 
    no fields in satp are modified.
  

  Hence all the fields in satp will need to contain satp.mode as a dependency and the only allowed illegal behavior on illegal mode fields is unchanged.

Table 3.2 of the privileged architecture (both the ratified version and the 2020/01/25 draft) indicates that the following bits are "Tentatively reserved": B, J, L, P, T, V. Every bit except "B" is allowed to be set in the SchemaValidator logic. Why’s “B” treated differently than the other bits?

In the new proposal, type can take 3 values: RO, WLRL and WARL.
RO refers to a hardwired read-only, which means that this field will always return the same value.

However, the spec defines fields like SD in mstatus which are readonly to the user but the value of the field depends on other micro-architectural state like xs and fs. So this doesn't fall under the RO category defined above neither is it WARL since it writes are not allowed to his field.

What should the type field be for such fields?
we can redefined RO to be ro_constant and define SD as ro_variable.

ro_constant will always respond with the same value.
ro_variable will however respond with different values but should we capture the function it depends on?

Hello everyone, I'm a Newbie who study yaml and cerberus first time. I found that in riscv-config/riscv_config/schemas/schema_isa.yaml:line181. The key 'max' has a value '[56]'.

    physical_addr_sz:
      type: integer
      max: [56]
      required: true
      check_with: phy_addr

As far as I can see, '[56]' seems to be a list with one element. But the type of physical_addr_sz is integer. It seems impossible to compare an integer with a list.

I don't konw whether it's a bug or it's just a feature I haven't known.

https://riscof.readthedocs.io/en/stable/coverage.html

The current directions say to run coverage:
riscof --verbose debug coverage --suite /path/to/suite --env /path/to/suite

this will generate an error. -c or --cgf_file is a required option.

However, even if -cgf_file is used, there is another error. riscof looks for the elf file in the wrong directory:

FileNotFoundError: [Errno 2] No such file or directory: '/riscof/riscof_work/rv32i_m/C/src/caddi-01.S/ref.elf'

but it looks like it should instead be looking in:
./rv32i_m/I/src/addi-01.S/ref/ref.elf

Thanks

Per table 3.2 of the privileged architecture (both the ratified version and the 2020/01/25 draft), the "Z" bit in misa is reserved. The title under the table notes all reserved bits must return 0 when read. The SchemaValidator not only allows the Z bit to be set, it requires it to be set in the presence of "Z" extensions in the ISA string.

Having worked a bit too much with regular expressions in the past I've spotted a few issues with the regex, first one:
[IE]+ at the beginning - this one matches one or more of the characters within the brackets:

What you want instead there is just ^RV(32|64|128)[IE] - that will match just one of them, exactly once.

Then the next issue: [ABCDFGJKLMNPQSTUVX]* - this group also includes the letters I and E, so they should be removed as they're already matched by the first one (and should be exclusive)

And third: the current regex requires all the Z-extensions to be in a given order when not the first (but the first one can be whichever).

I've rewritten it to be a bit simpler and work more as (I think) it's intended:

"^RV(32|64|128)[IE][ABCDFGJKLMNPQSTUVX]*((Zicsr|Zifencei|Zihintpause|Zam|Ztso|Zkne|Zknd|Zknh|Zkse|Zksh|Zkg|Zkb|Zkr|Zks|Zkn|Zbc|Zbb|Zbp|Zbm|Zbe|Zbf)(_(Zicsr|Zifencei|Zihintpause|Zam|Ztso|Zkne|Zknd|Zknh|Zkse|Zksh|Zkg|Zkb|Zkr|Zks|Zkn|Zbc|Zbb|Zbp|Zbm|Zbe|Zbf))*){,1}$"

Working example:

Negative examples (input errors which are correctly not matched):
Extra "B" after starting _Z extensions

Starting with _ before the first Z extension

Missing underscore between two consecutive Z extensions

I'll be happy to open a pull request with this new regex if you want (or you can just snip it from this issue post).
I'm already a RVI member (through my employer) if that's a concern 🙂

Custom exceptions and custom interrupts are captured within the ISA config and thus need to be removed from the platform yaml schema

Here's my understanding of how it works right now
The riscv-config checker will take the platform config and ISA(or CSR) config in YAML format, validate the format, and output YAML files with the full information. We expect this output to be used in verification, ISS config, compliance test etc. Here's my thought of the ideal integration flow: (pseudo code)

platform_config = load_platform_config(platform_yaml_file)
isa_config = load_isa_config(isa_yaml_file)

// Expect the checker to generate the validated config handle
valid, validated_isa_config, validate_platform_config = riscv_config_checker(platform_config, isa_config)

// Use the validated configure for various purposes. This could avoid each flow parsing the validated YAML file again.
if valid:
  // Generate CSR test
  gen_csr_test(validated_isa_config)
  // Generate ISS configuration
  gen_iss_config(validate_platform_config, validated_isa_config)
  ....

Please let me know your thought about this.

Ths following configuration must generate an error:

ISA: RV32IMAC
supported_xlen: [64]

Similar to #108

The "nmi" field should be optional, but is required, as can be seen in schema_platform.yaml.

Original issue: riscv-non-isa/riscv-arch-test#279

I'm trying to create ACT tests for clint and clic (ratified AIA will have the same issue). neither extension adds any instructions so does not need to be passed to the toolchain (toolchain won't recognize these instructions). but I need a way to tell riscof to select these tests. Is there a way to pass this info to either isa yaml or platform yaml so that Smclic, Smclint tests will be selected without passing that to the toolchain?

The clint tests I developed also use msip (software interrupts) but riscof generated an error when I included that in the platform yaml. riscof only currently expects mtime?

need to perform the following checks:

• for every pmpcfg implemented there is a corresponding pmpaddr defined and vice-versa
• The reset values of the pmpaddre* match the value indicated in the pmp_granulatrity field

The tests for subextension inclusion are outdated and not consistent with the crypto and bitmanip extensions ratified last November. In the file there are references to "K", "Zkg" or "Zbp", which are not present under those names in the final ratified extensions.

The following inputs in the legal field must cause a failure:

mhpmevent3[63:0] bitmask [0xFC]

Per table 3.2 of the privileged architecture (both the ratified version and the 2020/01/25 draft), the “G” bit in misa is reserved. The SchemaValidator allows the "G" bit to be set.

I wonder if new proposals like this new instruction should be added at this early stage to riscv-config
it is not in the ratified specs
and there seems no place from riscv.org that I can see its definition.
is it a real instruction or pseudo
will this instruction being in the device yaml affect anything - like selection/config of tests, test generators, simulators?
why has this instruction been singled out to be added?
what about all other proposed extensions.

thanks for any clarifications...

I keep getting error as hart_ids is not found while running riscv_config

Is there an example input ISA which takes into account hart_id ? for simplicity, lets assume single thread with hart id=0.
When I try to view https://github.com/riscv/riscv_config/blob/master/examples/template_isa.yaml
it does not work

Hi!

the latest draft of the riscv spec defines that misa.X be set if there are any non-standard extensions present. misa is only generated using the given ISA string and never actually mentioned in a "isa.yaml" - hence the default reset "setter" may need to change to accomodate custom extensions of the format _X[a-zA-Z0-9] in the isa string.

The online documentation at Read The Docs lists the tool name as "riscv_config" not "riscv-config", i.e. uses and underscore between the words instead of a hyphen.

While this is not a major error, it would be good to cleanup to avoid confusion.

Table 3.2 of the privileged architecture (both the ratified version and the 2020/01/25 draft) states a value of 0 can be returned to indicate misa register is not implemented. The way to represent this would be to set both “default” and “bitmask” fields to 0, along with the “implemented” field to “false”. The SchemaValidator doesn’t allow for this and errors out based on the three way XOR of default, bitmask and ISA string.

As near as I can find, the documentation does not contain any details as to how the tell if the input YAML files have been validated. The "Usage Examples" section shows output from the tool, but does not mention the error message "No errors..."

Some questions we might want to answer:

• Is the error the only indication of success or are there other, better ways to tell?
• Is validation by HART and thus this error must be checked for every HART?
• What happens in a multi-HART situation where HARTs 0, 2 and 3 are fine, 1 is bad? Does the tool complete and provide all results or end at first failure?
• What are common errors messages?
• Given an error, what is the common way to correct/fix them?
• What is the approach for handling multiple errors? Should the first one be corrected and tool re-run or should you attempt to fix them all?
• Is there a way to get more information for an error, such as enabling verbose mode or something?

This is not a critical gap but would be extremely nice to address given that this tool will be called out for explicit use in the "RISC-V Compatible Trademark Permission Process" described on the RISC-V Branding Guidelines & Materials web page.

While calling checker.check_specs() through an API call log is printed by default. It should be an optional feature.

isa_yaml with RV64IMAFDCSU gives isa_checked.yaml with the following registers as accessible.

• VSSTATUS
• VSIE
• VSIP
• VSSCRATCH
• VSEPC
• VSTVAL
• VSCAUSE
• VSTVEC
• VSATP

It can be seen here: https://github.com/riscv-software-src/riscv-config/blob/master/examples/rv64i_isa_checked.yaml#L5067

Shouldn't these registers depend on H-extension?

• Add --version option to arguments to print version and exit when specified.
• Print help and exit when no options/arguments are specified.

In the ISA schema, support needs to be added for the Zfinx extension.

The Sail model has added support for Zfinx. I need to enable it based on
the RISC-V config file.

the following fields need to be added:

• granularity of pmps
• priv_spec_implemented
• pmpaddr csrs need to be added

Context: Sail configuration: The Sail model has a command line switch, -P (pmp support enable),
that needs to be replaced with a RISCV-Config setting.

Per @neelgala , this should be done by looking at /hart0/pmpaddr0/rv32/accessible. I have extended
the check in the Sail model to:

rv_enable_pmp =
(
(rv_cfg_bool_c("/hart0/pmpaddr0/rv32/accessible") ) ||
(rv_cfg_bool_c("/hart0/pmpaddr0/rv64/accessible") )
)
;

However, the config validator should check for the condition that if pmpaddr0/accessible == false
then all other pmpaddrN/accessible are false as well.

following checks need to be done on mhpmcounters:

• each mhpmcounter has the corresponding mhpmevent declared and vice-versa

This issue is a parallel issue to: riscv/sail-riscv#192

Following is the text of that issue:

Reference: Priv Spec., Table 3.7 "Synchronous exception priority in decreasing priority order."

The priority of a "load/store/AMO address misaligned" exception can be made optionally
higher or lower than other memory access exceptions. The model needs to be made
configurable to handle this option.

This option will need to be added to the RISCV-Config structure.

The solution to this problem should use the "new" YAML configuration methods that have been introduced to the
model (see PR riscv/sail-riscv#175).

With respect to the misa register, the SchemaValidator doesn't allow for setting a default value of "1" for a writable bit. That conflicts with what section 3.1 suggests:

At reset, the Extensions field should contain the maximal set of supported extensions

For example, if an implementation supports the "M" extension but wants to keep it optional for M mode to enable it, the corresponding bit would need to be set to 1 in both the default and bitmask fields. That'd cause SchemaValidator to complain based on the three-way XOR between ISA string, default value and bitmask value of "Extensions" field of misa register.

Rather than a three-way XOR, there should be these separate checks:
The bitmask value must be a subset of what is specified in the ISA string since only implemented extensions can be enabled/disabled.
The default value must be a subset of what is specified in the ISA string since no bit is allowed to be set unless the extension is implemented.
A bitwise OR of the bitmask value and the default value must equal the value specified in the ISA string since each bit must either be hardwired to 1 (bitmask=0 and default=1) or it must be writable (bitmask=1 and default=don't care).
The default value should (not must) be equivalent to what is specified in the ISA string. Since this is not a strict requirement, perhaps there is nothing to check.

The spec mentions the following constraint on the misa extensions:

Writing misa may increase IALIGN, e.g., by disabling the “C” extension. If an instruction that
would write misa increases IALIGN, and the subsequent instruction’s address is not IALIGN-bit
aligned, the write to misa is suppressed, leaving misa unchanged.

This means that the warl behavior of any csr field can also depend on a few additional states in the hardware. It might be useful to allow for such dependencies to be specified in the warl function itself and add misa checks to ensure that the above is satisfied if C extension can be disabled at run-time. One might argue that this is a very specific scenario which depends largely on the program flow, but I think this should be specified in the warl function. A list of possible fields which can be allowed are:

• IALIGN
• XLEN(incase misa.mxl is not implemented and the implementation has a non-standard way of figuring out xlen. Although I am not sure how SAIL will emulate this behavior).

Currently only support pyyaml==5.2

Context: RISCV Sail model: configuring model with RISCV-Config

The RISCV Sail model has a command line switch, -d (enable-dirty-update), that
needs to be a part of RISCV-Config.

It's a boolean setting.

I have added it to a sample isa.yaml file as: /hart0/pte_dirty_update_enable
I've done this for testing purposes.

If there is another configuration setting that I should use, please let me know.

Bill Mc.

Table 3.2 of the privileged architecture (both the ratified version and the 2020/01/25 draft) says that "H" bit indicates the Hypervisor extension. SchemaValidator doesn't allow that bit to be set even though it allows bits to be set that are associated with other non-ratified extensions.

Migration to Github (from GitLab) is going to require the following:

• change name from rifle to riscv-config in all relevant files

• create pypi for riscv-config and delete only rifle

• shift to travis-yaml for version update and release

• link readthedocs to this repo

• LICENSE updates required?

According to the Spec mtval is a WARL field. However, a platform has a luxury to completely specify which exceptions must set mtval informatively and which may unconditionally set it to zero. To capture this the following is proposed:

1. Extend CSR template with a platform field:
   We add a boolean field platform to each csr which indicates if the platform-yaml
   has more information on the same node. The platform yaml should also contain a node with the same csr-name. The node in the isa-yaml will define the set of all legal/illegal values that mtval can take

2. Adding mtval node in platform-yaml:
   the mtval field in the platform yaml could be :

mtval:
  implemented: True
  behaviour:
    - [0, [0x00000000:0xFFFFFFFF] , "Address that was misaligned"]
    - [2, [0x00000000, 0x0000FFFF] , "lower 16-bits of Instruction that was illegal"]

Each entry under behaviour is a 3 element tuple. The first element is cause value, the second defines the set of legal values and the last element is the description.
Cause values missing in the behavior list are assumed to write "0" to mtval by default.

On this page: https://github.com/riscv/riscv-config/blob/master/docs/source/overview.rst
Details of this input file can be found here : :ref:isa_yaml_spec.
The embedded link points back to this page.

Validated string should be presented as a suggestion along with an error message.
riscv-software-src/riscof#67 (comment)
rv32imcfzk_xfoo -> RV32IMCF_Zicsr_Zk
RV32I_M_F_Zicsr -> RV32IMFZicsr
RV32I2p0M2F_Zicsr -> RV32IMFZicsr

Invalid ISA strings (i.e. wrong order) may be also sensibly fixed.
E.g. rv64gc_zam_zifencei -> RV64IMAFDCZicsr_Zifencei_Zam

https://github.com/riscv/riscv-config/blob/faab5e604cf0688f30437e1d92657fe37e5cdd99/riscv_config/schemaValidator.py#L84

The ISA string is checked for the letter 'U', but according to the description in the schema it should contain the extensions according to the user spec. In unprivileged spec version 20191213 section 27.11 'U' is not named as an extension.

I understand that this is reused to check the MISA register, but maybe the schema needs to be updated or 'U' removed?