Forum Discussion

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

16Bit YCbCr video port

Dear Altera-Team,

we want to convert 16Bit wide YCbCr data comming from our camera to fit to our 8Bit wide camera interface. The idea is to use a CPLD to buffer the 16Bit data and send it out in two 8Bit wide packages.

What CPLD can you recommend?

Our data rate is 16Bit x 74.5 MHz -> 8Bit x 149MHz plus HSync and VSync signals.

Regards,

Sebastian

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Even the lowest end Max V CPLD should be able to handle this easily.

    Mark.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Mark,

    I ordered a MaxV development kit and we are working on the necessary adapters.... I am still concerned about the timing requirements.

    The 16Bit input data will have a frequency of 74.25MHz, and the output will have even 148.5MHz. At this rate (74.25MHz) I have to buffer a 16Bit pixel in a variable inside the CPLD and read it 8Bit wise at the double rate (148.5MHz) and send it to output pins. With this method the reading the variable and sending it to the output pins process has to be as fast as 300MHz. Otherwise the process will be out of pixel clock sync.

    Can the MAX V be that fast?

    Regards,

    Sebastian
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    1) Hm, as far as I understood, you only need to feed the buffer with ~150MHz. Where you you need the 300 now?

    2) You can create a simple design with an synchronus FiFo 16/8 asymmetrical widths and try to fit it into a MAX2 with the free web edition to try if it works or not.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi,

    I just did a really naive implementation in Quartus and it met timing requirements with no effort. I don't see your requirement for 300 MHz operation. What you do need to watch out for is delays between your 74.25 MHz clock and your 148.5 MHz clock. Presumably one is generated from the other so they are always an exact multiple of 2, but delays through a PLL or PCB tracking could change their relative phase enough to break things. You can specify the delays in TimeQuest to make sure it really does meet the timing requirements of your real board.

    Mark.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Just found back to this thread since I dealed with a similar task recently. Indeed the 74.25 is the half frequency derived from the video clock (HDMI 148.5). Just for a test I realized a MAX-Design with a small converter and can confirm it operates well. The challanges with these video tasks are DSP usage in case of colour space conversion anyway which will required FPGA-power most probably then.