Tilelink GET operation


(Jing Gong) #1

Hey all
I am new to tilelink. I am currently studying the connection between rocket chip Dcache and tilelink.
In rocket chip data cache, it runs sort of mixs operation TL_UL,TL_UH and TL_UC. I print out some trace.
tla opcode 4 param TLBundleParameters(32,64,1,3,4) size 3 source1 address00000380 data0000000000000000

tld opcode 1 param TLBundleParameters(32,64,1,3,4) size 3 source 1 data f007f0080f500f60
tla opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source1 address00000100 data0000000000000000
tld opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source 1 data 0000000000000000
tla opcode 4 param TLBundleParameters(32,64,1,3,4) size 0 source1 address00000400 data0000000000000000
tld opcode 1 param TLBundleParameters(32,64,1,3,4) size 0 source 1 data 0000000000000000
tla opcode 4 param TLBundleParameters(32,64,1,3,4) size 0 source1 address00000400 data0000000000000000
tld opcode 1 param TLBundleParameters(32,64,1,3,4) size 0 source 1 data 0000000000000000
tla opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source1 address00000100 data0000000000000000
tld opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source 1 data 0000000000000000
tla opcode 4 param TLBundleParameters(32,64,1,3,4) size 0 source1 address00000400 data0000000000000000
tld opcode 1 param TLBundleParameters(32,64,1,3,4) size 0 source 1 data 0000000000000001
tla opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source1 address00000104 data0000000000000000
tld opcode 0 param TLBundleParameters(32,64,1,3,4) size 2 source 1 data 0000000000000000
tla opcode 4 param TLBundleParameters(32,64,1,3,4) size 3 source1 address00000380 data0000000000000000
tld opcode 1 param TLBundleParameters(32,64,1,3,4) size 3 source 1 data f1f11f1ff0f00f0f

look at the TL_A, it sent out the same address twice which is 00000380 but got different data from resp. Why is this happen?
kind of burst?

thanks


(Wesley W. Terpstra) #2

Presumably the value at that memory location changed between the two reads. Address 0x380 is the debug unit. Presumably the debug interface is being used to control the core in this scenario, so it is expected that the contents of the debug unit change over time.