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

Hi,

Apologies for the delayed reply.

Could you take a look at page 29 and page 15? https://docs.amd.com/v/u/en-US/ug578-ultrascale-gty-transceivers 

And check carefully what quad you select since the clock and the data should be as close as possible.

Using the GT Wizard from Vivado GUI might help you to choose the right pins/quads (looks like this https://docs.amd.com/viewer/attachment/U2GQR49CyPTcdLAya2_2Xg/ppnGOig73uz9Jtlw8tHPkw)

Here we have an example with 4 devices: https://github.com/analogdevicesinc/hdl/blob/main/projects/adrv9009zu11eg/adrv2crr_fmcomms8/system_project.tcl 

Best regards,
Iulia

i need to force the util_adrv9009_xcvr ip core to use the following GTHE4 Channels:

X1Y11; X1Y10 => QUAD X1Y2 => external clock coming to CLK0

X1Y5; X1Y4    => QUAD X1Y1 => clock from CLK0 of QUAD X1Y2

X0Y13; X0Y12 => QUAD X0Y3 => external clock coming to CLK0

X0Y9; X0Y8    => QUAD X0Y2 => clock from CLK0 of QUAD X0Y3

how i can achieve this configuration?

thanks.

Hi,

It is just a mater of constraints, chose the corresponding pins.
https://github.com/analogdevicesinc/hdl/blob/main/projects/adrv9009zu11eg/adrv2crr_fmcomms8/fmcomms8_constr.xdc#L29-L44

As Iulia pointed out, you should check the transceiver user guide, You will find there that the reference clock from a quad can drive only the adjacent quads.

Andrei

The UTIL_ADXCVR is a wrapper that instantiates transceiver quads, which are also full banks. For 4 channels it instantiates a quad common. The transceiver quads have fixed pinouts for each specific channel. When a channel is instantiated, the pinout for both TX and RX are fixed, there is not flexibility as compared with other general FPGA pins.

When doing the PCB design, ideally you should use pins from the same quad and adjacent quads. The reference clock should come from the dedicated clock pins of the quad. Depending on the lane rate, you can use also clocks from the quad above and quad below or quad 2 positions above and below.

Can you tell me what banks you have in your design and where does the clock comes from?

The UTIL_ADXCVR is a wrapper that instantiates transceiver quads, which are also full banks. For 4 channels it instantiates a quad common. The transceiver quads have fixed pinouts for each specific channel. When a channel is instantiated, the pinout for both TX and RX are fixed, there is not flexibility as compared with other general FPGA pins.

When doing the PCB design, ideally you should use pins from the same quad and adjacent quads. The reference clock should come from the dedicated clock pins of the quad. Depending on the lane rate, you can use also clocks from the quad above and quad below or quad 2 positions above and below.

Can you tell me what banks you have in your design and where does the clock comes from?

Certainly! Below is the FPGA pin configuration (xczu9eg-ffvb1156-2-e) used in conjunction with the GTH transceivers for the initial project, which featured a JESD204 interface driving 8 SoCs. This configuration has been tested and is functioning correctly:

However, in the new project, the board will remain unchanged, but the FPGA configuration will be modified. The desired configuration is as follows:

But Vivado gives me an error when I try to synthesize and implement it this way... assuming I have configured the util_xcvr block correctly.

We need some tests, but for this pinout you'll need to instantiate all 4 quads and it will complicated to use the other transceivers for other applications.

Is there any way to change the PCB pinout ?

Regards,

Adrian

Unfortunately, the board, and therefore the PCB, cannot be modified, meaning the routing of the various chips on the PCB cannot be changed. We need to explore an FPGA-based solution, where feasible, to implement the configuration outlined in the table.

One option would be to instantiate the util_adxcvr similar with the  older solution (16 channels) and only connect the pins you are using. Not sure how the tool will handle the other channels, so needs some exploration.

Another option would be to split the design similar with what we've done here: AD9208-DUAL-EBZ HDL reference design [Analog Devices Wiki] so you'll have a physical layer per adjacent banks. in this case you can probably instantiate the number of lanes to 6 per util_adxcvr, which will allow you to have two quad common and 4 channels.

On top of the vivado implication, there may be also software implications when you bring up the system.

Regards,

Adrian

Regarding the first option, we have already tried implementing a similar solution in Vivado, but it didn't work as expected. Vivado seems to struggle with it, and, from a software perspective, managing it would be overly complicated.

The second option, splitting the design and following the AD9208-DUAL-EBZ HDL reference design approach, could be a viable path. However, this would require significant software development effort to accommodate the change, so it’s important to assess whether we can handle the workload involved.

What I would like to understand more clearly is whether it is possible to synthesize and implement the project with the configuration we have in mind for the util_xcvr, as summarized in the simplified table below:

• X1Y11; X1Y10 => QUAD X1Y2 => external clock to CLK0
• X1Y5; X1Y4 => QUAD X1Y1 => clock from CLK0 of QUAD X1Y2
• X0Y13; X0Y12 => QUAD X0Y3 => external clock to CLK0
• X0Y9; X0Y8 => QUAD X0Y2 => clock from CLK0 of QUAD X0Y3

I need to determine whether this configuration is feasible, as it directly impacts the project. If this approach is not possible, we would likely need to redesign the PCB, which would lead to significant development costs and delays. The sooner we can confirm this, the better.

Additionally, I have another question: If we were to only implement the following configuration:

• X1Y11; X1Y10 => QUAD X1Y2 => external clock to CLK0
• X0Y13; X0Y12 => QUAD X0Y3 => external clock to CLK0

Would Vivado be able to synthesize and implement this setup successfully? Understanding this will help us determine if the implementation issue is due to using adjacent QUADs. According to Vivado’s wizard for managing GTHE4, it should be possible to supply the clock from one QUAD to the next, either from above or below, so I’d like to confirm if this holds true in practice.

I appreciate your insights on these points.

Regarding this:

• X1Y11; X1Y10 => QUAD X1Y2 => external clock to CLK0
• X1Y5; X1Y4 => QUAD X1Y1 => clock from CLK0 of QUAD X1Y2
• X0Y13; X0Y12 => QUAD X0Y3 => external clock to CLK0
• X0Y9; X0Y8 => QUAD X0Y2 => clock from CLK0 of QUAD X0Y3

You mean to create 4 util_adxcvr's each with two channels ?  All of these inside a single util_adxcvr won't be possible, except when instantiating for 16 channels.

I think the reference clocks should be fine when comming from adjacent quad.

Regards,

Adrian

No, I mean to create a single util_adxcvr that can manage the configuration I described to you.

What solution would you suggest?

Hi! Apologies for the very late reply, but we missed your thread somehow.

Did you manage to do something in the meantime?

Regrettably, the issue remains unresolved on our side. We’re counting on your valuable assistance to help us unlock the situation