> 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.
> 
> Andreas Hansson wrote:
>     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.
> 
> Erfan Azarkhish wrote:
>     I see your points Andreas. I will try to separate the patches to make 
> this easier.

Thanks Erfan. Could you also make sure that http://reviews.gem5.org/r/2993/ is 
applied _before_ this patch (or these patches once split)?


- 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

Reply via email to