All trap handlers?

[Silabs-ArjanB]

https://github.com/riscv-verification/RVVI/tree/main/RVVI-VLG states:

intr

When this signal is true, it indicates that this retired instruction is the first instruction which is part of a trap handler.

Any trap handler, so not only regular interrupts, but also NMI, exceptions, debug entry, debug exception entry?

[eroom1966]

This was a historical artifact of the ancestral RVFI definition For the Reference Model Imperas do not use this signal, it is not required. That is not to say that another client from another user/vendor of the RVVI interface will not use this signal, such as a coverage or logging plugin - or anything not yet considered

[Silabs-ArjanB]

Are you sure (this seems a copy/paste from the Halt issue text). If your above remark is accuratem can this signal be removed or renamed then or at least a note be added that this signal is not normally used?

[eroom1966]

Its a partial cop/paste - as the origin of RVFI is the same. Why do you want this signal removed ? Do you not think that there are tools which may be developed that will find this useful ? As I stated earlier in order to communicate with the Imperas Reference model - this is not required, but may be required by other tools.

From the historical RVFI spec

rvfi_intr must be set for the first instruction that is part of a trap handler, i.e. an instruction that has a rvfi_pc_rdata that does not match the rvfi_pc_wdata of the previous instruction.

[Silabs-ArjanB]

We are talking about RVVI here, not RVFI. If RVVI does not use the 'intr' signal then it should be removed to avoid confusion.

The fact that RVFI documentation is not adequate does not mean that the RVVI documentation should be equally inadequate. We have internally (and in the CV32E40X/CV32E40S user manuals) improved on the semantics/documentation of the RVFI signals and we expect clean definitions of RVVI as well.

[eroom1966]

Hi Arjan, the purpose of RVVI is for the core to provide information to downstream tools one of those downstream tools is the ImperasDV Reference Model for performing state comparison of a DUT

So when you say

If RVVI does not use the 'intr' signal then it should be removed to avoid confusion

I think what you mean to say is

If the ImperasDV Reference Model does not use the 'intr' signal then it should be removed to avoid confusion

The idea behind RVVI is to create a method to plug downstream tools which can monitor execution, the ImperasDV Reference Model, is only one potential user of this data, and in this respect it does not require this signal. This does not preclude other consumers of the RVVI data benefiting from this notifier

Are you saying that you cannot envisage any tools (ignoring the ImperasDV Reference Model) which would benefit from having been provided this notifier, if so - I would agree we should remove it.

[Silabs-ArjanB]

Hi Lee, I agree it can be kept if it might be useful for other (i.e. other than ImperasDV reference model) downstream tools. Still I think that 'trap handler' needs to be defined more explicitly (stating what trap handlers are included/excluded). I also think it would be good to document that the ImperasDV Reference Model does not use this signal (but maybe it is more logical to document that in the reference model documentation itself or even better in the documentation related to how the reference model will get integrated in core-v-verif).

[eroom1966]

I also think it would be good to document that the ImperasDV Reference Model does not use this signal (but maybe it is more logical to document that in the reference model documentation itself or even better in the documentation related to how the reference model will get integrated in core-v-verif).

Agreed, and this is documented as part of the ImperasDV integrators guide. this describes the necessary data items that must be present and populated in the RVVI interface, in order that the ImperasDV Reference Model has sufficient information