Hi, Mr Wang,
Thanks for your help! I'm so sorry that I didn't describe my question clearly.
Actually, I can receive the response of the request that I send to L2 cache. I
will describe my question more clearly below.
First, I add special master id to global master id list so that I can trace the
request that I send out. Then I insert schedReq() function into
Cache::CpuSidePort::recvTimingReq(PacketPtr pkt) to build user-defined requests
under special condition.
Second, I build the user-defined read request in schedReq() function, using
MemCmd::ReadReq, target addr A, special master id and other config. Then I call
Cache::CpuSidePort::recvTimingReq(PacketPtr pkt) to send the new read request
to L2 cache through the cpu side port(I have some code to avoid recurrence
relation).
Third, I override the Cache::CpuSidePort::schedTimingResp(PacketPtr pkt, Tick
when) function so that I can get the response of the request that has special
master id. Then I copy the data in the response packet to a new request packet,
which the request packet build with MemCmd::Writeback(don't need response),
target addr B(different from A) and so on. After that, I send the new write
request to Cache::CpuSidePort::recvTimingReq(PacketPtr pkt) and delete the old
read response to avoid it being send to upper level cache.
The words I said before "it works at beginning" means I do receive the response
of the user-defined read request, and send the new write request to L2 cache
successfully, the debug trace is shown below:
954816875: system.l2: Handling response ReadResp for addr 0x617d40 size 64
(ns)
954816875: system.l2: Block for addr 0x617d40 being updated in Cache
954816875: system.l2: replacement: replacing 0x5d7d40 (ns) with 0x617d40
(ns): clean
954816875: system.l2: Block addr 0x617d40 (ns) moving from state 0 to
state: 7 (E) valid: 1 writable: 1 readable: 1 dirty: 0 tag: c2
954816875: system.l2: access for Writeback addr 0x22aa03d40 size 64
954816875: system.l2: Writeback addr 0x22aa03d40 size 64 (ns) miss
954816875: system.l2: replacement: replacing 0x22a303d40 (ns) with
0x22aa03d40 (ns): writeback
954816875: system.l2: access new state is state: d (O) valid: 1 writable: 0
readable: 1 dirty: 1 tag: 45540
954816875: system.l2: Leaving recvTimingResp with ReadResp for addr 0x617d40
the 0x617d40 is addr A and the 0x22aa03d40 is add B. So I think the system is
running as I expect at this point. But soon the system prints nothing new when
I use --debug-flags=Cache, and when I change to use --debug-flags=DRAM, it just
prints endless:
26356456250: system.mem_ctrls2_0: All banks already precharged, starting
refresh
26356456250: system.mem_ctrls3_0: Refresh due
I think it's mean that dram is working normally and the cache may be blocked or
have dead locks. Yesterday, I check the trace info carefully and find something
interesting:
954823750: system.cpu.dcache: Blocking for cause 1, mask=2
It shows that dcache is blocked because its write buffer is full and I can't
find unblock info after that. So I guess is this the reason why cache stops
working? But I haven't injected other requests into the dcache. Or because the
user-defined requests' data occupy the cache line, so that the dcache write
buffer cann't evict data to L2 cache?But
954816875: system.l2: replacement: replacing 0x22a303d40 (ns) with
0x22aa03d40 (ns): writeback
shows that user-defined requests' data can be replaced, now I have no idea
again...If you have solution or suggestions, please help me! Thank you very
much, Mr Wang!
Best wishes,
Chunweiguan
>Date: Sun, 17 Apr 2016 12:36:17 -0400
>From: Yipeng Wang <[email protected]>
>To: gem5 users mailing list <[email protected]>
>Subject: Re: [gem5-users] How to inject user-defined data request into
> shared cache system
>Message-ID:
> <CAJDUSqpNfzUpsP4O2B6v=+Xg7ncknn=uwpdfg2prz4str69...@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Hi,
>
>You may want to show more details about your issue. As my understanding,
>you sent some your own request to cache but got no response. I think the
>most possible reason is that you did not create your user-defined read
>request properly, so that the request does not follow the normal path in
>the cache.
>
> Also, what do you mean that it works at beginning? Do you mean the
>simulation stop working or your own defined request stop working any more
>after some time? Since you use your own defined request, my suggestion is
>not only depending on the gem5's own debug-flags, but also try to insert
>your own printfs or debug flags to trace the cause of the issue.
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
