Hi,
We should be able to figure it out with a little digging.
It appears that the output is generated with "--debug-flags=RubySlicc". From
the "*.sm" files, we can see that some of the actions have:
DPRINTF(RubySlicc, "Address: %#x, Data Block: %s\n", address, tbe.DataBlk);
These "*.sm" files are used to help generate code when gem5 compiles the Ruby
protocol (which it seems that we're generating MOESI_CMP_directory). Within
the build folder in gem5, execute:
find ./build | xargs grep -I "$ACTION_NAME"
where $ACTION_NAME is the action name that encapsulates the DPRINTF above.
With "c_sendData..." supplied, it should generate a list of files like the
following:
./build/X86/mem/protocol/L2Cache_Transitions.cc:
c_sendDataFromTBEToL1GETS(m_tbe_ptr, m_cache_entry_ptr, addr);
./build/X86/mem/protocol/L2Cache_Controller.hh: void
c_sendDataFromTBEToL1GETS(L2Cache_TBE*& m_tbe_ptr, L2Cache_Entry*& ...
./build/X86/mem/protocol/L2Cache_Controller.cc:L2Cache_Controller::c_sendDataFromTBEToL1GETS(L2Cache_TBE*&
m_tbe_ptr, ...
./build/X86/mem/protocol/L2Cache_Controller.cc: DPRINTF(RubyGenerated,
"executing c_sendDataFromTBEToL1GETS\n");
./build/X86/mem/protocol/L2Cache_Controller.cc: fatal("Error in
action L2Cache:c_sendDataFromTBEToL1GETS: "
We figure out where the declaration is in the files above (looks like it's in
"L2CacheController.cc").
In examining the file, we notice that "addr" is passed as a parameter into the
functions. The only place that it looks to be called from is
"L2Cache_Transitions.cc"; it appears under "doTransitionWorker" which is called
from "doTransition".
find ./build | xargs grep -I "doTransition"
This generates many files, but L2Cache_Wakeup.cc looks promising. From
examining the file, it looks like all of the addresses come from
"((in_msg_ptr)).m_addr". Seems like "in_msg_ptr" can any one of multiple
message types (RequestMsg, TriggerMsg, ResponseMsg, etc..).
find ./build -name "RequestMsg.*"
Within the resulting files (Request.hh, Request.cc), it's not explicitly clear
if the address is a line address or a normal address. (It mentions that the
address is a physical address though.) However, we notice the
"RequestMsg::print" statement. Specifically, look at printAddress(m_addr).
find ./build | xargs grep -I "printAddress".
The definition of "printAddress" comes from
"build/***/mem/ruby/common/Address.cc". The function is masking the low order
bits:
"<< maskLowOrderBits(addr, RubySystem::getBlockSizeBits())"
Given this information, it only makes sense for the m_addr in the message files
to be a full address and not the line address.
Also, the data block output has the form: [ 0xXX 0xXX]; a byte can also be
represented as 0xXX. There are 64 of these 0xXX (just like a cache line). So,
it makes sense to suspect that this is the data for the line address that our
full address would create. You might try to verify that. :)
Regards,
Brandon
________________________________________
From: gem5-dev <[email protected]> on behalf of P Pinky
<[email protected]>
Sent: Thursday, October 29, 2015 5:13 AM
To: gem5 Developer List
Subject: [gem5-dev] Fwd: Line Address in SLICC
Hi all
I have tried to print the line address in protocol files from the
in_msg.LineAddress.
So by tracing the file, i got the following output.
355500: system.ruby.l1_cntrl0: MOESI_CMP_directory-L1cache.sm:364: *Line
address: 2097216*
407000: system.ruby.l2_cntrl0: MOESI_CMP_directory-L2cache.sm:799: *Address:
2097216*, Data Block: [ 0x1 0x2d 0xca 0x17 0x0 0x0 0x48 0x1 0x2d 0xab 0x1f
0x0 0x0 0x48 0x1 0x2d 0xac 0x1f 0x0 0x0 0x48 0x1 0x2d 0x95 0x3f 0x0 0x0
0x48 0x8d 0x3d 0x9e 0xff 0xff 0xff 0x48 0x81 0xe7 0x0 0x0 0xe0 0xff 0x48
0x89 0xf8 0x48 0xc1 0xe8 0x1e 0x48 0x25 0xff 0x1 0x0 0x0 0x74 0x33 0x48
0x8d 0x95 0x63 0x60 0x20 0x0 0x48 ]
the one in red color is what i printed using in_msg.LineAddress in L1
cache.sm
the one in green was in L2cache.sm but its address (not specified as line
address).
So am confused now whether it "2097216" is line address or not. Can some
one clarify this? Also 0x1,ox2d refers to datablocks. Can someone help me
with this?
I tried to change the L1cache size and associativity.But still the same
address is printing.So this means its not line address ? Then why
in_msg.LineAddress ?
THanks in advance
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
