| SLA Status | Assignee | Support Status |
|---|---|---|
| SLA Closed. | Open | |
from UG-1295:
When establishing a JESD204B link, it is desirable that the data arriving to the deframer does not arrive very close to an LMFC boundary. If this does happen, the deterministic latency can vary from system to system if the data on one system arrives just before an LMFC event, and arrives on another system just after an LMFC event. If this happens, there is an LMFC period difference in the latency between the systems. Furthermore, the architecture in the device does not support a very small delay through the FIFO, and data corruption occurs if the delay is too small. Therefore, it is important that the FIFO depth be checked after the link is established, and the link is adjusted to achieve a FIFO depth that is close to the medium depth. The FIFO depth can be checked in Register 0x15CE for Deframer 0 and in Register 0x161E for Deframer 1. Write to the appropriate register with a value of 0x80 to latch the current FIFO depth, and then read back. The readback value is reported as a signed, twos complement number located in Bits[D5:D0] of the register with valid values from +K2 to −(K/2 − 1). The value reported is the difference of the number of frames between the read and write pointers. If the value is found to be close to 0, for example, −2, −1, 0, +1, or +2, adjust the depth by varying the LMFC offset parameter on either end of the JESD204B link. Note that across multiple system starts, the depth in the FIFO can vary by one or two frames. This variation is expected because sampling phase uncertainties are absorbed by the FIFO to give deterministic latency. Consider this fact when optimizing the JESD204B link and performing multiple system starts to find the worst case depth values for a given LMFC offset.
root@zynq:/usr/bin# iio_reg adrv9009-phy 0x15CE
0x39
root@zynq:/usr/bin# iio_reg adrv9009-phy 0x161E
0x10
I have a few questions about this part of the user manual:
1) Which result is applicable for me? Is "tx-settings-deframer-sel" reflecting the number of the deframer? This is the info from my device three, deframer-b is not used:

2) from ug "Write to the appropriate register with a value of 0x80 to latch the current FIFO depth, and then read back"
This doesn't seems to have an effect, is my method correct? Are was it already been updated during boot?
root@ZCU102-A:/usr/bin# iio_reg adrv9009-phy 0x15CE
0x39
root@ZCU102-A:/usr/bin# iio_reg adrv9009-phy 0x15CE 0x80
root@ZCU102-A:/usr/bin# iio_reg adrv9009-phy 0x15CE
0x39
root@ZCU102-A:/usr/bin#
3) from ug "The value reported is the difference of the number of frames between the read and write pointers."
Is this correct?
write pointer: ADRV9009
read pointer: FPGA
I expected a result compared to the multiframe boundary? How can you read before the data is written (negative and positive results)?
4) from ug " If the value is found to be close to 0, for example, −2, −1, 0, +1, or +2, "
my result is -7, so this seems to be within specification
What if my result is 31 or -31, when do I reach the other end of the boundary? Is there a upper limit as well?
1. Looks correct.
wiki.analog.com/.../adrv9009-customization
2. No . Both read and write are for ADRV9009 as explained below #3. For queries on linux SW driver implementation, Please post this query in our Linus Software forum. https://ez.analog.com/linux-software-drivers/
3 Regarding FIFO depth , FIFO depth size is 32 frames and the value read back wil be from +16 to -15. The read pointer us at 0 and the value read back is the difference.

4. FIFO depth of -7 is good. See reading it on multiple boots , it should change by more than 1 or 2.