Forum Discussion

c-thaler's avatar
c-thaler
Icon for Occasional Contributor rankOccasional Contributor
1 month ago

AXI violation on H2F interface of S10

I'm using the H2F AXI interface to access external RAM via EMIF on an S10 SX SoC DK (1SX280HU2F50E1VGAS).

There are situations where I see the valid signal of the W channel go from 1 to 0 while the ready signal is 0. This is a violation of the valid/ready handshake protocol of AXI.
After a while the system freezes because no more write transaction are accepted on the AW channel.

What can cause this? Are there any known bugs in the bus master of the HPS?

Here is a waveform I sampled with SignalTap that shows the behavior:

There is a Linux 6.1 running on the ARM core. The RAM on the FPGA side is used for video memory. It is listed in the device tree and our drivers use it to make video memory allocations.
The memory is then mapped into user space and our test application transfers data into the memory (e.g. texture data).

Core Logic

3 Replies

  • c-thaler's avatar
    c-thaler
    Icon for Occasional Contributor rankOccasional Contributor
    1 month ago

    Hi Kian,

    thanks for the reply.
    DQ width in my case is 64. Therefore I think this does not apply to my case.
    And the HPS can access the EMIF successfully for quite a while before it hangs.

    H2F data widht is 128 while EMIF Avalon width is 512.

    Best regards
    Chris

    • KianHinT_altera's avatar
      KianHinT_altera
      Icon for Frequent Contributor rankFrequent Contributor
      1 month ago

      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