16Bit YCbCr video port

[Altera_Forum]

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

[Altera_Forum]

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

 Mark.

[Altera_Forum]

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]

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]

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]

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.