I would like some help with clarifying the intended MakeInvalid behavior.In AMBA CHI Specs, rev.G:If an RN is in SharedDirty state, is it allowed, based on "The request premits that any cached Dirty copies are discarded.", to discard its own dirty copy and move itself to Invalid state and issue the MakeInvalid?Doing so seems to contradict the second reference (sent only from UC, UCE, SC, I), so am I misunderstanding the first reference?If MakeInvalid can allow peer nodes to discard the dirty lines without returning data, would that also be acceptable for the issuer of the MakeInvalid?Thank you.
Thanks for raising this Ioannis,You're correct that MakeInvalid permits a cache line to effectively be dropped by the RN, regardless of the initial cache state. Externally, seeing a MakeInvalid means that invalidation has already taken place, but prior to the request being seen, the line could have been in any state.
The highlighted text under the table will be updated in a future specification release to something along the lines of:
Before a: CleanInvalid, CleanInvalidPoPA, Evict transaction, it is permitted for the cache state to be UC, UCE, or SC. MakeInvalid transaction, it is permitted for the cache state to be any state. However, it is required that the cache state transitions to the I state before a CleanInvalid, CleanInvalidPoPA, MakeInvalid, or Evict transaction is issued. Therefore, Table B4.42 shows I state as the only initial state.
Before a:
However, it is required that the cache state transitions to the I state before a CleanInvalid, CleanInvalidPoPA, MakeInvalid, or Evict transaction is issued. Therefore, Table B4.42 shows I state as the only initial state.