msgdma stuck in busy state

It looks like there is a problem with the f2h_sdram interface.

I added two on-chip memory to my design and configured one as rom and one as ram and transfered data between them without any problem.

I have also seen that the msgdma shows the behaviour, that after I have send a descriptor to it it keeps in busy. I can reset this by setting the reset dispatcher bit of control register. But I can't get the msgdma into stopped status, even if I have done a reset before. It seems like the msgdma module does stuck in a transfer even after I have reset it. When I transfer another descriptor after the reset this one keeps in the descriptor buffer, another sign that the old descriptor is still in progress after the reset.

Is there a known issue with connection between the msgdma and the hps f2h sdram? Or could anybody provide me a qsys configuration example?

Tom -

What do you have the burst size configured to in the mSGDMA for the f2h_sdram interface? I had a problem with the mSGDMA that I've been meaning to open a SR about. In my case it was an Arria 10 SoC design and the mSGDMA was MM to streaming vs. your MM to MM. But my problem was also on the f2h_sdram MM interface. What I saw was that if the mSGDMA MM burst size (f2h_sdram interface) was smaller than the transfer size then the f2h_sdram interface would hang. If the MM burst size is smaller than the transfer size then the mSGDMA must submit more than one read request to the MM interface to complete the transfer. Let's say the burst size is 256 bytes and the transfer size is 1024 bytes. The mSGDMA will submit 4 256-byte read requests to the MM interface in rapid succession (the MM interface buffers the requests). The MM interface then completes the first 256-byte burst transfer and stops. The mSGDMA is stuck waiting for the remaining three bursts that never come.

I saw this in simulation using an Avalon BFM to model the f2h_sdram interface. What I described happened 100% of the time whenever the transfer size was larger than the MM burst size. I was never able to clearly capture this happening in hardware with SignalTap but other than that the hardware was behaving the same as simulation: Whenever the transfer size exceeded the burst size the mSGDMA was stuck busy waiting for data from the HPS.

So my advice is to configure your mSGDMA burst size to be the same size as your configured maximum transfer size and see what happens. Or at least test with a transfer size that is <= to your configured burst size.

I always hesitate to submit SRs for complicated problems like this because the SR process gets bogged down in an endless back and forth between time zones that are 10-12 hours apart. But I'll get around to it eventually. I still don't know 100% that the problem in hardware was exactly what I saw in simulation, but from what I could see it looked like it was.

Good luck. Please post back what you see.

Bob

--- Quote Start ---

Tom -

What do you have the burst size configured to in the mSGDMA for the f2h_sdram interface? I had a problem with the mSGDMA that I've been meaning to open a SR about. In my case it was an Arria 10 SoC design and the mSGDMA was MM to streaming vs. your MM to MM. But my problem was also on the f2h_sdram MM interface. What I saw was that if the mSGDMA MM burst size (f2h_sdram interface) was smaller than the transfer size then the f2h_sdram interface would hang. If the MM burst size is smaller than the transfer size then the mSGDMA must submit more than one read request to the MM interface to complete the transfer. Let's say the burst size is 256 bytes and the transfer size is 1024 bytes. The mSGDMA will submit 4 256-byte read request to the MM interface in rapid succession (the MM interface buffers the requests). The MM interface then completes the first 256-byte burst transfer and stops. The mSGDMA is stuck waiting for the remaining three bursts that never come.

--- Quote End ---

Bob, I've been having my own issues with the mSGDMA and park mode, and am already 2+ months in to an SR about it. I'm a fan of getting SRs in, at least to get it recorded with Altera.

I haven't seen this issue on a streaming-to-MM in 15.1.2 on a Cyclone V with Max burst=32 and max transfer much larger, with a 128-bit-wide interface.

Thanks, derim. As I said, what I saw in simulation could be a BFM problem. But the hardware never worked with transfer size > burst size. I would like to go back and do more SignalTapping to make sure the behavior in sim and hardware was the same, but hard to justify the time now that we have it working.

Are you using the prefetcher or just feeding descriptors into the descriptor slave interface? Our data interface is also 128 bits.

Bob

Maybe the prefetcher is the difference (we're not using it yet, nor is the OP), but the MM transactions should be the same either way. Time will tell. Curious to see what the OP (Tom) comes back with.

Bob

--- Quote Start ---

So my advice is to configure your mSGDMA burst size to be the same size as your configured maximum transfer size and see what happens. Or at least test with a transfer size that is &lt;= to your configured burst size.

--- Quote End ---

Hello Bob,

Thanks for your post.

I followed your advice but this didn't solve the problem. You can see my configuration at the picture (https://www.dropbox.com/s/d7174gyidtpgzqf/qsys_msgdma.png?dl=0, I need to do it that way because the forum does resize it when I upload it... unreadable...).

I will keep on trying to get the msgdma to work... I'm open for ideas and hints:confused:

Tom

--- Quote Start ---

I don't think that the f2h_sdram interface supports queuing up multiple burst transfers.

--- Quote End ---

In simulation the Avalon-MM BFM did swallow four read requests before the first burst of read data was returned. In the real system it's sometimes hard to tell (for me anyway) what Qsys injects between entities on the Avalon interconnect. I actually have two mSGDMAs, one for each direction, and they share the f2h_sdram port.

I'm going to have to invest some time into fully understanding what was happening in the hardware before I open a SR on this.

--- Quote Start ---

Hello Bob,

Thanks for your post.

I followed your advice but this didn't solve the problem. You can see my configuration at the picture (https://www.dropbox.com/s/d7174gyidtpgzqf/qsys_msgdma.png?dl=0, I need to do it that way because the forum does resize it when I upload it... unreadable...).

I will keep on trying to get the msgdma to work... I'm open for ideas and hints:confused:

Tom

--- Quote End ---

Interesting, Tom. Your mSGDMA settings are almost identical to mine except that my max transfer size is 4096 bytes, so max burst count is 256. Sorry this didn't work for you.

I'll post back with whatever I learn about the problem I was having. More testing required.

Bob