On 2/20/2024 9:29 PM, chengyong zhong wrote: > Hi Eliot, > Thanks for your kind reply. Are there any sample to implement the feature in the Gem5 code repository? I wrote: Unless I've missed something, gem5 does not provide dual / multi port caches at present. Hence, no example (that I am aware of). Maybe somebody else on the list knows if there is something out there that can be adapted. In principle, requests could be sent one after the other over the existing xbar, but it seemed what you were looking for is concurrent sending of two requests at the same time, as if there were two separate sets of wires from the cpu to the data cache. This does not require another xbar, but it does require an additional port out of the cpu and an additional port into the data cache. the problem is that, AFAIK, the code implementing the cache is not prepared to consider multiple packets arriving in the same cycle or to provided concurrent cycling of the cache as a dual-ported cache would operate. It is kind of assumed that the cycle is a single memory being cycled (on hits anyway). The code is pretty complicated because of all the different kinds of packets and behaviors so I don't think it would be trivial to grow into the kind of parallelism you seem to be seeking. Can someone else confirm or deny my understanding? Best - EM

Thanks for the clarification. IMP, it is a common scenario for modeling a HPC core, can anyone provide some tips or sample programs? On the other hand, I found that multi-bank is supported in the RUBY cache model(ruby/structures/BankedArray.cc), how is the multi-load implemented in the RUBY model? Thanks Eliot Moss <moss@cs.umass.edu> 于2024年2月21日周三 10:48写道： > On 2/20/2024 9:29 PM, chengyong zhong wrote: > > Hi Eliot, > > Thanks for your kind reply. Are there any sample to implement the > feature in the Gem5 code repository? > > I wrote: Unless I've missed something, gem5 does not provide dual / multi > port caches at present. > > Hence, no example (that I am aware of). Maybe somebody else on the list > knows if there is > something out there that can be adapted. > > In principle, requests could be sent one after the other over the existing > xbar, > but it seemed what you were looking for is concurrent sending of two > requests > at the same time, as if there were two separate sets of wires from the cpu > to > the data cache. This does not require another xbar, but it does require an > additional port out of the cpu and an additional port into the data cache. > the problem is that, AFAIK, the code implementing the cache is not prepared > to consider multiple packets arriving in the same cycle or to provided > concurrent cycling of the cache as a dual-ported cache would operate. It > is > kind of assumed that the cycle is a single memory being cycled (on hits > anyway). > > The code is pretty complicated because of all the different kinds of > packets > and behaviors so I don't think it would be trivial to grow into the kind of > parallelism you seem to be seeking. > > Can someone else confirm or deny my understanding? > > Best - EM >

On 2/21/2024 5:04 AM, chengyong zhong via gem5-users wrote: > Thanks for the clarification. > IMP, it is a common scenario for modeling a HPC core, can anyone provide some tips or sample programs? > On the other hand, I found that multi-bank is supported in the RUBY cache model(ruby/structures/BankedArray.cc), how is > the multi-load implemented in the RUBY model? > Thanks I've never used Ruby so someone else will have to answer that. Cheers - EM