FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6355 Discussions

SGDMA behaves badly if its descriptors are in off-chip RAM?

Altera_Forum
Honored Contributor II
895 Views

I observed some odd SGDMA behavior today. Does SGDMA behave badly if its descriptors are in off-chip RAM? In any case I think I see it copying the wrong data in the attached signal tap output. The correct data flows in in the top trace, but the avalon-mm writes to memory are skipping some of the data that is streaming in? Perhaps the issues is contention between its descriptor read/write functions and the dma function if they are attached to the same tap on the same pipeline bridge? When I moved the descriptors into on-chip ram the problem vanished. I do use the IO functions to access the descriptors so there shouldnt be any cache flushing invalidating issues if the descriptors are in off-chip ram. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=7785
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
176 Views

No I've already used systems with the SGDMA using external memory on all its masters without any problem. 

Could you add the ready signal to your Signaltap output? 

Does Timequest report any timing violation?
0 Kudos
Altera_Forum
Honored Contributor II
176 Views

Unfortunately, I changed the QSYS code around to use on-chip descriptors only. Is it important to know these details in terms of understanding the situation? I am under some schedule pressure at the moment, but when I return from travel I might be able to grab the details you requested. 

 

There were not any timing violations in the code in question other than a very slim margin for an RGMII interface between chips; I am fixing that now, to run at a lower clock rate. 

 

It could be that my issues was due to programmer error, but the signal tap did appear to be quite odd so I decided to document the situation. Could this be caused by a configuration error on the avalon stream? In this case it was a direct connection between the TSE MAC and the SGDMA. 

 

Thanks for your attention to the matter,
0 Kudos
Altera_Forum
Honored Contributor II
176 Views

It is better to get all the signals in order to try to understand what the SGDMA is doing. It can also be an idea to check what is happening on the SGDMA's descriptor read master, and verify that it gets the correct descriptor. 

Except for that the only thing I can think about is verify that both the CPU and the SGDMA are connected to the memory that you are using for the descriptors, that they both see it at the same address, and that your software indeed writes the descriptor at the correct address.
0 Kudos
Reply