DDRé SDRAM configuration

G

Gladys

Guest
hi all, I want to implement a DDR2 SDRAM controller, as Xilinx
provides MIG software tool to create IP core for the memory
interface, however I have some questions about the port configuration.

I want to store up to 9 frames(3000H x 2748V) of image data into 1GB
DDR2 SDRAM(MT47H64M16), the frame size is resolution x bits/pixel = 10
megapixels(3664H x 2748V) x 12bits/pixel = 15MB.

In the prototyping, the address bits = 14, data bits=16, bank
address=3bits, I need asynchronous write and read from SDRAM:

1- How to choose Port Configuration among the 5 configurations? For
example:2 32bits Bidir + 4 32bits Unidir, 4 32bits Bidir, 2 64bits
Bidir, etc.

2- How to choos the fruequency, in the datasheet, the max frequency
could be 333MHz, actually the master clock of FPGA is set to 25MHz,
what frequency for the SDRAM should be fine?

3- Since each pixel has 12bits, the data bus is 16bits, How should the
storage perform, the extra 4 bits will be a waste, is it?

4- how are the frames stored? line by line, frame by frame, how to
seperate each line or each frame?

Thanks for your help!

Gladys
 
On Jul 15, 6:17 am, Gladys <yuhu...@gmail.com> wrote:
hi all, I want to implement a DDR2 SDRAM controller, as Xilinx
provides MIG  software tool to create IP core for the memory
interface, however I have some questions about the port configuration.

I want to store up to 9 frames(3000H x 2748V) of image data into 1GB
DDR2 SDRAM(MT47H64M16), the frame size is resolution x bits/pixel = 10
megapixels(3664H x 2748V) x 12bits/pixel = 15MB.
3664 x 2748 x 12 x 9 = 1,087,416,576 bits. That won't quite fit into
1 gigabit
or 1,073,741,824 bits.

In the prototyping, the address bits = 14, data bits=16, bank
address=3bits, I need asynchronous write and read from SDRAM:

1- How to choose Port Configuration among the 5 configurations? For
example:2 32bits Bidir + 4 32bits Unidir, 4 32bits Bidir, 2 64bits
Bidir, etc.
Is this the Spartan 6 memory controller? You need to select the size
and number of ports based on your system requirements. How fast
is the pixel data coming in? Is the readout required to run at the
same
rate or possibly even faster (as with image averaging).?

2- How to choos the fruequency, in the datasheet, the max frequency
could be 333MHz, actually the master clock of FPGA is set to 25MHz,
what frequency for the SDRAM should be fine?
Again this depends on your required bandwidth. Obviously you
can't run the memory faster than the chip allows (your part
number should have a speed grage at the end like -5 or -3.
you would need the -3 speed grade to run 333 MHz).
On the other hand why waste extra power and make it
harder to meet timing constraints if you don't really need
to run effectively 1.33 gigabytes per second total memory
bandwidth?

3- Since each pixel has 12bits, the data bus is 16bits, How should the
storage perform, the extra 4 bits will be a waste, is it?
Not if you want to fit 9 frames in memory. You'll need to pack
your data 4 pixels to every three words of memory, and even then
there will not quire be enough unless you reduce the image size
slightly.

4- how are the frames stored? line by line, frame by frame, how to
seperate each line or each frame?
When you have extra memory to waste you can use nice binary
powers to store lines and frames. In your case you don't have that
luxury and will need to keep track of the starting address of each
frame
buffer and the line stride within the frame.

Thanks for your help!

Gladys
 
On 16 juil, 21:10, Gabor <gabor@alacron.com> wrote:
3664 x 2748 x 12 x 9 = 1,087,416,576 bits.  That won't quite fit into
1 gigabit
or 1,073,741,824 bits.
The memory is 1 Gigabyte = 8,589,934,592 bits, it could fit about 70
frames of images.
I want to use SDRAM as circular buffer to store images. there should
be at least 9 frames
to meet system requirement.

