dma_fsm_q stuck at ST_DMA_WRITE_REQ

[shgoupf]

Hey @ThomasFuchs ,

I am running CAPI2.0 simulation on SNAP with our AFU. The AFU is going to issue AXI read and write with the following attributes, which is burst length 1, size 8 bytes, burst type incremental.

   axi_arburst        = 2'b01;
   axi_awburst        = 2'b01;
   axi_arcache        = 4'b0010;
   axi_awcache        = 4'b0010;
   axi_arsize         = 3'b011;
   axi_awsize         = 3'b011;
   axi_arlen[7:4]     = 4'b0;
   axi_awlen[7:4]     = 4'b0;

Then seems like the dma status machine in snap core stuck at status ST_DMA_WRITE_REQ, which leads to PSL only received XLATE command for some read commands, but no DMA_READ received. Finally, AXI will be stuck because some of the read don't have response from the snap core.

In the following waveform, read request at address 1A73040 and all succeeded reads don't get response because dma_fsm_q is trapped into the ST_DMA_WRITE_REQ status and never make back to ST_DMA_READ_REQ.

Could you please take a look at the waveform in the following path to see if it is a valid issue in snap DMA engine?

/afs/bb/u/shgoupf/vol0/nvdla_debug/20180824_011642

Please note that this issue persist even if I applied the fix from branch add_again_hdl_helloworld.

Thanks a lot.

[shgoupf]

Thanks Thomas on wrapping up the quick fix. After applying the changes in branch Issue_801, the read is no longer blocked.

[ThomasFuchs]

Reopen it, because the code is not yet in the master.

[ThomasFuchs]

The dma_fsm_q is problems to handle a lot of short AXI write requests. It could be, that the dma_wtag_q pointer looks to early to the next UTAG inside write_ctrl_q and hangs. Fix is in branch Issue_801

[ThomasFuchs]

Close the issue, because the fix is now in master