1. Messages
  2. Requirements on implementing cycle/instret/hpmcountern

Re: Requirements on implementing cycle/instret/hpmcountern

Paul Donahue
 

How is "csrr time" different than "div" in this regard?  There was a lot of discussion at some point about whether you could claim M extension compatibility if you trapped and emulated divides in M-mode.  My understanding of the outcome is that if an instruction is not supported by the execution environment visible to M-mode then you can't claim to implement that extension.  (Of course, the SEE can claim to support emulated instructions but I'm talking about what hardware can claim to support.)  The Zmmul extension was created specifically for that case.

Why is there a non-normative comment that says that reads of time can be emulated in M-mode?  I agree that the CSR read can be converted into a load of mtime but I don't think that "or emulate this functionality in M-mode software" complies with what I said above.  Just like emulation of divides, emulation of the time CSR would be seen by the execution environment visible to M-mode.  (Emulating in an implementation-defined mode that's at a higher privilege level than M would be OK.)


Thanks,

-Paul


On Mon, Jan 23, 2023 at 7:33 PM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
From an implementers point of view, that means an CSRR of the time CSR  could read the Mtime MMIO location (or a local copy if implemented that way_),
or it could trap and have Mmode firmware do the read and return a value. Any other type of access (CSRRW, CSRS*, CSRC*, etc) will trap

Form the ACT point of view we do not test firmware (e.g. the Mmode handler that would do that), 
so we only care whether it traps or returns some value that is monotonically increasing 
(at some rate that we need to define in terms of the only deterministically increasing counter we have which  is instret),
and whether other variations of the op cause a trap.

So, vendors need to supply a parameter (number of instret counts guaranteed to be longer than a time tick) and the tests will do the rest.


On Mon, Jan 23, 2023 at 1:19 AM Greg Chadwick <gac@...> wrote:
Thanks Greg and Jeff, useful to have my interpretation confirmed by a couple of people. I might put a PR together for the spec to add some clarification around these points.

Cheers,
Greg

On Fri, Jan 20, 2023 at 5:15 PM Greg Favor <gfavor@...> wrote:
On Fri, Jan 20, 2023 at 1:38 AM Greg Chadwick <gac@...> wrote:
On a related note I think it's permissible to not implement the 'time' CSR? It's an actual CSR that mirrors the memory mapped 'mtime' and the specification states 'Implementations can convert reads of the time and timeh CSRs into loads to the memory-mapped mtime register, or emulate this functionality in M-mode software' which presumably means M-mode accesses to 'time' can still be emulated by M-mode software (i.e. architecturally it's an illegal instruction exception and you're expecting the software to deal with it which is functionally identical to just not implementing it in hardware).

This is correct.  The overarching idea is that the 'time' CSR must appear to be present, i.e.  one can execute a CSR instruction accessing the 'time' CRS and the instruction - one way or another - will successfully be completed and will return a correct value.  Put differently, from an architectural and software perspective, the 'time' CSR must appear to be implemented - even if it isn't actually implemented in hardware as a physically distinct register.

Greg
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.