Query regarding profile 13_nonLinkSharing in ADRV9025 TES GUI

Dear all,

Could you please share the 13NLS profile with ORX disabled? We would like to cross-verify it with the profile generated from the GUI.

Appreciate your help and looking forward to your reply.

Ragards
Mahima

5822.UC13NLS_ORX_Disabled.txt

Attached, please change the file extension to .profile and upload it in the GUI

I hope your requirement is to disable the ORX JESD which i have done.

Dear AndreiDragomir ,

Sorry for the late reply. 
Regarding "I'm not sure what you mean by enabling the SYNCINB" 
- I have not mentioned clearly in the last reply. In Framer0, syncbInLvdsPnInvert is enabled

We are using "SYNCIN1P,N" for RX lanes and "SYNCOUT1_P,N" for TX lanes. There is no inversion both in HDL and  Hardware. 

Regarding "Are you using custom hardware?"
- I have mentioned in the above replies that we are working on the custom hardware.Our custom hardware has Zynq Ultrascale plus MPSoC and ADRV9025. 

As, The petalinux project is compiled without meta-adi layer, we cannot see jesd_status. 

Questions:

1. Please confirm if enabling syncbOutLvdsPnInvert is required for proper operation.
2. Lane latency is 8 octet which it should be more than 64 as per analog wiki page

How to get ILAS configuration parameters. Should we change lmfc_offset ? if yes, How? 

Regards
Mahima

Dear AndreiDragomir 

Please reply. Please let me know if you need any details.

Regards
Mahima

Hi mahima90 ,

Sorry for the late reply.

Regarding SYNCIN_P,N inversion, if there's no inversion in HDL or hardware, this needs to also be disabled in the profile. I don't really see how enabling this gets the link into DATA state, seems a bit random to me. Your boot log before enabling this looked good, so it might need only some fine tuning to get it from CGS to DATA. First, check the lane mapping of your RX lanes and make sure that those two lanes that you have constrained are the same ones that you enabled in the profile. Also if you have a custom design, your lane mapping could be different than the one in our HDL which is designed for the evaluation board. Otherwise, you could experiment with LMFC offset by changing the value of lmfcOffset in the profile. Also check if the sync remains asserted when in CGS state.

Regarding lane latency, I believe that the min and max values apply only for JESD204C.

I see that you based your design on 2023_R2 version. Maybe it would help you to check the main branch for differences, since the project is constantly being updated.

Best regards,
Andrei

Dear AndreiDragomir 

As per suggestion, We have verified
1. RX Lane Mapping: Checked in HDL, Hardware Schematic and 13-NLS generated profile.Lane0 and Lane1 are getting used.
2. In firmware profile, SyncbInLvdsPnInvert is reverted to 0.
3. Tried different lmfcoffset values in ActiveUseCase.profile. 
     It is observed that Lane Latency is changing but still errors are there.
     Case: lmfcoffset: 2
     On every power-up, Lane latency is changing 
       

      We have tested multiple LMFC offset values; however, the lane latency continues to vary significantly with each power-up.
      How to set SYSREF_LMFC_OFFSET value in JESD204 Link Receive Peripheral Block.

      One more point: How to check sync status in RX side?

      Regards
      Mahima

Dear AndreiDragomir ,

Please reply and suggest where should i check more.

How to check sync status in RX side?

Currently sysref configuration is:

                 /* SYSREF config */
                adi,sysref-src = <2>;
                adi,sysref-pattern-mode = <0>;
                adi,sysref-k-div = <512>;
                adi,sysref-nshot-mode = <5>;
                //adi,sysref-request-trigger-mode = <0>;
                adi,jesd204-desired-sysref-frequency-hz = <3840000>;

Are these correct ? What is the correct formula to find the adi,sysref-k-div value ?

Regards
Mahima

Hello mahima90 !

We’re sorry to inform you that the colleagues responsible for this project are currently unavailable due to the holiday season.

We will gladly provide the necessary support once they return in January.

Thank you for your understanding!

Kind regards,

