DDR3 configuration

[vishnu]

Hello Everyone,

This is Vishnu , FPGA Design Engineer. I need help from you, in my project I need to get data into DDR from camera and has to given for another data processing module. Here I have some doubts regarding storage .

1)  As camera is line scanning camera , Is it possible to store line information from camera (line-by-line)  and to access it full line-by-line  directly.(data is of 12 bit).

2) How many cycles will be delayed  if configuration is done with  Microblaze .

3) Help  me out some links for the configuration to do in customized version.

                     Thanks in advance.

Regards

Vishnu

[D@n]

Hello @vishnu, welcome to the forums!

Let's see if I can answer your question(s).  I myself have an Arty board, which has DDR3 SDRAM on it.  If I reference any hardware, it will be my experiences with that board.

Is it possible to store information line by line ... I don't see why not, as long as your lines end on a byte boundary.  You can pack the data so that two pixels take 3-bytes, or you can pack them so that one pixel takes two bytes, but it seems quite possible to do.  If what you meant to ask is whether or not someone had accomplished your problem already so that you could use/copy their code, though, then my answer is: I don't know. 

But I think what you'd like to know is the performance of the memory.  At one time, I tried to build a DDR3 SDRAM memory controller.  I got a long ways into the project, but still need to come back to it and finish it.  Using that project, I worked out exactly how many clocks were necessary to access memory--both initially and if that access were sequential to the last one.  I tuned the memory controller so that you could read from the memory at a speed of 128-bits per 81.25MHz clock after a couple clocks to set up the memory.  Writes were similar.  If you look at the link above, you can see some of my notes as I measured this.  As I recall, as long as you didn't try to read/write the memory during a refresh cycle, the whole operation might take about 10-clocks.  (It's been a while since I've done it, so I might be a clock or two slow here.)  So, reading/writing from memory could then take 10+N clocks, where N was the number of 128-bit words you wished to read or write.

The problem with that controller, though, are the DQS lines--data needs to be sampled at the rising/falling edge of DQS, and to do that you need hardware support.  Likewise when writing, data needs to be on the bus ready to be read/written at the rising/falling edge of DQS (the lines are bi-directional)  Xilinx offers that hardware support as part of what the Memory Interface Generator creates.  Their controller for the Arty, however, costs 23+N clocks--and I can't speak for whether or not they can read/write sequentially for long periods separated only by the need to refresh the memory.

Stepping back one step further, I wanted to then attach this memory to my CPU bus.  The wishbone bus implementation I am using is 32-bits wide, so it can only transfer 32-bits per clock.  On top of this, the wishbone wrapper I placed on top of Xilinx's memory interface core added four clocks.  So now things cost 27+N clocks, where N is now the number of 32-bit words you wish to read/write, and no longer the number of 128-bit words.

At this point, I'm sure you could connect your CPU to the bus, at least that's what I did.  I'm not using a MicroBlaze CPU but rather a ZipCPU.  If you look at section 4.6 of the ZipCPU specification, you'll find a discussion about how long it takes to do a memory copy.  It shouldn't come as too much of a surprise that it depends on how you code up your memory copy.  So, I offer a version that takes 2+12N clocks, another that takes 32+17N/4 clocks, and a DMA approach that takes roughly 2N clocks.  The numbers published in the specification, though, are specific to a block RAM memory.  If you are dealing with SDRAM, you have to add back in those 27 clocks we discussed earlier.  So you are back to 2+39N clocks, 32+47N/4 clocks, and 2*(27+1024)N/1024 clocks (N is the number of 32-bit values)

Hopefully this helps to answer your question, since you wanted details.

If not, here are my takeaways:

1. It depends upon your implementation
2. The fastest means of writing to your SDRAM will be a hardware/RTL means, not a CPU means.  (Look at the DMA numbers above, for example.)
3. If you choose to build a hardware controller, reading from the clock and writing to the RAM, you might manage to get close to those 23+N speeds above, where N is the number of 128-bit values you wish to write.  You may have to pack your 12-bit pixels into 128-bit words yourself to get to this speed, but it should be nearly possible.
4. It will also depend upon who else is trying to access the RAM at the same time--if you are running a graphics display at the same time, you may not be able to read/write for long unbroken periods.
5. And ... I haven't discussed memory refresh cycles, which can suddenly take the RAM offline for long periods and break any burst read/write you might be in the middle of.

Hope that helps,

Dan

[vishnu]

Hello @D@n

       Thanks for your explanation , now I got little idea where has to take care of storing data issues and got some help to give explanation how the data will  propogate and to make a decision for data flow . (have to get idea how data during refresh cycles to handle).

 

Regards

Vishnu

[ajay soman]

I have some queries. When I transfer file bitween two system using ethernet the system gets stalled and phy gets filled and not changing the status bit of fpga 

[D@n]

@ajay soman,

You might want to start your query in a new thread, since I'm not sure how well it applies to this one.  When you do ... please add some more details so I can tell what it is you are trying to solve.  For example, what hardware are you using?  How is your hardware set up?  What are you trying to accomplish, and how do you know it isn't working?

Thanks,

Dan