10 min
Earlier this week, we spent two days at a confidential I3C plugfest event hosted by the MIPI Alliance in Taipei, Taiwan. This event was an opportunity for device makers, IP designers, and test equipment manufacturers to confirm interoperability between their implementations of the MIPI I3C specification. In this article, we describe our biggest takeaway from this event! But first, let us discuss why an event like this exists in the first place and some of our observations on it.
Modern-day electronic interface specifications are driven by incredibly varied requirements, and this is especially true for interfaces such as the MIPI I3C® protocol. For example, according to the MIPI Alliance website, the I3C protocol is a “medium-speed, utility and control bus interface for connecting peripherals to an application processor in a range of mobile, IoT and automotive applications.” This broad space of applications means that the I3C protocol needs to cater to highly differentiated needs, and this is where industry standardization is helpful. Specifically, industry standardization means that companies from different backgrounds can collaborate to define how the interfaces work, and this standardization process has become a necessity in the semiconductor industry. Without standardization, even the richest companies in the world would not be able to deliver electronic solutions within realistic cost and/or timing constraints.
What standardization also means is that the protocol specifications are getting more and more complex because they tend to pool inputs from several companies with different feature priorities. It is not an exaggeration to say that a single protocol, like I3C, can be described through multiple documents that are hundreds of pages long each. This number of pages is simply what it takes to describe the communications protocol in a manner that can make it work reliably. With such a large set of documentation, design engineers are faced with the challenge of “interpreting” the intent of the documents they are designing toward. If a design engineer interprets a specification incorrectly, the cost to his/her company can be prohibitive! And this is where plugfests help. Plugfests are events in which engineers can work together and test their interpretations of the specifications. They are highly collaborative events, and they demonstrate the semiconductor industry’s maturity in dealing with the challenges of rapid technological advancement.
Figure 1: The SV6E-X is seen testing a new device at the I3C Plugfest.
Introspect’s SV6E-X Mid-Frequency Digital Test Module has been a mainstay at the MIPI I3C plugfest since 2018, and our engineers have had the opportunity to work directly with developers from many MIPI member companies. With our SV6E-X Mid Frequency Digital Test Module making the rounds, here are some observations on the latest plugfest.
There is a noticeable coming of age for I3C, and this plugfest was the best manifestation of it! We observed many of the implementations were successfully interoperating with each other, and they also supported several of the optional features of the protocol.
Sitting in our corner during the first day of the plugfest, we were called by two member companies who were failing to interoperate reliably between themselves – one of them was a controller and the other was a target. The SV6E-X was connected in a “probing” configuration (seen in Figure 2), and we used both our Protocol Analyzer and our PurVue Analyzer – featuring an embedded 2 channel, 1 Gsps real-time oscilloscope – to help the two companies figure out what was wrong. Within minutes, the SV6E-X was able to identify the root cause of the interoperability issue, and both the controller and target companies were able to proceed with functional testing. The real-time oscilloscope feature of the SV6E-X was crucial because it seamlessly enabled the debugging process while eliminating the need for having a traditional bench oscilloscope. It is truly remarkable.
Figure 2: The SV6E-X is seen probing the link between a controller device and a target device. Unlike in this picture, it is quite uncommon for the tester to be smaller than the form factor being measured.
Since our first plugfest event in 2018, we have continued to increase the capability of the SV6E-X product to make it as flexible as possible. This week, we were happy that the tool was able to react to every scenario that it was presented with. This is important because – notwithstanding standardization – the free market economy still requires differentiation between companies. So, each member’s device (which contains an I3C interface) will always have unique features representing their own innovation and their own contribution to the industry. Any tool like the SV6E-X must be flexible so that it can enable our companies to innovate!
So, here it goes.
In every I3C plugfest we have attended, we noticed that engineers often lose a lot of time simply because they’re using the wrong wires or using the wires incorrectly! And in every plugfest, it was the embedded real-time oscilloscope in the PurVue Analyzer of the SV6E-X that served as the tool to resolve the wiring issues! More than ever in this plugfest, the Introspect PurVue Analyzer was used as an educational tool to help engineers visualize the importance of selecting the proper wires and/or connecting them properly.
You see, coming from an I2C background and assuming that I3C is a “low frequency” bus, many engineers would use an SDA/SCL wire connection as shown in Figure 3.
Figure 3: Wires typically used for connecting the SCL and SDA signals of I3C. Can you spot what is wrong with these wires?
The problem is that I3C signals are transmitted in push-pull mode, which means that the edge rates on them are incredibly high even if the SCL frequency is relatively low. So, when the SDA and SCL signals propagate together with such close proximity along the wires in Figure 3, there is too much capacitive coupling between them, and this causes crosstalk. Crosstalk means that every time the SCL line toggles, the SDA line will have a huge voltage pulse or glitch on it. This is illustrated in Figure 4.
Figure 4: A huge amount of crosstalk can be seen on SDA every time SCL toggles.
In Figure 4, we show a section of the waveform where SDA is driving low bits while SCL is toggling. As can be seen, a glitch as large as 1.45 V occurs on SDA every time the SCL signal toggles, and this is quite large. When we pan to a section of the waveform that has active SDA transitions, things can get even worse, and this is illustrated in Figure 5. In this figure, we show an open-drain phase of SDA running at 4 MHz. While the risetime on SDA appears compliant, the glitch that occurs on it is so significant that it can easily be misinterpreted by the receiver.
Figure 5: Crosstalk affects SDA even when SDA is high. This amount of crosstalk can have catastrophic effects on the protocol.
Remember that the above waveform is a real situation from the I3C Plugfest in Taipei – it is not a simulation or an artificial setup. The glitches on SDA were so severe that they caused false protocol errors. Specifically, referring to Figure 6 below, we show a protocol analyzer trace that was obtained using the SV6E-X, and this trace shows an error transition highlighted in red. Looking at the analog waveform, we see that this error transition was caused by a glitch due to crosstalk!
Figure 6: Overlay of a protocol analyzer trace and the real-time oscilloscope trace showing how an SDA glitch was interpreted incorrectly as a protocol transition.
Remember that the above waveforms were all captured using the embedded oscilloscope feature of the SV6E-X without any external hardware.
Now, let us compare the above results to those obtained by simply changing the wires on the same platform. In Figure 7, we show the same SDA transition as that in Figure 5, but now there is hardly any glitch.
Figure 7: The same embedded real-time oscilloscope trace as in Figure 5 now exhibits almost no crosstalk. The only difference between the two plots is the wires used for connecting SDA and SCL.
And putting them side by side, we see the stark difference between the two captures. Remember, the only difference was that we changed the wires. Otherwise, it was the same SV6E-X with its embedded real-time oscilloscope that was measuring both scenarios.
Figure 8: Compare the two captures, both taken with the PurVue Analyzer, but using two different types of cables.
For even further certainty, let us zoom out to view the entire frame transmission with both the bad wires and good cables. Figure 9 shows both traces. As can be seen on the left hand side of the figure, the highlighted sections show that there is no space between the “VIL” and “VIH” regions on SDA, and this is why there is a large potential for erroneous protocol transitions. On the right hand side, there is a very nice separation between the VIL and VIH regions of the SDA signal. This is why the protocol captures did not show any errors.
Figure 9: Comparison of the entire frame transmission shows how severe crosstalk can be. On the left hand side, there is almost no separation between the VIH and VIL regions on the SDA signal.
With the above said, we show in this section the best kind of cable to use for I3C interoperability testing. Figure 10 shows the standard I3C cables that are shipped with the SV6E-X Mid-Frequency Digital Module, and they are the recommended way of performing I3C testing. The salient feature in this figure is that each of the SDA and SCL wires is completely shielded by a grounded shield. In fact, these wires are true 50-Ohm coaxial cables, although there is not necessarily a strong need to have controlled impedance on I3C cables. What matters is the ground shield. This ground shield ensures that there is no crosstalk between SDA and SCL lines. Additionally, it minimizes the ground return paths for all signals going back and forth across the cables.
Figure 10: Photograph of shielded coaxial cables that are shipped with every SV6E-X test module.
At the I3C Plugfest, our biggest takeaway was the importance of wires used for interoperability testing. Using the embedded real-time oscilloscope of the SV6E-X, we have shown how the incorrect wires can cause protocol errors due to excessive crosstalk or other signal artefacts. By using properly shielded cables, most signal integrity issues can be removed!
Are you developing I3C products? Save hours of debugging without the right tools and reach out to consult with our team at info@introspect.ca.
