I am using a ZCU102 board with a ADRV9009-W/PCBZ.
I noticed when I repeat following commands:
echo 1 > /sys/kernel/debug/iio/iio:device3/initializeecho 1 > /sys/bus/iio/devices/iio:device3/multichip_sync
The Rx lane latency is not always the same, sometimes it is:
/sys/bus/platform/devices/84aa0000.axi-jesd204-rx/lane0_info:Lane Latency: 1 Multi-frames and 102 Octets
/sys/bus/platform/devices/84aa0000.axi-jesd204-rx/lane0_info:Lane Latency: 1 Multi-frames and 103 Octets
When I only repeat the multichip_sync command, then the Lane latency will keep increasing.
Is this normal behavior?
Where can I find the tx latency? (Now I use "grep "" /sys/bus/platform/devices/*.axi-jesd*/lane*")
The complete MCS is a 12 step sequence, which must be performed at all to sync devices in parallel.
Tx latency must be read from the device itself, IIRC there is no API for that.
But how can I have deterministic latency with a single device?
In my test setup, I have loop-back from Tx port to the Rx. I want to decimate my Rx stream with factor of 12. The alignment is done to the sysref puls. This would only be correct if the lane latency is fixed or known.
Could it be fixed? Then the remaining error would be an offset.
If I know what the Tx and Rx latency is, I could compensate this in hdl. On which forum, shall I ask the question about the Tx latency?
Latency can be defined as deterministic when the time from the input of the JESD204x transmitter to the output of the JESD204x receiver is consistently the same number of clock cycles
There is always lane to lane latency. The overall latency should still be deterministic.
In Subclass1 we're using an additional synchronization signal (SYSREF), which has a fixed relationship with the device clocks and provides a deterministic release point for the elastic buffer, which can provide a big enough margin to absorb the non-deterministic delays of the interface...
Moving to HDL forum now
mhennerich said:Latency can be defined as deterministic when the time from the input of the JESD204x transmitter to the output of the JESD204x receiver is consistently the same number of clock cycles
So, if I receive:
And in a reboot I get:
I can conclude that there is something wrong?
JV-IE said:I can conclude that there is something wrong?
No - looks good - latency depends on Process, Voltage and Temperature (PVT).