Elena

Dear AndreiDragomir ,

We are still observing the RX JESD lane status in the INIT state. The following status is reported.

Additionally, after a hard reboot, we notice that different latency values are observed across boots.

We have verified the SYNC status using ILA, and it is observed that SYNC is getting deasserted.

Tested PRBS data, We are able to see data
For example, echo 2 > /sys/kernel/debug/iio/iio:device2/bist_framer_0_prbs

echo 3 > /sys/kernel/debug/iio/iio:device2/bist_framer_0_prbs

Any suggestions ?

Regards
Mahima

Hello mahima90 ,

My guess is that something could be wrong with the util_xcvr connections related to RX, so maybe you should double check that. Another suggestion would be to try some other profile that fits your custom hardware just to see if you can bring up the RX, to make sure its not a hardware issue.

I made a working design for your profile using the ZCU102 and ADRV9026 eval board. I started from the main branch and made the following changes: 

--- a/projects/adrv9026/common/adrv9026_bd.tcl
+++ b/projects/adrv9026/common/adrv9026_bd.tcl
@@ -175,6 +175,8 @@ ad_ip_parameter axi_adrv9026_rx_dma CONFIG.DMA_TYPE_SRC 2
 ad_ip_parameter axi_adrv9026_rx_dma CONFIG.DMA_TYPE_DEST 0
 ad_ip_parameter axi_adrv9026_rx_dma CONFIG.CYCLIC 0
 ad_ip_parameter axi_adrv9026_rx_dma CONFIG.SYNC_TRANSFER_START 1
+ad_ip_parameter axi_adrv9026_rx_dma CONFIG.AXI_SLICE_DEST {true}
+ad_ip_parameter axi_adrv9026_rx_dma CONFIG.AXI_SLICE_SRC {true}
 ad_ip_parameter axi_adrv9026_rx_dma CONFIG.DMA_DATA_WIDTH_SRC $adc_dma_data_width

-ad_ip_parameter util_adrv9026_xcvr CONFIG.TX_LANE_INVERT 6
+ad_ip_parameter util_adrv9026_xcvr CONFIG.TX_LANE_INVERT 5
 
-ad_xcvrcon util_adrv9026_xcvr axi_adrv9026_tx_xcvr axi_adrv9026_tx_jesd {3 2 0 1} {} adrv9026_tx_device_clk $TX_NUM_OF_LANES
+ad_xcvrcon util_adrv9026_xcvr axi_adrv9026_tx_xcvr axi_adrv9026_tx_jesd {} {} adrv9026_tx_device_clk $TX_NUM_OF_LANES {3 2 1 0}
 
-ad_xcvrcon  util_adrv9026_xcvr axi_adrv9026_rx_xcvr axi_adrv9026_rx_jesd {} {} adrv9026_rx_device_clk $RX_NUM_OF_LANES
+ad_xcvrcon  util_adrv9026_xcvr axi_adrv9026_rx_xcvr axi_adrv9026_rx_jesd {} {} adrv9026_rx_device_clk $RX_NUM_OF_LANES {1 0 2 3}
 
