Post Go back to editing

Enabling and checking PRBS

Category: Software
Product Number: AD9375
Software Version: 2022.2

Hello

I am using the ADRV9375 evaluation board with the ZCU102. I am using the 2022.2 meta-adi Petalinux layer to generate a Petalinux image. I am using ADI 2022.2 HDL firmware. I have a working setup where all four TX lanes are allocated to TX data and all four RX lanes are allocated to RX data. There is no OBS RX channel data. I am capturing RX data and sending TX data successfully. I am now investigating the PRBS functionality as a way of doing board level testing on our custom hardware when it is produced. For now, I am still testing on the ADRV9375 evaluation board with the ZCU102.

Firstly, the AD9375 supports enabling PN7, PN15 or PN31 inside the RX JESD framer. For the case of PN15, I am enabling this by:

root@adrv9371xzcu1022022r2meta:/sys/kernel/debug/iio/iio:device2# echo 2 > bist_prbs_rx

Inside the HDL firmware, the ADI adc_tpl_core (JESD204 Transport Layer for ADCs) includes support for checking PN9, PN23, PN7 and PN15. As far as I can tell, the corresponding IIO device driver for this HDL component is cf_axi_adc_core.c. Is that correct?

I believe the following function in cf_axi_adc_core.c is responsible for setting the desired PRBS sequence to check:

static ssize_t axiadc_debugfs_pncheck_write(struct file *file, const char __user *userbuf, size_t count, loff_t *ppos)

However, it only included support for enabling PN9 and PN23, neither of which are supported by the AD9375. 

So I added an extra if statement check:

if (sysfs_streq(p, "PN9"))
mode = ADC_PN9;
else if (sysfs_streq(p, "PN23"))
mode = ADC_PN23A;
else if (sysfs_streq(p, "PN15"))
mode = ADC_PN15;
else
mode = ADC_PN_OFF;

I built the new Petalinux image with this change in and then set the PRBS sequence to PN15 as follows (to match what is being generated by the AD9375):

root@adrv9371xzcu1022022r2meta:/sys/kernel/debug/iio/iio:device3# echo PN15 > pseudorandom_err_check

I then checked the PRBS status by doing the following:

root@adrv9371xzcu1022022r2meta:/sys/kernel/debug/iio/iio:device3# cat pseudorandom_err_check
CH0 : PN15 : Out of Sync : PN Error
CH1 : PN15 : Out of Sync : PN Error
CH2 : PN15 : Out of Sync : PN Error
CH3 : PN15 : Out of Sync : PN Error

However, the result stays the same. It never achieves PRBS synchronisation on any of the lanes. I know the links are working correctly because I can capture valid RX data. I have also verified the links in loopback from TX back to RX.

Is there a reason why cf_axi_adc_core.c did not include support for PN7 and PN15? Does it not work correctly in the corresponding HDL? Or is there something else I need to be setting to get the PRBS to synchronise and check for errors in PN15 or PN7 mode?

Thank you.

Gavin

 

Parents
  • I am a bit confused about how the PRBS is implemented in the AD9375. I have read other posts and I am still not sure.

    As far as I can tell, there are two possible implementations of the PRBS:

    1) The raw JESD serial bit stream is replaced with a PRBS data pattern. There is no framing.

    2) The RX data samples are replaced with a PRBS bit stream. Framing is maintained.

    My understanding was that (2) was being implemented in the AD9375 and was enabled through:

    echo 1 > bist_prbs_rx

    But I have added an ILA to the output of the JESD RX HDL firmware and I can see that after running for a short while with the PRBS enabled, the JESD data valid goes low indicating that it has lost frame alignment. This will explain why the adc_tpl_core is reporting no synchronisation because it would function in mode (2). In other words, the adc_tpl_core will be able to synchronise and check PRBS if the RX data samples were replaced with a PRBS bit pattern (2).

    Do you know which of the two PRBS modes ((1) or (2)) are being enabled in the AD9375 when I do the following:

    echo 1 > bist_prbs_rx

    Thank you.

Reply
  • I am a bit confused about how the PRBS is implemented in the AD9375. I have read other posts and I am still not sure.

    As far as I can tell, there are two possible implementations of the PRBS:

    1) The raw JESD serial bit stream is replaced with a PRBS data pattern. There is no framing.

    2) The RX data samples are replaced with a PRBS bit stream. Framing is maintained.

    My understanding was that (2) was being implemented in the AD9375 and was enabled through:

    echo 1 > bist_prbs_rx

    But I have added an ILA to the output of the JESD RX HDL firmware and I can see that after running for a short while with the PRBS enabled, the JESD data valid goes low indicating that it has lost frame alignment. This will explain why the adc_tpl_core is reporting no synchronisation because it would function in mode (2). In other words, the adc_tpl_core will be able to synchronise and check PRBS if the RX data samples were replaced with a PRBS bit pattern (2).

    Do you know which of the two PRBS modes ((1) or (2)) are being enabled in the AD9375 when I do the following:

    echo 1 > bist_prbs_rx

    Thank you.

Children