Is this the Spartan 6 memory controller?  You need to select the size
and number of ports based on your system requirements.  How fast
is the pixel data coming in?  Is the readout required to run at the
same
rate or possibly even faster (as with image averaging).?

yes, it's Spartan 6, the max pixel data in rate is 80MegaPixel/sec at
80MHz,
the max input bandwidth is 0.9375gigabits/sec. The output of SDRAM is
connected
with a DSP, the read data rate is about 8 time slower than write rate.
(the write rate
could be slower as needed )

Again this depends on your required bandwidth.  Obviously you
can't run the memory faster than the chip allows (your part
number should have a speed grage at the end like -5 or -3.
you would need the -3 speed grade to run 333 MHz).
On the other hand why waste extra power and make it
harder to meet timing constraints if you don't really need
to run effectively 1.33 gigabytes per second total memory
bandwidth?

the Spartan6 has a speed of -3, what I need is on one hand, SDRAM
stores
frames of images at a pixel clock rate, on the other hand, the GPIO
could access
to read out image for DSP at a much slower rate to avoid glitch.


Not if you want to fit 9 frames in memory.  You'll need to pack
your data 4 pixels to every three words of memory, and even then
there will not quire be enough unless you reduce the image size
slightly.

I don't quite understand what does it mean "You'll need to pack
your data 4 pixels to every three words of memory"


When you have extra memory to waste you can use nice binary
powers to store lines and frames.  In your case you don't have that
luxury and will need to keep track of the starting address of each
frame
buffer and the line stride within the frame.

As I have enough memory to store my images, could you please explain
more?

Thanks again for your help!

Gladys
 
On Jul 19, 8:45 am, Gladys <yuhu...@gmail.com> wrote:
On 16 juil, 21:10, Gabor <ga...@alacron.com> wrote:> 3664 x 2748 x 12 x 9 = 1,087,416,576 bits. That won't quite fit into
1 gigabit
or 1,073,741,824 bits.

The memory is 1 Gigabyte = 8,589,934,592 bits, it could fit about 70
frames of images.
I want to use SDRAM as circular buffer to store images. there should
be at least 9 frames
to meet system requirement.
The chip you mentioned, MT47H64M16, is 1 gigabit, not 1 gigabyte. You
need 8 of these chips for 1 gigabyte of memory. I don't think you'll
be able
to drive 8 chips with the Spartan 6 MIG controller. Check carefully
in the
customization screens for MIG to see what you can do.

Is this the Spartan 6 memory controller? You need to select the size
and number of ports based on your system requirements. How fast
is the pixel data coming in? Is the readout required to run at the
same
rate or possibly even faster (as with image averaging).?

yes, it's Spartan 6, the max pixel data in rate is 80MegaPixel/sec at
80MHz,
the max input bandwidth is 0.9375gigabits/sec. The output of SDRAM is
connected
with a DSP, the read data rate is about 8 time slower than write rate.
(the write rate
could be slower as needed )
So sticking to me original idea of a 16-bit wide interface, even if
you
wasted the upper 4 bits you could store and retrieve 600 million
pixels per second at 300 MHz. I would consider running the
interface at a more comfortable 200 MHz which still gives you
a lot of extra bandwidth if all you need is a pixel buffer.

Again this depends on your required bandwidth. Obviously you
can't run the memory faster than the chip allows (your part
number should have a speed grage at the end like -5 or -3.
you would need the -3 speed grade to run 333 MHz).
On the other hand why waste extra power and make it
harder to meet timing constraints if you don't really need
to run effectively 1.33 gigabytes per second total memory
bandwidth?

the Spartan6 has a speed of -3, what I need is on one hand, SDRAM
stores
frames of images at a pixel clock rate, on the other hand, the GPIO
could access
to read out image for DSP at a much slower rate to avoid glitch.
What is the speed grade of the MT47H64M16? That would need to
be -3 for the 300 MHz interface. a -5 part would be good enough
for 200 MHz.

