Post Go back to editing

Questions about AD9082-FMCA-EBZ board

Category: Software
Product Number: AD9082-FMCA-EBZ, AD9082

Hello,

One of our customers has the following questions:  

A few months ago, my company bought an AD9082-FMCA-EBZ board. We are going to use the “AD9082-FMCA-EBZ board” with an “Mercury XU8 SoC and ST1 board” from the Enclustra company (basically the Mercury XU8 SoC is a Xilinx Zynq

UltraScale+ MPSoC Module).



Based on the hdl (https://urldefense.com/v3/__https://github.com/analogdevicesinc/hdl__;!!A3Ni8CS0y2Y!6A7y31gGLhzNc9kx_WB1UwuZNVYRXikd5CN-CFvonnW0aOwVgcC_xGFP36XHpeYtiD_7dqe0qL2uLUzR9t73Zg$ ) for a ZCU102, I have made the modifications to adapt the hdl for Mercury XU8/ST1. The modified design considers the same clock for transmission and reception (due to available pins on the FMC connector of Mercury XU8/ST1, we use clkin10_n/p while clkin6_n/p are not used).



To build the embedded Linux I configured the tools and I was able to build the Linux using Petalinux for the ZCU102 case. I have tried to replicate the same steps for the Mercury XU8/ST1 and found the following

limitations:



---------------------------------------

Case 1: usign meta-adi git repository



* There is no coincidence between the versions of Enclustra and ADI to build embedded Linux. Enclusta provides the BSP files (https://urldefense.com/v3/__https://github.com/enclustra/Mercury_XU8_ST1_Reference_Design/releases__;!!A3Ni8CS0y2Y!6A7y31gGLhzNc9kx_WB1UwuZNVYRXikd5CN-CFvonnW0aOwVgcC_xGFP36XHpeYtiD_7dqe0qL2uLUzNNn0m0Q$ ) for Petalinux versions 2020.1 / 2020.2 / 2022.1. While ADI provides the meta-adi (https://urldefense.com/v3/__https://github.com/analogdevicesinc/meta-adi__;!!A3Ni8CS0y2Y!6A7y31gGLhzNc9kx_WB1UwuZNVYRXikd5CN-CFvonnW0aOwVgcC_xGFP36XHpeYtiD_7dqe0qL2uLUxzUhDNIQ$ ) for Petalinux versions 2018_R2 / 2019_R1 / 2019_R2 / 2021_R1 / 2021_R2 / 2022_R2 / 2023.1.



* I have not found a document that explains the proper way to create ‘device tree’ files (for example zynqmp-zcu102-rev10-ad9082-m4-l8.dts).

To build embedded Linux I need the  device tree files adapted to the Mercury XU8/ST1.



---------------------------------------

Case 2: using pbeltram git repository



* In the ADI EngineerZone, I found the following post:

https://ez.analog.com/fpga/f/q-a/573360/enclustra-st1-xu8-and-ad-fmcomms3-ebz/504460

The publication says that it worked with AD-FMCOMMS3-EBZ and the Mercury XU8/ST1, and access is also given to the git repository. I have followed the steps to build embedded Linux but like the previous case I do not have the device tree files.



* I manage to generate some device tree files by following the steps provided in https://urldefense.com/v3/__https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842279/Build*Device*Tree*Blob__;Kysr!!A3Ni8CS0y2Y!6A7y31gGLhzNc9kx_WB1UwuZNVYRXikd5CN-CFvonnW0aOwVgcC_xGFP36XHpeYtiD_7dqe0qL2uLUwNxCdeFw$ , in the generated files I do not find any reference to adi (axi_ad9081_adxcvr_rx, axi_ad9081_core_tx, adi,jesd-links, ad9081_adc0, ad9081_dac0, etc).

---------------------------------------



I have the following questions:



1). Could you generate the device tree files for the case of AD9082-FMCA-EBZ and Mercury XU8/ST1, or provide me with a guide on how to write these files?



2). For building embedded Linux, what steps and strategies can you recommend (case 1, case 2, or another more generic case that you know of)?



3). For another application we are going to use the AD9082-FMCA-EBZ but with another Zynq UltraScale+ model, do you know a generic method or flow for building embedded Linux?



I attach the system_top.xsa file generated with the hdl repository (adapted for AD9082-FMCA-EBZ and Mercury XU8/ST1) and the vivado 2020.2 version.

