Video Framebuffer using Nexys2 (Spartan-3E)

Hello, I am currently working on a school project that involves interfacing
an external video device with my Nexys2-1200 (XC3S1200E-4FG320) development
board.  The device has a resolution of 256x384 with 18-bit RGB video data
per pixel (6-bits per color).  To start, I took the 18-bit data and cut it
down significantly to 8-bit color (R=3bits,G=3bits,B=2bits).  This allowed
me to use the built-in VGA port on the Nexys2.  I then created 49152 bytes
of BlockRAM in a "Simple Dual-Port" configuration using the CORE Generator
in Xilinx ISE.  This is enough RAM to hold the top half of the screen on my
device (so 256x192).  One port is used strictly for writing to RAM and the
other port is strictly for reading from RAM.  Using all this, I got the
top-half of the screen to output through the VGA port.  The 256x192 is
sitting at the top-left corner of the VGA window and the rest is black. 
I'm actually surprised it works, haha.

Anyway, I would like to take the project a step further and use the entire
screen (the full 256x384) along with a higher color resolution of 16-bits
per pixel (R=5bits,G=6bits,B=5bits).  My problem is I don't know how to
effectively use the external 16MB Micron PSDRAM (MT45W8MW16BGX-708) for
this situation since the BlockRAM won't cut it.  My VGA pixel clock is
25MHz (40ns), and the external clock to latch the pixel data from my device
is 5.6MHz (180ns).  If I use the Micron RAM in the default asynchronous
mode, then the read/write access times are 70ns.  This is obviously too
slow for my pixel clock, but there are several different ways to operate
that Micron PSDRAM.  There is also free time during the blanking intervals
of the video that I can work with.  I guess my question is, what is the
general strategy to create a video framebuffer using a external RAM module
like the one I have?  Is it even possible with this specific chip or do I
need something faster and with dual ports?

Thanks for your help, and sorry if I'm not being too clear about anything. 
Just let me know and I'll clarify it.

Link to datasheet: http://www.micron.com/get-document/?documentId=444
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

> Anyway, I would like to take the project a step further and use the entire
> screen (the full 256x384) along with a higher color resolution of 16-bits
> per pixel (R=5bits,G=6bits,B=5bits).  My problem is I don't know how to
> effectively use the external 16MB Micron PSDRAM (MT45W8MW16BGX-708) for
> this situation since the BlockRAM won't cut it.  My VGA pixel clock is
> 25MHz (40ns), and the external clock to latch the pixel data from my device
> is 5.6MHz (180ns).  If I use the Micron RAM in the default asynchronous
> mode, then the read/write access times are 70ns.  This is obviously too
> slow for my pixel clock, but there are several different ways to operate
> that Micron PSDRAM.  There is also free time during the blanking intervals
> of the video that I can work with.  I guess my question is, what is the
> general strategy to create a video framebuffer using a external RAM module
> like the one I have?  Is it even possible with this specific chip or do I
> need something faster and with dual ports?

I think it should be fine. Use the MIG to an interface for your external 
RAM. Feed the incoming video into the MIG's FIFO and it'll write using 
burst mode. The 70 ns latency is only for switching to a new page - if 
you feed in a whole row of sequential writes this won't be such a big 
deal, and you can clock the RAM as fast as it'll go. Then read it back 
during the blanking period, or even in between writes if your 
calculations show that you'll have enough time.

Joel

On Friday, March 4, 2011 1:18:10 AM UTC-5, Joel Williams wrote:
> > Anyway, I would like to take the project a step further and use the entire
> > screen (the full 256x384) along with a higher color resolution of 16-bits
> > per pixel (R=5bits,G=6bits,B=5bits).  My problem is I don't know how to
> > effectively use the external 16MB Micron PSDRAM (MT45W8MW16BGX-708) for
> > this situation since the BlockRAM won't cut it.  My VGA pixel clock is
> > 25MHz (40ns), and the external clock to latch the pixel data from my device
> > is 5.6MHz (180ns).  If I use the Micron RAM in the default asynchronous
> > mode, then the read/write access times are 70ns.  This is obviously too
> > slow for my pixel clock, but there are several different ways to operate
> > that Micron PSDRAM.  There is also free time during the blanking intervals
> > of the video that I can work with.  I guess my question is, what is the
> > general strategy to create a video framebuffer using a external RAM module
> > like the one I have?  Is it even possible with this specific chip or do I
> > need something faster and with dual ports?
> 
> I think it should be fine. Use the MIG to an interface for your external 
> RAM. Feed the incoming video into the MIG's FIFO and it'll write using 
> burst mode. The 70 ns latency is only for switching to a new page - if 
> you feed in a whole row of sequential writes this won't be such a big 
> deal, and you can clock the RAM as fast as it'll go. Then read it back 
> during the blanking period, or even in between writes if your 
> calculations show that you'll have enough time.
> 
> Joel

