Hi Erfan, Thanks! What a great addition to gem5. I am really happy to see how much the gem5 modularity helps. No need for any complex HMCSim.
I have commented on some of the patches. I think the SerialLink is mostly fine as is, even though there is some room for improvement. The one thing I am curious about is the need for the round-robin host-side controller. I would imagine we could simply stick with address-range interleaving using the existing crossbar functionality. Do you think there are any issues in doing so? Andreas On 01/07/2015 03:41, "gem5-dev on behalf of Erfan Azarkhish" <[email protected] on behalf of [email protected]> wrote: >Hello All, > >I have submitted a set of patches which enable gem5 to simulate a simple >HMC device. >I have also attached the visualization file including the HMC device to >this email. > >This model highly reuses the existing components in gem5, and its >parameters have >been tuned based on the following references: > [1] http://www.hybridmemorycube.org/specification-download/ > [2] High performance AXI-4.0 based interconnect for extensible smart >memory cubes > (E. Azarkhish et. al) > [3] Low-Power Hybrid Memory Cubes With Link Power Management and >Two-Level > Prefetching (J. Ahn et. al) > [4] Memory-centric system interconnect design with Hybrid Memory Cubes > (G. Kim et. al) > [5] Near Data Processing, Are we there yet? (M. Gokhale) > http://www.cs.utah.edu/wondp/gokhale.pdf > >Here are the main components in this model: > >*- VAULT CONTROLLERS*: > Vault controllers are simply instances of the HMC_2500_x32 class with >their > functionalities specified in the DRAMCtrl class > >*- THE MAIN XBAR OF THE HMC:* > This component is just an instance of the NoncoherentXBar class, and its > parameters are tuned to [2] which is a cycle accurate and synthesizable >interconnect > to be used in the Logic-based of the HMC. > >*- SERIAL LINKS:* > Each SerialLink is a simple variation of the Bridge class, with the >ability to > account for the latency of packet serialization. We assume that the > serializer component at the transmitter side does not need to receive >the > whole packet to start the serialization. But the deserializer waits for >the > complete packet to check its integrity first. > * Bandwidth of the serial links is not modeled in the SerialLink >component > itself. Instead, bandwidth/port of the HMCController has been adjusted >to > reflect the bandwidth delivered by each serial link. > >*- HMC CONTROLLER:* > Contains a large buffer (modeled with Bridge - See config.dot.pdf) to >hide > the access latency of the memory cube. Plus it simply forwards the >packets > to the serial links in a round-robin fashion to balance the load among >them. > * It is inferred from the standard [1] and the literature [3] that >serial >links > share the same address range and packets can travel over any of them > so a load distribution mechanism is required among them. > >Lastly, an accuracy comparison of this model and our in-house cycle >accurate >model of HMC shows that "execution-time", and "bandwidth" match really >well >between these two (less than 5% difference). Also, we have adjusted the >queue >sizes in gem5 (in the Bridges and the DRAM Controllers) to obtain >reasonable >"memory-access-time" values in comparison with the cycle-accurate model, >nevertheless, there are still disparities and "memory-access-time" should >be >reported carefully. > >Here are the patches: > >http://reviews.gem5.org/r/2932/ >Change the page of the vault controllers to close_adaptive and adjust some >of its >parameters based on cycle-accurate simulation. > >http://reviews.gem5.org/r/2933/ >Make XBar::recvRangeChange a virtual method, to allow overriding it in >children > >http://reviews.gem5.org/r/2934/ >The class HMCController inherits from NoncoherentXBar with two simple >modifications: >1. It forwards the receiving requests on its slave port to the master >ports >using a round- >robin fashion >2. It accepts overlapping address ranges on its master ports ([3]). > >http://reviews.gem5.org/r/2935/ >SerialLink is simply a copy of gem5's Bridge class with the ability to >account for serialization >latency of the packets. I did not inherit SerialLink from Bridge, because >it required >some modifications in the Bridge. > >http://reviews.gem5.org/r/2936/ >The main python script composing a single HMC device as a sub-system and >specifying >all its parameters. I would like to mention that, one can easily >instantiate multiple instances of the HMCSystem >class and build a network of HMCs, but this patch instantiates only one. > >http://reviews.gem5.org/r/2937/ >Small modifications in MemConfig.py and fs.py to support the newly added >device for full-system simulation. >Plus a new script called hmctest.py which connects a traffic generator to >HMC. > >After applying the patches, you can simply run a full-system simulation: >./build/ARM/gem5.opt configs/example/fs.py \ >--mem-type=HMC_2500_x32 --mem-channels=16 \ >--caches --l2cache \ >--cpu-type=timing > >Or a traffic based simulation: >./build/ARM/gem5.opt configs/example/hmctest.py \ >--mem-type=HMC_2500_x32 \ >--mode=RANDOM > >I hope that this patch is helpful, > >Sincerely, >-- >Erfan Azarkhish >Micrel Lab - Viale Carlo Pepoli 3/2 - 40123, Bologna >DEI - University of Bologna, Italy >https://www.linkedin.com/in/erfanazarkhish >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
