Additional parameters

[christian-herber-nxp]

I am missing a parameter to define the behavior upon decoding a reserved instruction. This is UNSPECIFIED in the isa manual.
Now, while most if not all implementations will trap on reserved instructions, it is legal to do something else (including implementing custom instructions).

Another parameter is the NMI mtval value. I am not sure if that is intentionally, as NMI is currently not in the unified-db it seems.

Finally, the cache block management has a number of UNSPECIFIED behaviors, that should be translated into parameters.

[james-ball-qualcomm]

This is exciting to see community members using riscv-unified-db.

Christian, are you able to make specific proposals to solve these issues? For example, creating proposals for parameter names, their allowed values, which extension(s) cause the parameter to be defined, and a few sentence description of the parameter?

What is the extension name for NMI? I assume you are referring to the restartable (or something like that) NMI extension. Whatever the name, it can definitely be added to the database by creating a YAML file.

[dhower-qc]

For reserved instructions, that would be captured by this parameter:

    TRAP_ON_UNIMPLEMENTED_INSTRUCTION:
      description: |
        When true, fetching an unimplemented instruction will cause an `IllegalInstruction` exception.

        When false, fetching an unimplemented instruction is `unpredictable`.
      schema:
        type: boolean

For NMI, you are correct. That is not in the database yet.

Cache block management, the only parameter currently associated with it is the cache block size. Do you have a list of other parameters we need to add?

[christian-herber-nxp]

Christian, are you able to make specific proposals to solve these issues? For example, creating proposals for parameter names, their allowed values, which extension(s) cause the parameter to be defined, and a few sentence description of the parameter?

I will try my best.

What is the extension name for NMI? I assume you are referring to the restartable (or something like that) NMI extension. Whatever the name, it can definitely be added to the database by creating a YAML file.

There is no extension name for NMI (similar as PMP). The resumable interrupts are Smrnmi. So it seems obvious to call the NMI pseudo extension Smnmi.

For reserved instructions, that would be captured by this parameter:

    TRAP_ON_UNIMPLEMENTED_INSTRUCTION:
      description: |
        When true, fetching an unimplemented instruction will cause an `IllegalInstruction` exception.

        When false, fetching an unimplemented instruction is `unpredictable`.
      schema:
        type: boolean

I see. This might be something else however. The behavior I mentioned is TRAP_ON_RESERVED_INSTRUCTION. This is defined in RV32/64I.
I do not know how you define unimplemented. E.g. if a custom instruction was implemented in the reserved space, it is implemented.
For CRD, I think it is acceptable to have TRAP_ON_RESERVED_INSTRUCTION out of scope.

For NMI, you are correct. That is not in the database yet.

Cache block management, the only parameter currently associated with it is the cache block size. Do you have a list of other parameters we need to add?

If you search the instruction manual for the UNSPECIFIED keyword in the CBM section, this will give you all the options. It's a bit convoluted and depending on PMP/PMA etc.

[dhower-qc]

The behavior I mentioned is TRAP_ON_RESERVED_INSTRUCTION. This is defined in RV32/64I.
I do not know how you define unimplemented. E.g. if a custom instruction was implemented in the reserved space, it is implemented.
For CRD, I think it is acceptable to have TRAP_ON_RESERVED_INSTRUCTION out of scope.

I see. I think this is pointing to a need for two parameters, one for standard RESERVED encodings and one for UNIMPLEMENTED. Initially, the DB was written assuming it knows about every implemented instruction, even custom (you can provide an overlay for such configurations). But, that has clearly shifted as we are now trying to cover things like profiles/CRDs that are only paritally specified.