Overall, I think we're making this more complex than it needs to be. Down the road, if the complexity is warranted, we should do it, but I'm pretty sure that my proposal will cover everything that people want to do now.
> 1) Having a scalar "clock" is not the solution and the clocked objects (what > ever they are) should rather have a pointer to a clock object or a clock > domain? Until you implement DVFS, I see no reason to write this code. You can do things like "5 * Parent.clock.frequency" if you want to get a clock multiplier. Adding this now will just overcomplicate the change with something that is relatively orthogonal and should be in a separate commit anyway. I still think that the ClockedObject is a useful concept. Not all things that use a clock will always be MemObjects. > 2) Clock domain crossings are MemObject/SimObjects that have multiple clocks? I see no reason to support this right now. If ports have a clock, your clock domain crossings are taken care of. You can also always create two ClockedObjects each with different clocks that communicate using function calls to build your clock domain crossing if ports don't take care of everything. > 3) Ports always have a clock? Sure. Makes sense. > 4) We rely on a proxy to resolve clock domains by going to the parent by > default? Yes. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