Not if you want to fit 9 frames in memory. You'll need to pack
your data 4 pixels to every three words of memory, and even then
there will not quire be enough unless you reduce the image size
slightly.

I don't quite understand what does it mean "You'll need to pack

your data 4 pixels to every three words of memory"
If your pixels are 12 bits and you want to store them in 16-bit wide
memory, concatenate 4 of them to make 48 bits of pixel data
which fit into three 16-bit words.

When you have extra memory to waste you can use nice binary
powers to store lines and frames. In your case you don't have that
luxury and will need to keep track of the starting address of each
frame
buffer and the line stride within the frame.

As I have enough memory to store my images, could you please explain
more?
I'm still not convinced you do have memory to waste, but the basic
idea is
to start a new image line on say a 4096-word boundary even though the
actual line width is only 3664. This makes line addressing simpler.
Do
something similar by starting a new frame buffer at a 4096-line
boundary
even though the frame is only 2748 lines. This will mean that
addressing
within a frame buffer is a simpler function of pixel and line
position.

Thanks again for your help!

Gladys
 
On 19 juil, 17:08, Gabor <ga...@alacron.com> wrote:
The chip you mentioned, MT47H64M16, is 1 gigabit, not 1 gigabyte.  You
need 8 of these chips for 1 gigabyte of memory.  I don't think you'll
be able
to drive 8 chips with the Spartan 6 MIG controller.  Check carefully
in the
customization screens for MIG to see what you can do.
Yes you are right, it's 1Gigabit and there's only 1 memory chip in my
implementation, I think in this case I will scale down the image
resolution to 3000x2748, then it could fit 9 frames of images.

So sticking to me original idea of a 16-bit wide interface, even if
you
wasted the upper 4 bits you could store and retrieve 600 million
pixels per second at 300 MHz.  I would consider running the
interface at a more comfortable 200 MHz which still gives you
a lot of extra bandwidth if all you need is a pixel buffer.
I am quite confused with the 4, 8, 16 width mamory data bus and the
32, 64, 128 port configuation width, is there any documents which
explain the architecture?
Should I just use two 32bits bidirectional ports and disable the
others in the MIG configuration depends on my system requirement? I
still don't know how to implement the memory controller interface
using MIG.

What is the speed grade of the MT47H64M16?  That would need to
be -3 for the 300 MHz interface.  a -5 part would be good enough
for 200 MHz.
the speed grade of MT47H64M16 is -3. Then should I use 200MHz?

If your pixels are 12 bits and you want to store them in 16-bit wide
memory, concatenate 4 of them to make 48 bits of pixel data
which fit into three 16-bit words.
So is this concatenation performed in the memory controller while
writing the data?

I'm still not convinced you do have memory to waste, but the basic
idea is
to start a new image line on say a 4096-word boundary even though the
actual line width is only 3664.  This makes line addressing simpler.
Do
something similar by starting a new frame buffer at a 4096-line
boundary
even though the frame is only 2748 lines.  This will mean that
addressing
within a frame buffer is a simpler function of pixel and line
position.

If I do this, each frame of image will take 4096*4096*12201,326,592bits, I can olny store 5 image in the SDRAM, which doesn't
meet the requirement,
In this case, can I write images and meanwhile read them out, the
SDRAM will perform as a large FIFO. Also to simplify the logic, I can
leave the 4bits unused as I don't need to store as much images as
before?

Thanks again for your help!
 
On 19 juil, 17:08, Gabor <ga...@alacron.com> wrote:
The chip you mentioned, MT47H64M16, is 1 gigabit, not 1 gigabyte.  You
need 8 of these chips for 1 gigabyte of memory.  I don't think you'll
be able
to drive 8 chips with the Spartan 6 MIG controller.  Check carefully
in the
customization screens for MIG to see what you can do.

Yes you are right, it's 1Gigabit and there's only 1 memory chip in my
implementation, I think in this case I will scale down the image
resolution to 3000x2748, then it could fit 9 frames of images.

