Post Go back to editing

Enabling and checking PRBS

Category: Software
Product Number: AD9375
Software Version: 2022.2


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;
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.



  • 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.

  • I have read through the AD9375 user guide again. I am almost certain that the AD9375 is implementing (1) above. This explains why the JESD receiver loses frame lock and why the adc_tpl_core does not achieve PRBS synchronisation.

    This is not a Linux device driver issue. My understanding of the AD9375 PRBS implementation was incorrect based on the conflicting information regarding the AD9375 PRBS on the EngineerZone forum. The user guide is clear though.

  • Thank you Michael. This is exactly what I was looking for.