Cache Understanding wrt MSMCSRAM

RC,

It is very important to us that you understand clearly how to maintain coherence between your CorePac caches and your memory components outside of the CorePacs. This includes the MSMCSRAM and DDR3 memory, and also SRAM inside other CorePacs and memory-mapped peripherals.

The CorePac User Guide is intended to explain how the caches operate and how the coherency commands operate. We have Table B-1 which explains all of the terms used in the cache discussions in the User Guide; different companies use slightly different terms, so it helps to know exactly what TI means when describing a cache behavior or operation.

As I read through the CorePac User Guide to find the sections to point out to you, I realized that it does not talk about your side of the cache, the programmer's side or system developer's side; it talks about the chip function side to give you details on how it works, but not clearly how to use it.

In the Training section of TI.com, there is a training video set for the C6474. It may be helpful for you to review the memory and cache Module of this video set, in particular the last section which talks about cache coherency. This description, with graphics and a scripted explanation, may be more meaningful than what I can offer in a couple of paragraphs on the forum. You can find the complete video set here. The basics of coherency are the same as for the Keystone architecture, but you will still want to refer to the CorePac User Guide for details that are different from the C64x+ cache design.

To try to be 100% accurate and 100% helpful, I will offer how I would word what you are asking above. If my words have a different meaning, that means I did not understand your question, so please let me know what I missed.

RCReddy said:

1. We have a global variable "var" which is cache line aligned and is present in MSMC RAM.

Your global variable "var" is located in MSMCSRAM, which is being cached in CorePac0, in this case. The cache line alignment may not matter directly in this case, but it does prove that you understand the value of being concerned with cache line alignment, and that you take that into account when allocating your memory elements.

RCReddy said:

2. This variable is updated in CORE0 and I have performed Wb and Invalidation of this variable.

If the C66x in CorePac0 has simply written a new value to "var", then the new value of "var" may not be cached. L1D will only allocate a cache line when it reads a location (read-allocation); L2 will allocate a cache line when it reads or writes, but MSMCSRAM is not cached in L2 unless it has been mapped to an L3 address by the CorePac's MPAX module.

That is only a small detail, though, since we have to assume that "var" is cached and that the latest value needs to be written to the actual location in MSMCSRAM for use by other masters. This writing of the cached value to the actual location is done by the block writeback command. No invalidate is required at this time; an invalidate is needed only to ensure that the next read by CorePac0 will return a new value, if one is expected to be written by another master, including CorePac1.

RCReddy said:

3. Now, in CORE1, I will try to read this variable. Should I invalidate this before reading??? I am just reading this variable not writing it. I understand that, if I have to write this var in CORE1, I have to invalidate -> change the var -> Wb.

If you are reading this variable, and if it is possible that this variable is already cached in CorePac1, then you do need to do an invalidate before reading "var".

If you are writing this variable, then you need to do a writeback after writing "var".

RCReddy said:

Also, provide a case where we have to perform

1. Wb only

2. Wb and Inv together, by taking the same example

I think the graphics in the C6474 training video do a good job of explaining these situations, and the writeback has been mentioned above.

In general, you perform an invalidate before reading a variable and you perform a writeback after writing a variable. For many situations, these are done separately.

The writeback-invalidate is offered as an efficient way to handle the cases where you have updated data in a block of memory, and you will later need to read that same block of memory after it has been subsequently updated by another master.

If you work with separate input buffers and output buffers, then you will use invalidate on the input buffers before starting to process those and you will use writeback on the output buffers after you have processed those.

If you instead work with a buffer that you will process "in place", then the writeback-invalidate will save some time by doing both commands after processing is completed. It will be safest to also do an invalidate one time before any processing has begun on the very first processing operation just to make sure that the first reads are not from cache.

Regards,
RandyP