We are writing to seek the formal confirmation on our understanding of the TxnID and ReturnTxnID mapping rules defined in the AMBA CHI Architecture Specification, specifically for ReadNoSnp transactions initiated by the Home Node (HN) with DMT=0. Below is the relevant excerpt from the CHI specification ( IHI0050G_b: B2.4.4 Return Transaction Identifier, ReturnTxnID):
*************************************
A transaction request from Home to Subordinate also includes a ReturnTxnID field to convey the value of TxnID in the data response and the DBIDResp response from the Subordinate.
Its value, when applicable, must be either:• The TxnID generated by Home, when the ReturnNID is the node ID of the Home.• The TxnID of the original Requester, when the ReturnNID is the node ID of the original Requester.
In ReadNoSnp and ReadNoSnpSep:• Expected value is the original Requester TxnID but permitted to be the Home TxnID.• Used as the TxnID in the CompData and DataSepResp responses.
Based on the clauses above, my understanding is as follows: For a ReadNoSnp transaction sent from the Home Node to the Subordinate with DMT=0, where the ReturnNID is set equal to the SrcID, the ReturnTxnID in the HN-to-Subordinate request must be equal to the TxnID.
But here have a conflict when relate it with DWT=0 WriteNoSnp, that means it also needs to follw the ReturnTxnID==TxnID, but in the same chapter, it says "When DoDWT = 0, ReturnTxnID can take any value, and the value is not used in any response." That means the ReturnTxnID has no relationship with TxnID.
The second conflict relates to the description in Figure B2.26: ID value transfer in a Read request with ReadReceipt and CompAck. This figure illustrates the DMT=0 scenario, yet only TxNID information is shown. This implies that ReturnTxNID can be ignored in the discussed scenario.
After reviewing the specification, these inconsistencies have caused some confusion on our side.
Could you please clarify which definition is correct?
Best Regards,
Xi Wang
For read, the SN doesn't need to consider whether it should follow a DMT flow or not, it just returns the data as is indicated by the ReturnTxnID and ReturnNID. HNF determines whether to apply a DMT, by setting the ReturnNID to RN or to the HN itself. But for write, DoDWT bit is always needed, to indicate whether DWT is applied or not. Unlike DMT where there is only return message the needs to decide where to go, write might have two different messages to decide where to go. And that's why if DoDWT works, you don't need to constraint more on the ReturnTxnID, it can be simply ignored.