Hi Yingying, NetDest indicates in which of the Memory Caches the address is present in the protocols MachineType. In the case for MESI there are 4: (L1Cache, L2Cache, Directory, DMA).
[NetDest (4) 0 1 - 0 0 - 0 - 0 - ] In this case the tag is present only in the second L1Cache (L1Cache1) [NetDest (4) 0 0 0 0 - 1 0 - 0 - 0 - ] In this case the tag is present only in the first L2Cache (L2Cache0) The << routine for NetDest prints the set in the order of L1Caches - L2Cache - Directory - DMA. In both your simulations, you did not change the number of directories or DMA Caches. Malek On Tue, Oct 16, 2012 at 5:53 PM, Cookie <cookie.yingy...@gmail.com> wrote: > Hi, > > I am sorry but I was wrong for the 1st question. When I run the simulator > long enough it started printing out data blocks with real value. So I think > the all-zero information is not the real simulation. > > But I still have the 2nd question. When I set my system as 2-core CMP, > MESI_CMP_directory protocol, two 3MB/bank L2 caches, the NetDest info is > like [NetDest (4) 0 1 - 0 0 - 0 - 0 - ] > When I set it as 4-core CMP, MESI_CMP_directory, two 3MB/bank L2 caches, the > NetDest info is like [NetDest (4) 0 0 0 0 - 1 0 - 0 - 0 - ]. Could you > please explain what each field in the NetDest info means? Thank you and > sorry again for the trouble. > > > Thanks, > Yingying > > > On Tue, Oct 16, 2012 at 2:54 PM, Cookie <cookie.yingy...@gmail.com> wrote: >> >> Hi, >> >> I have a question about the data fetched from main memory. As in >> MESI_CMP_directory-L2cache.sm, action "ee_sendDataToGetXRequestor' sends the >> cache block (phyaddr and real data) to the requestor. It also prints out the >> debug information as " DPRINTF(RubySlicc, "Address: %s, Destination: %s, >> DataBlock: %s\n", out_msg.Address, out_msg.Destination, out_msg.DataBlk);". >> I noticed that the out_msg.DataBlk is always 0x0, as below: >> ------------------------------------------------ >> 33943500: system.l2_cntrl1: MESI_CMP_directory-L2cache.sm:557: Address: >> [0x7255240, line 0x7255240], Destination: [NetDest (4) 0 1 - 0 0 - 0 - 0 >> - ], DataBlock: [ 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ] >> ------------------------------------------------ >> And of course the received data of L1cache is also 0. However, I don't >> think the real data block can always be 0. Is there anything wrong about my >> cache configuration or there is no real data contained in cache blocks? >> >> Another question is about the NetDest class. As shown in the debug >> information, the destination information is like [NetDest (4) 0 1 - 0 0 - >> 0 - 0 - ]. I wonder what this information means. I configured the system >> as 2-core CMP with private L1I/L1D caches and 2 shared L2 caches (3MB/bank). >> I think it means there are two L2 cache banks, located on each CPU tile >> separately, but they are accessed as a whole unified L2 cache indexing by >> physical addresses for both two cores. Is it correct? If it is correct, >> could you please explain what the information [NetDest (4) 0 1 - 0 0 - 0 >> - 0 - ] means under this configuration? Thank you for your help! >> >> >> Best, >> Yingying > > > > _______________________________________________ > 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
