Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorSource of errors in data from SGDMA
Hello,
Sorry to be back so quick but I have spent the last two days on this and am at a loss. I have an SGDMA which is reading 16 bit data from an 8bit SDRAM and streaming this to a video pipeline. It is working but I am getting errors in the data. Whatever the problem is it manifests itself in two ways, the first I believe are errors in writing to the SDRAM which result in vertical lines of one pixel wide on the display, there are always 9 of them in a fairly consistent pattern. The second which I am focusing on are *seemingly* random drops of a few bits from various pixels which results in a 'storm' of dark pixels moving accross the display. Putting SignalTap accross the SGDMA data lines I can see both errors in the data being fed right from the SGDMA. Between the NIOSII program running of it and the refresh commands I cannot be sure of what I see on the SDRAM side. I have calculated my PLL shift and manually moved this up and down from its calculated value (2.08ns) up to 10ns and it makes no difference. Neither does changing the clock of the memory to anything between 40 and 90Mhz. Testing the content of the memory in the program results in incosistent responses, sometimes no errors are reported sometimes one every read. There is no termination on the data lines (OCT or otherwise), but what I dont get is if the SDRAM controller is the source of this how can the NIOSII program run? Does anyone have any idea what could be wrong? (To see what the problem looks like on screen: http://media.diynot.com/103000_102534_26014_87556468_thumb.jpg (http://www.diynot.com/network/sebmaster/albums/6462/26014) http://media.diynot.com/103000_102534_26015_41549493_thumb.jpg (http://www.diynot.com/network/sebmaster/albums/6462/26015)) And for a typical capture of one line in SignalTap: http://media.diynot.com/103000_102534_26013_19009104_thumb.jpg (http://www.diynot.com/network/sebmaster/albums/6462/26013)18 Replies
Altera_ForumYour signaltap image is unreadable.
I don't think that memory read or write errors in the SDRAM controller would create such a regular pattern. When you write to the SDRAM, do you flush the data cache? Do you have a FIFO between the SGDMA and the video output?- Altera_Forum
Hi Daixiwen,
Ill see if I can get a better image. I do have a FIFO thats buffering between two clock domains and it is working. The NIOSII I am using is the /e and so there is no data cache. - Altera_Forum
Here is a capture for a typical line with the frame buffer written to 0xFFF0:
http://rapidshare.com/files/417808007/stcap-blueframebuffer.jpg And here is one with an empty frame buffer (0x0): http://rapidshare.com/files/417808438/stcap-blackframebuffer.jpg Can you make any sense of them? To me the first one looks as if the data output by the SGDMA bears little relation to that on m_read. - Altera_Forum
I can't download the second image ("you reached the limit for free users"). Couldn't you just attach them to a message on the forum? If you save them as png or gif, the size should be quite small.
I would need to see the readdatavalid and ready/valid signals too, if possible on both sides of the FIFO. Did you configure the SGDMA to use bursts? - Altera_Forum
Hi Daixiwen,
Thank you for looking at this. Sorry I didn't realise this forum would allow me to attach the images. Do those show everything you need? The Ready/Valid looks about right if I query the FIFO fill level in software it oscillates around 8185-8190 as expected. Bursting is enabled with a max count of 8 on the data, no bursting on the descriptors (these have their own dedicated on-chip memory). - Altera_Forum
I agree it is strange that the values on m_read and out_data are different. Could you also show the readdatavalid signal on the m_read interface?
Is it the stream FIFO from SOPC builder that you are using? I thought that ready and valid needed to be active at the same time for an actual transfer to take place. - Altera_Forum
Here are some captures showing the readdatavaliad and other control signals for the SGDMA interfaces.
The m_read_read signal has an interesting pattern when comparing it with the spurious high bits which I assume make up the white lines, though not 100% consistent, but the random dropped bits still appear to be just that. I am using the 'On-Chip FIFO Memory v9.1' from the SOPC builder (as opposed to the Avalon-ST Dual Clock FIFO and Avalon-ST Shared Memory FIFO). - Altera_Forum
There doesn't seem to be anything wrong with the memory transfers done by the DMA. You should only look at the data on the m_read interface when readdatavalid is 1. When that signal is 0 the data could be anything.
So the problem could rather come from the data written by the Nios CPU to the memory, or a problem on the memory controller when it uses bursts. Could you do a setup with a Nios CPU that has a data cache (with bursts enabled) and run a memory test application from on-chip memory? This setup should test the burst operation of the DRAM controller. - Altera_Forum
Hi,
Ive spent the last few hours trying to set up the burst test but something has gone wrong; my new project doesn't seem to be able to access the memory at all. The program cannot read/write it and neither can I using the memory monitor in the debugger. The project and the controller have the same settings as the previous ones and the memory is connected to all the buses. I can access the memory using the memory monitor with an older project. The only odd thing is that in this new one, there are no entries for the memory data lines in the tsu section of the timing analysis report, does this mean anything to you? I will leave this project for now and add a NIOS /f to one I know that is working, but I don't understand what could have gone wrong. EDIT: Whoops never mind I just realised I made a very, very stupid mistake in my new project... - Altera_Forum
Hi Daixiwen,
It does appear to be the burst accesses. I have my program write a set value to every memory address in one go, then attempt to read the entire memory back checking the content of each address against this value. If I choose a value such as 0x0, 0xF0F0F0F0 or 0xFFFFFFFF it passes fine, however if I provide the program with a 'random' integer such as 468177612 it fails on every address, but not just on reading back any value. For the value above the program will read, from every address, 454813650. There may be one or two odd values in the list but for over 4000 addresses it will fail with that specific value. (My data cache is 1Kbyte and the line size is 32bytes) A similar pattern emerges when I provide other values; using uncached accesses makes no difference. The example memory test program doesnt get past the first bit of the data bus. If I disable the data cache of the NIOS the program completes successfully regardless of the values provided. Surely this means the error is with my SDRAM controller. I have tried manually tuning the PLL, so unless I have the timing parameters wrong does this mean I have a hardware problem?
