New Contributor
Super ContributorHi,
If check this previous forum https://community.intel.com/t5/Programmable-Devices/Avalon-to-AXI-implementation/td-p/1303625
Have you increase the DMA (AVMM) maximum pending read/write transactions and burst size to higher? Probably due to throughput issue.
Another thing is try using this bridge Avalon® memory mapped pipeline bridge in between avmm and axi heck this link https://www.intel.com/content/www/us/en/docs/programmable/683609/21-3/bridges-between-and-axi-interfaces.html
Try adjust the burst size and maximum pending read/write transactions. And may be use the writeresponse valid signal.
Thanks,
Regards,
Sheng
New ContributorThanks for the suggestions. Adjusting bridge parameters and related settings unfortunately did not resolve the issue. In particular, I cannot change “pending write transactions,” since neither interface supports the writeresponsevalid signal.
I tried to capture the problem with SignalTap and attached two exports (PDF + CSV). I triggered on the DMA’s arbiterlock signal. In the PDF, the relevant traces start on page 5.
Here is what I observed:
After reset, the Pixel Buffer DMA asserts arbiterlock briefly and is able to perform two consecutive reads.
Immediately after, its lock is released, and the Nios-V data master AXI interface begins toggling between AWREADY/AWVALID and WREADY/WVALID continuously.
From that point onward, the Pixel Buffer is never granted access to DDR4 again.
In this state, the entire hardware platform freezes to the point that I need to re-upload the .sof before I can even re-download software.
Interestingly, if I avoid writing to DDR4 from software, the system does not completely hang (I can still download new software). However, the Pixel Buffer DMA still stalls and never proceeds. In this scenario, the main AXI difference I see is that WVALID, WREADY, and WLAST remain asserted instead of toggling.
