----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1303/#review3093 -----------------------------------------------------------
I love the idea of this, but I still think that this does not belong in MemObject. I think that we should really have a ClockedObject class that derives from SimObject and that MemObject should derive from that. There are a number of things that use a clock that aren't necessarily MemObjects that could be moved over to the ClockedObject. Also, I have a bunch of random event queue diffs that you might be interested in. Let me know if you want me to send them your way. - Nathan Binkert On July 11, 2012, 1:58 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1303/ > ----------------------------------------------------------- > > (Updated July 11, 2012, 1:58 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9120:da3f3c760407 > --------------------------- > Clock: Move the clock and related functions to MemObject > > This patch moves the clock of the CPU, bus, and numerous devices to > the MemObject base class. Although there are currently a fair amount > of MemObjects that do not make use of the clock, they potentially > should do so, e.g. the caches should at some point have the same clock > as the CPU, potentially with a 1:n ratio. This patch does not > introduce any new clock objects or object hierarchies, but is still a > step in the direction of having a more structured approach clock > domains. > > The most contentious part of this patch is the serialisation of clocks > that some of the modules (but not all) did previously. This > serialisation should not be needed as the clock is set through the > parameters even when restoring from the checkpoint. In other words, > the state is "stored" in the Python code that creates the modules. > > The nextCycle methods are also simplified and the clock phase > parameter of the CPU is removed (this could be part of a clock object > once they are introduced). > > > Diffs > ----- > > src/arch/x86/interrupts.hh 9a72589ce4fd > src/arch/x86/interrupts.cc 9a72589ce4fd > src/arch/x86/utility.cc 9a72589ce4fd > src/cpu/BaseCPU.py 9a72589ce4fd > src/cpu/base.hh 9a72589ce4fd > src/cpu/base.cc 9a72589ce4fd > src/dev/CopyEngine.py 9a72589ce4fd > src/dev/Ethernet.py 9a72589ce4fd > src/dev/arm/RealView.py 9a72589ce4fd > src/dev/arm/pl111.hh 9a72589ce4fd > src/dev/arm/pl111.cc 9a72589ce4fd > src/dev/arm/timer_cpulocal.cc 9a72589ce4fd > src/dev/i8254xGBe.hh 9a72589ce4fd > src/dev/i8254xGBe.cc 9a72589ce4fd > src/dev/ns_gige.hh 9a72589ce4fd > src/dev/ns_gige.cc 9a72589ce4fd > src/dev/sinic.hh 9a72589ce4fd > src/dev/sinic.cc 9a72589ce4fd > src/mem/Bus.py 9a72589ce4fd > src/mem/MemObject.py 9a72589ce4fd > src/mem/bus.hh 9a72589ce4fd > src/mem/bus.cc 9a72589ce4fd > src/mem/mem_object.hh 9a72589ce4fd > src/mem/mem_object.cc 9a72589ce4fd > > Diff: http://reviews.gem5.org/r/1303/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
