What is already there seems to line up with your PR description. The implementation is in arch, but the MMIO setup is in chips. That seems like what we want.

I'm not clear what you mean. The current implementation is in the arch folder, but it's not a generic RISC-V implementation, instead it is a specific SiFive implementation that should be in chips.

Yes, having this in arch had me irritated as well. The machine timer implementations of some of the RISC-V chips are indeed very different.

mtime and mtimecmp are specified in the risc-v spec. How can they be substantially different and spec compliant? Or is it just the register mapping that is different?

They are specified in the RISC-V spec, but the memory map is not. The current arch/rv32i/src/machine_timer.rs implements the SiFive CLINT

Ok, I have done two things.

First I renamed the new SiFive timer to CLINT to better reflect what it is. I also created an issue #2490 to track writing a generic implementation of the mtime and mtimecmp that can be shared by all of the RISC-V timer implementations.

That doesn't yet address @bradjc 's concerns, but it does track them.

I won't block this, I guess, but I am still opposed to this change. Machine timer is not clearly the clint in sifive, as the e21 manual has it in the CLIC:

As has been pointed out, chip developers can just put mtime/mtimecmp wherever they want, so because sifive chose to put the registers in the memory map of an interrupt peripheral does make the machine timer code an implementation of that interrupt peripheral.

But, mtime and mtimecmp, their size, and their behavior is specified in the risc-v spec, and I think then that a basic implementation (which the current machine timer code is) should reside in the arch crate. The chip-specific code (the memory map) should be moved to chips, and I can do that if needed.

The arch crates in tock have always been logical groupings of relevant code to support various architectures, not required code for any chip using that architecture (to large extent). Chips then pick and choose what modules they need. For example, the MPU is implemented in cortex-m, but is only used if the Platform impl in chips chooses to use it. If a risc-v chip does not need a machine timer implementation, or it needs a custom one, it is free to ignore the machine timer implementation in arch/rv32i.

@bradjc After re-reading 3.1.10 of the RISC-V Privileged Spec of 2019-06-08 your statements seem absolutely correct. It does seem that in practice many chips (esp. softcores) are ignoring this (I think to have seen one implement this using a CSR which had me slightly worried whether it's a universally valid assumption to have it memory mapped somewhere) but given that the specification is very clear about this, I'd agree it's place in rv32i is justified - even if not every chip is going to use it.

I'm not saying that machine timer is always in the CLINT, that's kind of the point. The machine timer can be anywhere! For the HiFive1 it's in the CLINT, for Ibex it's in their timers, for SweRV it's in the syscontroller and for the E21 it's in the CLIC. Which is why calling the CLINT implementation the RISC-V machine timer doesn't make sense. It's not the RISC-V machine timer, it's just the CLINT.

No one else can use the current RISC-V machine timer. The frequency is specified as the frequency of the HiFive1 and the register map matches the CLINT and only the CLINT. That means the RISC-V "architecture" timer in Tock only works for one specific timer implementation. That is why I think it should go in chips. Even if a different board had the exact same register layout it couldn't use this timer as it has a difference frequency.

I agree that a basic implementation should go into the architecture crate. I'm looking into a nice way to do that now. What we currently have though is not that, it's just the CLINT. It is not generic and no other board or chip can use it (unless they also use the SiFive CLINT AND have the same clock frequency as the HiFive1).

I'm not saying every board needs to use something for it to go into the arch crate. I think that bar should be set somewhere above "one company uses this IP block (and sells it to others) so we include it in the arch crate".

I have added a commit to try and address: #2490

This adds a generic timer helper in the architecture that the CLINT and other time implementations can use.

Ping!

bors r+

Build succeeded:

• ci-build (macos-latest)
• ci-build (ubuntu-latest)
• ci-format (ubuntu-latest)
• ci-qemu
• ci-tests (macos-latest)
• ci-tests (ubuntu-latest)