Description
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:
- Build FW with > 16 channels (5+ ADRVs) hooked up
- Try to read common or channel DRP ports >15
- See that invalid data is returned, with respect to DRP ports < 16
- 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),
- 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.