Honored Contributor
Honored ContributorI 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!!!!!
