When instantiating idma_backend_rw_axi care has to be taken to pass the same AR channel through parameters read_meta_channel_t and axi_req_t.
In particular, during iDMA integration in Occamy to replace the legacy system DMA, read_meta_channel_t was wrongly misconfigured to use the AR channel from the frontend configuration interface, and the ID width mismatch would lead to malformed AXI requests from the backend.
I don't understand the need for the two somewhat redundant parameters, but I can think of two solutions to make instantiating the iDMA less error-prone:
- provide wrappers which instantiate frontend, midend and backend, deriving "redundant" parameters internally
- add assertion checks within the backend or transport layers to verify that "redundant" parameters match
I think the first would be the most valuable approach, but the second might still be valuable for iDMA developers in the development phase.
When instantiating
idma_backend_rw_axicare has to be taken to pass the same AR channel through parametersread_meta_channel_tandaxi_req_t.In particular, during iDMA integration in Occamy to replace the legacy system DMA,
read_meta_channel_twas wrongly misconfigured to use the AR channel from the frontend configuration interface, and the ID width mismatch would lead to malformed AXI requests from the backend.I don't understand the need for the two somewhat redundant parameters, but I can think of two solutions to make instantiating the iDMA less error-prone:
I think the first would be the most valuable approach, but the second might still be valuable for iDMA developers in the development phase.