SPRUIL1D May 2019 – December 2024 DRA829J , DRA829J-Q1 , DRA829V , DRA829V-Q1 , TDA4VM , TDA4VM-Q1
The Replay Timer of one device is closely connected to the Request Timer on the other device of the link. In general, one Replay Timer for each traffic class is running when transmitted frames are not acknowledged yet and is reset every time a new frame is sent or one or more frames are acknowledged. This timer protects the protocol against lost AFC or NAC frames. When for a period of DL_TC0ReplayTimeOutVal µs when no AFC is received and no new frame is sent for this traffic class, the timer expires and the link is re-initialized automatically and a retransmission is started.
An UFS device has two methods of generating an AFC frame for acknowledging data reception. The DL_TC0OutAck - Threshold value + 1 defines the number of received frames before an AFC is automatically generated. In addition, the AFC Request Timer at the receiver is used to trigger AFC generation before the Replay Timer at the transmitter is expired even when the DL_TC0OutAckThreshold value is not reached.
To secure proper operation, the AFC Request Timer needs to be programmed to a significantly smaller value than the Replay Timer on the other side. The configuring application should take care that the Replay Timer value includes the AFC Request value, internal processing of a new AFC frame generation, and transmission over the link. To be on the safe side, the local Request Timer should be programmed with a value twice the remote AFC Request Timer value. With this rule the allowed accuracy of the timers of ±10% should also be accounted for.
The AFC Request Timer should also have a quite high minimum value in order to not generate more AFC frames than actually needed. The following formula gives a general guideline for programming these two timer values.
1024 ≤ 2 × DL_AFC0RequestTimeOutVal ≤ DL_TC0ReplayTimeOutCal ≤ 4095;