You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
Describe the bug
There appears to be a bug in the axi_adxcvr.v file where the
axi_adxcvr_up
andaxi_adxcvr_are
are instantiated. Following the code, it looks like the DRP read data is daisy chained through theaxi_adxcvr_mdrp
IP and ultimately the end of the chain ends up hooked toaxi_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
axi_adxcvr_es
To Reproduce
Steps to reproduce the behavior:
axi_adxcvr_up
axi_adxcvr_es
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):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: