This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[ACE] Why CleanUnique must write back to memory?

If master1(M1) wants to write new vale to a cache item when M0 has it as SharedDirty(SD) state and M1 has it as SharedClean(SC),
M1 initiates CleanUnique(CU) transaction to invalidate(I) M0's cache and hold the item as UniqueClean state before writing as below: 

    M0: SD -> (invalidate & write back dirty data to memory) -> I

    M1: SC -> (CleanUnique: invalidation request to M0)       -> UC -> (write new value)

I'm wondering about why CU writes back dirty data of M0 to memory even though M1 has the same (modified) value?

I read below Q&A and understand that ACE protocol defines so, but why ACE forces it?

    https://community.arm.com/support-forums/f/embedded-forum/45430/readunique-and-cleanunique-transactions-in-ace-protocol/164161

I think if CU changes M1's cache state to "UniqueDirty", not UC, dirty responsibility will be kept by M1 and there won't be need of unnecessary write back in invalidation of M0.

Is there any problems such as data disappearance without write back?  Or my understanding is incorrect?
I'd appreciate it if you could answer my questions.

Thanks.

Parents
  • M1 SharedClean is the clean data while M0 SharedDirty data is dirty data.

    If your expectation is assumed, M1 and M0 will both have the SharedDirty data.  So how to save them because there are two dirty data copies?   

Reply
  • M1 SharedClean is the clean data while M0 SharedDirty data is dirty data.

    If your expectation is assumed, M1 and M0 will both have the SharedDirty data.  So how to save them because there are two dirty data copies?   

Children
No data