On Wed, 4 Sep 2019 at 13:56, Damien Hedde <damien.he...@greensocs.com> wrote: > > This series aims to add a way to model clock distribution in qemu. This allows > to model the clock tree of a platform allowing us to inspect clock > configuration and detect problems such as disabled clock or bad configured > pll. > > The added clock api is very similar the the gpio api for devices. We can add > input and output and connect them together. > > Very few changes since v5 in the core patches: we were waiting for multi phase > ability to allow proper initialization of the clock tree. So this is almost a > simple rebase on top of the current "Multi-phase reset mechanism" series. > Based-on: <20190821163341.16309-1-damien.he...@greensocs.com>
I've now gone through and given review comments on the patchset. I don't think there was anything particularly major -- overall I like the structure and API (and also the documentation!). The one topic I think we could do with discussing is whether a simple uint64_t giving the frequency of the clock in Hz is the right representation. In particular in your patch 9 the board has a clock frequency that's not a nice integer number of Hz. I think Philippe also mentioned on irc some board where the UART clock ends up at a weird frequency. Since the representation of the frequency is baked into the migration format it's going to be easier to get it right first rather than trying to change it later. So what should the representation be? Some random thoughts: 1) ptimer internally uses a 'period plus fraction' representation: int64_t period is the integer part of the period in nanoseconds, uint32_t period_frac is the fractional part of the period (if you like you can think of this as "96-bit integer period measured in units of one-2^32nd of a nanosecond"). However its only public interfaces for setting the frequency are (a) set the frequency in Hz (uint32_t) or (b) set the period in nanoseconds (int64_t); the period_frac part is used to handle frequencies which don't work out to a nice whole number of nanoseconds per cycle. 2) I hear that SystemC uses "value plus a time unit", with the smallest unit being a picosecond. (I think SystemC also lets you specify the duty cycle, but we definitely don't want to get into that!) 3) QEMUTimers are basically just nanosecond timers 4) The MAME emulator seems to work with periods of 96-bit attoseconds (represented internally by a 32-bit count of seconds plus a 64-bit count of attoseconds). One attosecond is 1e-18 seconds. Does anybody else have experience with other modelling or emulator technology and how it represents clocks ? I feel we should at least be able to represent clocks with the same accuracy that ptimer has. thanks -- PMM
