DS90UB953A-Q1: Ser-Des Pass-though? CSI-2 -> 953 -> 954 -> CSI-2 is a Tunnel?

Hello Alon,

Yes, you can consider 953 like a passthrough for CSI-2 data. It should be unmodified. 

Best Regards,

Casey 

Hi Casey, thank you for reply.

I understand that the csi-2 data is passthrough, but what about the original 16crc header? Is it removed on 953 and generated again on 954 side?

Hello Alon,

No it should just be passed through as well. 

Best Regards,

Casey 

OK Thanks.

I will explain our approach for the image path integrity : please correct me if I am wrong.

The Image sensor transmits a CSI-2 frame which contains a Header(ID,WC, ECC), Data (pixels), and Footer (16 CRC).

1. The Serializer (953) extract the data, computes the CRC and ECC to check for corruption MIPI link. Assuming a default configuration. in case the serializer finds ECC or CRC error, CSI_ERR_STATUS (Address 0x5D)  will be flagged. (953 datasheet, Table 94), ALARM_CSI_EN (Address 0x1C)  default is to set an alarm to the corresponding ECC\CRC error, what is this alarm? 

2. If case the is CSI-2 checksum error alarm, the CSI-2 frame will be forwarded to Deserializer?

3. How the 954 Deserializer will react? again, assuming default configuration (PORT_CONFIG (Address 0x6D), "Forward packets with error". the 954 will forward the errored packets with its original CRC?

Assuming that the CSI-2 frame hs passed through transparently, so we don't have to implement any register reading to ensure the Original frame received as generated by Image sensor?

We are checking for CRC and ECC only at received CSI from to HOST, we are not checking for 953-954 registers - so we assume that the original CSI header produced by the Image sensor will be passed through to the host, so it is sufficient to do the CRC and ECC comparison in the host side - that will cover the integrity of the link.

Please confirm that this approach will ensure Imager-Ser-Des-Host link.

Hello Alon,

I believe your understanding here is correct. The 953 will check the CSI-2 packet for ECC/CRC first and flag any errors/alarms like you mentioned. Errored frames at the 953 should be forwarded to the 954 but I do expect this behavior to be very unpredictable because SoT/EoT errors or other protocol errors besides just data bit errors may trigger a while packet not to get recognized. 

Finally on the 954 side, CSI-2 errored packets are forwarded by default as they were received. This can be disabled with registers to disable forwarding errored packers. I think to be safe, CSI-2 errors should be monitored from the 953/954 as well. 

Best Regards,

Casey 

Hi Casey. 

1. "Errored frames at the 953 should be forwarded to the 954 but I do expect this behavior to be very unpredictable because SoT/EoT errors or other protocol errors besides just data bit errors may trigger a while packet not to get recognized. "  

Can you please explain a bit more? not sure I understand.

2. " I think to be safe, CSI-2 errors should be monitored from the 953/954 as well."

 I think that every bitflip \ failure on the link will be recognized be the CRC checksum at Host? in case the CRC is not regenerated.

Why it is safer to check for CSI-2 errors on Ser\Des if we perform the checksum for the received packet to Host? it is end-to-end verification.

3. by 953 datasheet :

3.1 "Each frame contains video payload data"  That means that the FPD link contains the Video payload data only from the CSI2 frame?? this is why I asked about the original Header and Footer from the CSI-2... 

3.2 "CRC information" Is that the Forward channel CRC for the FPD from? what type of CRC?

Thanks again,