I agree. Whatever we develop long-term should allow multiple levels of arbitrary hierarchy. In the end, it would be ideal if M5's front-end configuration removed the .slicc files and directly glued the state machines together. In particular, it would be great if there was a "domain" super class that could encapsulate some number of state machines and generate domain mapping functions that were used by the .sm files. Of course this is the end goal and will require a large amount of work and coordination to do so.
In the meantime, what do we do to support hierarchies? Here are a few options, let me know if you see others: - The simplest thing is to do what GEMS has done in the past and create specific routing functions in RubySlicc_ComponentMapping.hh that use the MachineType "#define"s. - Follow Derek's suggestion to add a simple Chip class that encapsulates a chip's state machines. - Bite off the major tasks of removing the .slicc files and add a new domain class to the .rb files that auto generates domain mapping functions. My vote is that for the short-term we don't completely deprecate the "#define"s in RubySlicc_ComponentMapping.hh and allow for protocol specific routing functions. Later on, when we have the time to fully integrate the GEMS and M5 configurations, creating a domain class in the .rb files could be a nice intermediate step before migrating the ruby configuration to M5's python files. I like Derek's suggestion, but as Steve points out this may be too much work for only an intermediate solution and it may not solve everyone's problems. For instance, I can imagine some situations will call for more levels of hierarchy than just at the chip level. What is your opinion? Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Reinhardt Sent: Monday, August 03, 2009 2:51 PM To: M5 Developer List Subject: Re: [m5-dev] Fwd: GEM5 Issues On Mon, Aug 3, 2009 at 2:38 PM, Derek Hower<[email protected]> wrote: > > I see. Unfortunately this isn't possible at the moment. In the new > configuration, there really isn't any notion of "local" because there > is no longer a generated chip object. Now Ruby (network included) > doesn't care where a controller is located and treats them all the > same. You configure a multi-chip system by just adjusting latencies > to reflect off-chip communication. > > This of course complicates finding on-chip components. Here's one > idea of how to fix this that follows the "keep it generic" philosophy: > > 1. Create a Chip class that basically just contains pointers to > AbstractControllers, e.g., > > class Chip { > public: > void addController(AbstractController* c) { ... } > void getControllers(MachineType type) { ... } > > private: > Vector* m_controllers = new Vector[MachineType_NUM]; > } > > 2. Also add a getChip() function to AbstractController. > > 3. Then add a function in RubySlicc_ComponentMapping called > getLocalBroadcast(AbstractController*, MachineType). You'll need the > ability to reference "this" in SLICC, which I don't think you can > currently do. > > 4. Modify the generated Controller init functions and add lines like: > m_chip = RubySystem::getChip(m_cfg["chip"]); > m_chip->addController(this); > > 5. Here's the only tricky part - you'll need to add chips to the > Ruby-lang configuration. This will involve adding a new attribute to > NetPort called chip, adding a chip argument to all NetPort subclasses, > and printing out the actual chip configuration. > > Thoughts? If you like this approach I can help you navigate through > the configuration changes. I like the fact that Ruby no longer enforces the notion of a "chip", and I'm hesitant to see us add one back in, even if it's optional. I'd prefer to see something that at least has the appearance of providing support for an arbitrarily deep generic hierarchy, even if it's just a matter of changing the name Chip to Domain or Neighborhood or something like that. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
