Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

VIP FrameBuffer - How do you think it is accessing the SDRAM?

Hi!

I am thinking about FrameBuffer Core Altera provides. In the VIP User Guide it is explained clearly, how the FB is working, with the concepts of dual and triple buffering.

What I don't understand is, how Altera could get the FB working with only one SDRAM. So my problem is, I want to implement a system, where I write Video-Data into SDRAM and read it with the FrameReader to output it with a CVO. My system should be:

... -> Writer -> AccessArbiter(SDRAM) -> FrameReader -> CVO

I don't get it to work this way, because the Altera SDRAM-Controller Core is running only with 100Mhz max. My system runs at 100Mhz, too. So I need two SDRAM to manage read and write and switch them by a selfwritten AccessArbiter every Frame, like a dual buffer. My actual system looks like this:

... -> Writer -> AccessArbiter(SDRAM0, SDRAM1) -> FrameReader -> CVO

How do they get it to work with only one SDRAM? Anyone has an idea?! I have thought about this some time now and don't find a solution. Everything I tried with FIFOs got me overflows, because the SDRAM adds to much cycles while writing and reading.

Any advise would be appreciated.

Thanks, Peter.

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The way it can work with one SDRAM is if you make sure your SDRAM bandwidth is over twice your video data rate. If you hit a limit on the clock rate of your SDRAM, you can also try increasing the width.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi Kevin, I thought about your suggestion and I am now unsure if this is possible without changing the hardware. The system I am working with is predefined, so I could not change the bandwith as you suggest I think, but perhaps I am missunderstanding the concept of the sdram. I made a sketch, how I understand it, based on http://www.altera.com/literature/ug/ug_embedded_ip.pdf chapter 1-9.

    In the attachement, you see the FB attached to the SDRAM Controller, by two Avalon-MM Interfaces. In my opinion this is a place where I could raise the datawidth in this constellation, but I don't expect any positive changes in this alternation without making canges at the controller. The SDRAM controller accesses now with a datawidth of 32bit, 2 chipselect and 4 banks. 13 rows and 9 colum addresswidth.

    Do you mean to increase the datawith to 64bit and then use 2 chipselects while using 2 banks? Could that work? Am I correct, that I then would need two SDRAM Memory Chip that are both 32bit data width devices?

    So when I want to still work with the 4 banks I would have to use 64bit datawidth for the controller, 1 chipselect and 4 banks. The controller would then access 64bit at once everytime. Then I will have to change my whole system to process 64bit words, that inherit two 32bit words of my videodata everytime, so I would have doubled the overall bandwidth.

    Yours, Peter.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    Do you mean to increase the datawith to 64bit and then use 2 chipselects while using 2 banks? Could that work?

    --- Quote End ---

    Yes, that is basically what I am suggesting. By increasing the data width from 32 bit to 64 bit, you are doubling the available bandwidth. Make sure to also increase the avalon master port width in the frame buffer setup to be at least as wide as your local memory interface width. Due to the way the frame buffer packs pixels into words, it can sometimes help to make the width even higher so that there is less wasted bandwidth. This is described in the VIP manual.

    --- Quote Start ---

    Am I correct, that I then would need two SDRAM Memory Chip that are both 32bit data width devices?

    --- Quote End ---

    I have never worked with more than one SDRAM chip in detail myself, but I believe it is possible to parallel two 16 bit SDRAMs to get a 32 bit bus. Either way, this would be a change to your hardware, so if your system is completely fixed, you may be stuck.

    Perhaps you should give a few more details on your exact requirements. What resolutions and frame rates are you trying to achieve? How many bits per pixel? What color space (RGB, YCC, ...)? Maybe you don't need as much bandwidth as you think.

    Now that I just re-read your original email, I see you have referred to both a frame buffer and a frame reader. I originally thought you were only talking about a frame buffer. With the frame reader, the required bandwidth will vary significantly depending on how fast you want to update the video frame contents. For a static image or a very infrequent or small change, you can get away with a lot less bandwidth.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi Kevin, I can't tell to much about the system, because it will be my bachelor thesis and that could bring some trouble up. The problem I was fighting is to write 32bit to the sdram and read 32bit with both 65Mhz, while the sdram only runs with 100Mhz. So your suggestion brought me to a whole new idea, I had not found on my own. While increasing the datawidth it could be possible that I can process the data without problems. I calculated and programmed already a bit and the idea is great, but I did not have a working solution, yet. But I am very thankful, that you gave me this impulse. Thanks.

    Yours, Peter.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi Kevin, I just wanted to tell you, your comment above was right, that I need to change the hardware to change the datawidth. I finished my code today and in the simulation it works nicely, but as I wanted to synthesize the design it got clear, that the datawidth of the outputpins will never match the new design, so I got totally stuck now. Haven't realised that before I got to this point.

    Now I am really disappointed, I really thought it could be possible to work it out somehow with this 64bit datawith, but that was nothing.

    Yours, Peet.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Can you increase the clock rate of your memory?

    Can you use DDR memory (if you aren't already)?

    Perhaps you could use fewer bits per pixel and still get reasonable results?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi. As I mentioned the hardware is predefined, but I also thought about decreasing the bits per pixel. At the moment I am processing 24Bit per pixel. So I will give that a try, it is the last possible solution I can think of.

    Will program that now, let's see how it looks then afterwards.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Is the 65 MHz you mentioned before taking into account the horizontal blanking? For example, if your pixel clock is 65 MHz, the average rate per line would be less if there is a horizontal blanking interval.

    Also, have you tried to optimize the way pixels are packed into words by the frame buffer? For example, if you set the word size to 32 bit, you are wasting 25% of your bandwidth storing 24 bit pixels into 32 bit words. If you increased the word size to 128 bit, you could store 5 pixels in one word which would only waste 6.25%.

    Even taking into account the above, you may still not have enough bandwidth. But I thought I would mention it just in case.

    If you need to, reducing the bit depth may have less impact than you might think. 16 bit RGB tends to look noticeably bad depending on the image, but 16 bit 422 YCrCb looks fairly good.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi Kevin, your comments are very helpfull and I got it now working, also I still don't understand how it is possible to compute the pixeldata in time for the altera framebuffer.

    I have attached a sketch how the FB is right now attached to my system. In the settings of the FB I set 128bit for the Port width and 256 as burst target. I still don't understand, what the sopc build from this information. In my opinion it should not be possible to buffer the incoming data to write and read it in the SDRAM with the same rate.

    The SDRAM Controller is set to the same values as in my version of the system with my self build FrameBuffer. So Altera must have another trick to buffer the data, that I don't found, yet. You know what I mean? I am almost doing the same thing, except the processing with 128bit word with, so I am still loosing this datarate. The problem I am getting before the datawidth problem is to access the SDRAM Controller with read and write at the same time. Perhaps they optimize the read/write some way, blockwise processing or something like that? I would love to get my FB running the same way the Altera FB does, but everything I get are fifo overflows out of it.

    Thanks again for your great help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Are you using burst transfers with your custom frame buffer?

    You can't actually read and write to SDRAM at the same time. You are either doing one or the other at any given time. Switching between read and write mode is slow. Therefore you want to perform your reads and writes in bursts to keep the efficiency higher.

    Are you sure your FB does not have some other bug causing problems not related to memory bandwidth? Perhaps you could test the system with a much slower pixel clock to try and prove the rest of the logic is correct.