Questions about Cache in the MPC5777C

[jongminna]

Dear Everyone,

I used MPC5777C for my application.

Our OEM want to disable the cache for SRAM.

I mean SRAM cache inhibited via MMU TLB configuration.

I supposed that their intend(cache inhibit) is data coherency between core 0 and core 1.

But, I think It can be achieved by Data coherency bit at mas2. Isn't it?

In other words, Even though apply cache for SRAM, Prevent some corrupted data between cores If data coherency bit is set.

Actually, I imlemented data copy routine from core 1 to core 0. There is little bit large data and so that copying time is 100us when cacheable. But cache disabled then 230us takes approximately.

So  I think I can get more effective performance through the cache.

Or If there is other side effect, Please let me know.

[lukaszadrapa]

Hi,

yes, Platform Coherency Unit can be used to maintain the coherency between cores and also DMA. It is necessary to configure the MMU pages with M and W bits set:

And then the PCU can be enabled by setting MnWMEN bits (to enable individual masters to be monitored) and ENB (to globally enable PCU monitoring) in PCU_CESR register:

This should help to achieve higher performance.

Regards,

Lukas

[francescodolcin]

Hi Lukas,

is setting M2WMEN and M3WMEN required if only coherency between core0 and core1 is needed?

in the simple case of cache coherency required only between core0 and core1 is needed to check for snooping error (CP1ERR[1:0], CP0ERR[1:0]) and to enable/manage snooping error interrupt?

Thanks,

Francesco

[lukaszadrapa]

First, overflow error is not expected to occur. There are safeguard mechanisms in place to prevent the queues from overflowing. Specifically, when the queues fill to a certain capacity, the PCU notifies the cores and DMAs to temporarily stall issuing any stores to shared space until the queue dips below the threshold. This should prevent the queue from ever overflowing. The overflow error condition was installed as a backup mechanism in the unlikely event that the DMAs and/or cores do not respond to the stall request.

Yes, user is supposed to check the error flags CP1ERR[1:0] and CP0ERR[1:0]. In case of snooping error, a core can get non-coherent data. In this case, user can invalidate the data cache and reset the PCU by SRST_EN. Before that, user can read more details about the error in error registers. It’s rather application dependent how to react on such error.

Regards,

Lukas

[peter_vranken]

Dear Lukas,

According to your explanations above, data writers are stalled if the PCU's cache
synchronizing queue gets full. This means for repeated writes to a cache coherent memory
area that the memory bandwidth becomes the minimum of the throughput of memory and of

queue. The likelihood that the queue's throughput is significantly lower than the normal memory
throughput seems high. Which would mean that the memory throughput is reduced to that of
the queue.
  Is this correct?
  If yes, then the question arises to which extend the normal memory throughput is higher
than that of the queue?
  Is setting the property "cache inhibited" of a memory area in the MMU of both the cores an
equivalent way of ensuring data coherence (besides timing)?
  My final, resulting question: If we want to use bursts of writes of data for cross-core
communication (e.g. memcpy of a few hundred Byte at once), would it be better to use cache
inhibited memory instead of cached memory with PCU maintained cache coherence? Is the PCU
mechanism rather intended for occasional writes?

Regards

Peter

[lukaszadrapa]

Hi Francesco,

It is not necessary to configure M2WMEN and M3WMEN, it's for DMA only.

I'm not really sure about the error handling. It is not clear from RM. Let me check. I guess it will take some time...

Regards,

Lukas