-for {set i 0} {$i < $RX_NUM_OF_LANES} {incr i} {
+for {set i 0} {$i < 4} {incr i} {
   set ch [expr $i]
   ad_xcvrpll  $rx_ref_clk util_adrv9026_xcvr/cpll_ref_clk_$ch
   ad_xcvrpll  axi_adrv9026_rx_xcvr/up_pll_rst util_adrv9026_xcvr/up_cpll_rst_$ch

diff --git a/projects/adrv9026/zcu102/system_constr.xdc b/projects/adrv9026/zcu102/system_constr.xdc
index 3b0e6bc58..d54997247 100644
--- a/projects/adrv9026/zcu102/system_constr.xdc
+++ b/projects/adrv9026/zcu102/system_constr.xdc
@@ -14,19 +14,19 @@ set_property -dict {PACKAGE_PIN D33}  [get_ports rx_data_p[0]]
 set_property -dict {PACKAGE_PIN D34}  [get_ports rx_data_n[0]]                               ; ## A3   FMC1_DP1_M2C_N        MGTHRXN1_130
 set_property -dict {PACKAGE_PIN E31}  [get_ports rx_data_p[1]]                               ; ## C6   FMC1_DP0_M2C_P        MGTHRXP0_130
 set_property -dict {PACKAGE_PIN E32}  [get_ports rx_data_n[1]]                               ; ## C7   FMC1_DP0_M2C_N        MGTHRXN0_130
-set_property -dict {PACKAGE_PIN C31}  [get_ports rx_data_p[2]]                               ; ## A6   FMC1_DP2_M2C_P        MGTHRXP2_130
-set_property -dict {PACKAGE_PIN C32}  [get_ports rx_data_n[2]]                               ; ## A7   FMC1_DP2_M2C_N        MGTHRXN2_130
-set_property -dict {PACKAGE_PIN B33}  [get_ports rx_data_p[3]]                               ; ## A10  FMC1_DP3_M2C_P        MGTHRXP3_130
-set_property -dict {PACKAGE_PIN B34}  [get_ports rx_data_n[3]]                               ; ## A11  FMC1_DP3_M2C_N        MGTHRXN3_130
-
-set_property -dict {PACKAGE_PIN D29}  [get_ports tx_data_p[0]]                               ; ## A22  FMC1_DP1_C2M_P        MGTHTXP1_130  (tx_data_p[2])
-set_property -dict {PACKAGE_PIN D30}  [get_ports tx_data_n[0]]                               ; ## A23  FMC1_DP1_C2M_N        MGTHTXN1_130  (tx_data_n[2])
-set_property -dict {PACKAGE_PIN F29}  [get_ports tx_data_p[1]]                               ; ## C2   FMC1_DP0_C2M_P        MGTHTXP0_130  (tx_data_p[3])
-set_property -dict {PACKAGE_PIN F30}  [get_ports tx_data_n[1]]                               ; ## C3   FMC1_DP0_C2M_N        MGTHTXN0_130  (tx_data_n[3])
-set_property -dict {PACKAGE_PIN B29}  [get_ports tx_data_p[2]]                               ; ## A26  FMC1_DP2_C2M_P        MGTHTXP2_130  (tx_data_p[1])
-set_property -dict {PACKAGE_PIN B30}  [get_ports tx_data_n[2]]                               ; ## A27  FMC1_DP2_C2M_N        MGTHTXN2_130  (tx_data_n[1])
-set_property -dict {PACKAGE_PIN A31}  [get_ports tx_data_p[3]]                               ; ## A30  FMC1_DP3_C2M_P        MGTHTXP3_130  (tx_data_p[0])
-set_property -dict {PACKAGE_PIN A32}  [get_ports tx_data_n[3]]                               ; ## A31  FMC1_DP3_C2M_N        MGTHTXN3_130  (tx_data_n[0])
+set_property -dict {PACKAGE_PIN D29}  [get_ports tx_data_p[2]]                               ; ## A22  FMC1_DP1_C2M_P        MGTHTXP1_130  (tx_data_p[2])
+set_property -dict {PACKAGE_PIN D30}  [get_ports tx_data_n[2]]                               ; ## A23  FMC1_DP1_C2M_N        MGTHTXN1_130  (tx_data_n[2])
+set_property -dict {PACKAGE_PIN F29}  [get_ports tx_data_p[3]]                               ; ## C2   FMC1_DP0_C2M_P        MGTHTXP0_130  (tx_data_p[3])
+set_property -dict {PACKAGE_PIN F30}  [get_ports tx_data_n[3]]                               ; ## C3   FMC1_DP0_C2M_N        MGTHTXN0_130  (tx_data_n[3])
+set_property -dict {PACKAGE_PIN B29}  [get_ports tx_data_p[1]]                               ; ## A26  FMC1_DP2_C2M_P        MGTHTXP2_130  (tx_data_p[1])
+set_property -dict {PACKAGE_PIN B30}  [get_ports tx_data_n[1]]                               ; ## A27  FMC1_DP2_C2M_N        MGTHTXN2_130  (tx_data_n[1])
+set_property -dict {PACKAGE_PIN A31}  [get_ports tx_data_p[0]]                               ; ## A30  FMC1_DP3_C2M_P        MGTHTXP3_130  (tx_data_p[0])
+set_property -dict {PACKAGE_PIN A32}  [get_ports tx_data_n[0]]                               ; ## A31  FMC1_DP3_C2M_N        MGTHTXN3_130  (tx_data_n[0])

diff --git a/projects/adrv9026/zcu102/system_project.tcl b/projects/adrv9026/zcu102/system_project.tcl
index 44684a910..604bd3317 100644
--- a/projects/adrv9026/zcu102/system_project.tcl
+++ b/projects/adrv9026/zcu102/system_project.tcl

-  RX_JESD_L           [get_env_param RX_JESD_L          4 ] \
+  RX_JESD_L           [get_env_param RX_JESD_L          2 ] \

diff --git a/projects/adrv9026/zcu102/system_top.v b/projects/adrv9026/zcu102/system_top.v
index a9328255d..355958f98 100644
--- a/projects/adrv9026/zcu102/system_top.v
+++ b/projects/adrv9026/zcu102/system_top.v

-  input       [ 3:0]      rx_data_p,
-  input       [ 3:0]      rx_data_n,
+  input       [ 1:0]      rx_data_p,
+  input       [ 1:0]      rx_data_n,

-    .rx_data_0_n (rx_data_n[0]),
-    .rx_data_0_p (rx_data_p[0]),
-    .rx_data_1_n (rx_data_n[1]),
-    .rx_data_1_p (rx_data_p[1]),
-    .rx_data_2_n (rx_data_n[2]),
-    .rx_data_2_p (rx_data_p[2]),
-    .rx_data_3_n (rx_data_n[3]),
-    .rx_data_3_p (rx_data_p[3]),
+    .rx_data_0_n (rx_data_n[1]),
+    .rx_data_0_p (rx_data_p[1]),
+    .rx_data_1_n (rx_data_n[0]),
+    .rx_data_1_p (rx_data_p[0]),

-    .tx_data_0_n (tx_data_n[0]),
-    .tx_data_0_p (tx_data_p[0]),
-    .tx_data_1_n (tx_data_n[1]),
-    .tx_data_1_p (tx_data_p[1]),
-    .tx_data_2_n (tx_data_n[2]),
-    .tx_data_2_p (tx_data_p[2]),
-    .tx_data_3_n (tx_data_n[3]),
-    .tx_data_3_p (tx_data_p[3]),
+    .tx_data_0_n (tx_data_n[3]),
+    .tx_data_0_p (tx_data_p[3]),
+    .tx_data_1_n (tx_data_n[2]),
+    .tx_data_1_p (tx_data_p[2]),
+    .tx_data_2_n (tx_data_n[1]),
+    .tx_data_2_p (tx_data_p[1]),
+    .tx_data_3_n (tx_data_n[0]),
+    .tx_data_3_p (tx_data_p[0]),

Hope this can serve as a guide to help you figure out the issue.

Regards,
Andrei

Hello AndreiDragomir ,

Initially, we have also made working design with ZCU102 and ADRV9026. RX jesd lane is in DATA state.
WRT custom hardware, I have verified the util_xcvr connections related to RX. It seems correct.
i have attached util_xcvr configuration values . Please check.

Property                 Type     Read-only  Value
ALLOWED_SIM_MODELS       string*  true       rtl
CLASS                    string   true       bd_cell
CONFIG.A_TXDIFFCTRL      string   false      "10110"
CONFIG.CH_HSPMUX         string   false      0x2424
CONFIG.CPLL_CFG0         string   false      0x01FA
CONFIG.CPLL_CFG1         string   false      0x0023
CONFIG.CPLL_CFG2         string   false      0x0002
CONFIG.CPLL_CFG3         string   false      0x0000
CONFIG.CPLL_FBDIV        string   false      4
CONFIG.CPLL_FBDIV_4_5    string   false      5
CONFIG.Component_Name    string   true       system_util_ad9371_xcvr_0
CONFIG.DATA_PATH_WIDTH   string   false      4
CONFIG.LINK_MODE         string   false      1
CONFIG.POR_CFG           string   false      0x0006
CONFIG.PPF0_CFG          string   false      0x0600
CONFIG.PPF1_CFG          string   false      0x0600
CONFIG.PREIQ_FREQ_BST    string   false      0
CONFIG.QPLL_CFG0         string   false      0x331C
CONFIG.QPLL_CFG1_G3      string   false      0xD038
CONFIG.QPLL_CFG1         string   false      0xD038
CONFIG.QPLL_CFG2         string   false      0x0FC0
CONFIG.QPLL_CFG2_G3      string   false      0x0FC0
CONFIG.QPLL_CFG3         string   false      0x0120
CONFIG.QPLL_CFG4         string   false      0x0003
CONFIG.QPLL_CFG          string   false      "000011010000000000110000001"
CONFIG.QPLL_CP           string   false      "0001111111"
CONFIG.QPLL_CP_G3        string   false      "0000011111"
CONFIG.QPLL_FBDIV        string   false      "0000101000"
CONFIG.QPLL_FBDIV_RATIO  string   false      1
CONFIG.QPLL_LPF          string   false      "0100110111"
CONFIG.QPLL_REFCLK_DIV   string   false      1
CONFIG.RTX_BUF_CML_CTRL  string   false      000
CONFIG.RXCDR_CFG0        string   false      0x0002
CONFIG.RXCDR_CFG2        string   false      0x0269
CONFIG.RXCDR_CFG2_GEN2   string   false      "1001100101"
CONFIG.RXCDR_CFG2_GEN4   string   false      0x00B4
CONFIG.RXCDR_CFG3        string   false      0x0012
CONFIG.RXCDR_CFG3_GEN2   string   false      0b011010
CONFIG.RXCDR_CFG3_GEN3   string   false      0x0012
CONFIG.RXCDR_CFG3_GEN4   string   false      0x0024
CONFIG.RXDFE_KH_CFG2     string   false      0x0200
CONFIG.RXDFE_KH_CFG3     string   false      0x4101
CONFIG.RXPI_CFG0         string   false      0x0002
CONFIG.RXPI_CFG1         string   false      0x0015
CONFIG.RX_CDR_CFG        string   false      0x0b000023ff10400020
CONFIG.RX_CLK25_DIV      string   false      10
CONFIG.RX_DFE_LPM_CFG    string   false      0x0104
CONFIG.RX_LANE_INVERT    string   false      0
CONFIG.RX_LANE_RATE      string   false      9.83
CONFIG.RX_NUM_OF_LANES   string   false      4
CONFIG.RX_OUT_DIV        string   false      1
CONFIG.RX_PMA_CFG        string   false      0x001E7080
CONFIG.RX_WIDEMODE_CDR   string   false      "00"
CONFIG.RX_XMODE_SEL      string   false      "1"
CONFIG.TXDRV_FREQBAND    string   false      0
CONFIG.TXFE_CFG0         string   false      0x03C2
CONFIG.TXFE_CFG1         string   false      0x6C00
CONFIG.TXFE_CFG2         string   false      0x6C00
CONFIG.TXFE_CFG3         string   false      0x6C00
CONFIG.TXPI_CFG0         string   false      0x0300
CONFIG.TXPI_CFG1         string   false      0x1000
CONFIG.TXPI_CFG          string   false      0x0054
CONFIG.TXSWBST_EN        string   false      0
CONFIG.TX_CLK25_DIV      string   false      10
CONFIG.TX_LANE_INVERT    string   false      0
CONFIG.TX_LANE_RATE      string   false      9.83
CONFIG.TX_NUM_OF_LANES   string   false      4
CONFIG.TX_OUT_DIV        string   false      1
CONFIG.TX_PI_BIASSET     string   false      1
CONFIG.XCVR_TYPE         string   false      8
LOCATION                 string   false      3 670 880
NAME                     string   false      util_adrv9026_xcvr
PATH                     string   true       /ADRV9026_TOP/JESD_TOP/xcvr_top/util_adrv9026_xcvr
SCREENSIZE               string   false      220 1036
SELECTED_SIM_MODEL       enum     false      rtl
TYPE                     string   true       ip
VLNV                     string   true       analog.com:user:util_adxcvr:1.0

After a hard reboot, we observed that the latency values vary with large variation across different boots, as seen from the lane status values.

Is it related to ad9528 sysref configuration?

Currently sysref configuration is:

                 /* SYSREF config */
                adi,sysref-src = <2>;
                adi,sysref-pattern-mode = <0>;
                adi,sysref-k-div = <512>;
                adi,sysref-nshot-mode = <5>;
                //adi,sysref-request-trigger-mode = <0>;
                adi,jesd204-desired-sysref-frequency-hz = <3840000>;

Meanwhile, I need to check with different profile.

Regards
Mahima

Hello mahima90 ,

You're util_xcvr parameters look good, the only thing that stands out is RX_NUM_OF_LANES = 4. Have you tried changing this to 2, since you use only 2 lanes for RX?

The sysref configuration also seems good, but I would try changing the sysref frequency to half (1.92 MHz). I believe that the k-div setting is redundant when specifying the desired-sysref-frequency, but just to make sure, k-div should theoretically be 64 in order to get the 1.92 MHz sysref.

Regarding the large variations of latency, it might be caused by the difference between the link clk and device clk, since the link clocks are generated by util_xcvr from refclk, while the device clocks are generated by axi_clkgen from core_clk. So if the two suggestions from above still don't fix the issue, you might want to experiment with clock grouping between the link clocks, device clocks and sysref, either by constraints or by altering the clocking architecture, for example generating the link clock from the same axi_clkgen as the device clock, or using the link clk as input for the axi_clkgen instead of core_clk. These could ensure a deterministic phase relationship between link clk and device clk, hopefully reducing latency variations.

Regards,
Andrei

Hello mahima90 ,

You're util_xcvr parameters look good, the only thing that stands out is RX_NUM_OF_LANES = 4. Have you tried changing this to 2, since you use only 2 lanes for RX?

The sysref configuration also seems good, but I would try changing the sysref frequency to half (1.92 MHz). I believe that the k-div setting is redundant when specifying the desired-sysref-frequency, but just to make sure, k-div should theoretically be 64 in order to get the 1.92 MHz sysref.

Regarding the large variations of latency, it might be caused by the difference between the link clk and device clk, since the link clocks are generated by util_xcvr from refclk, while the device clocks are generated by axi_clkgen from core_clk. So if the two suggestions from above still don't fix the issue, you might want to experiment with clock grouping between the link clocks, device clocks and sysref, either by constraints or by altering the clocking architecture, for example generating the link clock from the same axi_clkgen as the device clock, or using the link clk as input for the axi_clkgen instead of core_clk. These could ensure a deterministic phase relationship between link clk and device clk, hopefully reducing latency variations.

Regards,
Andrei

Hi mahima90 !

Do you have any updates? Did you manage to solve your issues?

Regards, Elena

Dear elenahadarau ,

We won’t be able to work on this issue for some time. Please keep this thread active, as we’ll be resuming work on it shortly.

Regards
Mahima

Dear AndreiDragomir ,

Current Update: in custom board, ADC-to-DAC loopback through CPRI interface is functional and the spectrum is visible;
however, the ADC JESD lane status is still reported as INIT.
As suggested, we updated RX_NUM_OF_LANES = 2. We also changed the SYSREF frequency to half (1.92 MHz) and set the K-divider to 64. Still there is no change wrt JESD lane status.

Any other suggestion ?

Regards
Mahima