Questions on Release 0.9

[hirooih]

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 attached includes some other typo things.

clic.patch