This question is only related to AD9361 HDL design vs specific Ultrascale board. DDR, pinouts, routing, timing, etc in relation to the carrier board is not what I am concerned at the moment.
I am planning a project to port the existing AD9361 HDL reference design to TRENZ Ultrascale xczu4cg FPGA (https://shop.trenz-electronic.de/en/TE0803-03-4AE11-A-MPSoC-Module-with-Xilinx-Zynq-UltraScale-ZU4CG-1E-2-GByte-DDR4-5.2-x-7.6-cm?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0803/REV01).
For planning purposes I need to understand if there is any show stopper that I should consider here? Or if there are no big alarms how about the I and O SERDES? Does zcu102 design have everything I need? Is there anything I need to modify in that AD9361 core? I didnt fully understand how is SERDES really used in the AD9361 design but I noticed that ISERDES2 (instead of 3) is used in /xilinx/xommon/ad_serdes_in.v but that doesnt seem to be instatinated anywhere (or I didnt see it).
I have seen several threads on this forum for similar topic but nothing is really answering what I am after? I read the porting doc https://wiki.analog.com/resources/fpga/docs/hdl/porting_project_quick_start_guide.
Any comments will be much appreciated. Many thanks,
The ad9361 does not use SERDES macros. Look at xilinx/common's ad_data_in.v, ad_data_out.v, and ad_data_clk.v to see what macros are used in the low level. As you will see we're using simple IO buffer…
The ad9361 does not use SERDES macros. Look at xilinx/common's ad_data_in.v, ad_data_out.v, and ad_data_clk.v to see what macros are used in the low level. As you will see we're using simple IO buffer and IO delay controllers.
What is your targeted interface type, CMOS or LVDS? You should not have any big show stopper.
Thanks Istvan for the reply. Much appreciated.
Very nice! Understood! Good to know.
The interface type is LVDS. So hopefully it all should be ok (will know in couple of weeks when I get to it :)).
It has been a while wrt this but I managed to create the project, synthesise and implement on the carrier board. But getting the RX Tune failures now. :(
dmesg | grep ad9[ 1.683564] ad9361 spi1.0: ad9361_probe : enter (ad9364)[ 3.194753] ad9361 spi1.0: ad9361_probe : enter (ad9364)[ 3.436756] ad9361 spi1.0: ad9361_probe : AD936x Rev 2 successfully initialized[ 3.454850] cf_axi_dds 99024000.cf-ad9361-dds-core-lpc: Analog Devices CF_AXI_DDS_DDS MASTER (9.00.b) at 0x99024000 mapped to 0xffffff8009165000, probed DDS AD9364[ 4.001462] ad9361 spi1.0: ad9361_dig_tune_delay: Tuning RX FAILED![ 4.008271] cf_axi_adc: probe of 99020000.cf-ad9361-lpc failed with error -5
Not sure why. I used HDL 2018_r2.
Also I am a bit confused reading this https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/interface_timing_validation. It looks above that dds was initialised correctly. Which means that transmit path from FPGA to AD9364 is ok, right? It is the path from AD to FPGA that fails? That timing doc suggests that first receive path is tuned (which makes sense) and then the transmit path. According to that timestamps above it is other way around? What am I missing? Also any suggestions for tackling the tuning? I have read a few forum questions on this and tried most of them.
We have similar boards that work well and the same routing is applied here. And yes these are costume boards.
Did you try to run that little script? (bist_timing_analysis)
Thanks. I did but it turns out that a resistor was missing on the custom carrier board which is related to the RX clock from the AD9361. Sorted now. :)