Parameterization of number of IRQ levels

[christian-herber-nxp]

I do not see a top level parameter to specify the number of interrupt levels. This would be important, as most designs will only need a few, not 256. I would expect between 3 and 5 level bits to be used, with the rest fixed to one.
The CLIC specification defines a standard parameter, but that definition is currently being reworked. Thus, I would suggest waiting on riscv/riscv-fast-interrupt#331 to complete

[alex96295]

Hello,

We currently allow for deciding the number of interrupt levels at runtime, through the mcliccfg.xnlbits register field, which encodes the number of interrupt levels. This would ideally be done at platform init stage.

The maximum number of bits to encode both level and priority is set by an elaboration-time parameter (INTCTLBITS), and the HW checks that mcliccfg.xnlbits < INTCTLBITS, otherwise saturates to that value.

I see there are some optional parameters in the draft specs for the number of levels (CLICLEVELS and CLICCFGLBITS), but I would also wait for clearer specs from the RISC-V fast interrupt TG in the PR you mentioned above

[christian-herber-nxp]

ah ok I missed the connection between INTCTLBITS and the level. This does bring me to a different issue. The spec currently states:

Only 0 or 8 level bits are currently supported, with other values currently reserved.

According to this, any other value should trap, which I guess it doesn't here. To me thats quite fine, but its something to consider.

If you want to comply, you have the choice of supporting either levels or prios. Given that preemption is essential for a fast interrupt controller, and levels are the means of preemption within a privilege level. Therefore I would almost certainly assume that you will only make use of the levels and not the priorities.

Nevertheless, I think it is a good feature to have this somewhat controllable.

I could however imagine that a levels only solution would save some logic. If thats the case, it might make sense to add a parameter for that. I am not sure if that would be considered standard compliant either though.