Hi Andreas, Sure. I see what you're saying about the hierarchies being orthogonal. To clarify, it appears that both clock domains AND voltage domains can form separate orthogonal hierarchies, correct?
This suggests that they should be checked for consistency in an orthogonal way also. In particular, both clock and voltage trees could be checked the same way as the prior SimObject hierarchy (before clock and voltage domains), but separate from each other hierarchy, so that we don't get these warnings. Perhaps this means introducing separate object hierarchies (i.e. something other than SimObject/ClockedObject/MemObject) that can be checked in an analogous way. I also find that clock/voltage domain setup feels inverted, though it appears the solution you've introduced is probably the most straightforward. I've included some notes just to relay some more perspective: 1) Typically, we try to avoid adding a parent SimObject as a parameter to a child SimObject, because of the potential for circular references. The RubySystem is a long-standing counterexample to this: many Ruby components have parameters pointing back to the RubySystem in order to have access to Ruby-wide functions (e.g. getBlockSizeBytes()). Then again, the RubySystem could also be considered an example of an orthogonal hierarchy to the SimObject hierarchy that descends from it. 2) The clock/voltage domains are highly analogous to the Ruby network topology, which we define in a top-down manner (rather than inverted): The topology hierarchy is instantiated before any Ruby memory hierarchy components, and as these components are instantiated, they are appended onto appropriate lists in the topology (as opposed to the topology being added as a parameter to each of the components the way clock/voltage domains are). At the beginning of the simulation, the topology object connects all the child components as appropriate. This process makes it clear that the topology is the parent network object and that the memory hierarchy components are children, and it further allows the topology to perform verification that the hierarchy makes sense while connecting the children. 3) Visual or scripted verification of the clock/voltage domain setup in config.* files is still hard. Previously, you had to check each separate SimObject to make sure the "clock" parameter was correct. With the new clock/voltage domains, this becomes a two-stage process: First, you need to verify that each separate SimObject is in the correct domain, and then you need to verify that each domain has the correct parameters (e.g. "clock"). This process would be simplified if you could just look at the hierarchy of domains, which each included a list of the SimObjects that are in the domain. Overall, it looks like it would be a fair amount of work to redefine the clock/voltage domains so they could be set up like the Ruby network topology. On the other hand, it looks as though it would be fairly simple to introduce orthogonal class hierarchies (separate from the SimObject/ClockedObject/MemObject hierarchy) for the clock and voltage domains. This should allow for simplified hierarchy consistency checking and avoidance of the warnings we're seeing. Thoughts? Joel On Fri, Sep 13, 2013 at 8:39 PM, Andreas Hansson <[email protected]>wrote: > Hi Joel, > > As it turns out, clock domains and power domains are also hierarchies, > just like our SimObject (or even better, MemObjects), however, they are > not the same hierarchy as what we have at the moment. In other words, they > slice the object hierarchy (for lack of a better terminology), into an > orthogonal hierarchy. I very much agree that this makes life complicated, > and I am open for suggestions around how to better express this. A prime > example of this is all the platform devices. > > Let me know what you think would make life easier and we take it from > there. > > Andreas > > > On 13/09/2013 11:37, "Joel Hestness" <[email protected]> wrote: > > >Hey guys, > > I've been trying to update to the latest gem5 for gem5-gpu, and I'm > >getting all kinds of warnings about clock domains because of the way they > >are handled currently. In particular, clock domains are attached as > >children of the SimObjects that represent a part of the processor's > >functionality (e.g. cpu cores have a child clock domain), but often in > >system configuration files, you need to hang onto the clock domain by > >attaching as a child of, say, the system that you're instantiating. This > >leads to warnings that the clock domain already has a parent (both > >SimObjects and the system). > > > > This seems really backwards to me. I think that clock domains should be > >managed by the top-level system, and other components in the system should > >be added as children of the clock domains, especially since we've also > >introduced derived clocks, which make the whole object hierarchy even > >messier when they are children of SimObjects and the parent clock domain. > > > > Is there a particular reason why this was inverted? If not, I think we > >should aim to make clock domains the parents of all the processor > >component > >SimObjects. > > > > Thanks, > > Joel > > > >-- > > Joel Hestness > > PhD Student, Computer Architecture > > Dept. of Computer Science, University of Wisconsin - Madison > > http://pages.cs.wisc.edu/~hestness/ > >_______________________________________________ > >gem5-dev mailing list > >[email protected] > >http://m5sim.org/mailman/listinfo/gem5-dev > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
