behavior of NMI in CLIC mode

[eroom1966]

@Silabs-ArjanB @silabs-hfegran Can I ask how is NMI handled in CLIC mode ? I see nothing that documents this, it appears as though it is routed through the CLIC interface somehow

[Silabs-ArjanB]

Hi @eroom1966 It is described at https://docs.openhwgroup.org/projects/cv32e40s-user-manual/en/latest/exceptions_interrupts.html#non-maskable-interrupts. Anyhting specific you are wondering about that is not documented there?

[eroom1966]

This does not describe how mcause is updated in CLIC mode.

[eroom1966]

how are mcause, mintstatus updated when an NMI interupt is taken in CLIC mode This does not appear to be specified

[Silabs-ArjanB]

Is the following not clear enough?

[eroom1966]

I am searching for this section, is this part of 0.8.0, or is this later ? (update, this is not in the 0.8.0 spec)

BTW, I think minsttatus is a typo ?

[Silabs-ArjanB]

@eroom1966 I will correct the typo. This is the most recent user manual indeed (link provided in my initial response). The mintstatus remark was added because of a recent clarification to the RISC-V CLIC specification.

[eroom1966]

(@silabs-hfegran copy) I just want to confirm that upon an NMI being taken, mintstatus should NOT change value, as you have described above.

We are observing that mintstatus is in fact cleared to zero by the RTL when taking an NMI.

Is this incorrect behavior in the RTL, or incorrect in the spec?

Can the specification be made more specific about the behavior of NMI in CLIC and non-CLIC modes? Currently, it just says:

Non Maskable Interrupts (NMIs) update mepc, mcause and mstatus similar to regular interrupts.

We have seen that when an NMI is taken in CLIC mode, mcause is updated in a different way to non-CLIC mode (the CLIC-mode mcause.pil field is modified as if this was a CLIC interrupt). Because NMI behavior is custom, I think the specification should explicitly state what happens and precisely what state is modified in all modes.

[Silabs-ArjanB]

We are observing that mintstatus is in fact cleared to zero by the RTL when taking an NMI. Is this incorrect behavior in the RTL, or incorrect in the spec?

That would be incorrect RTL. I thought we had fixed that 1-2 weeks ago. Are you on a recent version of the RTL?

I would expect that mcause.mpil is just updated with the previous interrupt level as you (or at least I) would expect. We will mention that in the user manual.

[eroom1966]

latest under core-v-verif I am running commit d8e7e67d1570b610a8c668e103d1204c71bfefb0 (HEAD -> cv32e40s/dev, origin/cv32e40s/dev) Merge: c4a58c25 6c7c3bf1 Author: Henrik Fegran henrik.fegran@silabs.com Date: Wed Mar 29 09:26:36 2023 +0200

Merge pull request #1755 from silabs-hfegran/dev_hf_missing_no_bitmanip_zcmt_hotfix

Hotfix: Fixed missing zcmt for no_bitmanip cfg

[eroom1966]

Looks like this is the RTL under use in core-v-verif

commit a9c6c716e4d1a219775b968bafec239f1190ac16 (HEAD) Merge: 189417e5 44a9ae66 Author: Arjan Bink 40633348+Silabs-ArjanB@users.noreply.github.com Date: Thu Feb 23 11:18:33 2023 +0100

Merge pull request #409 from silabs-oysteink/silabs-oysteink_merge-w8-2

Merge from CV32E40X

[Silabs-ArjanB]

Hi @eroom1966 That RTL still had the bug (i.e. clearing mintstatus). Current RTL should not affect mintstatus due to NMIs.

[Silabs-ArjanB]

Hi @eroom1966 Can this issue be closed now? If not, what info is missing?

[Silabs-ArjanB]

Hi @eroom1966 Closing this issue due to lack of response. If there are still questions related to this please open a new issue.