This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB953A-Q1EVM: MIPI clk and the 832 mbps data

Part Number: DS90UB953A-Q1EVM
Other Parts Discussed in Thread: DS90UB953-Q1

If my MIPI clock is at 450 MHz am I okay to operate with the 832 Mbps per lane limit on the 953?

Does my 450 MHz clock mipi correspond to 900 Mbps of data total and thus 400 Mbps per channel (we are two channel)?

  • Hello Andrew,

    The maximum supported MIPI clock rate is 416MHz for this device no matter how many lanes are used. So this is not a supported configuration with 450MHz (900Mbps)

    Best Regards,

    Casey 

  • Interestingly I have observed the IMX219 camera operating at 455MHz (with and e-field probe) and WITH the FPD link working in the signal chain!

    Can you tell me how this speed limit may manifest? Would you expect it: 

    - not work at all

    - some degradation of the content (frames etc)

    - might it work but it is not guaranteed over the population of FPD parts

  • Andrew,

    The DS90UB953-Q1 has a very small CSI-2 data buffer inside (<< than one video line), so the CSI-2 input speed must be <= to the FPD-Link CSI-2 frame speed at all times. Otherwise you are likely to get a buffer overflow on the CSI-2 path meaning that you will get truncated or missing video lines output on the deserializer side.

    Best Regards,

    Casey 

  • Thanks,  455 MHz is our clock rate, but changing the resolution and frame rate has no impact on the clock frequency. Is this typical for CSI2?

    Also we did a theorhetical calculation of data rate and found that we could likely get quite close the camera's peak capacity and stay within the 832 Mbps. How does it handle this excess of clock cycles not needed for pixels? Is it just a larger back porch or does it scale all data and thus make it more tolerant to this small buffer?

    Do you think a longer cable would have any impact, we have only tested at 5m, looking for a 15m Fakra F-F?

    Best.

  • Andrew,

    CSI-2 does not require discrete DPI timing for horizontal pixel data which is why it is common for CSI-2 transmitters to run at fixed rates which are asynchronous to the actual throughput. Basically you will just get idle (LP11) time on the DPHY bus between line packets. I discuss this concept a bit in this video: https://www.ti.com/video/6247583604001?keyMatch=AGGREGATION 

    Most camera sensors have configurable CSI-2 TX rate - you would need to consult with the image sensor vendor on that configuration. 

    Again, the SER is not designed to tolerate an input CSI-2 rate beyond 832Mbps/lane. So that is not a recommended configuration. It does not have any dependency on the cable length 

    Best Regards,

    Casey 

  • I understand that our clock of ~450 MHz means we will be sending data at a peak rate of 900 Mbps per channel (and we have two channels), although our averaged data rate may be <832 Mbps.

    Would the likelihood of video corruption increase with increased camera resolution or frame rate, as it would increase the amount of frame content and reduce the duration of LP11?

    Note: I have not yet observed any video corruption!

  • Andrew,

    I see what you are saying here - this is 900Mbps/lane with 2 lanes? In that case you are not going to have issues with CSI-2 buffer overflow in the 953 since the data pipe can handle up to 3.328Gbps total (distributed over 4 lanes). That explains why you are not seeing immediate data corruption. 

    However the DPHY receiver in the 953 is not qualified to run at this high of a speed which means there is risk of mis-sampling the data due to insufficient timing margin in the 953 RX. It is not possible to quantify a likelihood of failure since this condition is outside of what the device is designed/tested for, but this is definitely not a supported use case and TI recommends not to apply lane rates outside of the datasheet allowable range because we can't guarantee that the DPHY will be able to properly sample the data at these speeds across all units process, temp, and voltage variation. 

    Best Regards,

    Casey