> On 2012-01-10 22:02:34, Steve Reinhardt wrote:
> > Maybe the old code was trying too hard to be clever, but this seems like a
> > bigger change than necessary. Why not just add the fromCpuSide flag like
> > you've done, but without getting rid of incomingPort and otherSidePort, and
> > then the only thing you'd have to change in functionalAccess() is this:
> >
> > if (done) {
> > pkt->makeResponse();
> > } else {
> > otherSidePort->sendFunctional(pkt);
> > }
> >
> > to this:
> >
> > if (done) {
> > pkt->makeResponse();
> > } else if (fromCpuSide || forwardSnoops) {
> > otherSidePort->sendFunctional(pkt);
> > }
> >
The main reasons for the proposed structure is: 1) similarity with the
atomic/timing access that differentiates between the accesses coming from the
memory side and the CPU side and uses the port member variables cpusidePort and
memsidePort; 2)future changes that introduce master and slave ports where the
mem side port and the CPU side port have different roles and the function
cannot simply have to two port pointers, i.e. it is no longer symmetrical.
In conclusion, it makes our life easier if we can proceed with the change the
way it is and minimises future changes.
- Andreas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/979/#review1890
-----------------------------------------------------------
On 2012-01-10 09:16:24, Andreas Hansson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/979/
> -----------------------------------------------------------
>
> (Updated 2012-01-10 09:16:24)
>
>
> Review request for Default.
>
>
> Summary
> -------
>
> MEM: Differentiate functional cache accesses from CPU and memory
>
> This patch changes the functionalAccess member function in the cache
> model such that it is aware of what port the access came from, i.e. if
> it came from the CPU side or from the memory side. By adding this
> information, it is possible to respect the 'forwardSnoops' flag for
> snooping requests coming from the memory side and not forward
> them. This fixes an outstanding issue with the IO bus getting accesses
> that have no valid destination port and also cleans up future changes
> to the bus model.
>
>
> Diffs
> -----
>
> src/mem/cache/cache.hh a1d5a0e2e970
> src/mem/cache/cache_impl.hh a1d5a0e2e970
>
> Diff: http://reviews.m5sim.org/r/979/diff
>
>
> Testing
> -------
>
> util/regress all passing (disregarding t1000 and eio)
>
>
> Thanks,
>
> Andreas
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