Please contact me directly so I can share the xsa file mentioned above.

Thanks

Alex Moreira

Thread Notes

Parents
  • 1). Could you generate the device tree files for the case of AD9082-FMCA-EBZ and Mercury XU8/ST1, or provide me with a guide on how to write these files?

    Unfortunately we can't do that for you.

    Please take a look here:

    1. https://github.com/analogdevicesinc/linux/blob/main/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev10-ad9081-default.dtsi
    2. https://github.com/analogdevicesinc/linux/blob/main/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-rev10-ad9082-m4-l8.dts

    This will be very similar to yours.

    The first one has the device nodes for the PL side.

    While the second one has the nodes for the SPI devices in the PL.

    2). For building embedded Linux, what steps and strategies can you recommend (case 1, case 2, or another more generic case that you know of)?

    I would use meta-adi

    Please follow the instructions on the README.md here: (Adding a new Devicetree)

    https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx

    3). For another application we are going to use the AD9082-FMCA-EBZ but with another Zynq UltraScale+ model, do you know a generic method or flow for building embedded Linux?

    You can also follow this guide here:

    https://wiki.analog.com/resources/tools-software/linux-build/generic/zynqmp

    That's what most people do. 

    -Michael

  • Hello,

    Please see below response from customer:

    As suggested, in the devicetree file adi,axi-pl-fifo-enable has been added as follows:

     

    &axi_ad9081_core_tx {

    adi,axi-pl-fifo-enable;

    };

     

    &axi_ad9081_core_rx {

    adi,axi-pl-fifo-enable;

    };

     

    Unfortunately the results have not changed much, the problem still persists.

    I attach a new figure from IIO Oscilloscope.

     

    By executing the iio_attr -D hmc7044 status command we have:

    ST1ME-XU8-4CG-1E-D11E:~# iio_attr -D hmc7044 status

    --- PLL1 ---

    Status: Locked

    Using: CLKIN0 @ 100000000 Hz

    PFD: 1000 kHz

    --- PLL2 ---

    Status: Locked (Synchronized)

    Frequency: 3000000000 Hz (Autocal cap bank value: 13)

    SYSREF Status: Valid & Locked

    SYNC Status: Synchronized

    Lock Status: PLL1 & PLL2 Locked

    ST1ME-XU8-4CG-1E-D11E:~#

     

    Is this a correct result?

    The other suggestions to isolate the error are not yet done. I will send you the results as soon as possible.

     

    -------------------------------------------

    Regarding the questions asked:

     

    Can they confirm that their Vivado design successfully passes timing ?

    Our design successfully passes timing.

     

    One thing that confuses me a bit, is that the jesd_status_RX doesn’t seem to show lane related data. I need to check if it’s the case for our 2022 release. It would be interesting to know if there are reported errors on the lanes.

    The jesd_status does not show lane related data (as a note, when the AD9082-FMCA-EBZ board was tested on a zcu102, jesd_status also did not show the data related to the lane).

    The attached file called “jesd204-rx lane_info mexu8st1.txt” contains the information obtained by executing:

    grep "" /sys/bus/platform/drivers/axi-jesd204*/*/status /sys/bus/platform/drivers/axi-jesd204*/*/lane* /sys/bus/platform/drivers/axi-jesd204*/*/encoder

    ST1ME-XU8-4CG-1E-D11E:~# grep "" /sys/bus/platform/drivers/axi-jesd204*/*/status /sys/bus/platform/drivers/axi-jesd204*/*/lane* /sys/bus/platform/drivers/axi-jesd204*/*/encoder
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Link is enabled
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Measured Link Clock: 249.998 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Reported Link Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Measured Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Reported Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Desired Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Lane rate: 10000.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Lane rate / 40: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:LMFC rate: 31.250 MHz
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:Link status: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:SYSREF captured: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/status:SYSREF alignment error: No
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Link is enabled
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Measured Link Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Reported Link Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Measured Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Reported Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Desired Device Clock: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Lane rate: 10000.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Lane rate / 40: 250.000 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:LMFC rate: 31.250 MHz
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:SYNC~: deasserted
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:Link status: DATA
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:SYSREF captured: Yes
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/status:SYSREF alignment error: No
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:Lane Latency: 3 Multi-frames and 7 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:DID: 0, BID: 0, LID: 2, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:FCHK: 0x89, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane0_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:Lane Latency: 3 Multi-frames and 6 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:DID: 0, BID: 0, LID: 0, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:FCHK: 0x87, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane1_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:Lane Latency: 3 Multi-frames and 6 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:DID: 0, BID: 0, LID: 7, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:FCHK: 0x8E, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane2_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:Lane Latency: 3 Multi-frames and 6 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:DID: 0, BID: 0, LID: 6, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:FCHK: 0x8D, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane3_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:Lane Latency: 3 Multi-frames and 3 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:DID: 0, BID: 0, LID: 5, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:FCHK: 0x8C, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane4_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:Lane Latency: 3 Multi-frames and 8 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:DID: 0, BID: 0, LID: 4, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:FCHK: 0x8B, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane5_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:Lane Latency: 3 Multi-frames and 6 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:DID: 0, BID: 0, LID: 3, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:FCHK: 0x8A, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane6_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:Errors: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:CGS state: DATA
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:Initial Frame Synchronization: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:Lane Latency: 3 Multi-frames and 6 Octets
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:Initial Lane Alignment Sequence: Yes
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:DID: 0, BID: 0, LID: 1, L: 8, SCR: 1, F: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:K: 32, M: 4, N: 16, CS: 0, N': 16, S: 1, HD: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:FCHK: 0x88, CF: 0
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:ADJCNT: 0, PHADJ: 0, ADJDIR: 0, JESDV: 1, SUBCLASS: 1
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/lane7_info:FC: 10000000
    /sys/bus/platform/drivers/axi-jesd204-rx/84a90000.axi-jesd204-rx/encoder:8b10b
    /sys/bus/platform/drivers/axi-jesd204-tx/84b90000.axi-jesd204-tx/encoder:8b10b
    ST1ME-XU8-4CG-1E-D11E:~#
    

    Additional information Feb 07th >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    I attach the figures that show the results using test mode RAMP.

     

    To use the Eye Scan tool, in the links provided it is not clear how the installation is carried out, and I have not found a document that explains it.

    Is there a document that clarifies the installation mode and configuration?

     

    On the other hand, the Mercury XU8/ST1 has 2GB DDR4 memory in the PS part. Reviewing the address map of the HDL architecture (see the figure called “address map - mexu8st1”), apparently the Mercury XU8/ST1 would require more than 2GB, is this correct?

       

      

  • Hi,

    I can comment only regarding this error:

    ERROR: [IP_Flow 19-3452] Invalid long/float value '' specified for parameter 'HBM sections per master(HBM_SEGMENTS_PER_MASTER)' for BD Cell 'storage_unit'.

    It was solved in this commit, but on the main branch. This didn't get the chance to be merged into hdl_2022_r2, and it won't be. https://github.com/analogdevicesinc/hdl/commit/608044d1245bb6d3ac05512a8e1132523c695994. You can cherry-pick it though. This error was discovered only when porting to Vivado 2023 versions, as before it wasn't reported somehow...

    Regards,
    Iulia

  • On ultrascale devices, theoretically we could go up to about 16.3 Gbps and our default design is 15Gbps for AD9082. If we take 8 lanes and 8B10B encoding, we have a bandwidth of 12GB/sec, so the PL DDR cannot keep up with that. Another thing to look at efficiencies of the DDR transfers, they may be 40-75% in a real system.  A use case with 10GBps lane rate will give 8 GB/sec requirements, which is kind of at the limit.

    However, depending on the application, this may be enough.

    Regards,

    Adrian

  • Hi Adrian, Iulia and Michael,

    Our customer has further observations and questions:

    I will share the four attachments via email.

    -----------------------------------------------------------------

    We have stopped using Ultra RAMs, now we only use BRAMs in the HDL design. Everything works normally when using the ADI IIO-Oscilloscope. When performing a python example test using pyadi-iio, we get the following message in the UART terminal:

    ad9081 spi1.0: channel ftw is not updated

     

    -----------------------------------------------------------------

    On the other hand, in our application we want to work only with real data (Total DCM = 1 and Total Interpolation = 1). Considering Tx Lane rate = Rx Lane rate = 10Gsps, Tx core clock = Rx core clock = Lane rate / 40 = 250 MHz, ADC rate = 2 Gsps, and DAC rate = 2 Gsps, we find the following parameters in the document called “AD9081/AD9082 System Development User Guide”:

    - RX, Page 115, Table 70: L= 8, M = 2, F = 1, S = 2, K = 32, N = 16, NP = 16, HD = 1, Total DCM = 1, JTX Async = False, JTX_MODE = 19.

    - TX, Page 164, Table 92: L= 8, M = 2, F = 1, S = 2, K = 32, N = 16, NP = 16, Dual Link = No, Interpolation Mode = 1x1, JESD204B Mode = 63.

    We adapt the device-tree file with the parameters presented and the jesd_status shows that the Tx and Rx configuration has no errors.

    When using ADI IIO-Oscilloscope, we cannot change the test mode, for example the ramp test mode is not executed. The tone produced by the DDS is always displayed. We also observe that the sinusoidal signal is always distorted. When using a python application we also observe the messages:

    ad9081 spi1.0: channel ftw is not updated

    ad9081 spi1.0: main ftw is not updated

     

    I attach the device-tree files, the python file, and figures for the following questions:

    1) Is the choice of parameters appropriate for the case of a Zynq UltraScale+?

    2) Is the configuration of the device-tree files correct?

    3) Are the messages obtained when running a python application normal?

    4) How could I solve the problem I encounter when using the ADI IIO-Oscilloscope?

    5) Would the distorted signal (see m2-l8-s2distorted waveform.png) be a consequence of using ADC rate = DAC rate = 2 Gsps?

     

    When disabling DDS in the ADI IIO-Oscilloscope, we can see the appearance of random pulses (see m2-l8-s2-random pulses.png). This seems to be unusual behavior.

  • we get the following message in the UART terminal:

    ad9081 spi1.0: channel ftw is not updated

    That's just a warning. In full bandwith mode. When the channel FDDCs FDUCs are bypassed. You can't set the NCO frequency. And apparently the pyadi-iio example did that and the driver just warned about it.

    When using a python application we also observe the messages:

    ad9081 spi1.0: channel ftw is not updated

    ad9081 spi1.0: main ftw is not updated

    Same explanation as above. But now also the main CDDC and CDUCs NCOs are also written.

    1) Is the choice of parameters appropriate for the case of a Zynq UltraScale+?

    Yes this should work.

    2) Is the configuration of the device-tree files correct?

    There are a few things 

    Use: 

    adi,nco-mixer-mode = <AD9081_ADC_NCO_ZIF>;

    adi,converter-select =
    <&ad9081_rx_fddc_chan0 FDDC_I>, <&ad9081_rx_fddc_chan1 FDDC_I>;

    Also I think the minimum DAC rate is 2.9 GSPS and the 2GSPS used here is violating this.

    3) Are the messages obtained when running a python application normal?

    Yes for this mode, they are expected.

    -Michael

  • The HDL project needs also be rebuilt with the new mode, not only the devicetree. Did you do that ?

    Regards,

    Adrian

  • Yes, they got a new system_top.xsa file using:

    make RX_JESD_L=8 RX_JESD_M=2 RX_JESD_S=2 TX_JESD_L=8 TX_JESD_M=2 TX_JESD_S=2 RX_LANE_RATE=10 TX_LANE_RATE=10

  • Some comments and some additional questions:

     ------------------------------------------------------------------------

    Regarding this response that I received:

    Also I think the minimum DAC rate is 2.9 GSPS and the 2GSPS used here is violating this.

    Could you confirm that the minimum DAC rate is 2.9 GSPS?

    In the document called “AD9081/AD9082 System Development User Guide”, page 13 states the following:

    “In either case, the DAC clock is the primary clock and the ADC clock is derived from the DAC clock. The sampling clock passed onto the DAC core must be set to the desired DAC clock rate. The ADC clock is a divided version of the DAC clock with the divider circuit controlled by Register 0x0180. The divider setting of 1, 2, 3, or 4 is set by the ADCDIVN_DIVRATIO_SPI bits, and the ADCDIVN_PD bit provides a power-down option. ”

    Then the divider can be 1, as a consequence I would have ADC clock = DAC clock.

    And page 115, Table 70, I choose the parameters for FADC Range = 1.6 GSPS to 3.1 GSPS (see m2-l8-s2-table70-ADC.png). Hence, I can set FADC = 2 GSPS. Also for real data I have Total DCM = 1 and Total Interpolation = 1, then ADC rate = DAC rate = 2 GSPS.

    Is my deduction correct or is there something I'm leaving out?

    Does the divider equal to 1 have to be specified in the device-tree file or is it configured automatically with the good parameters?

     ------------------------------------------------------------------------

    On the other hand, when the AD9082-FMCA-EBZ board is configured to perform interpolation and decimation (for example L= 8, M = 4, F = 1, S = 1, for TX y RX), there is complex data at the reception.

    Is there any configuration to suppress/eliminate the imaginary part of the data without modifying the real part?

    Using write_pfilt_config of pyadi-iio (programmable filter), I try to eliminate the complex part but I think it is not a good option.

     

    Following this questions above, the customer sent another email below:

     

    I would like to be more precise about processing complex data (Total Interpolation >1 and Total Decimation >1). For our application we seek to eliminate the complex part of the complex data.

     

    Roughly speaking, the data path to the DAC is as follows:

    Our Real Data ==> Total Interpolation ==> Complex Data ==> DAC

    By connecting a spectrum analyzer to the DAC, one can observe that the spectrum of the signal generated by the DAC is composed of the spectrum of the real part and imaginary part of the complex data. For our application we only need the spectrum of the real part.

    Is there any configuration to suppress/eliminate the imaginary part of the data without modifying the real part?

     

    Similar to the DAC, the data path from the ADC is as follows:

    Complex Data <== Total Decimation <== Programmable FIR filter <= ADC <= Our Real Data

    In this case my question is the same:

    Is there any configuration to suppress/eliminate the imaginary part of the data without modifying the real part?

  • The source of truth is the datasheet:

    Is there any configuration to suppress/eliminate the imaginary part of the data without modifying the real part?

    Not sure I understand the ask here. But there shouldn't be complex data in full bandwidth mode. The IIO channel namings are likley not correct, but you should see two real channels even they falsely name _i and _q but they should terminate each on a single DAC.

    -Michael

  • Hello,

    Please see additional question from customer:

    I think the question related to complex data was taken as part of the case when DUCs/DDCs are bypassed, but my question is for the case where I-Q data exists.

     

    In the case that DUCs/DUCs are used, the I-Q data is presented (complex data). Considering Tx Lane rate = Rx Lane rate = 10Gsps, Tx core clock = Rx core clock = Lane rate / 40 = 250 MHz, ADC rate = 4 Gsps, and DAC rate = 8 Gsps, we have:

    - RX: L= 8, M = 4, F = 1, S = 1, K = 32, N = 16, NP = 16, HD = 1, Total DCM = 4, JTX Async = False, JTX_MODE = 18.

    - TX: L= 8, M = 4, F = 1, S = 1, K = 32, N = 16, NP = 16, Dual Link = No, Total Interpolation = 8, JESD204B Mode = 17.

    By connecting a spectrum analyzer to the DAC, In figure “spectrum-dac.PNG” we can observe that the spectrum of the signal generated by the DAC is composed of the spectrum of the real part and imaginary part of the complex data. For our application we only need the spectrum of the real part.

    Is there any configuration to suppress/eliminate the imaginary part of the data without modifying the real part?

  • Not sure If I fully understand the ask here.

    Typically - To eliminate negative frequencies, you can shift the entire spectrum of the I/Q signal to a positive frequency range.

    Multiply each I/Q sample by a complex oscillator output with a frequency of π/2 (90 degrees).

    Better use the on chip NCOs to do this for you.

    -Michael