So sticking to me original idea of a 16-bit wide interface, even if
you
wasted the upper 4 bits you could store and retrieve 600 million
pixels per second at 300 MHz.  I would consider running the
interface at a more comfortable 200 MHz which still gives you
a lot of extra bandwidth if all you need is a pixel buffer.


What is the speed grade of the MT47H64M16?  That would need to
be -3 for the 300 MHz interface.  a -5 part would be good enough
for 200 MHz.
the speed grade of MT47H64M16 is -3.

If your pixels are 12 bits and you want to store them in 16-bit wide
memory, concatenate 4 of them to make 48 bits of pixel data
which fit into three 16-bit words.

How to implement this? If I choose the 128bit R/W port configuration,
Should I pack 12bits pixel at the host side for the 128bits write data
FIFO?

I'm still not convinced you do have memory to waste, but the basic
idea is
to start a new image line on say a 4096-word boundary even though the
actual line width is only 3664.  This makes line addressing simpler.
Do
something similar by starting a new frame buffer at a 4096-line
boundary
even though the frame is only 2748 lines.  This will mean that
addressing
within a frame buffer is a simpler function of pixel and line
position.

If I do this, each frame of image will take 4096*4096*12201,326,592bits, I can olny store 5 image in the SDRAM, which doesn't
meet the requirement,
In this case, can I store images and meanwhile read them out, the
SDRAM will perform as a large FIFO. Also to simplify the logic, I can
leave the 4bits unused as I don't need to store as much images as
before?
Thanks!
 
On 19 juil, 17:08, Gabor <ga...@alacron.com> wrote:
The chip you mentioned, MT47H64M16, is 1 gigabit, not 1 gigabyte. You
need 8 of these chips for 1 gigabyte of memory. I don't think you'll
be able
to drive 8 chips with the Spartan 6 MIG controller. Check carefully
in the
customization screens for MIG to see what you can do.
Yes you are right, it's 1Gigabit and there's only 1 memory chip in my
implementation. Actually now I just need to store maximum 3 frames of
images in the DDR2, so there will be enough memory space for 3664 x
2748 x 12 x 3 = 362472192.

So sticking to me original idea of a 16-bit wide interface, even if
you
wasted the upper 4 bits you could store and retrieve 600 million
pixels per second at 300 MHz. I would consider running the
interface at a more comfortable 200 MHz which still gives you
a lot of extra bandwidth if all you need is a pixel buffer.
Do the store and retrieve perform at the same frequency? Shall I slow
down the rate of read in the read FIFO of MCB?

What is the speed grade of the MT47H64M16? That would need to
be -3 for the 300 MHz interface. a -5 part would be good enough
for 200 MHz.
the speed grade of MT47H64M16 is -3. I just need to write and read
about 30 million pixel once, so is 200MHz good enough for the design?

If your pixels are 12 bits and you want to store them in 16-bit wide
memory, concatenate 4 of them to make 48 bits of pixel data
which fit into three 16-bit words.
How to implement this? If I choose the 128bit R/W port configuration,
Should I pack 12bits pixel at the host side for the 128bits write data
FIFO?

Also now since I just need to store 3 frames, so I can waste the upper
4 bits, However, I don't understand how does the internal 128bits
signal at host side transfered to 16bits signal at the DDR2 side, is
the 128bits a set of 8 16 bits?

I'm still not convinced you do have memory to waste, but the basic
idea is
to start a new image line on say a 4096-word boundary even though the
actual line width is only 3664. This makes line addressing simpler.
Do
something similar by starting a new frame buffer at a 4096-line
boundary
even though the frame is only 2748 lines. This will mean that
addressing
within a frame buffer is a simpler function of pixel and line
position.
Can I store the 3 images in different bank, for example, frame 1 in
bank 1and 2, frame 2 in bank 3 and 4, and so forth.

Sorry about my stupid questions, thank you again for your anwsers.
 

Welcome to EDABoard.com

Sponsor

Back
Top