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.

DS90UB962-Q1: I2C speed calculation

Part Number: DS90UB962-Q1
Other Parts Discussed in Thread: DS90UB935-Q1

Expert,

I put I2C master at UB962 side to control camera at UB935 side. Both side run I2C in 400KHz with clock stretch but failed. (100KHz I2C operation is OK)

I 've read "I2C over DS90UB913/4 FPD-Link III with Bidirectional Control Channel" and "I2C Communication Over FPD-Link III with Bidirectional Control Channel". 

I have some questions about DS90UB962-Q1 with DS90UB935-Q1 I2C speed calculation.

I2C mast is at DS90UB962-Q1 side. External Ref clk is 25MHz for 962. UB935 works at synchronize clock mode.

According to App notes, I2C throughput is 9 bits / ((Host_bit * 9) + (Remote_bit * 9) + FCdelay(1us) + BCCdelay(12us)).

But the example in App notes is for UB913/914. What is FC delay and BCC delay for UB962 with UB935?

I saw typical latency is 1.5us for 50MHz BC case at  "Table 10. Back Channel GPIO Typical Timing" in UB962 datasheet. So BCC delay is 1.5us? 

"7.4.11.3 Forward Channel GPIO" in UB962 datasheet said "The minimum latency for the GPIO remains consistent (approximately 225 ns)," so FC delay is 225ns?

If so , if both host side and remote side (camera) I2C are 400KHz, final throughput is slight less than 200KHz?

Does it mean both host side and remote side (camera) can operate at 400KHz but both should support clock stretch to reduce effective throughput to less than 200KHz?

And I2C  mode "standard/fast/fast-plus" is only for local I2C access or for remote I2C access?

For above 400KHz I2C for both host side and remote side (camera) scenario, is it "standard" I2C mode? I set 0x0A/0x0B "SCL HIGH/LOW TIME"  register to value 0x7A. Is it correct?

Looking forwarding your suggestion.

Great thanks

  • Hello Ryan,

    I am trying to follow through all your comments here, I think the latency numbers provided for GPIOs are a good guage for the I2C latency as well.  The datasheet lists values to right to SCL_HIGH and SCL_LOW in order to get the speeds you want.  As for how it affects each side of the link, typically in our applications the SER is the master on the remote bus and the DES is the slave on the local bus.  The SER recreates what the DES sees and the DES holds the clock while it is waiting for a response.  

    With all that said I think the calculations in the app note will work for both 913 and 935.  Just need to update the values with what the 935 is capable of.

    Regards,

    Nick

  • Nick,

    Thanks for feedback. Let me double confirm:

    For below table in "I2C over DS90UB913/4 FPD-Link III with Bidirectional Control Channel.pdf"

    Table 6. Typical I2C bit rates
    Host I2C Rate Remote I2C Rate "SCL High Time" Net Bit Rate register "SCL Low Time" register
    400 kbit/s 400 kbit/s 0x32 0x32 155 kbit/s

    1. Does it mean host and remote slave(camera) can run at 400Kbps I2C but the real throughput is only 155Kbps? Both host and slave should support clock stretch to avoid error, right?

    2. For 962, 935 400Ksps pair, Effective rate = 9bits / (2.5us*9 + 2.5us*9 + 1.5us + 0.225us) = 192.6kbit/s.  Then "SCL High Time"+"SCL LOW Time"=1/192.6=5.2us   "SCL High Time"= "SCL LOW Time"=2.6us 

    40 ns × (SCL_HIGH_TIME + 4)=2.6us thus SCL_HIGH/LOW_TIME=61=0x3D. I should set 0x0A/0x0B "SCL HIGH/LOW TIME"  register to value 0x3D. 

    Is my above calculation correct?

    Great thanks

  • Hi Hirata,

    So my understanding is that you are trying to calculate the high-time and low-time register values for a specific I2C rate? If you want to use 400kbits/s then I would recommend you use the default values suggested in the datasheet.  The effective throughput will be significantly less because of the latency of transferring the I2C data over the FPD-Link channel and it must be recreated on the remote I2C bus.  You shouldn't need to change the frequency of the I2C communication to compensate for this.

    Regards,

    Nick

  • Nick,

    great thanks for feedback