SGDMA descriptor questions

[Altera_Forum]

Hi, 

 Before i ask the question, i would like to clarify my doubts regarding SGDMA. 1) A single descriptor needs 32 byte of memory to store its addresses, status, and control. right? (Since the sumation of all the bits in the descriptor data struc is 256 bits) 2) Each descriptor is able to transfer a maximum of (65536 bytes) . right? (since the data type of length is alt_u16) 3) So, 32 descriptors are required to transfer a memory size of 2MB. right? (Since 32*65536 = 2MB.)  Please let me know if any of my assumption above are wrong.   Here is my questions: 1) If i connect SGDMA(MM-ST) to a DCFIFO, and when the DCFIFO overflows, do i need to be concerned with this situation? will the SGDMA stops automatically, and continue transferring after DCFIFO has more space to store more data? or would it terminate transfer and report error? 2) How do i allocate descriptor memory in non heap environment? As my design will have multiple SGDMA, so i want to store descriptors in individual on-chip RAM for all SGDMA. 3) Does the descriptor deletes itself, after that particular transfer is done? because i want to do the transfer again after maybe 3 seconds, from the same source, to the same destination, with the same length, and i do not want to go through the trouble of re-configuration. In this case, what do i do?    As you can see, i am really stuck !!:cry: If you know the answer to any of my question above, Please try your best to explain it. any response is highly appreciated.  Thank you.  Regards, Michael

[Altera_Forum]

#1 Either the thing emptying the DCFIFO can't keep up or the DCFIFO is too shallow. Yes the SGDMA will stall if the DCFIFO is full since the FIFO will dessert the ST ready signal which will then stop the SGDMA from reading until there is more room available. 

 # 2 There are different ways. To have predictable memory usage you can carve up a block of memory into descriptors and divide them amungst the SGDMAs. That method allows you to build circular buffers easily as well as makes it much easier to transverse the linked-list (if you know where they are in memory then you don't have to jump through the list).  # 3 Nope the descriptor still remains in memory. When the transfer completes the SGDMA will write the actual_bytes transfer into the descriptor field as well as set "owned by hardware" to 0. So if you want to reuse those descriptors you might be able to just flip the owned by hardware back to 1.

[Altera_Forum]

--- Quote Start ---  #1 Either the thing emptying the DCFIFO can't keep up or the DCFIFO is too shallow. Yes the SGDMA will stall if the DCFIFO is full since the FIFO will dessert the ST ready signal which will then stop the SGDMA from reading until there is more room available.   --- Quote End ---     And this will not produce any error?    --- Quote Start ---  # 2 There are different ways. To have predictable memory usage you can carve up a block of memory into descriptors and divide them amungst the SGDMAs. That method allows you to build circular buffers easily as well as makes it much easier to transverse the linked-list (if you know where they are in memory then you don't have to jump through the list).   --- Quote End ---  Right now, i am using a 256bit width RAM with depth of 50, so the total is 1600 bytes RAM to store all the descriptors. It worked out pretty well. In my experiment, i was moving content in RAM(65K) to another RAM(65K). I created random data in Source_RAM using In-system Memory content editor, and watch the data with it in Destination_RAM after the transfer.  I have 1 question, why can't i fill in ALL the the data in Destination_RAM using DMA? it seems like certain part of my Destination_RAM is write-protected, but i just cant find any settings in Eclipse that is responsible for this. In the attached picture, the red zeros should not be there if the transfer is successful, all the data above is correct, just the bottom part is messed up. It seems like i cannt even write data manually to these range of memory address . have any idea why?? and the range of "inaccesible" RAM will only shift when some of my code changes, like using usleep(10000000); // delay 10sec .        --- Quote Start ---  # 3 Nope the descriptor still remains in memory. When the transfer completes the SGDMA will write the actual_bytes transfer into the descriptor field as well as set "owned by hardware" to 0. So if you want to reuse those descriptors you might be able to just flip the owned by hardware back to 1.    --- Quote End ---   It works! changing owned by hardware bit back to 1 will allow me to do another asyn transfer. This is how i change it.  for(i=0;i<NUMBER_OF_BUFFERS;i++){  IOWR_32DIRECT(DESC_MEM_BASE,28+32*(i), 0x80000000);   }    But is there a better way of doing this? can i set "park" to 1? so that my owned by hardware bit will not go 0 after transfer??   regards, Michael

[Altera_Forum]

A functional error due to the FIFO becoming full depends on your implementation. Data will not be dropped between the SGDMA and FIFO since both use the streaming valid and ready signals to apply back pressure. 

 You will need to use two descriptors to move 65kB of memory, descriptors only have a 16-bit length field so that means you can only write up to 65535 bytes total. So it's not that the memory is write protected, the SGDMA just can't write that much data using a single descriptor.  When parked is set then the SGDMA just doesn't flip the owned by hardware bit when the transfer completes. The tricky think is you will not know how many times the same descriptor has been reused by the SGDMA if parked is enabled so that may or may not matter to you.

[Altera_Forum]

--- Quote Start ---    You will need to use two descriptors to move 65kB of memory, descriptors only have a 16-bit length field so that means you can only write up to 65535 bytes total. So it's not that the memory is write protected, the SGDMA just can't write that much data using a single descriptor.   --- Quote End ---     I was using a chains of descriptors, not just 1. I know 1 DMA transaction can move 65KB of data, so i used a chains of 4 DMA transaction to move 16384 bytes each time, so i can move 4*16384=65536 Bytes, but still some ranges of memory address in the destination RAM is not writable, as shown in the picture    Michael

[Altera_Forum]

I recommend simulating the system since it'll be a lot easier to figure out why the memory isn't being updated.