Correct me if I'm wrong, but the last time I looked, MIG
only supported the standard DDR, and DDR2 parts for
Spartan 3, not the "specialty" parts like Cellular
PSDRAM.  Does the Nexsys2 kit come with some other
IP to talk to the PSDRAM?  Or do they just assume
that it's a simple enough interface to roll your
own?  In burst mode it should certainly be more than
fast enough to do what you want.  You could even
intersperse reading and writing as long as you
keep one direction long enough to keep up the
required throughput rate.  Just buffer the reads
and writes with block RAM.  You need some sort
of simple arbiter to switch between the read
and write processes at a "burst" level.  Then
the camera input can be effectively asynchronous
to the VGA screen refresh.

-- Gabor

>> I think it should be fine. Use the MIG to an interface for your external
>> RAM. Feed the incoming video into the MIG's FIFO and it'll write using
>> burst mode. The 70 ns latency is only for switching to a new page - if
>> you feed in a whole row of sequential writes this won't be such a big
>> deal, and you can clock the RAM as fast as it'll go. Then read it back
>> during the blanking period, or even in between writes if your
>> calculations show that you'll have enough time.
>>
>> Joel
>
> Correct me if I'm wrong, but the last time I looked, MIG
> only supported the standard DDR, and DDR2 parts for
> Spartan 3, not the "specialty" parts like Cellular
> PSDRAM.  Does the Nexsys2 kit come with some other
> IP to talk to the PSDRAM?  Or do they just assume
> that it's a simple enough interface to roll your
> own?  In burst mode it should certainly be more than
> fast enough to do what you want.  You could even
> intersperse reading and writing as long as you
> keep one direction long enough to keep up the
> required throughput rate.  Just buffer the reads
> and writes with block RAM.  You need some sort
> of simple arbiter to switch between the read
> and write processes at a "burst" level.  Then
> the camera input can be effectively asynchronous
> to the VGA screen refresh.
>
> -- Gabor

Sorry, you're right, of course!

The Nexys2's built in self test code contains a memory controller 
(NexysOnBoardMemCtrl.vhd) but it's not clear at first glance if it's 
advanced enough to support burst mode. Probably not.

You could also try http://opencores.org/project,opb_psram_controller , 
which looks like it would support the Nexys2.

There might also be some helpful hints in the comments of this video: 
http://www.youtube.com/watch?v=nyrllob-Juk

Joel

>>> I think it should be fine. Use the MIG to an interface for your
external
>>> RAM. Feed the incoming video into the MIG's FIFO and it'll write using
>>> burst mode. The 70 ns latency is only for switching to a new page - if
>>> you feed in a whole row of sequential writes this won't be such a big
>>> deal, and you can clock the RAM as fast as it'll go. Then read it back
>>> during the blanking period, or even in between writes if your
>>> calculations show that you'll have enough time.
>>>
>>> Joel
>>
>> Correct me if I'm wrong, but the last time I looked, MIG
>> only supported the standard DDR, and DDR2 parts for
>> Spartan 3, not the "specialty" parts like Cellular
>> PSDRAM.  Does the Nexsys2 kit come with some other
>> IP to talk to the PSDRAM?  Or do they just assume
>> that it's a simple enough interface to roll your
>> own?  In burst mode it should certainly be more than
>> fast enough to do what you want.  You could even
>> intersperse reading and writing as long as you
>> keep one direction long enough to keep up the
>> required throughput rate.  Just buffer the reads
>> and writes with block RAM.  You need some sort
>> of simple arbiter to switch between the read
>> and write processes at a "burst" level.  Then
>> the camera input can be effectively asynchronous
>> to the VGA screen refresh.
>>
>> -- Gabor
>
>Sorry, you're right, of course!
>
>The Nexys2's built in self test code contains a memory controller 
>(NexysOnBoardMemCtrl.vhd) but it's not clear at first glance if it's 
>advanced enough to support burst mode. Probably not.
>
>You could also try http://opencores.org/project,opb_psram_controller , 
>which looks like it would support the Nexys2.
>
>There might also be some helpful hints in the comments of this video: 
>http://www.youtube.com/watch?v=nyrllob-Juk
>
>Joel
>

