Remember that the cache much coherently update the line. The request in 8 bytes, but line is likely 64 bytes. In the case of a miss the cache that is handling the write (L1) must get the entire line and replace the 8 bytes, otherwise any other data in the line would be incorrect. In the case of a hit the data is written into the line, in the case of a miss the line is requested from another cache or the memory system with exclusive access permission and then the write completes.
Thanks, Ali On Jun 16, 2013, at 12:15 PM, biswabandan panda <biswa....@gmail.com> wrote: > Hi Ali, > > I have been trying to track store requests and responses between processor > and cache. > There is a case > When there is a write hit, the response from dcache to processor is writeResp > with size 8 and no new data is copied into the packet. > If write miss, the response from dcache to procesor is readExResp with size > 32 (assuming block size is 32) and data which is got by filling the cache. > > Example: > ------When c5fc0 misses (block_aligned of c5fd0) > 872000: system.cpu0.dcache: WriteReq c5fd0 miss > 873000: system.cpu0.dcache: getTimingPacket WriteReq for address c5fd0 size 8 > 873000: system.cpu0.dcache: getBusPacket created ReadExReq address c5fc0 size > 32 > 914000: system.cpu0.dcache: ReadExResp addr: c5fc0 data : 0 size 32 > ------When c5fc0 hits > 1016000: system.cpu0.dcache: access for WriteReq address c5fc0 size 8 > 1016000: system.cpu0.dcache: WriteReq c5fc0 hit state: f (M) valid: 1 > writable: 1 readable: 1 dirty: 1 tag: 31 data: 0 > 1016000: system.cpu0.dcache: WriteResp addr: c5fc0 data : ac size 8 > > Will it not affect the execution path? When there is a miss, the data that is > sent is different from when there is a hit in the cache -- should it not > depend on cache? > > > > On Sat, Jun 15, 2013 at 9:33 PM, Ali Saidi <sa...@umich.edu> wrote: > Are you looking at a request or a response. The request very well could not > have any data associated with it, but the response will. > > Ali > > On Jun 14, 2013, at 1:00 AM, biswabandan panda <biswa....@gmail.com> wrote: > >> Hi, >> In an unmodified copy of gem5, I made the data in packet.hh as public >> and tried to print it in schedSendTiming. It shows 0 as value for all the >> packets when I print it using (int)*(pkt->data). >> Is the data that is fetched from cache being sent to cpu? If yes how do I >> track(print) it? >> Thank you once again for your time. >> >> >> On Fri, Jun 14, 2013 at 11:14 AM, Ali Saidi <sa...@umich.edu> wrote: >> Actual data is stored in the caches. >> >> Ali >> >> On Jun 13, 2013, at 11:49 PM, biswabandan panda <biswa....@gmail.com> wrote: >> >>> >>> Hi, >>> I have modified the access function in cache to service a miss as hit >>> even when a particular block is not found. (This is just to collect some >>> statistics). I initially had assumed that gem5 does not store actual data >>> in cache and hence if a request misses at L1, if I just do "insertBlock, >>> memcpy and satisfyCpuSideRequest" and return true so that recvTimingReq >>> follows hit path, there ll be no error except that my simulation results >>> (ipc, misses, hits etc) will not be correct. >>> But when I run the same, I get this error >>> panic: fault (unalign) detected @ PC (0x120046574=>0x120046578) >>> When I googled for this error in one of the replies it says PC value is >>> corrupted. If gem5 did not store any data in cache, I by my code would have >>> modified only the timing parameter. How did this happen? If gem5 stores >>> actual data, how do I print it? >>> I also get this error for few other benchmarks >>> panic: Tried to access unmapped address 0x8. >>> >>> >>> Any pointers would be of great help. >>> >>> -- >>> >>> thanks®ards >>> BISWABANDAN >>> http://www.cse.iitm.ac.in/~biswa/ >>> >>> “We might fall down, but we will never lay down. We might not be the best, >>> but we will beat the best! We might not be at the top, but we will rise.” >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> -- >> >> thanks®ards >> BISWABANDAN >> http://www.cse.iitm.ac.in/~biswa/ >> >> “We might fall down, but we will never lay down. We might not be the best, >> but we will beat the best! We might not be at the top, but we will rise.” >> >> >> _______________________________________________ >> 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 > > > > -- > > thanks®ards > BISWABANDAN > http://www.cse.iitm.ac.in/~biswa/ > > “We might fall down, but we will never lay down. We might not be the best, > but we will beat the best! We might not be at the top, but we will rise.” > > > _______________________________________________ > 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
