Lane Latency

The complete MCS is a 12 step sequence, which must be performed at all to sync devices in parallel.

https://github.com/analogdevicesinc/linux_image_ADI-scripts/blob/master/adrv9009_multichip_sync.sh

Tx latency must be read from the device itself, IIRC there is no API for that.

mhennerich said:

The complete MCS is a 12 step sequence, which must be performed at all to sync devices in parallel.

Do I have to synchronize the 12 step procedure on both devices simultaneous. Or can I put the sysref source to continuous an run the mcs sequence on device1 and a few seconds later on device2?

mhennerich said:

The complete MCS is a 12 step sequence, which must be performed at all to sync devices in parallel.

Do I have to synchronize the 12 step procedure on both devices simultaneous. Or can I put the sysref source to continuous an run the mcs sequence on device1 and a few seconds later on device2?

It depends on how many deframers are used. If you are using single deframer at FPGA you need to run simultaneously. If they are different framers/ deframers then you can send it sequentially or simultaneously.

I have two zcu102 boards, each connected to an ADRV9009. I have an extra PLL board with the AD9528  on it, which provides sysref and device_clock to both platforms with  ADRV9009 and FPGA. I have used following hdl design:  https://github.com/analogdevicesinc/hdl/tree/adrv9009_zcu102_2_tx_lanes

I use Deframer A and Framer A for Tx and Rx on each platform.

What shall I do? Is sequentially enough?

At this moment I run it sequentially, but if I compare both Tx outputs on a VNA, the phase will jump after each 12 step mcs sequence. And it seems to result in 4 different phase diff positions. If I compare Tx to Rx, I don't have this issue. This let me to the conclusion that the RFLO is not properly phase synchronized.

I don't understand why there is a difference in mcs procedure (parallel or sequential), when using a single framer/deframer or different framers/deframers.

If it is an evaluation board setup , you do not need a separate AD9528. Please see below post.

https://ez.analog.com/wide-band-rf-transceivers/design-support-adrv9008-1-adrv9008-2-adrv9009/f/q-a/105981/two-adrv9009-eval-boards-on-zcu102

here same AD9528 supplies the clock and you can run both inits  together. If you plan to run sequentially you need to program AD9528 to generate required sysref pulses for both chips. 

Vinod said:

If you plan to run sequentially you need to program AD9528 to generate required sysref pulses for both chips

Is it enough to set the AD9528-1 sysref pattern mode to "continuous" instead of "N shot"?

Will "continuous" be a problem for step 8 in mcs sequence? (https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/adrv9009.c#L1212)

Or do I need to gate the sysref pulses with the AD9528-2 when I walk trough 12 step mcs procedure?

I need deterministic phase and lane latency.

But it is still unclear for me, if I can run both mcs 12 steps sequentially? Which is easier to implement.

In case sequentially is not an option, I need to generate the sysref pulses at the same time for both platforms. But if I look at mcs step 8 (https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/adrv9009.c#L1212), I need to disable and enable the sysref pulses in one step. So I need to subdivide the mcs sequence, so I could synchronize the sysref pulses for each step for both platforms.

I currently use the adrv9009_multichip_sync.sh commands too run the 12 steps. I will replace this method if sequentially is not an option with a common TCP/IP socket, to sync the mcs sequence).

mhennerich said:

github.com/.../quote]