> On Sept. 28, 2015, 7:42 a.m., Lang Ma wrote: > > Dear Andreas, > > > > I apply this patch to gem5-44ef5ed3aee0 and follw steps to get DRAMSim2 as > > part of gem5, but I face a problem as follws: > > > > se.py: error: option --mem-type: invalid choice: 'dramsim2' (choose from > > 'LPDDR2_S4_1066_x32', 'LPDDR3_1600_x32', 'WideIO_200_x128', > > 'DDR3_1600_x64', 'SimpleMemory', 'SimpleDRAM', 'lpddr3_1600_x32', > > 'lpddr2_s4_1066_x32', 'ddr3_1600_x64', 'wio_200_x128', 'simple_mem') > > > > It's seems that I didn't add dramsim2 to the list. Would you please tell me > > the steps to use this patch file?
This patch was pushed more than a year ago... If you follow the instructions and recompile gem5 after adding dramsim2 in ext/dramsim2 the wrapper is built. I'd like to point out though that I question the usefulness of this functionality for anything but comparisons of controller models. The built in DRAMCtrl module is much faster, and a much more capable. Why would you want to use DRAMSim2? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2087/#review7294 ----------------------------------------------------------- On Nov. 14, 2013, 6:24 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2087/ > ----------------------------------------------------------- > > (Updated Nov. 14, 2013, 6:24 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9981:02da0086461e > --------------------------- > mem: Add a wrapped DRAMSim2 memory controller > > This patch adds DRAMSim2 as a memory controller by wrapping the > external library and creating a sublass of AbstractMemory that bridges > between the semantics of gem5 and the DRAMSim2 interface. > > The DRAMSim2 wrapper extracts the clock period from the config > file. There is no way of extracting this information from DRAMSim2 > itself, so we simply read the same config file and get it from there. > > To properly model the response queue, the wrapper keeps track of how > many transactions are in the actual controller, and how many are > stacking up waiting to be sent back as responses (in the wrapper). The > latter requires us to move away from the queued port and manage the > packets ourselves. This is due to DRAMSim2 not having any flow control > on the response path. > > DRAMSim2 assumes that the transactions it is given are matching the > burst size of the choosen memory. The wrapper checks to ensure the > cache line size of the system matches the burst size of DRAMSim2 as > there are currently no provisions to split the system requests. In > theory we could allow a cache line size smaller than the burst size, > but that would lead to inefficient use of the DRAM, so for not we > fatal also in this case. > > > Diffs > ----- > > .hgignore 329b8a20958b > SConstruct 329b8a20958b > configs/common/MemConfig.py 329b8a20958b > ext/dramsim2/README PRE-CREATION > ext/dramsim2/SConscript PRE-CREATION > src/mem/DRAMSim2.py PRE-CREATION > src/mem/SConscript 329b8a20958b > src/mem/dramsim2.hh PRE-CREATION > src/mem/dramsim2.cc PRE-CREATION > src/mem/dramsim2_wrapper.hh PRE-CREATION > src/mem/dramsim2_wrapper.cc PRE-CREATION > > Diff: http://reviews.gem5.org/r/2087/diff/ > > > Testing > ------- > > Ran a bunch of regressions and other test cases making use of the > wrapper. > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
