We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
In CHI.G Chapter B2.9.2.1 metioned that "The AllowRetry field must be asserted the first time a transaction is sent.",
but in AMBA CHI C2C spec B4,1,2 said the Request Retry flow dose not support in C2C,and AllowRetry field can not be transfer.
So is seems mismacth between two Spec, so when AllowRetry bit is after the C2C to the remote die is 0, and not satisyied the CHI spec"The AllowRetry field must be asserted the first time a transaction is sent."
Is it acceptable and any risk?
I'm looking forward to your replay.
Thanks a lot!
You're correct that there is a difference between the two protocols here, and this is expected to be handled by the C2C gateway.
Consider a system where Chip1 has an RN, and Chip2 has the assocaited HN and SN for the location being accessed.
When the RN issues the request the first time, it will do so with AllowRetry set to 1. If there are not enough available C2C request credits to snd the transaction over the C2C link, and there are no additional buffers in the C2C Tx gateway, the expecation here is that the C2C Tx gateway would give a RetryAck response back to the RN. When credits are available a PCrdGrant message can be sent from the C2C Tx gateway to the RN and the Request can be resent.
The same is then true once the Request has made it across to the C2C Rx gateway. That is, the C2C Rx gateway will set AllowRetry to 1 when it sends the request to the HN. If the HN provides a RetryAck, it is then the responsibility of the C2C Rx gateway to handle this.
The C2C link should never see RetryAck, PCrdGrant or PCrdReturn messages.
The AllowRetry and PCrdType fields are not included in C2C messages, as per Table B4.12 "CHI message fields not inlcuded in C2C messages" in CHI C2C-A.
Hope this helps.
Hi Arm
Thanks,your answer is helpful. But I still have some confusion:
1. What is the interaction interface about C2C gateway you mentioned？Also CHI？or C2C packeted in CXS？IS C2C gateway part of CMN NOC or C2C/UCIe controller?
2. What about you mentioned “C2C Rx gateway to handle this” when HN provides a RetryAck？Does it mean C2C Rx gateway will buffer this request untill PCrdGrant？
Hi Jinyu,
1. The gateway logic is ultimately what is used to convert between on-chip CHI, to packed CXS. Ultimately, it is the logic that implements the Protocol to Link Layer mapping, when viewed in reference to Figure B2.1: C2C interface structure in CHI C2C-A. This would be part of any interconnect IP, including CMN, that would then output CXS towards the Link Layer.
2 Yes, that is correct. A RetryAck message must not be sent across the C2C interface, so if the HN provides one, the C2C Rx gateway must buffer the request until PCrdGrant and then re-issue.
Ben
Hi Ben,
Since "The AllowRetry field must be asserted the first time a transaction is sent" has been mentioned in CHI.G spec, is that acceptable for all the Node in CHI Bus Architecture just disable the "Transaction Retry mechanism", and keep the "AllowRetry" always low for all kind of request transaction. What kind of risk will it lead with.
Looking forward to your reply with best regard :)
Thanks
Hi Lingfan,
Not adhering to the AllowRetry rules for the first time a transaction is sent would be a protocol violation, and would very likely cause behavioral issues. AllowRetry=0 is often interpreted as a very strict meaning, namely that a PCrdGrant allocated credit is being used. Credit counters are often acted upon by this.
The option for CHI without Retry is being considered for a future release, but I would expect this to be covered by properties and rules, rather than by changes to protocol field values. This is not something that is currently supported as of CHI-G.