Thanks for the response Mitch. It seems like a nice way to fake a pipelined fetch.
Amin On Tue, Aug 26, 2014 at 10:54 AM, Mitch Hayenga < mitch.hayenga+g...@gmail.com> wrote: > Yep, > > I've thought of the need for a fully pipelined fetch as well. However my > current method is to fake longer instruction cache latencies by leaving the > delay as 1 cycle, but make up for it by adding additional "fetchToDecode" > delay. This makes the front-end latency and branch mispredict penalty the > same (for branches resolved at decode as well as execute). > > I haven't yet seen a case where this adding additional latency later to > make up for the lack of real instruction cache latency makes much of a > difference. > > > > On Tue, Aug 26, 2014 at 11:32 AM, Amin Farmahini via gem5-users < > gem5-users@gem5.org> wrote: > >> Hi, >> >> Looking at the codes for the fetch unit in O3, I realized that the fetch >> unit does not take advantage of non-blocking i-caches. The fetch unit does >> not initiate a new i-cache request while it is waiting for the an i-cache >> response. Since fetch unit in O3 does not pipeline i-cache requests, fetch >> unit throughput reduces significantly when the i-cache hit latency is more >> than 1 cycle. I expected that fetch unit should be able to initiate a new >> i-cache request each cycle (based on BTB addr or next sequential fetch >> addr) even when fetch unit is waiting for i-cache responses. Any thoughts >> on this? >> >> I understand a large fetch buffer can mitigate this to some degree... >> >> Thanks, >> Amin >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
