> On April 1, 2016, 2:14 p.m., Erfan Azarkhish wrote: > > Dear Abdul, > > I disagree with breaking the crossbar into 4 smaller crossbar, because I am > > quite sure that this is not how it works in the HMC. > > Maybe if you could modify the crossbar into a hierarchical-crossbar with > > non-uniform access latencies to the local and non-local quadrants that > > would make much more sense. > > However having 4 independent crossbars not correct, and will limit the > > functionality of the serial links: Chaining of multiple HMC devices won't > > be possible because the address ranges of the serial links would be > > different. Also link power down cannot be implemented, because again links > > deliver different address ranges. > > > > Finally, about the "round robin" HMC controller. Again I disagree with > > removing it. Because something should be there to connect 1 host to more > > than one serial link. It would be great if you could provide a better > > implementation for an HMC controller. But I believe that this component is > > necessary otherwise the model won't be an HMC device anymore. > > > > Thank you,
Two things: 1) The round robin is just spreading traffic across multiple links. The hashing and interleaving built in to the crossbar does exactly the same. Agreed? There is no difference in functionality, and the 1 host with multiple links is still working just fine. 2) The four crossbars is just making it multi hop. The overall address range distribution should be exactly the same. It is effectively just a way of creating non-uniform latencies within and between quadrants. Chaining should work just as before. Link power down is an interesting use-case that indeed gets more tricky since effectively the address mapping has to change. I would say this is the _only_ usecase that really warrants a separate host-side "HMC controller". You could argue that it's easier to modulate each link (lane scaling) as opposed to link scaling, but I see your point here. Do we really care about that use-case though? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3373/#review8133 ----------------------------------------------------------- On March 11, 2016, 11:35 a.m., Abdul Mutaal Ahmad wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3373/ > ----------------------------------------------------------- > > (Updated March 11, 2016, 11:35 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > In this new hmc configuration we have used the existing components in gem5 > mainly [SerialLink] [NoncoherentXbar]& [DRAMCtrl] to define 3 different > architecture for HMC. > =========== > Highlights > =========== > 1- It explores 3 different HMC architectures > 2- It creates 4-HMC crossbars and attaches 16 vault controllers with it. This > will connect vaults to serial links > 3- From the previous version, HMCController with round robin funtionality is > being removed and all the serial links are being accessible directly from > user ports > 4- Latency incorporated by HMCController (in previous version) is being added > to SerialLink > > > Diffs > ----- > > configs/common/HMC.py UNKNOWN > configs/common/MemConfig.py UNKNOWN > > Diff: http://reviews.gem5.org/r/3373/diff/ > > > Testing > ------- > > Current version only works for traffic generator setup {can be extended for > full-system and system-emulation} > =============== > How to run it > =============== > from you gem5 home directory run the following commands > > build/ARM/gem5.opt configs/example/hmctest.py --mem-type=HMC_2500_x32 > --mode=RANDOM --arch=0 > build/ARM/gem5.opt configs/example/hmctest.py --mem-type=HMC_2500_x32 > --mode=RANDOM --arch=1 > build/ARM/gem5.opt configs/example/hmctest.py --mem-type=HMC_2500_x32 > --mode=RANDOM --arch=2 > > Dependency > =========== > This patch required another tester patch to be applied before running the > test > > http://reviews.gem5.org/r/3374/ > > > Thanks, > > Abdul Mutaal Ahmad > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
