• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 472 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DS90UB964-Q1: Could it replace DS90UB960 without modifying software and hardware configuration

DS90UB964-Q1: Double check the pclk bandwidth and data format pairing with 935

Zirui Su
Expert 5340 points
Part Number: DS90UB964-Q1

Hi team

I had asked a question about the 935-964 solution with customer specific resolution:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1038357/ds90ub964-q1-could-it-replace-ds90ub960-without-modifying-software-and-hardware-configuration?tisearch=e2e-sitesearch&keymatch=DS90UB964#

You could also check the system block diagram below:

About the figure above, the car OEM has raised alternative solution for the camera 2 that is: change from 1280*720@30fps to 1920*1080@30fps and with YUV422 8bit for 935 paring with 964.

I would like to double confirm the questions from your side:

1. In my opinion, DS90UB935 could pair with DS90UB964 and it is confirmed by your expert side, should we configure 935 to be under certain mode like DVP mode to support this link combination?

2. Could 1920*1080@30fps YUV 422 8bit data format be supported by the DS90UB935 to DS90UB964? Does 964 or 935 have the PCLK limitation, if so what is the value? 100Mhz?

3. Will it be some potential risks when we pairing 964 with 935 rather than pairing with 913/933 since customer is under 960 and 962 shortage;

4. I have seen an AN that described 953 pairing with 934 or 914A that 953 could NOT support YUV 422 8bit, so we are afraid that 935 pairing with 964 also could NOT support YUV 422 8bit?

snla270a.pdf

5. If YUV 422 8bit could not be supported by 935-964, what is the reason for this and what data type could support by this 935-964 combination?

Please kindly help to carefully confirm our questions since it will affect customer project design because they used to use 960 but due to the shortage they only have the 964 device to use, so it is quite important for both of them and us, thank you.

  • 0
    TI__Expert 5340 points

    Hi team,

    Any feedback? Since it is a little bit urgent and customer need your confirmation about whether we could use this configuration for long term RTM, thank you.

  • 0 in reply to Zirui Su
    TI__Mastermind 18755 points

    Hi Zirui,

    My answers to your questions are below:

    1. It can however it would require software changes and even then it is technically it is still only designed to work with 913/933.

    2. This resolution should be fine with 935/964.  Since they are both CSI serializer and CSI deserializer PCLK doesn't really make sense in this context.

    3. I would say that there are risks because the 964 is technically not meant to pair with 935.  I would say for testing purposes this should be okay but in production we should use the correct part.

    4. This is actually something I hadn't thought about should not be a problem.  The note in the datasheet is a bit confusing however the problem is related to how data is packed.  since the YUV 8-bit, 10-bit, and 12-bit formats are technically 16-bits, 20-bits, and 24-bits per pixel respectively the 10-bit and 12-bit formats will pack nicely into RAW 10 and RAW 12 packets.  The YUV 8-bit mode (16bpp) does not pack into a RAW 10 packet or RAW 12 packet very will.  It is still possible to work however the SoC would need to be to ignore the unused bits.

    5. Explained in answer 4. 

    Regards,

    Nick

  • 0 in reply to Nicholas Darash
    TI__Expert 5340 points

    Hi Nick,

    Thanks for your detailed explanation. So your final conclusion is that we must use the correct part to pair with 964 rather than 935 paired with 964 because it is not designed for this pair. 

    Nicholas Darash said:
    I would say that there are risks because the 964 is technically not meant to pair with 935. 

    Could you please provide some detailed risks for us and are these related to the data packaging or some other risks?

    Nicholas Darash said:
    since the YUV 8-bit, 10-bit, and 12-bit formats are technically 16-bits, 20-bits, and 24-bits per pixel respectively the 10-bit and 12-bit formats will pack nicely into RAW 10 and RAW 12 packets.  The YUV 8-bit mode (16bpp) does not pack into a RAW 10 packet or RAW 12 packet very will.  It is still possible to work however the SoC would need to be to ignore the unused bits.

    Double confirm that 964 could only support DVP mode right? Who will pack the YUV422 8bit to RAW10 or RAW12? 935 or 964?

    Please kindly help us to provide more explanations about this pair's potential risk and hope your response before Christmas holiday so that we could convince customer of using other DES like 960 or 962 rather than 964, thank you!

  • 0 in reply to Zirui Su
    TI__Guru** 103215 points

    Zirui,

    964 only supports DVP mode. This is confirmed for sure. 

    As Nick mentioned, YV 8 bit formats are not natively supported in this combination of 935/964 since they don't fit the same pixel packing structure of RAW10 or RAW12. When the 935 is used in DVP mode, it basically looks like a RAW10 or RAW12 transmitter to the 964. Those pixel formats use 2 pixels per 3 bytes or 4 pixels in 5 bytes, but YUV422 8 bit uses 1 pixel per 2 bytes. So it does not divide evenly into the pixel packing structure. 

    Please recommend that the customer use 960 or 962 for this kind of pairing and data format 

    Best Regards,

    Casey