Don't access time/timeh in ZicntrU test if UDB_TIME_CSR_IMPLEMENTED is not defined

[Luke Wren (Wren6991)]

These CSRs are optional even when Zicntr is implemented, and even when the address-mapped time/timeh registers (e.g. in CLINT) are implemented.

UDB configuration can express this using the TIME_CSR_IMPLEMENTED boolean, but the SAIL model just provides Zicntr.supported and clint.supported, so it's not sufficiently granular to cover this (common) configuration.

As a compromise, skip the time/timeh tests when the UDB says the CSR is not implemented.

[Jordan Carlin (jordancarlin)]

See related discussion in #1924.

The Zicntr extension defines (and as far as I can tell, requires) the time CSR. If we don't test the time CSR, then we are not testing the full Zicntr extension. From an unpriv perspective, there is no optionality in the spec.

The priv spec then has the following non-normative note:

Implementations can convert reads of the time and timeh CSRs into loads to the memory-mapped mtime register, or emulate this functionality on behalf of less-privileged modes in M-mode software.

The UDB parameter seems to come from that non-normative note. That note does not make the time CSR optional, it just suggests one implementation of it is to trap and emulate. RISC-V technically allows trapping and emulating on any instruction when in lower priv modes. I don't think this case is any different than testing something like fdiv on a core that traps and emulates that instruction due to a bug in the hardware divider. In this case it is a design choice instead of a bug, but it is still a required CSR that should be accessible from a User/Supervisor perspective.

The current proposed solution is to catch this CSR access in the trap handler when TIME_CSR_IMPLEMENTED is false and invisibly emulate it.

[Luke Wren (Wren6991)]

I don't think trap-and-emulate is applicable here because the test is checking whether the access traps. These are both valid answers to that question, per the spec:

• Trap always (to permit M-mode emulation)

• Trap when mcounteren.tm is false.

Unfortunately this type of optionality is difficult to support when the tests are checked with signature diffing instead of in-test logic.

So there is an actual structural issue with the tests that is not solved by installing a trap handler, IMO. Maybe the trap-and-emulate-style behaviour just needs to be supported in the SAIL model?

[Luke Wren (Wren6991)]

The priv spec then has the following non-normative note:

This is non-normative because it gives no additional permission: an implementation can always provide S- or U-mode functionality through M-mode emulation.

Looking at this pragmatically, mtime/mtimeh and time/timeh are in a bit of an odd position because mtime was retconned from a normal CSR to a weird memory-mapped hybrid fairly late in the ratification process, and I think it's worth handling this one as a special case. A commenter on the other issue already mentioned SiFive U74 as an example of an implementation that doesn't implement time. Hazard3 is another example.

[Allen Baum (allenjbaum)]

The test should not test that it traps or not; it should test that, when TIME CSR is read, the value of MTIME is written to the destination XREG, and no other architectural state (that is accessible to the privilege mode that executed the CSR read) should be modified. That does turn out to be tricky in this case, because the current plan is to delegate everything except ECALL In this case, the illegal access to TIME doesn't result in an ECALL, so it is delegated to (or back to) Smode - which knows nothing about it, and also destroys Smode trap state (SEPC, etc), so it is irrecoverable. Tests have to turn off delegation before testing anything requiring Mmode emulation . This is just one case, and if there are other cases like this (e.g. FDIV) the same thing has to happen. I don't see any other clean way of doing this except to change the current plan to delegate illegal ops to Smode and always trap to Mode if ANY op will need special Mmode handling. (based on an implementation defined parameter if it knows it needs any emulation support). The DUT Mmode handler will need to test for illegal ops that it knows it must delegate, and - handle them & MRET if it has a handler for that opcode, or or emulate delegation to Smode when the op doesn't have a special handler. Our RVI sample trap handler won't even test for illegal ops, so it could always delegate - or not. Tests will work either way. That's a heavy hammer, since every illegal op trap will need to trampoline through Mmode, even if no special handling is needed, but that's what a core that requires emulation to be ISA-compliant will need to do in the real world anyway. The alternative is to only turn off delegation when it is known that the particular op being tested (or maybe some other op in a test ) needs emulation. While we could special case the TIME CSR test (because we have the TIME_CSR_IMPLEMENTED parameter) we can't do it for any other random instruction that needs emulation - that doesn't scale - so that machinery must be there and it is unclear whether we should bother to special case it.

…

On Sat, Aug 22, 2026 at 2:08 AM Luke Wren ***@***.***> wrote: *Wren6991* left a comment (riscv/riscv-arch-test#2155) <#2155 (comment)> The priv spec then has the following non-normative note: This is non-normative because it gives no additional permission: an implementation can *always* provide S- or U-mode functionality through M-mode emulation. Looking at this pragmatically, mtime/mtimeh and time/timeh are in a bit of an odd position because mtime was retconned from a normal CSR to a weird memory-mapped hybrid fairly late in the ratification process, and I think it's worth handling this one as a special case. A commenter on the other issue already mentioned SiFive U74 as an example of an implementation that doesn't implement time. Hazard3 <https://github.com/wren6991/hazard3> is another example. — Reply to this email directly, view it on GitHub <#2155?email_source=notifications&email_token=AHPXVJT7MS46X3MQW7LUBYT5LFPIVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZXHE2DOMBYGMZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5379470833>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQU7THQTVJ4JMOFQF35LFPIVAVCNFSNUABFKJSXA33TNF2G64TZHMYTGNBQGAZTSNBVHNEXG43VMU5TKMRSGAYDEMJYHEYKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AHPXVJQ2YLGG5V57KSACMH35LFPIVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZXHE2DOMBYGMZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AHPXVJXAY52DXVKS7XDJQF35LFPIVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZXHE2DOMBYGMZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Jordan Carlin (jordancarlin)]

I'm working on an example implementation of this and will hopefully get it pushed in the next few days. The standard trap handler that we provide will automatically emulate accesses to time if TIME_CSR_IMPLEMENTED is false by reading from mtime. There will also be an RVMODEL hook for additional trap-and-emulate instructions so users don't need to modify the trap handler if they need to catch other instructions. These trap-and-emulate routines will happen at the beginning of the trap handler before any of the signature logic, so the test results will not change when an invisible trap is taken.