> On Oct. 16, 2015, 2:53 p.m., Nilay Vaish wrote: > > configs/common/HMC.py, line 49 > > <http://reviews.gem5.org/r/2986/diff/7/?file=50319#file50319line49> > > > > Why do we need to derive HMCSystem from SubSystem? > > Erfan Azarkhish wrote: > My goal has been to improve modularity, readability of the stats, and > visualization of the HMC device. > Also, based on HMC specs it should be possible to instantiate multiple > HMC devices and connect them to each other in different forms. > I think having HMC as a subsystem can be helpful for the mentioned > reasons. > > Nilay Vaish wrote: > Somehow I still do not like the current organization. But I am failing to > come with anything better. So I'll take what you have.
I think a SubSystem is a great way of accomplishing modularity here. We don't use it enough imho. What is your reservation Nilay? > On Oct. 16, 2015, 2:53 p.m., Nilay Vaish wrote: > > configs/example/fs.py, lines 220-223 > > <http://reviews.gem5.org/r/2986/diff/7/?file=50321#file50321line220> > > > > I think all of this code should be in MemConfig.py. This is not as clear cut as you make it sound Nilay. The memory controller itself represents a single channel, and traditionally the MemConfig functions have created a number of channels, and attached them to a crossbar (usually the system.membus). In the HMC case we are dealing with a more complicated system, and you may even have different links connecting different "systems". I am not objecting to moving things into MemConfig, but "mem_type" is being slightly abused here as it normally refers only to the subclass of DRAMCtrl. Here the string is being hi-jacked to also mean insert a host-side controller and a number of serial links. I am tempted to suggest we leave this out of this patch, and rather allow an option "Buffer-on-Board" or similar, in addition to the mem_type. > On Oct. 16, 2015, 2:53 p.m., Nilay Vaish wrote: > > configs/example/hmctest.py, line 1 > > <http://reviews.gem5.org/r/2986/diff/7/?file=50322#file50322line1> > > > > Drop this file. Sooner or later it would become out of date. Instead > > add a new regression test for HMC. > > Erfan Azarkhish wrote: > As you said, I dropped this file. I will add the regression test later in > a separate patch. Because I don't know how to do it yet. > > Nilay Vaish wrote: > Absolutely fine with me. No reason why the test cannot call the config in configs/dram or configs/example... - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2986/#review7380 ----------------------------------------------------------- On Oct. 17, 2015, 7:11 p.m., Erfan Azarkhish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2986/ > ----------------------------------------------------------- > > (Updated Oct. 17, 2015, 7:11 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11174:28f05276748f > --------------------------- > 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 > ----- > > src/mem/hmc_controller.hh PRE-CREATION > src/mem/hmc_controller.cc PRE-CREATION > src/mem/xbar.hh 3a4d1b5cd05c > 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 > configs/common/HMC.py PRE-CREATION > > 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
