Missing a catchy terminology for the selection priority

[christian-herber-nxp]

CLIC defines level and priority (seemingly equivalent to Arm group priority and sub priority). Arm defines the exception priority to be the concatenation of group priority and sub priority.

In CLIC, there is not such term. I think it would be useful to have a term that refers to the {level | priority}, or even {level | priority | id}.

I do not have a good term to offer, but I think the spec would benefit from a clear way to refer to this.

[christian-herber-nxp]

I have been thinking on this. I think level is generally not a good terminology for something that is used as a priority. I can understand that the state of the hart would be described as interrupt level. As for the terminology, i would proposed the following:

1. Interrupt level: this can be kept as describing the state of a hart
2. What is currently called interrupt priority: This is misleading, and should be changed to Subpriority in line with established terminology used in the industry.
3. New definition of interrupt priority: Introduce a new definition of interrupt priority, which is interrupt_priority[i] = {clicintattr[i].mode | clicintctl[i] | i} = {clicintattr[i].mode | interrupt_level[i] | subpriority[i] | i}

This will allow accurately making statements like the highest priority interrupt is being selected without saying something completely different than intended.

From what I can see, this would be a change that is not affecting any implementation/register definition, but just the descriptive text.

[james-ball-qualcomm]

I'm ramping up on the CLIC spec and was confused by the use of "level" and "priority". These can be synonyms since "level" also prioritizes which interrupt is selected. I understand that "level" is used for prioritization and preemption whereas "priority" is only prioritization between interrupts at the same "level". As Christian states, the hart is aware of "level" but not "priority" (priority is only a concept inside the CLIC). The selection of interrupts within a "level" is determined by both "priority" and "interrupt number" where "priority" is programmable and has higher precedence and "interrupt number" is hardwired in an implementation. I'm going to think about names and how to present this information in the CLIC spec.

[james-ball-qualcomm]

BTW, are we clear that there are strong use cases requiring "priority" for the CLIC? Or are we doing this because competing products offer this?

[james-ball-qualcomm]

Here's what I've come with for "level":

• Use an acronym that is more descriptive than "level" and makes it clear that "level" is known by the hart
• Maybe also make it clear that "level" is programmable at run-time
• Examples: HIL (Hart Interrupt Level) or PHIL (Programmable Hart Interrupt Level)
• Both of the above are easy to pronounce
• Say "level" instead of the acronym when the context is clear

And now for "priority":

• Priority seems like too generic a term.
• Make it clear that it orders interrupts within a level and maybe also that it is programmable at run-time (vs. the interrupt ID which is hardwired).
• I'd like the CLIC spec to have clear language around topics like "Prioritization of Interrupts" (i.e., "{level | priority | id"}) or the concept of an "interrupt's priority" (also currently "{level | priority | id"}).
• We need another word for "priority" so I'm recommending "rank" and acronyms using "rank"
• Examples: RWL (Rank Within Level), PLR (Programmable Level Rank), PCIR (Programmable CLIC Interrupt Rank)
• Hard to pronounce so maybe something better could be invented
• Say "rank" instead of the acronym when context is clear

Finally, what to call combinations of the 3 prioritization values:

• "level | priority | id" call it "full interrupt priority"
• "level | priority" call it "programmable interrupt priority"
• "priority | id" call it "CLIC interrupt priority"

[christian-herber-nxp]

BTW, are we clear that there are strong use cases requiring "priority" for the CLIC? Or are we doing this because competing products offer this?

I would start by saying the feature is more or less free to implement. For selection of next interrupt, you always use the full clicintctl[i], and when signalling an interrupt to the hart you mask out the prio bits, just sending the level value.

The feature could be useful to limit the stack size, and improve interrupt throughput by chaining rather than constantly preempting. This is just what I can come up with on the spot. Stack size would seem the most obvious to me. If you have 500 interrupts at different levels that can preempt each other, this can really add up.

[james-ball-qualcomm]

This makes sense. Having run-time configuration of how to allocate the available bits between level and priority means an implementation can limit the max stack size since in theory you need enough stack for every level since they can preempt each other.

I see that interrupt level shows up in several places in the CLIC spec:

• clicintctl[i] CSRs (level and/or priority for each interrupt)
• mintstatus CSR (current hart interrupt level for each privilege mode)
• mintthresh CSR (temporary threshold interrupt level)
• mcause.mpil CSR (previous hart interrupt level before interrupt triggered a trap)
• s* CSRs of some of the above

My suggestion is to say "privilege mode" instead of "privilege level" in the CLIC spec so every time the word "level" is used it means interrupt level.

As for priority, that has to go since it is too confusing as previously discussed. I don't think sub-priority is all that useful given that we use the term "level" and not "priority". So, how about "rank" instead of priority. Then we can use priority when talking about combinations of level, rank, and ID. Namely:

• "level | rank | ID" call it "full interrupt priority"
• "level | rank" call it "programmable interrupt priority"
• "rank | ID" call it "CLIC interrupt priority"