TMS320DM6437ZWTQ5 CCD Controller interface question.

Chris,

I think we will need more information on your sensor.

768x506x30 does not require anything like 95MHz, even if the R, G & B components are sent one after the other, so there is a miss-match with the timing information here.

Depending on your sensor it may be possible to 'fake' the input such that the RGB data is simply stored in memory, bypassing any conversion. Some devices also have raw modes which can be used if your sensor can output data in 8 bit or 12 bit modes.

You may also want to look at the following devices

OMAP3 (35xx, 37xx, etc...)

DM3xx (DM365, DM368, etc...)

OMAP L138 family

BR,

Steve

Paul,

If the sensor supports RGB output in 8 bit TDM mode is it possible to configure the CCDC to accept 8 bit raw data and bypass color processing?

BR,

Steve

Yes Steve, very good suggestion.

Steve and Paul,

Thanks a lot for your input.

I realize I haven't given enough information about the image sensor - unfortunatelly I don't have more. For know, I have to work based on assumptions based on some of my customer feedback and what's on the existing design, righ now.

I'm probably misunderstanding something in Steve's comment about the 95 MHz.

For 30 fps X 768 X 506 X 24 bit (color information) = 279 797 760 or roughly 280 MHz, and assuming a 10 bit parallel interface the needed PCLK freq is roughly 28MHz.

If the above is correct we couldn't send the RGB info "one after another" - it needs to be parallel (like it actually is). Am I missing something?

Thank you

"Why do you have to have RGB888 precision?"

That was the generic requirement from my customer, and I was thinking like I know the VPBE can do RGB888, but what's the point in having that if the original information from the imager is not at least the same precision (RGB888), so I would require the whole chain (from the imager to the display) to handle RGB888, or else I would ask the customer to drop the RGB888 precision requirement and have a more "relaxed" spec. Does this sound logical to you?

Thanks, 

"The pixel rate is 768x506x30 = 11.658MHz

If you send RGB in a TDM mode at 8 bits then the data rate would be 11.658 x 3 = 34.975MHz"

Then the PCLK could manage this data flow being as low as 3.4975 MHz, assuming a 10 bit interface (TDM = time division multiplex).

Is that right?

Thanks

Chris,

I don't understand the question?

You are mixing up PIXEL rate and BIT rates I think.

The 34.975 MHz is BYTES per second though an 8 bit interface.

Don't divide the 39MHz by 10 since it is already accommodating an 8 bit interface.

The 'pixel rate' mentioned above is independent of color depth. It is the number of pixels per second, regardless of the color depth. For an RGB888 pixel the data rate is either x3 BYTES per second or x24 BITS per second.

PCLK and data rate mentioned above are the same, there is no divide by 10.

BR,

Steve

Steve Clynes said:

Chris,

I don't understand the question?

You are mixing up PIXEL rate and BIT rates I think.

You are right. I was mixing pixel rate with bit rates.

The 34.975 MHz is BYTES per second though an 8 bit interface.

Don't divide the 39MHz by 10 since it is already accommodating an 8 bit interface. I was dividing (mistakenly) by 10 because the interface between the imager and DSP's CCDC is 10 bit in the current design - the current imager has 10 image data outputs, out of which only 8 seem to be used, according to the Image sensor data sheet, for "RGB565 output timing diagram". The last 2 (least significant) bits seem to be dropped.

The 'pixel rate' mentioned above is independent of color depth. It is the number of pixels per second, regardless of the color depth. For an RGB888 pixel the data rate is either x3 BYTES per second or x24 BITS per second. Then, "PCLK" as defined by the DSP data sheet is actually the so called "data rate" in your comments? Is that correct?

PCLK and data rate mentioned above are the same, there is no divide by 10.

BR,

Steve

Thanks a lot - I appreciate your help.

Chris

Chris,

You are more than welcome. We will try our best to make sure you have all the information you need :)

For the PCLK question, the answer is "it depends".  From the processor perspective the term PCLK is used to mean clock a single unit of data in/out. Now, if you are in a TDM mode where each of R, G & B are sent one after the other then technically the pixel rate is 1/3 the clock rate. At this point you have to carefully study the terminology since the processor has a signal called PCLK, but in this case it is not clocking a complete pixel in every clock, but 1/3 of a pixel.

Hopefully I didn't confuse things more with this!!!

BR,

Steve

OK. I think I get right this time.

I understand it's the actual "data rate" but let me call it PCLK as in the DSP data sheet and it should be at least 34.975MHz (from the image sensor) in order to support 768 X 506 X 30 fps X RGB888 on a 8 bit interface towards CCDController.

Please confirm the above statement is correct.

I'm a HW guy and need to know the value of this frequency (or baud rate).

Thanks a lot, 

Thanks a lot Steve.

I think this thread should be closed now.

Should I do anything else besides click on "verify answer"?

Chris

Chris,

As long as you are happy with the information and you have what you need then yes, please just verify the answer.

If you have any other questions please do not hesitate to ask.

BR,

Steve