The problem with a hardware random number generator is that programs want a repeatable sequence, and there may be more than one program concurrently using it. Hence each app must have its own RNG state, which must be saved/restored at switch. That save/restore cost is paid by everyone, whether they use RNG or not, and the Mill tends to avoid such things in the basic architecture.
The alternative is to give the RNG the semantics of an i/o device: you open it, you own it. That works for a bunch of embedded type uses, but not for the general case. Or you can treat it as a functional unit, like an ALU, and the app maintains the state in its own space. That also works, but the load/store cost of calling the unit would swamp the actual RNG compute, and having the state in the app invites back-channel attacks..
We have considered a seed generator in hardware, that would use a physical process (back-biased diode or some such) to give low-precision value that could be used as a seed for a conventional software RNG. Repeatability of sequence is then available by using a fixed seed, while the physical seed would be unique each time and so not need save/restore. That still might happen, although it’s not in the current sim.