How does a real time clock interface with a computer?

Question

How does a real time clock device interface with a computer? I am currently desinging my own computer using memory mapped IO and DMA but I am curious how a real time clock would be used in such a situation without hogging access from the memory controller?

Answer 1

Read for example the HPET & PIC wikipages and the Real-time clock one.

In practice, assuming your computer is fast enough, you could deliver periodic interrupts to your computer.

In the past, interrupting the processor at the frequency of the AC current (e.g. 50Hz or 60Hz) has been very effective. That frequency is too low to hogging access from the memory controller (since today, most RAM have access times measured in hundreds of nanoseconds and even very cheap microcontrollers have today clock rates of at least 10MHz. Your laptop's processor operates above the GHz; read also about the MegaHertz Myth).

Answer 2

You could do what modern x86 does, and include a CPU instruction that puts the time in a CPU register (rdtsc).

On x86 it's actually a timestamp counter of "reference" cycles since last reboot, but it counts at a fixed reference frequency regardless of power-saving halts and changes to the actual CPU frequency.

So you'd probably want an off-chip battery-backed RTC to keep time when the computer is off, and either let the OS keep track of scale factors and offsets for rdtsc like x86 does, or allow the OS to program the CPU's internal time so the read-clock instruction gives absolute time in nanoseconds directly (e.g. split into 64-bit seconds / 64-bit nanoseconds values.)

Anyway, this gives very low overhead for getting the current time in user-space (a few tens of cycles, no switch to kernel mode, and no contention for resources like I/O shared by multiple cores). So it doesn't matter that access to the actual battery-backed RTC is slow.

---

The reference frequency on x86 is the "rated" / sticker clock speed, i.e. 4.0 GHz for i7-6700k, regardless of its max turbo or whatever. This is due to historical factors; rdtsc used to count core clock cycles and be directly useful for performance, then OSes started using it as a cheap time source. But then CPU vendors introduced variable-frequency CPUs with power-saving that broke this, and only later invented this reference cycles thing and added the non-stop feature so the rdtsc clock doesn't stop when the CPU's clock real clock is halted.

You can sidestep all that by just designing it as a low-overhead wall-clock in the first place, with no expectation that it correlates with core clock speed unless that's convenient for you to design. (e.g. have it count a clock input, and let the OS and/or user-space easily find out what frequency that runs at.)