AXI violation on H2F interface of S10

Hi Chris,

Based on your setup, I agree that probably that does not apply to your case.

I'm wondering whether this is due to the width mismatch where you have the H2F AXI4 128bit while EMIF AvalonMM at 512bit. Most probably you will have the width adapter in Platform designer to handle the width needed (narrow to wide data pack , 4x 128  = 512bits)

So happy path when every data in 128bit is aligned and packed into 512bit send to AvMM.

The not so happy path is when issues starts occurs, these are some suspected areas

1. The 128bit to 512 bit width and burst adaptation logic can be stressed by unaligned addresses, narrow transfer size, sparse bytes that can flood the memory with many small transactions.

Things to confirm: Retest with 64-byte-aligned, full-width transfers (and/or with DMA). If that stabilizes the bus while raw user-space texture copies don't, then we could confirm that adaptation + traffic shape path is the weak link here that causes the issue you're seeing.

2. Memory controller or interconnect backpressure where external memory interface or the soft interconnect is not accepting writes fast enough causing backpressure on the queue and eventually stops accepting new write address transaction. 

Things to confirm :  At hang, are the Avalon wait-request and write-data ready stuck in a backpressure state? Does lowering write rate delay or remove the hang? Try capture the HPS-to-FPGA write-address, write-data, and write-response channels on the HPS-to-FPGA fabric clock, plus the Avalon write and wait-request signals on the memory side.

3. Similar to 2, is there any chance that write addresses/data are accepted faster than the write responses coming back eventually hitting the write limit and stops accepting new write all together.

Things to confirm : Count accepted write addresses vs completed write responses at hang. Try setting maximum pending writes = 1 and see what's the behavior, is it stable or instantly stall?

Thanks

Regards

Kian