Source of errors in data from SGDMA

[Altera_Forum]

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)

[Altera_Forum]

Your 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? 

[Altera_Forum]

You could have a look at the avalon bus side of your sdram controller using Signaltap, but it indeed looks like a timing problem. 

Converting your values to hex shows that you have a repeated byte. You write 0x1be7d2cc but read back 0x1b1be7d2

[Altera_Forum]

I will look at the timing parameters in the controller again but ive checked them three times now. The data sheet gives me a bit of trouble as its not as verbose as an equivalent from a company like Hynix. 

 The SDRAM I am using is a K4S510832M (attached).   The controller settings are: Data: 8 Chip Select: 1 Banks: 4 Addr. Width: 13 Col. Width: 11   I would suppose these have to be correct or else even the simple memory tests would not pass.   CAS Latency: 3  Data Sheet specifies CL of 2 & 3.   Init. Refresh. Cycles: 2 Cannot find specification in data sheet   Issue one refresh command every: 15.625 us Data sheet specifices refresh period of 64ms/8K cycles which is what I used to calculate this.   Delay after powerup, before initialization: 100us Cannot find specification in data sheet   Duration of refresh command (t_rfc): 70ns Cannot find specification in data sheet   Duration of precharge command (t_rp): 20ns Cannot find specification in data sheet   ACTIVE to READ or WRITE delay (t_rcd): 20ns Data sheet specifies tRCD but as the !RAS to !CAS delay which I don't think means the same thing   Access time (t_ac): 5.5ns Data sheet specifies 'Clock to output valid delay' as the closest thing I could find.   Write recovery time (t_wr): 14ns Cannot find specification in data sheet    Im thinking the memory does power up and work with no bursts, so the initialization, refresh and precharge commands are likely OK. So I should tweak the t_rcd, t_ac and t_wr values increasing them a few times to see what effect that has (assuming that the memory is sampling too quickly resulting in dropped data and misplaced bytes).

[Altera_Forum]

Hello, 

 I have played with the timing settings of the SDRAM controller without much success.   Modifying the t_ac access time and the t_wr (data write recovery time) resulted in a greater range of erroneous values but no signifcant change in reliability.   I put SignalTap on the SDRAM data and control lines and my scope on a couple to have a look at what it was doing. (At this point I was writing a value of 185, below 255 so I could try and see why the bytes were shifting position)   The only thing that stands out to me is the waveform of the line Data0 on the scope in comparison to the clock, and that is that its rise time is equal to an entire wavelength of the clock, could this be the source of the errors?

[Altera_Forum]

I don't have a lot of experience debugging those kind of interfaces so I can't be of much help here. The rise time indeed looks long. Are you sure it isn't due to the scope probe? 

Did you use a Vref pin for that I/O by any chance? VRef pins have a higher capacity than regular I/O pins, and can cause slower rise/fall times. Did you check also your Timequest assignments? Do you meet all timing requirements?

[Altera_Forum]

Hi Daixiwen, 

 Though there is a VREF pin used within the data bus that capture was on a DIFFIO pin; I have monitored a couple more data bits and the waveforms are practically identical. I am not sure how to tell if it is the scope or not as I only have one type of probe, the rise time of the clock signal however doesn't seem to be affected. (Though that is a PLL output)   Until now I was using the Classic Timing Analyzer. It reports the rise time of 0.9ns, for both the clock and the data bus pins. I am taking one of the online tutorial/courses from Altera on TimingQuest and will try and use this to assess the design.

[Altera_Forum]

Hello, 

 Using the example in the excellent document in this thread (http://www.alteraforum.com/forum/showthread.php?t=1269&page=2) I wrote a short SDC file and recompiled my project. After removing the phase shift on the PLL to meet the timing requirements the new constrained project works perfectly with no errors on the burst reads & writes, running at 70Mhz, so problem solved! :D   Thank you very much Daixiwen. I really appreciate all your time you've spent helping me with this. I'll get another SDC written up for the LCD project and then hopefully everything should work from here on in.     If I may just ask one last thing about the timing constraints; when I set my PLL to output 70MHz I get a couple of reported failures on the PLL output which feeds the memory clock pin (the one that I originally had the phase shift on).  I just wanted to know what the source of this was, I was thinking it had something to do with the phase of this clock with respect to the controller logic but when I try to offset it with a phase shift in the PLL it makes the slack worse.   I remove the PLL phase shift in order for the timing analysis to pass, so I assume the phase shift (if needed) is being applied automatically based on my timing constraints?   Thank you again! Sebastian

[Altera_Forum]

It may depend on the output delay that you stated for the clk pin. Try to put a longer one. 

But as long as all your I/O timing requirements are made relative to the clock pin, it shouldn't be a problem. At 70MHz SDR I think that Quartus is able to make you meet the timing requirements without requiring a phase shift. If you get negative slack on the I/O again, you can try and adjust the shift until you don't.

[Altera_Forum]

Hi Daixiwen, 

 I created an SDC for the graphics project and this worked well with the exception of a couple of read errors which derailed the program. You must be correct about Quartus meeting constraints at 70Mhz with no phase shift as to resolve this I removed the phase shift and instead extended the minimum input delay to account for my board which probably has a poorer performance than the Altera documentions standard estimate of 0.5ns assumes.   Once I added this slight delay the problems were resolved, confirmed with some lengthy memory tests. The display is now working perfectly.   Thank you again for all your help. Sebastian