[BUG] axi_adxcvr - Common/Channel DRP ports aren't hooked up past channel 16

[hl-dlisi]

Describe the bug There appears to be a bug in the axi_adxcvr.v file where the axi_adxcvr_up and axi_adxcvr_are are instantiated. Following the code, it looks like the DRP read data is daisy chained through the axi_adxcvr_mdrp IP and ultimately the end of the chain ends up hooked to axi_adxcvr_up.

These ports into axi_adxcvr_up/es appear to be outdated with respect to 32 channels, as they take the end of the chain from 16 channels still.

axi_adxcvr_up

    .up_cm_rdata (up_cm_rdata_12_s),
    .up_cm_ready (up_cm_ready_12_s),
    .up_ch_pll_locked (up_ch_pll_locked_15_s),
    .up_ch_rst_done (up_ch_rst_done_15_s),
    .up_ch_prbserr (up_ch_prbserr_15_s),
    .up_ch_prbslocked (up_ch_prbslocked_15_s),
    .up_ch_bufstatus (up_ch_bufstatus_15_s),
    .up_ch_rdata (up_ch_rdata_15_s),
    .up_ch_ready (up_ch_ready_15_s),

axi_adxcvr_es

    .up_es_rdata (up_es_rdata_15_s),
    .up_es_ready (up_es_ready_15_s),

To Reproduce Steps to reproduce the behavior:

1. Build FW with > 16 channels (5+ ADRVs) hooked up
2. Try to read common or channel DRP ports >15
3. See that invalid data is returned, with respect to DRP ports < 16
4. Update the above code to: axi_adxcvr_up

   .up_cm_rdata (up_cm_rdata_28_s),
   .up_cm_ready (up_cm_ready_28_s),
   .up_ch_pll_locked (up_ch_pll_locked_31_s),
   .up_ch_rst_done (up_ch_rst_done_31_s),
   .up_ch_prbserr (up_ch_prbserr_31_s),
   .up_ch_prbslocked (up_ch_prbslocked_31_s),
   .up_ch_bufstatus (up_ch_bufstatus_31_s),
   .up_ch_rdata (up_ch_rdata_31_s),
   .up_ch_ready (up_ch_ready_31_s),

   axi_adxcvr_es

   .up_es_rdata (up_es_rdata_31_s),
   .up_es_ready (up_es_ready_31_s),

5. Build FW, and see that all DRP reads are valid

Expected behavior All common/channel DRP accesses return valid data

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Project name and used carrier board: Custom HW
• Used Software: Petalinux 2022.2
• Tool version: Vivado 2022.2
• HDL Release version: 2022_r2
• Software Release version: 2022_r2

Additional context Add any other context about the problem here.

[FilipG24]

Hello @hl-dlisi,

Last year I made a PR that should fix this issue, you can find it Here, this was tested on hardware and I'm expecting it to work but it was not 100% verified and validated, this is why it was never merged to master!

Regards! -Filip