Hmmm...let me just recap to make sure I understand everything thus far. 
Okay, so the general strategy is to sequentially push/pull the data to/from
DDR memory while using some BlockRAM to hold data between bursts.  Also,
some logic will be needed to determine when would be the best time to
switch between reading and writing.  Normally, one would create a DDR
memory controller using the MIG in Xilinx's Core Generator.  However, my
board doesn't have a standard DDR memory module and instead has a
PseudoSRAM (which the MIG doesn't support).  This particular external RAM
has a mode that acts like asynchronous SRAM which is slow but easy to write
a controller for.  It also has a burst mode that acts like synchronous
DRAM, which is fast but needs a more complicated controller.  All Digilent
supplies you with is a VHDL module that probably doesn't even support burst
mode.  I have a textbook that explains how to use the slow asynchronous
mode, but of course that won't cut it.

Since I know nothing about VHDL (I'm a Verilog boy), should I even attempt
learning VHDL to analyze the above sample code or should I just jump
straight into writing it in Verilog from scratch?  If I were to create a
VHDL controller based on the links above, can I even instantize a VHDL
module from my Verilog top module?  I don't want to have to rewrite the
rest of my code.  I should mention that we only have 40 days left until we
have to present this project, although Spring break is next week and I
should have tons of spare time.  Showing half the screen is good enough for
me, but I would like the whole picture to be available.  Because I know
nothing about DDR style memory controllers, is there anything else you guys
can point me to for help in designing a burst mode controller from scratch
(preferably more concepts than code)?  Or am I just stuck with what that
datasheet gives me?

Sorry for the run-on sentences, all the questions, and my stupidity.  But
thanks for all the help thus far!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

> Hmmm...let me just recap to make sure I understand everything thus
> far. Okay, so the general strategy is to sequentially push/pull the
> data to/from DDR memory while using some BlockRAM to hold data
> between bursts.  Also, some logic will be needed to determine when
> would be the best time to switch between reading and writing.
> Normally, one would create a DDR memory controller using the MIG in
> Xilinx's Core Generator.  However, my board doesn't have a standard
> DDR memory module and instead has a PseudoSRAM (which the MIG doesn't
> support).  This particular external RAM has a mode that acts like
> asynchronous SRAM which is slow but easy to write a controller for.
> It also has a burst mode that acts like synchronous DRAM, which is
> fast but needs a more complicated controller.  All Digilent supplies
> you with is a VHDL module that probably doesn't even support burst
> mode.  I have a textbook that explains how to use the slow
> asynchronous mode, but of course that won't cut it.

All sounds right!

> Since I know nothing about VHDL (I'm a Verilog boy), should I even
> attempt learning VHDL to analyze the above sample code or should I
> just jump straight into writing it in Verilog from scratch?

It's been a few weeks since I looked at the module, but from memory it
wouldn't have been too difficult to convert it from VHDL to Verilog. I
would probably do this just so that I can attempt to understand what
it's doing, by analysing it line by line.

The OPB_PSRAM_CONTROLLER code looks quite a lot nicer, though you'd need 
to implement an OPB bus to use it without modification 
(http://www.xilinx.com/support/documentation/ipembedprocess_coreconnect_opbbusstruct.htm)

> If I were to create a VHDL controller based on the links above, can
> I even instantize a VHDL module from my Verilog top module?

Yes, there shouldn't be any problem doing that.

> Because I know nothing about DDR style memory controllers, is there
> anything else you guys can point me to for help in designing a burst
> mode controller from scratch (preferably more concepts than code)?
> Or am I just stuck with what that datasheet gives me?

I've never tried doing it, but the data sheet should hopefully tell you 
everything you need to do! :) Basically, work out what the sample code 
is doing and match it up to the data sheet. Then work out what you need 
to do differently for burst mode.

Joel

Thanks, Joel, for all the answers and the motivating attitude.  One of the
other members of our squad is pretty keen on VHDL.  We'll try our best!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Hi Joel,

I have very similar project and I am thinking using a dev kit like Digilent Nexys 2 for a TFT test purpose, and I have some question. Did you solve your problem with RAM buffer, did you succeed to store the whole picture inside the PSDRAM ?

I need to test a GVIF or LVDS signals that have 50 MHz pixel clock and 24 bits RGB with Hsync and Vsync, firstly I wa thinking to store a whole image inside PSDRAM but it's looks like too slow for this purpose...

Thanks for your support.

David

Hi Joel, 

I have very similar project and I am thinking using a dev kit like Digilent Nexys 2 for a TFT test purpose, and I have some question. Did you solve your problem with RAM buffer, did you succeed to store the whole picture inside the PSDRAM ? 

I need to test a GVIF or LVDS signals that have 50 MHz pixel clock and 24 parallel bits RGB with Hsync and Vsync (TFT have 1024 x 768 pixels), firstly I was thinking to store a whole image inside PSDRAM but it's looks like too slow for this purpose... 

Thanks for your support. 

David 

On Sunday, March 13, 2011 11:11:18 PM UTC-7, Ste wrote:
> ...
> Since I know nothing about VHDL (I'm a Verilog boy), should I even attemp=
t
> learning VHDL to analyze the above sample code or should I just jump
> straight into writing it in Verilog from scratch?

One underappreciated tool is VHD2VL, which translates VHDL to Verilog with =
passable fidelity.  I'm not a VHDL guy either, so I use it whenever I need =
to deal with a board support package or other existing HDL modules that are=
 only available in VHDL.  It usually gets you 99% of the way to a usable Ve=
rilog implementation. =20

Its latest incarnation seems to be at http://doolittle.icarus.com/~larry/vh=
d2vl/ but he doesn't provide a Windows executable.  I posted one at http://=
www.ke5fx.com/VHD2VL_Windows_x64.zip if anyone wants to grab it.

> If I were to create a
> VHDL controller based on the links above, can I even instantize a VHDL
> module from my Verilog top module? =20

Yes, you can mix and match HDLs freely.  ISE will do the right thing automa=
tically if you add .vhd files to a Verilog project.

-- john