allenjbaum
commented
1 year ago Yes - but, because of WARL fields, it is difficult to test in general. When WARL field support is added to Sail, this will become somewhat possible (though we really need to be able to test the behavior against a 2nd reference, of which none exist...). So we may want to do some minimal testing which doesn't require the the correct values for WARL field, but just tests CSRs that we can test. That is being done at some level with PMP and ePMP tests that are being written - that's exactly the first set of tests.
The trap handler actually tests a bit more of that (it uses the scratch registers, put doesn't use the immediate variants) but there is a ton of variability there as well. Overall, you're correct; we should set up a ZiCSR folder just for CSR tests and start populating with the simple ones we can test.
On Tue, Feb 14, 2023 at 9:01 AM ssecatchseagate @.***> wrote:
Many of the test suites are predicated on having Zicsr (ie, floating point, c.ebreak, privilege), however, the CSR opcodes themselves (CSRRW, CSRRS, CSRRC, CSRRWI, CSRRSI, CSRRCI) are not covered by testing, though some do appear in those testcases for trap handling and configuration. (The opcodes CSRRCI and CSRRSI don't ever appear in any testing at all, as far as I can tell)
It appears that the MSCRATCH register would be usable as a possible CSR target for testing for these opcodes. (it's read-write, not allowed to be changed by hardware, doesn't impact hardware behavior, and doesn't appear to be optional)
Additionally, read-only testing should be validated by attempting to write a read-only CSR, which should trigger an illegal instruction exception as required by the privilege specification when the CSR access has a write effect. MARCHID, a required CSR, would be appropriate for this. The value itself is controlled by hardware and so comparing it within the signature would be difficult without configuration of the SAIL model, but certainly writing it and detecting that the trap handler was triggered is feasible.
— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUHHQQUHFYIJKBVNYTWXO3ALANCNFSM6AAAAAAU32AIYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Many of the test suites are predicated on having Zicsr (ie, floating point, c.ebreak, privilege), however, the CSR opcodes themselves (CSRRW, CSRRS, CSRRC, CSRRWI, CSRRSI, CSRRCI) are not covered by testing, though some do appear in those testcases for trap handling and configuration. (The opcodes CSRRCI and CSRRSI don't ever appear in any testing at all, as far as I can tell)
It appears that the MSCRATCH register would be usable as a possible CSR target for testing for these opcodes. (it's read-write, not allowed to be changed by hardware, doesn't impact hardware behavior, and doesn't appear to be optional)
Additionally, read-only testing should be validated by attempting to write a read-only CSR, which should trigger an illegal instruction exception as required by the privilege specification when the CSR access has a write effect. MARCHID, a required CSR, would be appropriate for this. The value itself is controlled by hardware and so comparing it within the signature would be difficult without configuration of the SAIL model, but certainly writing it and detecting that the trap handler was triggered is feasible.