It would be very useful to have a description of the respective roles of MTVEC and MTVT prior to this section.
Specifically, that in CLIC mode mtvec.base specifies the address of a dispatcher for both synchronous exceptions and software-vectorable interrupts (software vectorable interrupts are identified using mnxti).
The CLIC vector table base is specified in MTVT. This table defines per-interrupt handler addresses - these handlers are invoked by one of CLIC selective hardware vectoring (if present and enabled), or software vectoring by the dispatcher at the PC specified in mtvec.base with handler addresses provided by accesses to the CLIC mnxti register.
[I read the sentence "In CLIC mode, synchronous exception traps always jump to NBASE" puzzling because nothing is said about interrupts].
Taking this a step further, it would be valuable to implementors to have some indication of how the features described in the spec are intended to be used, prior to launching into their descriptions. I appreciate this is information that would normally be found in a requirements document... however my experience in implementing to this spec is that a lot of time was spent cross-correlating the features descriptions and examples so as to guess at the intended use model(s).
Section 3.8.4 New mtvec CSR mode for CLIC
It would be very useful to have a description of the respective roles of MTVEC and MTVT prior to this section.
Specifically, that in CLIC mode mtvec.base specifies the address of a dispatcher for both synchronous exceptions and software-vectorable interrupts (software vectorable interrupts are identified using mnxti).
The CLIC vector table base is specified in MTVT. This table defines per-interrupt handler addresses - these handlers are invoked by one of CLIC selective hardware vectoring (if present and enabled), or software vectoring by the dispatcher at the PC specified in mtvec.base with handler addresses provided by accesses to the CLIC mnxti register.
[I read the sentence "In CLIC mode, synchronous exception traps always jump to NBASE" puzzling because nothing is said about interrupts].
Taking this a step further, it would be valuable to implementors to have some indication of how the features described in the spec are intended to be used, prior to launching into their descriptions. I appreciate this is information that would normally be found in a requirements document... however my experience in implementing to this spec is that a lot of time was spent cross-correlating the features descriptions and examples so as to guess at the intended use model(s).