Clarification of roles of MTVEC and MTVT

[mark-honman]

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).

[mark-honman]

Notes:

CLIC introduces a new interrupt vector table with two alternative hardware-assisted access methods, which can be selected on a per-interrupt basis. When the CLIC is enabled interrupts and exceptions normally cause a transfer of control to trap dispatcher software starting at the address specified in mtvec.base. If the trap is an exception, an exception handler is called - otherwise interrupts are dispatched with hardware assistance implemented in the MNXTI CSR. Accesses to MNXTI identify the address of the CLIC vector table entry containing a function pointer to the handler for the most important interrupt that is currently available.
However if hardware vectoring is enabled for an interrupt, the trap dispatcher is bypassed and control transfers directly to the start of of the handler pointed to by that interrupt's CLIC vector table entry.

Could say in the mtvec section, CLIC introduces a layer of hardware translation from the occurrence of an interrupt to transfer of control to an interrupt specific handler. This translation produces the address of a memory location in the CLIC vector table.
This can work in one of two ways, on a per-interrupt basis:
a. Software Vectored - initially, control is transferred a single common interrupt dispatcher which then uses MNXTI to determine the location in the CLIC vector table containing the function pointer of the interrupt-specific handler for the most important available interrupt. The interrupt dispatcher may need to handle synchronous traps, and may be given responsibility for saving and restoring the interrupted context.
b. Hardware Vectored - there is no common interrupt dispatcher; if selective hardware vectoring is enabled for an interrupt, hardware determines the location of the CLIC vector table entry containing the function pointer and transfers control to that function.

The CLIC vector table is used for both software and hardware vectored modes. Note that a CLINT interrupt dispatcher can use the same table of function pointers to dispatch interrupts, there is no need to have separate dispatch tables for CLINT direct and CLIC modes; however CLINT vectored mode uses an incompatible vector table format.

Need to define the term VTBASE prior to use.
Move info about table addresses from 5.2.1 to a more general section?

Make a flowchart to describe software interrupt dispatcher's view of CLIC in non SHV mode.