The following are what are unclear from reading the specifications. I hope this helps.
Chapter 7. suclic U-mode CLIC extension
Is N-extension still alive? From RISC-V Spec:
Preface to Version 20211203
...
Removed the N extension.
It was my understanding that the N extension was removed from the candidate for the extended specification.
9.3. CLICINTCTL Parameters
Only 0 or 8 level bits are currently supported, with other values currently reserved.
0 level bit cannot support the horizontal interrupt preemption which is the most important feature of CLIC. I doubt it is worth supporting.
8 level bits cannot support the interrupt priority. I guess this might be a patent issue. When will we be able to support other settings?
... xCLICINTCTLVALUES would be the set [0-255].
"[0-255]" should be "[1-255]" according to the table on the next page.
... when clicintattr[i].mode bits 7:4 are all 1s otherwise s-mode.
According to "5.4. CLIC Interrupt Attribute (clicintattr)", clicintattr[i].mode is assigned to bits "7:6" and "11" means Machine mode. I don't understand what this paragraph means.
with the lower unimplemented bits treated as hardwired to 1.
The lower unimplemented bits of clicintctl[i] should be read as 1s by a CSR instruction?
From the last paragraph:
... For example, when nmbits is 0, ... to clicintctl[i] registers.
I think this sentence should be moved to "10.1.1. CLIC Configuration (xcliccfg registers)".
9.4. Additional CLIC Parameters
CLICLEVELS 2-256
"2-256" should be "1-256" if the "0 level bit" is supported.
CLICMAXID 12-4095
From where the number "12" comes? The max ID is 2 in the example on 17.4. Only one interrupt does not require CLIC features. "1" may be the minimum number.
INTTHRESHBITS 1-8
All other parameters are prefixed by "CLIC". Is it intentional that only this parameter is not prefixed by "CLIC"?
10.1.2. Specifying Interrupt Privilege Mode
I have no idea why cliccfg.nmbits exists.
For example In the following case (and M/U-mode systems without the suclic extension) we can hardware the clicintattr[i].mode to "11".
For example, in M-mode-only systems, only M-mode exists so we do not need any extra bit to represent the supported privilege-modes. In this case, no physically implemented bits are needed in the clicintattr.mode and thus cliccfg.nmbits is 0 (i.e., cliccfg.nmbits can be hardwired to 0).
The following are what are unclear from reading the specifications. I hope this helps.
Chapter 7. suclic U-mode CLIC extension
Is N-extension still alive? From RISC-V Spec:
It was my understanding that the N extension was removed from the candidate for the extended specification.
9.3. CLICINTCTL Parameters
0 level bit cannot support the horizontal interrupt preemption which is the most important feature of CLIC. I doubt it is worth supporting.
8 level bits cannot support the interrupt priority. I guess this might be a patent issue. When will we be able to support other settings?
"[0-255]" should be "[1-255]" according to the table on the next page.
According to "5.4. CLIC Interrupt Attribute (clicintattr)",
clicintattr[i].modeis assigned to bits "7:6" and "11" means Machine mode. I don't understand what this paragraph means.The lower unimplemented bits of
clicintctl[i]should be read as 1s by a CSR instruction?From the last paragraph:
I think this sentence should be moved to "10.1.1. CLIC Configuration (xcliccfg registers)".
9.4. Additional CLIC Parameters
"2-256" should be "1-256" if the "0 level bit" is supported.
From where the number "12" comes? The max ID is 2 in the example on 17.4. Only one interrupt does not require CLIC features. "1" may be the minimum number.
All other parameters are prefixed by "CLIC". Is it intentional that only this parameter is not prefixed by "CLIC"?
10.1.2. Specifying Interrupt Privilege Mode
I have no idea why
cliccfg.nmbitsexists. For example In the following case (and M/U-mode systems without the suclic extension) we can hardware theclicintattr[i].modeto "11".The attached includes some other typo things.
clic.patch