Scalability of the IP core "util_adrv9009_xcvr" from managing 8 SoCs ADRV9009 to 4 SoCs ADRV9009

Good morning everyone,

I have taken over a project that features a JESD204 link with 16 channels (managing 8 ADRV9009 chips).

This project originated from Analog Devices' reference design, which was modified to work with 16 channels.

We are now creating a new project with a similar architecture, but the number of channels is reduced from 16 to 8, meaning we will only control 4 ADRV9009 chips.

The FPGA target is XCZU9EG-FFVB1156-2-e

Thus, the previous JESD204 parameters, which were:

1. Number of Lanes (L) = 16
2. Number of Converters (M) = 32
3. Bits per Sample (N') = 16
4. Converter Resolution (N) = 16
5. Samples per Frame (S) = 1
6. Octets per Beat = 4

have now been changed to:

1. Number of Lanes (L) = 8
2. Number of Converters (M) = 16
3. Bits per Sample (N') = 16
4. Converter Resolution (N) = 16
5. Samples per Frame (S) = 1
6. Octets per Beat = 4

The outputs of the IP core "util_adrv9009_xcvr" (such as tx_0_p, tx_0_n, etc.) are connected to specific pins that are fixed at the PCB level and route the signals to the different ADRV9009 chips. Here’s the current mapping:

#set_property -dict {PACKAGE_PIN K6} [get_ports tx_data_a_p[0]] (tx_0_p)
#set_property -dict {PACKAGE_PIN K5} [get_ports tx_data_a_n[0]] (tx_0_n)
#set_property -dict {PACKAGE_PIN H6} [get_ports tx_data_a_p[1]] (tx_1_p)
#set_property -dict {PACKAGE_PIN H5} [get_ports tx_data_a_n[1]] (tx_1_n)

#set_property -dict {PACKAGE_PIN K2} [get_ports rx_data_a_p[0]] (rx_0_n)
#set_property -dict {PACKAGE_PIN K1} [get_ports rx_data_a_n[0]] (rx_0_n)
#set_property -dict {PACKAGE_PIN J4} [get_ports rx_data_a_p[1]] (rx_1_p)
#set_property -dict {PACKAGE_PIN J3} [get_ports rx_data_a_n[1]] (rx_1_n)

With this configuration, the project synthesizes successfully. However, I need to remap the tx_0_p, tx_0_n, etc., to different pins, such as the tx_data_c_p pins, and when I make this change, the project no longer implements, and I get the following error:

[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 suboptimal 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_xcvr/inst/i_xcm_0/qpll2ch_clk] >

i_system_wrapper/system_i/util_adrv9009_xcvr/inst/i_xcm_0/i_gthe4_common (GTHE4_COMMON.QPLL0OUTCLK) is provisionally placed by clockplacer on GTHE4_COMMON_X1Y3
i_system_wrapper/system_i/util_adrv9009_xcvr/inst/i_xch_0/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y5
i_system_wrapper/system_i/util_adrv9009_xcvr/inst/i_xch_1/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X1Y4
i_system_wrapper/system_i/util_adrv9009_xcvr/inst/i_xch_2/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y9
i_system_wrapper/system_i/util_adrv9009_xcvr/inst/i_xch_3/i_gthe4_channel (GTHE4_CHANNEL.QPLL0CLK) is locked to GTHE4_CHANNEL_X0Y8

I understand that there is an issue with the GTHE components, but I am unsure how to instruct Vivado which specific GTHE to use for the designated output pins. The "util_adrv9009_xcvr" IP core does not offer many configurable options beyond a few parameters related to frequency management. How should I proceed to resolve this issue?

I appreciate your help in advance.