• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 871 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-Q1: Are the Frame & Line Start & End synchronization Short Packets mandatory to be sent by the attached sensor?

Olivier Alavoine1
Prodigy 50 points
Part Number: DS90UB953A-Q1

Hi,

We plan to use the DS90UB953A serializer  (and its counter deserializer) for transporting an 'almost MIPI-CSI2' stream of data.

Is the DS90UB953 expect to receive the start frame short packet (data type 0x00) plus the end frame short packet (data type 0x01), AND the line start short packet (data type 0x02) plus line end short packet (data type 0x03)?

CSI-2 spec says the line start/end short messages are optional. So can we expect the DS90UB953 to correctly work if we attach to it a sensor that doesn't send these line start/end short packets?

Also for a packet header, how the 953 is performing the ECC error detection? Is it considering only the 24 first bits on the packet header, or is it also using the 2 MSbits of the last byte of the header (which contains now the 2 Virtual Channel Extension bits (so bit 24 and 25 of the header, supposed to be used for the transmitter to compute the ECC code, which occupies bits[5:0] of the last byte of the header)?

Regards,

Oliver

  • 0
    TI__Intellectual 2930 points

    Hello Oliver

    1. Can u please expand on 'almost MIPI-CSI2 stream definition?

    2. We follow the CSI spec. So we do expect to see start frame and stop frame short packets but line start and line end are optional

    3. Can you please clarify your question on ECC? ECC is generated on the Imager side. ECC is calculated for 16 bit word count as well as the 8 bit VC ID

    Thanks

    Vijay

  • 0 in reply to Vijaya Ceekala
    Prodigy 50 points

    The frame stream we can send includes Frame Start (short packet) , then 2 Generic short packets Code 1 (data type = 0x08), then the RGB-8-8-8 Long packet for payload, and this for every line of the frame (so 2x short packets (Data type = 0x08) then one long packet RGB 8-8-8 (data type 0x24), with Low-Power state btw each packet), and finishes with a Frame End (short) packet. 
    Is there any potential issue for DS90UB953 to see these 2 Generic Short Packet Code 1 packets before each RGB line long packet?

    In CSI-2 MIPI spec, CSI-2 Tx can use Virtual channel extension (VCX), which consists of 2 bits (bits [7:6]) transmitted with the ECC bits (6 bits) inside the last header byte of the packet. We don't use this new VCX, hence these 2 VCX bits will be transmitted as zero. MIPI CSI-2 spec says: "Receivers conforming to this CSI-2 v2.1 Specification version that receive Packet Headers from transmitters without the VCX field should forcibly set received bits 24 and 25 to zero in such Packet Headers prior to any parity generation or syndrome decoding (this is the function of the “VCX Override” block shown in Figure 65). This guarantees that the receiver will properly ignore any errors occurring at bit positions 24 1097 and 25, in order to match the behavior of receivers conforming to previous versions of this Specification."

    So is there a configuration mode in DS90UB953 that disregards (force to zero) the VCX bits (bits [7:6]) prior to perform syndrome computation, or it assumes that ECC bits transmitted have been computed on 24 + 2 (VCX bits) bits of the header? I assume that as we transmit zeroes for these 2 VCX bits, but compute the 6-bit ECC value using only the 3 first bytes of the header, this is equivalent to computing ECC on 26 bits with the 2 upper bits (corresponding to VCX) equal to zero. Can you confirm?

    Thanks and Best Regards,

    Olivier

  • 0 in reply to Olivier Alavoine1
    TI__Intellectual 2930 points

    Olivier

       Please note that 953 receiver is compliant to MIPI CSIv1.3 specification (Not 2.1) so a lot of optional features that are part of v2.1 cannot be met by 953.

    It assumes that ECC bits transmitted have been computed on 24+2 bits of the header and so no way to disregard the VCX bits

    Thanks

    Vijay

  • 0 in reply to Vijaya Ceekala
    Prodigy 50 points

    Thanks, so no ECC issue expected in 953 as long as our device drives to zero the VCX bits (bits 6 and 7 of the ECC Byte)!

    What's about the two "Generic Short Packet Code 1 (Data Type 0x08)" sent before each payload pixel Long Packet (before each line of pixel): any issue for the 953? Shall I expected these packets to be recognized correctly by 953, and transported so that deserializer (954) will receive them and present them on its CSI-2 port. 

    Can you confirm that the fact that these 2 short packets are 'interleaved' with pixel data within a frame, is not causing any issue for 953?

    Thanks,

    Olivier

  • 0 in reply to Olivier Alavoine1
    TI__Intellectual 2930 points

    Hello

       As long as the data sequence follows MIPI CSIv1.3 specification, it should not cause any problem for 953

    Thanks

    Vijay