Review Board 2.0.15


eventq: add classes for Clock, ClockTicker, and PeriodicEvent

Review Request #8 - Created April 18, 2010 and updated

Information
Nathan Binkert
gem5
Reviewers
Default
eventq: add classes for Clock, ClockTicker, and PeriodicEvent
- Clock class is simply a phase and a period and can calculate the
next edge based on these variables
- ClockTicker class keeps track of the current clock cycle and is
intended to be used to schedule events
- PeriodicEvent class uses a ClockTicker to call an event on every
clock edge with simple functions to enable and disable the ticker

   
Review request changed
Updated (April 18, 2010, 3:45 p.m.)
Posted (May 8, 2010, 1:30 a.m.)
How often do you use Clock without ClockTicker?  It seems like ClockTicker doesn't really have state, in a sense, it's just a cache for not having to recalculate tick/cycle values near curTick (or if it's not exactly that, does it make sense to make it that?)

Also, I'm not sure it's worth it, but did you consider having a base Clock class that doesn't have a phase?  How often is the phase non-zero anyway?
src/base/clock.hh (Diff revision 2)
 
 
*All* of the classes need comments... you've already got decent descriptions in the patch description, just add them as comments in the code too.
src/base/clock.hh (Diff revision 2)
 
 
Please document these two fields.
src/base/clock.hh (Diff revision 2)
 
 
Please document this method
src/base/clock.hh (Diff revision 2)
 
 
Isn't this equivalent to the next three statements:
// Find the previous unshifted edge
Tick edge = unshifted - unshifted % period;
// Advance to next edge and shift
edge += period + phase;

It's more intuitive to me, anyway...
src/base/clock.hh (Diff revision 2)
 
 
Please add in 'assert(edge > when)' (or >=) to double-check your math and document the exit condition.  Better yet:
assert(edge > when && edge <= when + period)
src/base/clock.hh (Diff revision 2)
 
 
Shouldn't this comment apply to the whole method, not just this line of code?
src/base/clock.hh (Diff revision 2)
 
 
Do we care about dealing with the corner case when (when < phase)?  Rounding for negative integer division isn't standardized in C.
src/base/clock.hh (Diff revision 2)
 
 
Please document these fields.
src/base/clock.hh (Diff revision 2)
 
 
Please document this method.
src/base/clock.hh (Diff revision 2)
 
 
This comment doesn't make sense to me in this context.
src/base/clock.hh (Diff revision 2)
 
 
What if tick > curTick already?
src/base/clock.hh (Diff revision 2)
 
 
Are there other special cases to check here before we do all the math?  What about where curTick is between the old tick and new tick values?
src/sim/periodic_event.hh (Diff revision 2)
 
 
This flag name isn't quite right... sounds like a pointer var not a flag.  How about DeleteTicker?