Video Framebuffer using Nexys2 (Spartan-3E)

[Ste]

Hello, I am currently working on a school project that involves interfacin
an external video device with my Nexys2-1200 (XC3S1200E-4FG320) developmen
board. The device has a resolution of 256x384 with 18-bit RGB video dat
per pixel (6-bits per color). To start, I took the 18-bit data and cut i
down significantly to 8-bit color (R=3bits,G=3bits,B=2bits). This allowe
me to use the built-in VGA port on the Nexys2. I then created 49152 byte
of BlockRAM in a "Simple Dual-Port" configuration using the CORE Generato
in Xilinx ISE. This is enough RAM to hold the top half of the screen on m
device (so 256x192). One port is used strictly for writing to RAM and th
other port is strictly for reading from RAM. Using all this, I got th
top-half of the screen to output through the VGA port. The 256x192 i
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 entir
screen (the full 256x384) along with a higher color resolution of 16-bit
per pixel (R=5bits,G=6bits,B=5bits). My problem is I don't know how t
effectively use the external 16MB Micron PSDRAM (MT45W8MW16BGX-708) fo
this situation since the BlockRAM won't cut it. My VGA pixel clock i
25MHz (40ns), and the external clock to latch the pixel data from my devic
is 5.6MHz (180ns). If I use the Micron RAM in the default asynchronou
mode, then the read/write access times are 70ns. This is obviously to
slow for my pixel clock, but there are several different ways to operat
that Micron PSDRAM. There is also free time during the blanking interval
of the video that I can work with. I guess my question is, what is th
general strategy to create a video framebuffer using a external RAM modul
like the one I have? Is it even possible with this specific chip or do
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

 

[Joel Williams]

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

 

[Gabor]

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

 

[Joel Williams]

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

 

[Ste]

I think it should be fine. Use the MIG to an interface for you
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/fro
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 t
switch between reading and writing. Normally, one would create a DD
memory controller using the MIG in Xilinx's Core Generator. However, m
board doesn't have a standard DDR memory module and instead has
PseudoSRAM (which the MIG doesn't support). This particular external RA
has a mode that acts like asynchronous SRAM which is slow but easy to writ
a controller for. It also has a burst mode that acts like synchronou
DRAM, which is fast but needs a more complicated controller. All Digilen
supplies you with is a VHDL module that probably doesn't even support burs
mode. I have a textbook that explains how to use the slow asynchronou
mode, but of course that won't cut it.

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

Sorry for the run-on sentences, all the questions, and my stupidity. Bu
thanks for all the help thus far!


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Joel Williams]

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

 

[Ste]

Thanks, Joel, for all the answers and the motivating attitude. One of th
other members of our squad is pretty keen on VHDL. We'll try our best!


---------------------------------------
Posted through http://www.FPGARelated.com

 

[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 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

 

[John Miles]

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 attempt
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 Verilog implementation.

Its latest incarnation seems to be at http://doolittle.icarus.com/~larry/vhd2vl/ 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?

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

-- john