Confusing SDRAM

[Gericom]

Hi everyone,
I am working on a PAL Composite Video generator, and with color bars (no frame buffer), it works great. Now I am at the point that I need a frame buffer, and since the internal memory of the Spartan-6 would never be enough for a full 720x288x3 pixel frame buffer, I hoped to be able to use the SDRAM for this. I have tried, but the results are very bad. I think it is not fast enough or something. I used hamsters SDRAM controller.
 
Is it possible to use the SDRAM as a frame buffer, and is it fast enough? The process that needs the data (RGB->YUV conversion), runs at 50 MHz, but I think it should be possible to do this at 12.5 MHz aswell. According to hamsters wiki, the data should be available at the next clock cycle. But at the top of the controller file, stands that it may take 16 cycles.
 
I don't know if this is enough information, but I hope someone can help me with this.
 
Edit: Here is a capture of the color bars.

[hamster]

Most of the time you can issue a read command every other cycle. The times you can't are when the desired SDRAM row or bank is not the one currently open, you have delayed a refresh for a very long time or you have delayed a refresh for a long time.

 

You can use the SDRAM up to about 160MB/s or so, as long as the above cases don't happen too often.

 

The easiest way to ensure this is the case is to put a small FIFO between the memory controller and the display (64 32-bit words?) and when the FIFO is over half empty then issue 16 reads in quick succession. Issuing these reads should take priority over any else you want to do with the SDRAM.... (e.g. writing an image into it).

 

If the frame buffer is write only from the user's perspective then it should be pretty simple, as any data out of the read port goes into the display FIFO...

[Gericom]

Thanks for your quick response, but I don't understand it completely yet. The way it works right now is like this:

 

MainProc: Generates the composite video

 

ConvProc: If the current line is >= 23 and < 309, the right color bar color (rgb) is chosen, based on the pixel that will be converted. The RGB values are fed into a RGB->YUV converter ip core, and the active_video_in signal is set high. When the active_video_out signal goes high, I copy the converted YUV values to the line buffer, and the MainProc will use this buffer to modulate the YUV values in real time.

 

The first part with the RGB source, should come from the SDRAM instead (or the FIFO that is connected to it). But where do I have to do the read cycles? In an apart process?

 

Edit: I got it working with the SDRAM now, but I still have a lot of weird problems.

This for example:

It should look the same as the picture in the first post, but it is about 60% smaller. (the pink on the right is just memory that is not written) This is very weird, and it seems related to reading. If I change the clock of the read process from 100MHz to 50MHz, the picture becomes twice as big as the picture in the first post. This should not happen, since each pixel should be inserted in the fifo once.

 

And sometimes I get weird dots at a couple of places, as if the data was not transfered correctly, and when writing, I have to put the data in reversed order, to get the right order at the output. (if the output has to be XRBG, the input has to be BGXR. R,G,B and X are all bytes)

 

Edit2: I now got it working. It turned out, that I don't need a fifo or a separate process. I will try to get a picture loading from the flash memory soon, so I can show it working.

 

Edit3: This picture is uploaded using serial rather than the flash, but it works!

The lines are all doubled, because I have not implemented interlacing yet, and I send the line number as a byte over the serial, so that's why the top of the picture is repeated at the bottom (after 255 lines). At some places you can also see some little dots, caused by the sdram, which seems to not recieve correct data at some times.

[Jack Gassett]

Very cool Gericom!

[hamster]

At some places you can also see some little dots, caused by the sdram, which seems to not recieve correct data at some times.

 

I would be really keen to see what is going on with the odd little dots. Do they shimmer? (i,e, is it read errors?) Reads have the trickiest timing, where as for writes the data is all from the FPGA to the SDRAM, so timing errors are unlikely. 

 

Is there any chance of checksumming the data as it is sent (maybe to some LEDs), allowing the us to see if it is a problem on the SDRAM's write interface or if it is a problem on the RS232 side of things? It could be a very small timing glitch in your RS232 RX, however if that was the case it would be more normal for entire bytes to get dropped, and then the picture would go crazy.

 

The last project I put up does pretty much the same but with audio and I have a bit of noise that I think is from the one-bit DACs driving low impedance headphones, but might be data errors. My plan was is to use an I2S DAC and see if the noise goes away....

[Gericom]

Very cool Gericom!

Thanks!

 

I would be really keen to see what is going on with the odd little dots. Do they shimmer? (i,e, is it read errors?) Reads have the trickiest timing, where as for writes the data is all from the FPGA to the SDRAM, so timing errors are unlikely. 

 

Is there any chance of checksumming the data as it is sent (maybe to some LEDs), allowing the us to see if it is a problem on the SDRAM's write interface or if it is a problem on the RS232 side of things? It could be a very small timing glitch in your RS232 RX, however if that was the case it would be more normal for entire bytes to get dropped, and then the picture would go crazy.

 

The last project I put up does pretty much the same but with audio and I have a bit of noise that I think is from the one-bit DACs driving low impedance headphones, but might be data errors. My plan was is to use an I2S DAC and see if the noise goes away....

The dots did also appear with those color bars, so it's definitly not the uart. After the dots have appeared, they don't move or something, so I think it must be a writing issue. Maybe it is related to a delayed refresh or something?

Edit: I added interlacing!

The dots are still there.

In this picture, you can see the dots very good:

This is the original picture:

Edit2: After changing the pixel clock from 50MHz to 54MHz (4x13.5MHz), I realised that I forgot to wait for the last pixels to come out of the sdram. And now the dots are gone!

[hamster]

So in summary we are all good? Do I need to add any notes to my wiki page to help others in the future?

 

Mike

[Gericom]

So in summary we are all good? Do I need to add any notes to my wiki page to help others in the future?

 

Mike

Yea, I think so.

I don't know if waiting for requested data, before doing a write is the solution. That would require some more testing.

[offroad]

>> The last project I put up does pretty much the same but with audio and I have a bit of noise that I think is from the one-bit DACs driving low impedance headphones, but might be data errors. My plan was is to use an I2S DAC and see if the noise goes away....

 

Hi,

 

I wasn't able to make those work on the retrocade, beyond a resolution of maybe 7 bits or so. When the signal level gets too low, the signal breaks up.

This SPI DAC works for me, fairly straightforward to program:

http://numato.com/cs4344-audio-expansion-module