Reply
  • Not sure If I fully understand the ask here.

    Typically - To eliminate negative frequencies, you can shift the entire spectrum of the I/Q signal to a positive frequency range.

    Multiply each I/Q sample by a complex oscillator output with a frequency of π/2 (90 degrees).

    Better use the on chip NCOs to do this for you.

    -Michael

Children
  • Hello,

    To organize the questions a little, I am sending you this new email with additional questions from customer: 

    ---------------------------------------------

    To use the 4 DACs and 2 ADCs of the AD9082-FMCA-EBZ board, we consider Tx Lane rate = Rx Lane rate = 15Gsps, Tx core clock = Rx core clock = Lane rate / 40 = 375 MHz, ADC rate = 6 Gsps, and DAC rate = 12 Gsps,

    where:

    - RX: L= 8, M = 4, F = 1, S = 1, K = 32, N = 16, NP = 16, HD = 1, Total DCM = 4, JTX Async = False, JTX_MODE = 18.

    - TX: L= 8, M = 8, F = 2, S = 1, K = 32, N = 16, NP = 16, Dual Link = No, Total Interpolation = 16, JESD204B Mode = 15.

     

    We obtain the system_top.xsa file using

    make RX_JESD_L=8 RX_JESD_M=4 RX_JESD_S=1 TX_JESD_L=8 TX_JESD_M=8

    TX_JESD_S=1 RX_LANE_RATE=15 TX_LANE_RATE=15

     

    We adapt the device-tree file (see

    zynqmp-mexu7-rev10-ad9082-rx-m4-l8-tx-m8-l8.dtsi) and the jesd_status shows that the Tx and Rx configuration has no errors (see figures jesd_rx_xu7.png and jesd_tx_xu7.png). We use the branch 2022 R2 for the HDL and embedded Linux.

     

    Using the same parameters to generate two tones, we see that the amplitude of the two tones are not equal.

    In figure waveform_xu7.png, the green tone (DAC0 -> ADC0) has approximately twice the amplitude of the blue tone (DAC1 -> ADC1).

     

    1) Could you help us solve this problem of amplitude mismatch?

      ---------------------------------------------

    On the other hand, in the document called “AD9081/AD9082 System Development User Guide”, page 164 (Table 92. DAC Path Supported JESD204B Modes), interpolation mode 1x1 only occurs when M=2:

     

    2) Does this mean that only 2 DACs can be used with real data (NO I-Q data)?

    3) Or is there a configuration to use all 4 DACs with real data? 

    ----------------------------------------------------

    Main modifications made to the HDL architecture (hdl_2022_r2) In folder <path-to-hdl>/projects/ad9081_fmca_ebz/, we create a copy of the zcu102 folder  and call it viqthor_xu7. We adapt the architecture and the time constraints. The main changes are in system_top.v file:

    • input gpio_bd_i and output gpio_bd_o are adapted.
    • the modified design considers the same clock for transmission and reception (i.e. rx_device_clk = tx_device_clk), we use clkin10_n/p while clkin6_n/p are not used.
    • the agc1[0] and agc1[1] inputs are not used.
    • inputs “fpga_refclk_in_replica_n/p” are added, these inputs are used to generate the signal “ref_clk_replica” (similar to the “ref_clk”

    signal). Signal “ref_clk_replica” is connected to “ref_clk_q1” while signal “ref_clk” is connected to signal “ref_clk_q0”. We adapt the pins of the FMC connector, where “fpga_refclk_in_replica_n/p” are connected to “GBTCLK1_M2C_N/P”, that is, the CLKIN8_P/N signals are used.

     

    The changes made to the device-tree file were explained above.

     ----------------------------------------------------

    When testing the 4 DACs, we observed that DAC 1, DAC 2, and DAC 3 behave normally, but DAC 0 distorts the signal. In figure “distorted waveform -

    DAC0 to ADC0.png”, a sinusoidal signal is sent to DAC 0 and recovered in ADC 0, one can see the irregular appearance of distortion. Similarly, figure “distorted waveform - DAC0 to ADC1.png” shows the sinusoidal signal sent to DAC 0 and recovered at ADC 1.

     

    Do you have any ideas about the origin of the error and its possible solution? 

    ----------------------------------------------------

    On the other hand, a python code using pyadi-iio has been created to generate 4 different tones and test the 4 DACs. By running the python code, tones are generated at the desired frequency and sent to the DACs.

    On reception, we observe that the recovered tones have half the initial frequency. For example, a tone of frequency 300 MHz is sent to the DAC and the recovered tone has a frequency of 150 MHz. The python code is attached.

     

    Could you help us fix the python code problem?

     ----------------------------------------------------

    I will send the files mentioned above direct via email.

    Thank you

    Alex

  • Hi, I can address a few of these:

    2/3: Can you use mode 12 or 13 in 204C in dual link mode (table 93)? This way you can have a total of M=4 with no interpolation. 

    Assuming in the python code your jesd setup is the same as described at the top of this post, your baseband datarate on the dac side is half the datarate on the adc side: fdac=12Gsps, so with 16x interpolation your baseband datarate is 750Msps. On the adc side Fadc=6Gsps/4x dcm = 1500Msps. If you are analyzing the adc output as if the data rate matches the Tx side at 750Msps the recreated waveform will be at half the expected frequency.

    For loopback situations where you are seeing distortion or amplitude differences at the adc, have you verified the dac output itself on a spec an or oscope so you can isolate on which side (tx or rx) the distortion is happening?