Nikhil, I like your question and I don't think you've been given a
straight answer.
The spec says: "which holds a count of the number of clock cycles
executed by the processor core [...] The underlying 64-bit counter
should never overflow in practice. The rate at which the cycle counter
advances will depend on the implementation and operating environment."
The spec does not say "successive reads to rdcycle will be
monotonically increasing", but then it does not say "successive reads
to rdcycle may return the same value" either. Hence, the spec is, to
some degree, ambiguous.
Since the spec doesn't say which clock to use, it isn't clear if a
very slow clock can be used (nonmonotonic), or if the counter can be
left unimplemented (always returns same value).
The discussion part of the spec clarifies that these counters are
mandated to be available (as 64b, possibly doing the 32 MSB in
software). However, the discussion isn't part of the formal spec....
it shouldn't be adding mandatory requirements in the discussion. The
discussion reads: "We mandate these basic counters be provided in all
implementations as they are essential for [...analysis and
optimization...]. [...] We required the counters be 64 bits wide, even
on RV32, as otherwise it is very difficult for software to determine
if values have overflowed. "
If the counter is expected to be implemented, and always monotonic,
then the spec should be clear, and it should not rely upon the
discussion.
Note that 64b counters are quite costly in area in small, embedded
FPGA implementations, increasing area about +30%, from 550 LUTs to
700LUTs. I gave a scatterplot of the area penalty in my 3rd RISC V
Workshop presentation (attached).
Guy
> To view this discussion on the web visit
https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/22966.60063.394393.263425%40dhcp-45-115.EECS.Berkeley.EDU.