|
Hello, We have a question relating to some work we are performing using a TMS320C6711 chip. We are experiencing some problems which lead us to believe that there is a problem with the L1D writing to onboard memory. The following code snippet shows the essence of the problem. /*setup onboard memory to be all sram (no L2 cache)*/ (*CCFG) &= 0x00000000; twid_fwd_addr = (float *)(0x0000a000); twid_inv_addr = (float *)(0x0000a200); (*CCFG) |= invalidate_L1D; for(i=0;i<64;i++) { twid_fwd_addr[2*i] = (float)((float)i * 2.0); twid_fwd_addr[2*i+1] = (float)((float)i * 3.0); twid_inv_addr[2*i] = twid_fwd_addr[2*i]; twid_inv_addr[2*i+1] = twid_fwd_addr[2*i+1]; } After executing this code and dumping the contents of the memory, we see the following results: Node[1]> [r .twid_inv_addr] 800264ec -> 0xa200 Node[1]> [r .twid_fwd_addr] 800264e8 -> 0xa000 Node[1]> [r 0x0000a000] a000 -> 0.000000 Node[1]> [] a004 -> 0.000000 Node[1]> [] a008 -> 0.000000 Node[1]> [] a00c -> 0.000000 Node[1]> [] a010 -> 0.000000 Node[1]> [] a014 -> 0.000000 Node[1]> [] a018 -> 0.000000 Node[1]> [] a01c -> 0.000000 Node[1]> [] a020 -> 8.000000 Node[1]> [] a024 -> 12.000000 Node[1]> [] a028 -> 0.000000 Node[1]> [] a02c -> 0.000000 Node[1]> [] a030 -> 0.000000 Node[1]> [] a034 -> 0.000000 Node[1]> [] a038 -> 0.000000 Node[1]> [] a03c -> 0.000000 Node[1]> [] a040 -> 16.000000 Node[1]> [] a044 -> 24.000000 Node[1]> [] a048 -> 0.000000 Node[1]> [] a04c -> 0.000000 Node[1]> [] a050 -> 0.000000 Node[1]> [] a054 -> 0.000000 Node[1]> [] a058 -> 0.000000 Node[1]> [] a05c -> 0.000000 Node[1]> [] a060 -> 24.000000 Node[1]> [] a064 -> 36.000000 ... Node[1]> [] a200 -> 0.000000 Node[1]> [] a204 -> 0.000000 Node[1]> [] a208 -> 2.000000 Node[1]> [] a20c -> 3.000000 Node[1]> [] a210 -> 4.000000 Node[1]> [] a214 -> 6.000000 Node[1]> [] a218 -> 6.000000 Node[1]> [] a21c -> 9.000000 Node[1]> [] a220 -> 8.000000 Node[1]> [] a224 -> 12.000000 Node[1]> [] a228 -> 10.000000 Node[1]> [] a22c -> 15.000000 Node[1]> [] a230 -> 12.000000 Node[1]> [] a234 -> 18.000000 Node[1]> [] a238 -> 14.000000 Node[1]> [] a23c -> 21.000000 Node[1]> [] a240 -> 16.000000 Node[1]> [] a244 -> 24.000000 Node[1]> [] a248 -> 18.000000 Node[1]> [] a24c -> 27.000000 Node[1]> [] a250 -> 20.000000 Node[1]> [] a254 -> 30.000000 Node[1]> [] a258 -> 22.000000 Node[1]> [] a25c -> 33.000000 Node[1]> [] a260 -> 24.000000 Node[1]> [] a264 -> 36.000000 ... Of note is the fact that the first 8 bytes of every 32 bytes are correct in the first array. 32 is the line size of the L1D cache. We believe that for some reason, the L1D isn't writing the proper results back to the proper location. To validate this claim, we performed a few tests. First, we invalidated the cache just after the two statemens which write to twid_fwd_addr[2*i] and [2*i+1]. We invalidated the L1D by "or"ing into the CCFG the word 0x00000100. When we do this on every iteration of the loop, we see correct results. (The memory dump from 0x0000a200 matches that of 0x0000a000.) A second test we performed was to invalidate the L1D after the full computation was completed, but this also gives the same incorrect results. We believe that the L1D isn't performing a write for the words between the proper results in the first output (e.g. at addresses 0x0000a048, 0xa04c, 0xa050..0xa05c). To substantiate this claim, we power-cycled the processor and dumped the memory contents. This of course results in garbage. We then load and run the code snippet above and we get the correct results written as shown above, but we see the same garbage between those locations. This leads us to believe that in the locations above where zeros are seen, the L1D simply does not attempt to write anything. When we use off-chip memory locations for our twid_fwd_addr and twid_inv_addr, we don't see this same error. We only see this problem when our data is stored in on-chip memory. Has anyone seen something similar to this? Is there some configuration which we are missing? Any suggestions would be very appreciated. Thanks Brandon. |
FW: L1D write problems on C6711
Started by ●November 10, 2000
