> On April 6, 2016, 9:43 p.m., Andreas Hansson wrote: > > No objections, but a high-level question: Should the long-term play here be > > to use the "normal" gem5 address mapping functionality embedded in the > > AddrRange class? This class (along with the XBar) already has support for > > interleaving and hashing. > > Brandon Potter wrote: > With these patches that handle routing based on certain ranges of the > address, it seems that this is well aligned for that adoption. I'm not too > familiar with how classic does it's mappings, but I did briefly look at the > AddrRange class and I suspect that I understand what you mean. It remains to > be seen if this patch will go through, but it's what I am pushing right now. > The address based mapping with bitSelect seems like a good way to handle the > routing problems. > > You can thank Nilay for this solution if you see him on the boards > anytime soon; kudos go to him for this. > > Andreas Hansson wrote: > Are you suggesting it's not worth merging the two at this point? > > Brandon Potter wrote: > We are discussing the AddrRange proposal internally. I think it can be > done (and probably should be done); though, we haven't tried to do it yet. > > However, I don't think that it should become a prerequisite for accepting > this change into the source. If that change works out, it will come as a > subsequent patch.
Agreed. I was mostly hoping that we can get on a trajectory that leads to less overlap - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3433/#review8152 ----------------------------------------------------------- On April 4, 2016, 11:43 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3433/ > ----------------------------------------------------------- > > (Updated April 4, 2016, 11:43 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11435:9b3faddc9c0b > --------------------------- > ruby: improved component mapping > > This patch aims are improving how addresses are mapped to different entities > in the memory system. The main issue was having a static member function in > the DirectoryMemory class and several different globally visible functions > almost doing the same thing. The functions map_Address_to_DirectoryNode, > map_Address_to_Directory, and broadcast() are being dropped. There is no > replacement provided for broadcast(), but one should be able to use the one > already available provided in the NetDest class. The functions > map_Address_to_DirectoryNode and map_Address_to_Directory should be replaced > with mapAddressToRange(). > > > Diffs > ----- > > src/mem/protocol/RubySlicc_Util.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/ruby/slicc_interface/RubySlicc_ComponentMapping.hh > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/ruby/structures/DirectoryMemory.hh > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/ruby/structures/DirectoryMemory.cc > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/ruby/structures/DirectoryMemory.py > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/ruby/structures/Prefetcher.cc > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-dir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-probeFilter.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_directory-L2cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_directory-dma.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_token-L1cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_token-L2cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_token-dir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_CMP_token-dma.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_hammer-cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_hammer-dir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_hammer-dma.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/Network_test-cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/RubySlicc_ComponentMapping.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-Region-CorePair.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-Region-dir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-RegionBuffer.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-RegionDir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Two_Level-dir.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Two_Level-dma.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MI_example-cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MI_example-dma.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-CorePair.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MOESI_AMD_Base-L3cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Two_Level-L1cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Two_Level-L2cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_VIPER_Region-TCC.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Three_Level-L1cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_VIPER-TCP.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_VIPER-SQC.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_VIPER-TCC.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_RfO-TCCdir.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_RfO-TCP.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_RfO-SQC.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/GPU_RfO-TCC.sm cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MI_example.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MOESI_AMD_Base.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MOESI_CMP_directory.py > cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MOESI_CMP_token.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MOESI_hammer.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/Network_test.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/GPU_VIPER_Baseline.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/GPU_VIPER_Region.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MESI_Three_Level.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/MESI_Two_Level.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/GPU_RfO.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/ruby/GPU_VIPER.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > > Diff: http://reviews.gem5.org/r/3433/diff/ > > > Testing > ------- > > > Thanks, > > Brandon Potter > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
