AD9361 No-OS custom board with a10 fpga, TX tuning failed

let me know if more clarification is required

Are you using CMOS or LVDS interface?

Also, are you using the latest no-OS drivers? If not using latest, then please upgrade to the latest and then try initializing with the default sequence:

https://github.com/analogdevicesinc/no-OS/tree/master/projects/ad9361 

https://github.com/analogdevicesinc/no-OS/tree/master/drivers/rf-transceiver/ad9361 

https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/software/baremetal#downloads   

Hi srimoyi 

I am using LVDS interface

As for the hdl, I am using hdl_2019R1, for its compatibility with Quartus 18.1 std.

Does executing intel_serdes in non-dpa mode, affects the digital tuning of ad9361?

Also which is the best suitable hdl repository for A10+AD9361

Moving to FPGA reference designs for comments.

Hi,

there is one more observation in the design, if we try to calibrate it at LO > 3 GHz, it throws error ”Failed to restore ensm state”

Hi,

Sorry for the delay.

Prince_Punia said:

Does executing intel_serdes in non-dpa mode, affects the digital tuning of ad9361?

Active DPA helps. Ideally you wil control the PLL feeding the DPA at run time. If you create the proper constraints regarding the delays between data lines and clock, you should be fine.

Prince_Punia said:

Also which is the best suitable hdl repository for A10+AD9361

We always recommend the latest release or master branch, because we have the tools installed and have a good knowledge of the features/fixes/limitations/bugs.
But in this case, we do not have an active design supported on a10 with AD9361, and the last functional changes done on axi_ad9361 for a10 were included in hdl_2019_r2 branch.

You decide what version is better suited for you. The support we ca offer is limited in this case.

Andrei

Hi,

Sorry for the delay.

Prince_Punia said:

Does executing intel_serdes in non-dpa mode, affects the digital tuning of ad9361?

Active DPA helps. Ideally you wil control the PLL feeding the DPA at run time. If you create the proper constraints regarding the delays between data lines and clock, you should be fine.

Prince_Punia said:

Also which is the best suitable hdl repository for A10+AD9361

We always recommend the latest release or master branch, because we have the tools installed and have a good knowledge of the features/fixes/limitations/bugs.
But in this case, we do not have an active design supported on a10 with AD9361, and the last functional changes done on axi_ad9361 for a10 were included in hdl_2019_r2 branch.

You decide what version is better suited for you. The support we ca offer is limited in this case.

Andrei

Hi Andrei, 

As of now, while calibrating AD9361, it gets tuned at 25MHz, but not at 40MHz and 61.44 MHz  (In 2r2t mode)

Where as, it gets tuned at 25MHz and 40Mhz but not at 61.44 MHz (In 1r1t mode) 

I would also like to add that this is the case with RX.

In case of TX, Tuning Fails for all three rates i.e. 25Mhz, 40Mhz and 61.44MHz.

Should I add some kind of delay in tx_frame or tx_data_out?

Hi,

Ideally the delay for data and frame in regards to the tx clock should be close to none. The tuning algorithm should set the right delays at the ad9361 level.
Can you add a signal tap and look at the signals? Is there something strange on the tx side. 
I would suggest to double check the hardware connections as much as possible on the tx.
- are data/frame pins connected correctly?
- do you have test points on the FMC doughtier card or an extender/expansion card that word allow you access to the clock/frame/data lines for debug?

Andrei

Hi,

I added a few clk_buffers at rx_clk, after that ad9361 is tuning at 25 MHz for both RX and TX but failing for both 40MHz and 61.44MHz.

I just want to point out that this is the case with a10 and ad9361. So Altera serdes IP is used and that too in non-dpa mode. 

Maybe individual serdes elements (one for each tx_data_out[0..5]) are adding variable delays, due to which ad9361 is not tuning at higher data rates?

Would request your comments on this issue.

Regards

Prince

Hi,

I will have to think/consult with colleagues about this, mostly in regards with the a10 SERDES, haven't played with it in a while. From the top of my head, this should not be the case on tx, but maybe I'm missing something.

Andrei

Hi,

Some hardware things that can cause this behavior:
1. trace length mismatch
2. cross talk between clock and data/frame lines.
My suggestion is to check the above and play a bit with the drive strength of the tx pins.

Andrei

Hi Andrei,

Just a quick query about trace length. should the tx data lines and rx data lines have same trace length? 

I mean frame lines, data lines etc should all have same trace length?

Regards

Prince

Hi,


Yes, as a group, on Rx clock, frame and data should have the same trace lengths, similar for the Tx group. The interfaces are source synchronous, making Tx and Rx lines at the same trace length does not add any benefit from my point of view.

Andrei