XCASUE with CLIC option

[panda1628]

In RISC-V Core-Local Interrupt Controller
(CLIC) Version 0.9-draft-20210406,

4.7. Changes to xcause CSRs

In both original basic and CLIC modes, the xcause CSR is written at the time an
interrupt or synchronous trap is taken, recording the reason for the interrupt or trap.
For CLIC mode, xcause is also extended to record more information about the
interrupted context, which is used to reduce the overhead to save and restore that
context for an xret instruction. CLIC mode xcause also adds state to record
progress through the trap handling process.

Is there any option for CLIC in the compliance test?
MCAUSE bit 29:27 will not be the same withOUT it

Thanks in advance for any information

[allenjbaum]

We have not implemented tests for interrupts in the arch-tests yet (or any other priv-mode tests). The fast-interrupt github repo has some, though I haven't looked at them in detail. Because there is no way to force CLINT external interrupts to occur programmatically, we don't know which PC will be saved - which breaks the current signature framework. We are currently discussing an API for vendors to use to cause an external interrupt , and changes to the comparison algorithm that will enable it to work Vendors will be required to supply a driver that conforms to the API and which will cause interrupt wires to be asserted or deasserted. CLIC is much more difficult because we can't even guarantee which external interrupts exist - it is implementation defined - so a lot of infrastructure needs to be defined. This would require tests that can be configured for any vendor-defined implementation (defined by the YAML file provided to the frameework) - and implementing CLIC in Sail as a reference implementation.

…

On Wed, Jun 30, 2021 at 10:44 PM panda1628 ***@***.***> wrote: In RISC-V Core-Local Interrupt Controller (CLIC) Version 0.9-draft-20210406, 4.7. Changes to xcause CSRs In both original basic and CLIC modes, the xcause CSR is written at the time an interrupt or synchronous trap is taken, recording the reason for the interrupt or trap. For CLIC mode, xcause is also extended to record more information about the interrupted context, which is used to reduce the overhead to save and restore that context for an xret instruction. CLIC mode xcause also adds state to record progress through the trap handling process. [image: Screenshot 2021-06-30 223611] <https://user-images.githubusercontent.com/73319136/124071064-ad238a80-d9f3-11eb-9e46-33016250fc5c.png> Is there any option for CLIC in the compliance test? MCAUSE bit 29:27 will not be the same withOUT it Thanks in advance for any information — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#194>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRJYEMZ3JDCX2CYXQTTVP6CLANCNFSM47TX4EKQ> .

[panda1628]

MCAUSE bits 29-28, 27, 23-16
CLINT defines those bits as zero and CLIC defines them as mpp, mpie and mpil

The current compliance test expects them as zero.
If a DUT has implemented CLIC, then MCAUSE will not match.

[allenjbaum]

which tests are testing interrupts of any type? IF they aren't in the github.com/riscv/riscv-arch-test/riscv-test-suite/ repo - then they aren't our tests. But - if they were - We need different tests for interrupts (as opposed to exceptions) for CLIC vs. CLINT, or at least different reference signatures IT is actually the responsibility of the TG that has proposed the extension to write those tests, and generate the reference signature. Even then it will take a bit of effort to have the existing framework select those tests over any (hypothetical) existing tests. This will become much easier when we transition to the next version of the framework, which uses a YAML description of the implementation to select the tests. But: that also requires the reference model (Sail) to have CLIC support - also the responsibility of the TG...

…

On Fri, Jul 2, 2021 at 10:11 AM panda1628 ***@***.***> wrote: MCAUSE bits 29-28, 27, 23-16 CLINT defines those bits as zero and CLIC defines them as mpp, mpie and mpil The current compliance test expects them as zero. If a DUT has implemented CLIC, then MCAUSE will not match. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJRMQKVZSRATD7RGQHDTVXXKNANCNFSM47TX4EKQ> .

[panda1628]

In riscv-arch-test/riscv-test-env/p/riscv_test.h

trap_vector:
/* test whether the test came from pass/fail */
addi t0, zero, 13;
csrr t5, mcause;
li t6, CAUSE_USER_ECALL;
beq t5, t6, write_tohost;
li t6, CAUSE_SUPERVISOR_ECALL;
beq t5, t6, write_tohost;
li t6, CAUSE_MACHINE_ECALL;
beq t5, t6, write_tohost; \

The upper bits will not match.
Can we mask off bits 29-28, 27, 23-16 for the comparison? (beq)

[allenjbaum]

There should be no test that will cause a transfer to the label "trap vector" because we no longer have self testing tests. You'll notice that this is inside the macro RVTEST_CODE_BEGIN_OLD which exists for models that aren't using spec conforming tests that load a standard trap handler In any case - the entire test environment directory will be deprecated after we transition to riscof, v3 of the framework, and so this is in the "will not fix" category.

…

On Fri, Jul 2, 2021 at 3:58 PM panda1628 ***@***.***> wrote: In riscv-arch-test/riscv-test-env/p/riscv_test.h trap_vector: /* test whether the test came from pass/fail */ addi t0, zero, 13; csrr t5, mcause; li t6, CAUSE_USER_ECALL; beq t5, t6, write_tohost; li t6, CAUSE_SUPERVISOR_ECALL; beq t5, t6, write_tohost; li t6, CAUSE_MACHINE_ECALL; beq t5, t6, write_tohost; \ The upper bits will not match. Can we mask off bits 29-28, 27, 23-16 for the comparison? (beq) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJVE63CAPEH63MFORS3TVZACTANCNFSM47TX4EKQ> .

[panda1628]

Even though I can add code to mask off those bits before comparison to avoid the mismatch, I try to avoid changing the compliance tests. It looks like I need to do it until the riscof shows up .

Allen, thanks for your responses.

[allenjbaum]

Despite the seemingly minor difference, even after riscof we will have separate tests (or tests with embedded "#ifdef/#endif that do the masking) depending on whether clic is implemented or not.

…

On Sun, Jul 4, 2021 at 5:25 PM panda1628 ***@***.***> wrote: Even though I can add code to mask off those bits before comparison to avoid the mismatch, I try to avoid changing the compliance tests. It looks like I need to do it until the riscof shows up . Allen, thanks for your responses. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#194 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJU5BUGOHWXCC6VG4STTWD3XJANCNFSM47TX4EKQ> .