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.