> On Oct. 21, 2015, 9:45 a.m., Andreas Hansson wrote: > > Can we close the open issues (if they are resolved)? > > > > I also think we should split out the changes to the HMC DRAM config into a > > separate patch. That can then go in with the serial link without having to > > close out the bigger config system issues. > > Erfan Azarkhish wrote: > Dear Andreas and Nilay, > I can split the patches as you say, but I think it is better to solve > this problem now, instead of postponing it to future. > I can remove "Subsystem" and insert my components directly in System, but > I still don't understand the problem with Subsystem, and why I cannot use it > when such functionality is available. I think Subsystem is a perfect > mechanism to group related components and introduce some sort of hierarchy. > For example a cluster of processors with their caches can be grouped as a > subsystem, and one can easily simulate a multi-cluster system by > instantiating more subsystems. In my opinion, HMC is another good candidate > for a subsystem. Having hierarchical components (components composed of other > standard components) can have many benefits and can provie new opportunities > to model more complex components (GPUs, Accelerators, Network of HMCs, etc) > in a clean and scalable fashion. > Please correct me if I'm wrong and help me improve this model.
I think there are two issues that requires some thinking (and splitting the patch would allow us to make progress while resolving them): 1) The subsystem issue. Erfan, you are right in that Subsystems are great for bundling stuff up in the Python world. I completely agree. The value of inheriting from a SubSystem is not obvious though, as you may as well inherit directly from SimObject. Any object can have children in the object hierarchy. Does that make sense? 2) The configuration/assembly issue. Our configuration system is not great, and an HMC memory is not just any DRAM. In fact, the HMC config is only for the DRAM controller, and in addition the whole cube requires additional crossbars, links etc. We could add a command line option to express something like "--mem_org" with options like BoB and direct etc, but I am not sure what they would all look like. Do you see my point Erfan? We would then have --mem_org=BoB to do the insertion of serial links and the base-layer crossbar, and for every BoB we would then use mem_type and mem_channels to setup the actual DRAM media controller. It's a bit contrived, but no worse than the rest of the config system. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2986/#review7409 ----------------------------------------------------------- On Oct. 18, 2015, 4:31 p.m., Erfan Azarkhish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2986/ > ----------------------------------------------------------- > > (Updated Oct. 18, 2015, 4:31 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11174:6e02b2208e16 > --------------------------- > mem: Simple HMC Model > > This patch enables modeling a complete Hybrid Memory Cube (HMC) device. It > highly reuses the existing components in gem5's general memory system with > some small modifications. This changeset requires an additional patch (2993) > for modeling the serial links. > > > Diffs > ----- > > configs/common/HMC.py PRE-CREATION > configs/common/MemConfig.py 3a4d1b5cd05c > configs/example/fs.py 3a4d1b5cd05c > src/mem/DRAMCtrl.py 3a4d1b5cd05c > src/mem/HMCController.py PRE-CREATION > src/mem/SConscript 3a4d1b5cd05c > src/mem/hmc_controller.hh PRE-CREATION > src/mem/hmc_controller.cc PRE-CREATION > src/mem/xbar.hh 3a4d1b5cd05c > > Diff: http://reviews.gem5.org/r/2986/diff/ > > > Testing > ------- > > gem5 compiles > fs.py executes and Linux boots correctly. > hmctest.py executes correctly, and stats correlate with cycle-accurate > simulation > > > Thanks, > > Erfan Azarkhish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
