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)

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?

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.

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.

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?

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).

Source of errors in data from SGDMA | Altera Community

18 Replies

Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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?
multiple-attachments.zip1.5 MB
Altera_Forum
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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
Honored Contributor
15 years ago
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

Forum Discussion

Source of errors in data from SGDMA

18 Replies

Recent Discussions

Cyclone-V SCFIFO with M10K/MLAB memory - adding ECC

Agilex3/5 GTS Hard Ethernet IP 10G example design pin loc and io std wanted

Agilex 7 slew rate reconfiguration

Agilex-7 AXI MCDMA for PCIe hang

Constraints not being picked for DCFIFO