Two ADRV9009 EVAL Boards on ZCU102

Please refer to the below post:

https://ez.analog.com/linux-device-drivers/linux-software-drivers/f/q-a/99855/adrv9009-on-zcu102/297565#297565 

Refer to the RFPLL phase synchronization section in UG for more details on MCS.

Hi Srimoyi and Tobe,

The given URL just confirms that we can use 2 ADRV9009s on ZCU102, but does not mention about the data synchronization between 2 boards.

In my case, I have built two separated versions - one ADRV9009 on HPC1 , the other on HPC0. Both version works flawlessly. But when combing them to create a version for 2 ADRV9009, it does not work anymore. JESD204 link cannot establish. I am investigating issues may cause this problem.

For data synchronization between 2 boards, I think they should be sourced from a common clock source for device clock and SYSREF. Do you have any further constraint for 2-boards synchronization?

Best Regards,

Trung Nguyen

Ignore this comment, found it in the ADRV900x Design Package.

If i try to similar thing according to this picture. will it work correctly. Please share any idea for bypassing the sysref from 2nd AD9528.

I used 8 TX lanes for two adrv9009. First 4 TX lanes connected with HPC1. When I connect other 4 tx lanes with HPC0 the I find GTH Transceiver Error "

[Place 30-739] Sub-optimal placement for an IBUFDS_GT / GT component pair.Processing will continue as all instances of this rule have been LOCed.

    i_ibufds_ref_clk1 (IBUFDS_GTE4.O) is locked to GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_1/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y12
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_5/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y10
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_4/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y9
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_3/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y15
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_7/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y8
     and i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_6/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y11
[Place 30-739] Sub-optimal placement for an IBUFDS_GT / GT component pair.Processing will continue as all instances of this rule have been LOCed.

    i_ibufds_ref_clk1 (IBUFDS_GTE4.O) is locked to GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_1/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y12
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_5/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y10
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_4/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y9
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_3/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y15
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_7/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y8
     and i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_6/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y11
[Place 30-510] Unroutable Placement! A GTHE_COMMON / GTHE_CHANNEL clock component pair is not placed in a routable site pair. The GTHE_COMMON component can use the dedicated path between the GTHE_COMMON and the GTHE_CHANNEL if both are placed in the same clock region. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
    < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xcm_4/qpll2ch_clk] >

    i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xcm_4/i_gthe4_common (GTHE4_COMMON.QPLL0OUTCLK) is provisionally placed by clockplacer on GTHE4_COMMON_X0Y1
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_5/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y10
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_4/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y9
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_7/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y8
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_6/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y11

    The above error could possibly be related to other connected instances. Following is a list of
    all the related clock rules and their respective instances.

    Clock Rule: rule_bufds_gthchannel_intelligent_pin
    Status: FAIL
    Rule Description: A BUFDS driving a GTHChannel must both be placed in the same or adjacent two clock
    regions (top/bottom)
     i_ibufds_ref_clk1 (IBUFDS_GTE4.O) is locked to GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_1/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y12
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_5/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y10
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_4/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y9
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_3/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y15
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_7/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y8
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_6/i_gthe4_channel (GTHE4_CHANNEL.GTREFCLK0) is locked to GTHE4_CHANNEL_X1Y11
    ERROR: The above is also an illegal clock rule
    Workaround: < set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets ref_clk1] >

    Clock Rule: rule_bufds_gthcommon_intelligent_pin
    Status: PASS
    Rule Description: A BUFDS driving a GTHCommon must both be placed in the same or adjacent two clock
    regions (top/bottom)
     i_ibufds_ref_clk1 (IBUFDS_GTE4.O) is locked to GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xcm_0/i_gthe4_common (GTHE4_COMMON.GTREFCLK00) is provisionally placed by clockplacer on GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xcm_4/i_gthe4_common (GTHE4_COMMON.GTREFCLK00) is provisionally placed by clockplacer on GTHE4_COMMON_X0Y1

    Clock Rule: rule_gthcommon_gthchannel
    Status: PASS
    Rule Description: A GTHCommon driving a GTHChannel must both be in the same clock region
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xcm_0/i_gthe4_common (GTHE4_COMMON.QPLL0OUTCLK) is provisionally placed by clockplacer on GTHE4_COMMON_X0Y3
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_1/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y12
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_3/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y15
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y13

    Clock Rule: rule_gt_bufggt
    Status: PASS
    Rule Description: A GT driving a BUFG_GT must be placed in the same clock region of the device as the
    BUFG
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.RXOUTCLK) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_rx_bufg (BUFG_GT.I) is provisionally placed by clockplacer on BUFG_GT_X0Y95

    Clock Rule: rule_gthchannel_bufgsync_rx
    Status: PASS
    Rule Description: A GTHChannel drives a BUFG_GT_SYNC pin must both be in the same clock region and
    both have to be in specific sites.
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.RXOUTCLK) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/BUFG_GT_SYNC (BUFG_GT_SYNC.CLK) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y49

    Clock Rule: rule_gthchannel_bufgsync_tx
    Status: PASS
    Rule Description: A GTHChannel drives a BUFG_GT_SYNC pin must both be in the same clock region and
    both have to be in specific sites.
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.TXOUTCLK) is locked to GTHE4_CHANNEL_X0Y13
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/BUFG_GT_SYNC_1 (BUFG_GT_SYNC.CLK) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y47

    Clock Rule: rule_gt_bufggt
    Status: PASS
    Rule Description: A GT driving a BUFG_GT must be placed in the same clock region of the device as the
    BUFG
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.RXOUTCLK) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_rx_bufg (BUFG_GT.I) is provisionally placed by clockplacer on BUFG_GT_X0Y93

    Clock Rule: rule_gthchannel_bufgsync_rx
    Status: PASS
    Rule Description: A GTHChannel drives a BUFG_GT_SYNC pin must both be in the same clock region and
    both have to be in specific sites.
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.RXOUTCLK) is locked to GTHE4_CHANNEL_X0Y14
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/BUFG_GT_SYNC (BUFG_GT_SYNC.CLK) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y55

    Clock Rule: rule_bufgsync_bufg_withGTDriver
    Status: PASS
    Rule Description: A BUFG_GT_SYNC driving a BUFG_GT must be placed in the same clock region of the device
    as the BUFG_GT
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/BUFG_GT_SYNC (BUFG_GT_SYNC.CESYNC) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y49
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_rx_bufg (BUFG_GT.CE) is provisionally placed by clockplacer on BUFG_GT_X0Y95

    Clock Rule: rule_bufgsync_bufg_withGTDriver
    Status: PASS
    Rule Description: A BUFG_GT_SYNC driving a BUFG_GT must be placed in the same clock region of the device
    as the BUFG_GT
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/BUFG_GT_SYNC_1 (BUFG_GT_SYNC.CESYNC) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y47
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_0/i_tx_bufg (BUFG_GT.CE) is provisionally placed by clockplacer on BUFG_GT_X0Y94

    Clock Rule: rule_bufgsync_bufg_withGTDriver
    Status: PASS
    Rule Description: A BUFG_GT_SYNC driving a BUFG_GT must be placed in the same clock region of the device
    as the BUFG_GT
     i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/BUFG_GT_SYNC (BUFG_GT_SYNC.CESYNC) is provisionally placed by clockplacer on BUFG_GT_SYNC_X0Y55
     and i_system_wrapper/system_i/util_adrv9009_p_som_xcvr/inst/i_xch_2/i_rx_bufg (BUFG_GT.CE) is provisionally placed by clockplacer on BUFG_GT_X0Y93

[Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.
[Common 17-69] Command failed: Placer could not place all instances
 

Please post new queries as new. You need to post above query in our FPGA support forum.

https://ez.analog.com/fpga 

Hi trungnguyen , a couple of quick questions on this.

I am trying to follow the same design of having 2 ADRV9009 eval boards on a single ZCU102.

1. What exactly is the link_layer block in the diagram given above? I was under the assumption that we only need to modify the lanes and clocks connected to util_adxcvr block.

2. For the design what steps need to be followed for generating the device tree? I have generated the device-tree using the usual process that I have done so far for projects involving only FMC1. Now how do i modify the .dtb or the procedure so that the connections for FMC0 is also included in the device-tree. Also are any changes to the linux drivers required?

Thanks,

Vignesh

For FPGA related queries , please post in our FPGA forum. https://ez.analog.com/fpga

For Linux Driver , device tree post in Linux Forum. https://ez.analog.com/linux-software-drivers/

 Post your queries as new thread and you can reference the thread in the post that you have already followed.

 Have you checked below posts.

 Designing with multiple ADRV9009 chips 

This doesn't appear to be correct.  On the ADRV9009, SYSREF_IN_CLK+/- goes to the AD9528, not the ADRV9009. Is the intention to feed SYSREF from one of the outputs on board 1's AD9528 to the SYSREF Input on board 2's AD9528, and then program the AD9528's output (SYSREF_IN+/-) on board 2 to repeat the SYS_REF_CLK_IN signal?

Thanks

Rich

I have created a new post for your question as this is a long thread, please refer below and post your problem which you are facing and also share the block diagram of clock connections between boards.

https://ez.analog.com/wide-band-rf-transceivers/design-support-adrv9008-1-adrv9008-2-adrv9009/f/q-a/561035/configuration-of-advr9009-clocking

Please refer to the below image for the clock distribution for multiple devices.

Hi, can you inform me how did you success to work on hpc0? Do we need to modify device tree?

Will be followed here:

 Is it possible to use two adrv9009 on zcu102 board independently?  

Will be followed here:

 Is it possible to use two adrv9009 on zcu102 board independently?