Issue with Pixel Buffer DMA AVMM -> AXI connection on DE25-Standard (Agilex5)

[Wiede]

I’m working with the DE25-Standard board from Terasic, which has an Agilex5 FPGA (A5ED013BB32AE4SR1).

In Quartus 25.1.1 Platform Designer, I’m using a Nios V/g CPU with the standard on-chip memory and an additional DDR4 external memory component. This setup by itself works fine.

The problem appears when I try to get HDMI output using the default IP cores. My design is similar to what I previously used on an older board (DE2-115). Whenever I connect the Pixel Buffer DMA controller’s AVMM host interface to the DDR4’s AXI slave, the CPU eventually hangs. It looks like an issue with the automatically generated AVMM → AXI translation.

To isolate the problem:

• The Pixel Buffer → Video output system works in principle.

• I tested the DMA controller with a custom “pixelbuffer_test” component, which simply returns the requested address on readdata. This setup worked.

• The HDMI subsystem also works when driven by the Test Pattern Generator.

So the issue seems to arise specifically when the DMA master is connected to DDR4 via AVMM → AXI.

Question: Are there any known issues with AVMM ↔ AXI crossing in this configuration? Do you have ideas on how to solve this problem (other than writing my own AXI4 DMA controller or similar)?

I attached the Platform Designer system view, which shows both the working pixelbuffer_test connection and the intended DMA → DDR4 AXI connection. Note: the other DDR4 AXI4 subordinate connections go to Nios V’s data_manager and instruction_manager.

[ShengN_Intel]

Hi,

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

[Wiede]

Thanks 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.

[ShengN_Intel]

Hi,

Understood that since there's no writeresponse valid signal so the “pending write transactions” cannot be set.

The DDR4 AXI is connected to multiple master which are NIOS V and DMA controller

Could you try using the Fixed Priority Arbitration check this https://www.intel.com/content/www/us/en/docs/programmable/683364/18-1/designate-a-slave-to-use-fixed-priority.html

May I know this connection you're refering to design example?

Thanks,

Regards,

Sheng

[ShengN_Intel]

Hi,

Another thing is lowering the data rate does the problem happen?

Could you try change the interconnect settings of Burst Adapter Implementation to faster check this link https://www.intel.com/content/www/us/en/docs/programmable/683364/18-1/interconnect-requirements.html

Thanks,

Regards,

Sheng

[ShengN_Intel]

Hi,

May I know if any further update or concern from your side?

Thanks,

Regards,

Sheng

[Wiede]

Im sorry. Im not in the office this week

Ill return to this issue on Monday

[ShengN_Intel]

Sure, understood that. Let me know once you got the update.

[Wiede]

I finished trying your suggestions. Sadly, nothing seems to work. The interconnect still seems to freeze the system.

[RichardTanSY_Altera]

Please be informed that starting October 1st, the FPGA Forum on community.intel.com will be placed in read-only mode.

You will still be able to view and access existing content, but new posts, comments, or edits will no longer be permitted during this transition period.

For urgent technical support, we kindly ask that you reach out through Intel Premier Support (IPS) via your DFAE (Altera authorised distributors) engagement.

We appreciate your patience as we prepare for the official launch of the new FPGA forum on October 14th, where posting capabilities will resume.

Thank you for your continued support and understanding.

Regards.

Richard Tan