DS90UB949-Q1: Diagnostics and data integrity check

Hello Logan,

Thank you for the details!

Regarding the question 2 and 3, I wanted to understand more on the below points. Please correct me if my understanding is wrong:

1. The video data is sent from serializer to deserializer through FPD link

2. The feedback, GPIO, I2C, lock status, etc is sent from deserializer to serializer through back channel

3. The deserializer has a provision to check the CRC of the video data sent from serializer

4. The deserializer also provides the lock status

5. The serializer receives the feedback of lock status and CRC errors detected by deserializer ( as given in point 3 )

6. The serializer also checks the CRC of the back channel data received ( as given in point 2 and 5 )

7. Hence the serializer is able to find the CRC error in the forward channel video data, from the feedback of deserializer, and also itself calculates and detects the CRC errors in the back channel data

Hi Aishwarya, 

There is no CRC feature in forward channel link between 949 and 948, only check-sum error count. Back-channel does have CRC checking.

Regards, 

Logan

Logan Cummins said:

There is no CRC feature in forward channel link between 949 and 948, only check-sum error count. Back-channel does have CRC checking.

Regards,

Hello Logan,

Thank you for the clarification! 

Below is a snapshot of the datasheet of Serializer. where the 1st bit of the General Status register is indicating the CRC error in normal communication with deserializer. So can you please confirm if this CRC error bit is for back channel data or not?

Also, can you please suggest how we can retrieve the check-sum error count for forward channel data? 

Also is checking the LOCK status from deserializer sufficient enough to say that the forward channel data is completely received by deserializer, along with clock input ?

Along with LOCK status, do the deserializer have any other mechanism to check and ensure the data integrity of the video data received in Normal Operation Mode ( not in BIST mode ) ? Please do suggest.

Thank you,

Hi Aishwarya, 

Aishwarya Tadaki said:

can you please confirm if this CRC error bit is for back channel data or not?

Yes, this is for back-channel errors. 

Aishwarya Tadaki said:

Also, can you please suggest how we can retrieve the check-sum error count for forward channel data? 

Actually, I didn't realize you were using UB version of device. Check-sum is only available for UH versions; so it will not be available for UB.

Aishwarya Tadaki said:

Also is checking the LOCK status from deserializer sufficient enough to say that the forward channel data is completely received by deserializer, along with clock input ?

LOCK means that deserializer is able to successfully able to lock on to incoming signal (clock recovery, etc).

Aishwarya Tadaki said:

Along with LOCK status, do the deserializer have any other mechanism to check and ensure the data integrity of the video data received in Normal Operation Mode ( not in BIST mode ) ?

Other than the previously mentioned check-sum, no it does not. 

Regards, 

Logan

Hello Logan,

Thank you very much for the details and confirmation Logan!
I would like to further request you to provide me some hints or suggestions on below point:

1. We have a functionality to display data on screen, which is rated ASIL B and the display data is communicated through the previously mentioned Serializer- Deserializer pair. Hence, we are required to ensure the data integrity of the display data that is communicated through this pair. As there is no checksum feature present and only LOCK status can be obtained from deserializer, is there any other way/mechanism which can be followed to ensure the correctness of data transferred from serializer to deserialzer? The below mentioned components are currently used in design:

Serializer :      ds90ub949-q1

Deserializer :  ds90ub948-q1

Thank you,

Hi Aishwarya, 

When using UB devices, there are no other checksum/CRC features to verify forward channel video stream data integrity during operation. 

Regards, 

Logan