On 25 September 2018 at 14:59, Damien Hedde <damien.he...@greensocs.com> wrote: > > > On 9/25/18 11:42 AM, Peter Maydell wrote: >> Having a ClockPort which ClockIn and ClockOut are derived >> from seems a bit heavyweight. When would you want to operate on >> a generic ClockPort rather than either a ClockIn or ClockOut ? >> Why would you want the name (canonical_path) to be different >> at the input and output ends -- is it possible to simplify >> to just having the output end keep the name string ? > > Here the canonical path is the full qom's canonical path. It is cached > in the state to avoid recomputing it when needed. It is only used for > log/trace purpose (without it, log is useless and calling > object_get_canonical_path at every log seemed too costly to me). > A connected ClockOut and ClockIn do not have the same (qom) parent, > their canonical path is different. > For example, in the zynq platform, there are 2 uarts, each one having a > "refclk" input. There is also a clock controller (slcr) having 2 > outputs "uart0_ref_clk" and "uart1_ref_clk". We end up with something > like this concerning canonical path: > + output "[...]/slcr/uart0_ref_clk" drives input "[...]/uart0/refclk" > + output "[...]/slcr/uart1_ref_clk" drives input "[...]/uart1/refclk" > > Right now, I log a line for every end (output and input) when the clock > frequency change, which lead to a kind-of-duplicate log line (names > differ, but clock frequencies are obviously the same). I could only log > at the output end and drop the canonical path for the input or pust the > path in both objects. > > Anyway it is easily possible to drop the ClockPort common ancestor. A > user never operates on it.
I think that would be preferable -- having the debug logging drive the object hierarchy setup seems like the tail wagging the dog to me. thanks -- PMM
