• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 493 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.

DS90UB971-Q1: Serializer to deserialize SM communication

Sandeep Pinninti
Prodigy 190 points
Part Number: DS90UB971-Q1

Hello Team 

I have one question regarding DS90UB971-Q1 (ASILB) component 

we are using this to convert imager data to convert high speed FPD Link IV in camera module 

As per our customer discussion they are not interested in reading the safety critical registers in terms they don't want any safety mechanism to be implemented serializer

instead they will be using imager safety mechanisms with embedded data  

But as per my qualitative FMEDA i see i should have at least (I2C related safety mechanisms back channel) :   SM11, SM13, SM15) to have error free communication between the camera components (Like PMIC, Imager, EEPROM) in the camera module

My question is 

For forward channel data transfer is there any risk if i am not implementing any safety mechanisms in DS90UB971 

If so could you please suggest what are the SMs i have to implement in order have error free data transfer from serializer to deserialize

 Few other details: 

Deserialize: DS90UB9702 (QM)

Overall project ASIL level : ASILB

Support on this was highly appreciated  

Thank you 
Sandeeep P

  • 0
    TI__Guru** 103215 points

    Hello Sandeep,

    Thank you for your question - hopefully we can provide you with some guidance here. 

    The safety documentation for 971/9702 was developed using the ISO26262 safety element out of context (SEooC) methodology since these devices are designed to be utilized in a wide variety of applications where system context and safety goals may be different from eachother. With the SEooC method, TI develops assumptions of use for the devices outlining an example use case as well as example safety goals for the system, and what types of failures effect or don't effect those safety goals. You can find those assumptions of use inside the safety manual documentation. 

    Next, the device FMEDA is tailored based on those assumptions by enabling safety mechanisms to provide transient/latent coverage on faults which affect those safety goals until the SPFM/LFM/PMHF metrics fall within the desired ASIL-B level. If your system safety goals differ from those described in the assumptions of use, then you could change the FMEDA tailoring accordingly. If you end up disabling certain safety mechanisms such as status register readbacks that are enabled in the FMEDA, then you can check after that if the totals still meet ASIL-B. 

    For example, in your system you may consider that I2C-related functions are not relevant to your system safety concept and that a failure in I2C communications does not violate your safety goals. In that case you could mark that failure as "not safety related" in the FMEDA which means that any failures in that functional block will not contribute towards the SPFM/LFM/PMHF. 

    Best Regards,

    Casey