using the SGDMA (M -> ST) without a NIOS processor

[Altera_Forum]

Hi, 

 I am having a hard time getting thre sgdma to work without the use of a nios processor.   What I want to achieve is to read a bunch of data from the SDRAM and push that into a dual clock ST FIFO.  So I setup a basic qsys with sdram controller, sgdma, dcstfifo, a custom st sink component to connect the output of the dc st fifo to and a custom component which should control the datatransfer (start it).  The st sink component I got working but the other controller is the problem.  For that IP I have a mm master -> sgdma csr, two mm slaves -> sgdma read descriptor / write descriptor and a irq receiver -> sgdma interrupt.  On the SGDMA I enabled bursting, set read burstcount signal length of 4 (I want to transfer 800 bytes (400 32 bit words)) and datawidth to 32 bits, error width is 0. So what I do is I first initialize the sgdma by writing to the control register with the mm master. Address = 4 I set the bits of IE_DESCRIPTOR_COMPLETED, IE_GLOBAL, PARK, CLEAR_INTERRUPT so it should be NOT running, generate a interrupt when a descriptor has been completed, NOT modify the owned by hwbit, and it should stop after one descriptor has been completed.  If I want to start a transfer I write again to the control register: Address = 4 I set the bits of IE_DESCRIPTOR_COMPLETED, IE_GLOBAL, RUN, PARK  So now I was expecting to see a read request on one of the mm slaves for the read descriptor but nothing is happening, I can read back the status register of the sgdma but it is always 00000000. Can someone please give me hint what I am doing wrong? ... I am really surprised that I have such a hard time understanding the documentation of the QSYS / Avalon stuff and getting it to run because before all this I was working with mikrocontrollers for years and I ate datasheets for breakfast and was always able to pull off what I wanted to do...  What I figured is that I would just need 1 dma descriptor because I want to read always the same amount of bytes just from a different starting address. (Pixel Line Buffer) So I do not want to use onchip memmory or something like that to store the descriptors in but to generate them on the fly with the mm slaves when they are needed.

[Altera_Forum]

Hello Grobi, 

Have you worked with the SGDMA with nios? If you have, you can mimic the library in how they send the descriptors and such. If you have a PCie card, you can get the drivers for it as well. Their document is very crude so it might take some time to get working. I know i had to make some fixes for it to work properly.  --Trukng

[Altera_Forum]

--- Quote Start ---  Hello Grobi, Have you worked with the SGDMA with nios? If you have, you can mimic the library in how they send the descriptors and such. --Trukng  --- Quote End ---   ... I have not worked with it before, first touch so to speak.... but thats a brilliant idea to observe a running system and mimic it, why haven't I thought of that? I will give it a shot and that will also get me a lil bit acquainted with signaltap, have not used that tool before either. Thank you!

[Altera_Forum]

Ok, I got it running now after some extensive trial and error, I found out the address of the Descriptor Read and Write master was in 32 Bit words so I had to divide it by 4 so the descitptor fields are not at address 0 , 4, 8 ... 28 they are at 1, 2 .... and the source address in the desciptor must be byte aligned. 

I also had to enable byte reordering on the sgdma to get the correct pixel data out of the dc_fifo.  BUT I do not understand the burstcount signal of the SGDMA, what is it for? It is set to 4, chaning this to 8 does not do anything, changing it to 2 and the transfer takes longer time.  BTW it takes about 2000 clocks at 100MHz to get the 1600 bytes for one line out of the sdram via the sgdma, datawidth is 32 bit, (sdram is also at 100 MHz clock phase -54 deg) . I thought it would be faster!!! If I change the datawidth of the sgdma to 16 bit like the sdram datawidth, it takes longer time for the datatransfer. I see in the sopc generator output that the sdram controller has a burstcount signal with a width of 0, so how can burst be used at all? If I disable burst transfer on the sgdma the tranfer does take longer time. One other problem is when write to the sdram to fill / clear the framebuffer, I see several pixels per line which do not get written correctly to the sdram or are not read back correctly. It looks like an uninitialised ram cell (random color).  the following is the code I use to clear / write the framebuffer (doublebuffer):  -- clear buffer clearscreen : process begin wait until rising_edge(clock_clk); if (reset_reset = '1') then clearcounter <= 0; sdram_master_write <= '0'; clearscreen_finished <= '0'; else if (clearscreen_finished = '0') then if (clearcounter < (frameHeight * frameWidth * 2)) then if (sdram_lock_required = '0') then if (sdram_master_waitrequest = '0') then sdram_master_address <= sdram_master_address <= std_logic_vector(to_unsigned(SDRAMbase + (clearcounter / 2), 32)); if (clearcounter < (frameHeight * frameWidth)) then sdram_master_writedata <= "0000100000000000" & clearcolor; else sdram_master_writedata <= "00000000001000000000000000100000"; -- g end if; sdram_master_byteenable <= "1111"; sdram_master_write <= '1'; clearcounter <= clearcounter + 2; end if; else if (sdram_master_waitrequest = '0') then sdram_master_write <= '0'; end if; end if; else if (sdram_master_waitrequest = '0') then sdram_master_write <= '0'; clearscreen_finished <= '1'; end if; end if; end if; end if; end process clearscreen;  Am I not honoring the waitrequest correctly? I want clear_buffer to run at the start of the system and to be paused during the sdram_lock_required signal is set to 1 when the sgdma is perfomring the next transfer.

[Altera_Forum]

I was able to reduce the amount of unset pixel to just a few by setting the burstcount on the sgdma to a value of 10, higher values have no effect except incerasing the amount of needed memory resources exponentially. I also found out that I wont gain any speed for the sdram access by changing the burstcount value, it wont get faster but some values like 1 or3 or 6 or 8 will make it slower. So I gues with the design of the available sdram controller, there is no more speed to gain. Doing the math 1600 bytes @ ~20µs x 1000000 / 1024 / 1024 = ~76,2 MB/s thats not bad at all but I read at http://hamsterworks.co.nz/mediawiki/index.php/sdram_memory_controller that the hardware on the board is capable of doing about 145 MB/s @ 100MHz at mixed read / write operations and in my case it is alway a continous read operation of 1600 bytes and than the other hardware can have access to the sdram, it should be possible to speed this up. Is it the altera sdram controller which is limiting the transfer speed? I guess if I wanted to use the implementation from http://hamsterworks.co.nz/mediawiki/index.php/sdram_memory_controller I would need to create a qsys component around it and only god knows what will all go wrong with that. But I will give it a try. If somebody else has an idea how to squeeze more speed out of the sdram of the DE0-nano board and the sdram controller megafunction PLEASE tell me!!!!!

[Altera_Forum]

It is working!!! 

I am so sorry to have wasted your time, I made a stupid mistake regarding the sdram clock, it is fixed now and with the burstcount of 10, I have not tried other values, yet, I get twice the speed about 138 MB/s and the pixel errors are gone!