ARMv8 introduces this new attribute of memory type. (B2.8.2)
And also it recommends that "early write acknowledgement" attribute should be exported to interface between PE and interconnect fabric. (J4.1.1)
However, there is no any clue about its encoding on AXI signals.
Contrast to memory attributes of ARMv7, AXIv4 has a table to list "memory type encoding" about them. (AXIv4, spec, A4.4, Table A4-5)
I am wondering whether it could be identical to "AxCACHE[0]" , device bufferable ?
Because I want to know,
is it validate for an AXI wrapper before interconnect to response to a write transaction with "No Early Write Acknowledge"?
Device-nGnRnE is equivalent to the strongly ordered memory type from ARMv7 so would be represented with AxCACHE='b0000 in an AXI system.
No early write acknowledgement is considered a hint so it is legal for a wrapper to respond but the system designer needs to be careful here. Returning the response signals to the processor that that transaction has completed, for instance a DSB will only hold the pipeline until it receives that response so the rest of the system needs to behave like that write has actually completed.
Thanks Peter,
But I am confused about why it just is a "hint", not a compliance requirement? Under this circumstance, using DSB could not guarantee the transaction completed by real slave.And moreover, a strongly-order device may still response SLVERR, that will result in "imprecise data abort".That sound irrational, right?
System designer is thinking it is not illegal, but that will make SW guys suffer all the pain.I can also understand why system designer take this decision, that is because of performance.Not all of the device addressing destination in a smallest 4k page are necessarily strongly-order memory type. No mater "E" or "nE", the best trad-off is all treated as "E", and asking SW do some workaround for it.
By the way, I think the best solution should be an "instruction-level" method, to provide load/store with attributes hint.And then, a compliance requirement could be included to request exactly mapping of CPU memory attribute to bus interface attribute. Is there any such thought before ?