tSCO should not be 0

[juneysun]

Hi, Paul:

Thank you very much for your quick response to my issue #8. Sorry that I didn't follow up early since I didn't have any updated info. I have attached two waveform for this issue.

In previous issue #8, I think the problem was the glitch on the SDA line. After adding some glitch filter, the issue went away. But after debugging more, I think the real problem was the IP using negedge of 8th SCL and posedge of 9th SCL to control the SDA for the ACK and T bits. From I3C basic spec figure 32 and 40, the SLV_SDA should be driving for tSCO time after rising edge of the SCL before releasing it. In the attached file, top waveform, IP logic falsely detected the STOP condition because of this 0 tSCO. On the bottom figure, the other side master can't detect the T bit correctly. By adding delays to SDA both directions in the simulation environment, these two issues will be resolved. I am wondering if this design may cause any issue in real application. Though the pads and wire may contribute some delay, it could be contribute to both SCL and SDA. Is it better to add some logic to control the tSCO in the IP design?

tSCO0.pptx

Thanks,

June

[pkimelman-nxp]

In the real world, there is no such thing as an instantaneous pad or 0 time wire. The tSCO comprehends the time for the SCL to make it through the pad Schmitt, then in the core domain to the logic, then out of the logic to the pad which has to drive a PMOS or NMOS FET, depending on direction, and then back to the Master. So, each aspect adds real time, often in 1 or more ns. The Schmitt adds time, the path to logic adds time, the path back adds time, the pad driver takes serious time to transition the SDA line (it will be slewed under the C of the traces, etc), etc. You are also incorrect about the wire delay - they ARE added to both SCL and SDA, but they are in opposite direction so the sum of the delays is even higher! The diagram below shows this (from the I3C spec for tSCO; see GETMXDS in spec). Note that most people struggle to meet the 12ns SCL to SDA timing because in real ASIC and FPGA, these propagation delays and pad delays are quite high. The pad is usually contributing 1 to 3ns alone. Note also that the rise and fall time MIN spec for I3C is 3ns. So, even if the rest of it defined physics, the SCL trigger (ViH or ViL) to SDA output trigger (ViH or ViL of receiver) will be at least 3ns if conformant. So, you are assured that none of this is possible - just an artifact of simulation.

[cid:5B41958B-9FD8-4D6C-BF0A-4233F2ADF5DF]

On Jul 15, 2019, at 9:26 AM, juneysun notifications@github.com<mailto:notifications@github.com> wrote:

Caution: EXT Email

Hi, Paul:

Thank you very much for your quick response to my issue #8https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fi3c-slave-design%2Fissues%2F8&data=02%7C01%7Cpaul.kimelman%40nxp.com%7C872ca20550ee4e35425508d7094134e7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636988047973214624&sdata=Eo2MBkyJ4ll2klue7wNSjwLgBAxRWpUWox%2F5cTWxO7k%3D&reserved=0. Sorry that I didn't follow up early since I didn't have any updated info. I have attached two waveform for this issue.

In previous issue #8https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fi3c-slave-design%2Fissues%2F8&data=02%7C01%7Cpaul.kimelman%40nxp.com%7C872ca20550ee4e35425508d7094134e7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636988047973214624&sdata=Eo2MBkyJ4ll2klue7wNSjwLgBAxRWpUWox%2F5cTWxO7k%3D&reserved=0, I think the problem was the glitch on the SDA line. After adding some glitch filter, the issue went away. But after debugging more, I think the real problem was the IP using negedge of 8th SCL and posedge of 9th SCL to control the SDA for the ACK and T bits. From I3C basic spec figure 32 and 40, the SLV_SDA should be driving for tSCO time after rising edge of the SCL before releasing it. In the attached file, top waveform, IP logic falsely detected the STOP condition because of this 0 tSCO. On the bottom figure, the other side master can't detect the T bit correctly. By adding delays to SDA both directions in the simulation environment, these two issues will be resolved. I am wondering if this design may cause any issue in real application. Though the pads and wire may contribute some delay, it could be contribute to both SCL and SDA. Is it better to add some logic to control the tSCO in the IP design?

tSCO0.pptxhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fi3c-slave-design%2Ffiles%2F3393227%2FtSCO0.pptx&data=02%7C01%7Cpaul.kimelman%40nxp.com%7C872ca20550ee4e35425508d7094134e7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636988047973224618&sdata=tKfFdInT6f9LLLT7zGghDlPgvfBVJizzuIYG%2FlRSd04%3D&reserved=0

Thanks,

June

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FNXP%2Fi3c-slave-design%2Fissues%2F10%3Femail_source%3Dnotifications%26email_token%3DAFNELX2TNZPB3B73QM5YITLP7SQLTA5CNFSM4IDYSOR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G7IPXYA&data=02%7C01%7Cpaul.kimelman%40nxp.com%7C872ca20550ee4e35425508d7094134e7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636988047973224618&sdata=XnZAcXtOgonfpj4%2BppDq89ZypUORc0uX8dBrJrj1Rqw%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFNELX4L6ZNNUVZ47DCL3YLP7SQLTANCNFSM4IDYSORQ&data=02%7C01%7Cpaul.kimelman%40nxp.com%7C872ca20550ee4e35425508d7094134e7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636988047973234610&sdata=3jKYaYMczUxBYNSbE65AYAJBJYjL8GEmXTMbEiAaNog%3D&reserved=0.

-- Paul Kimelman – Automotive Platform Architecture 408.906.9676

[pkimelman-nxp]

[juneysun]

Hi, Paul:

Thank you for your analyzing. For the output path, T bit, I agree with you. One thing I worried was the input path. Since both SCL and SDA using the same pads with similar delay. If the delay for SCL is a little smaller than SDA, will it be an issue for the input path as shown in my top waveform?

Thanks,

June

[pkimelman-nxp]

If someone violates the bus and has SDA changing ahead of or with the SCL, then of course it would be a problem. But, there are 3 cases of drive, and none allow this:

1. The OD pull-up cannot drive SDA very quickly, so clearly it will have SDA well after SCL.
2. The Master drives SCL and SDA: it is obligated to separate SDA from SCL by at least the 3ns rule. That is, Master cannot drive SDA until SCL has passed ViH or ViL. So, since SDA now has min slew of 3ns, you have a separation of at least 3ns. Many Masters will create more skew of timing to be safe.
3. Slave is responding to SCL and changing SDA. That could not happen in less than the 3ns of required slew, but in reality will be far more for the reasons already shown.

So, this case only could occur if you have a broken system, and it would be in violation of the spec, so the behavior is not defined, but would reasonably be a STOP detect.

[juneysun]

Hi, Paul: Makes sense. Thank you!

June