Hi Joel, You're right both clock and voltage are separate hierarchies (although you would hope they are aligned).
You're also right that perhaps using SimObjects to describe them and "bolt" them onto the existing objects is less than ideal. I very much welcome the discussion on how to achieve this, and as you already noticed, I think the current way is the most straightforward and least invasive. That doesn't mean we have to stop here though, and I hope this thread can at least shake out any opinions and thoughts on this matter. Perhaps it's a good opportunity to make the Ruby hierarchy visible in the normal gem5 world as well. When it comes to the simple bits, I have also had some thoughts around the different views in config.dot (SVG in particular), and I think we might be able to visualise the different layers so that you can see the clock domains and power domains. We need someone skilled in client side scripting to pimp up the SVG based on node anchors and tags :-), at least that seems the easiest way forward. Is there anyone besides Joel and myself that has spent any brain cycles on this matter and have ideas to share? Andreas On 15/09/2013 22:07, "Joel Hestness" <[email protected]> wrote: >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 > -- 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
