How to Connect Sensors with I3C

• In-band Interrupt, the capability for a device to send an interrupt to the master over the two-wire bus (I²C required separate interrupt lines for any device that needed to interrupt)
• Dynamic device addressing (I²C required static addresses and a registry that Philips ran to hand them out)
• Multi-master (capability for one master to pass control temporarily to another master such as a sensor hub)
• Standardized commands
• Time control
• Hot-join (typically not plugging and unplugging, like with USB, but on-chip blocks being powered down and up)
• Error detection and recovery
• Plus I3C should be higher performance and lower power

The top left of the picture above shows an I²C architecture system. Despite I²C requiring just two wires, lots of other signals are required to cope with the things that I²C could not handle, such as interrupts. In the lower right is the equivalent system put together with I3C, so that literally the two wires of I3C are the only signals needed to connect up all the devices.

One of the big challenges with I3C was to keep I²C compatibility. A large number of I²C components are available from many manufacturers, including sensors, memories, microcontrollers, and more. Since these parts already exist, they cannot be changed. The biggest challenge is how to get the I²C components to ignore I3C operation without being able to change them to make them I3C-aware. That way there could be four types of device on the bus:

• I3C main master
• I3C secondary master
• I3C slave
• I²C slave

Some features of I²C, such as extended addressing and clock stretching, are not supported. I²C devices need to have a 50ns spike filter and then they will ignore any I3C high data rate (HDR) signalling since it won't make it through the filter. Also, I²C devices already have static addresses and so can't participate in the dynamic address assignment.

There are a number of different data rates: standard data rate (SDR), high data rate (HDR), double data rate (HDR-DDR), and ternary data (using both lines for data) called HDR-TSP/TSL. Not all I3C devices need to support the higher data rates, but they do need to be designed to recognize the start and end high data rate symbols so that they can ignore the high-speed data but start listening again once it finishes transmitting.

I3C Verfication

Next, Alex Passi of Cadence talked about i3C HDR Modes—From Spec to Real Devices. His focus was on verification of high-speed data and real-life scenarios.

Verification is done using both active and passive components. An active component behaves just like the real component. In fact, often it will be the SystemVerilog RTL of the real component. The passive components listen to what is going on, flag errors, and collect coverage. For example, if an incorrect packet of data is transmitted from a slave, then the active master will behave as it would in the real world (probably ignoring the packet) and attempt to recover. The passive component will flag the error. Of course it might not really be an error, part of verification involves sending "bad" data (such as data with a bad CRC) and making sure that the devices handle the bad data the way the I3C spec describes.

In HDR-DDR where data is transmitted on both edges of the clock, the main verification issues are:

• Ensuring the invisibility of HDR-DDR to  I²C devices on the bus
• Correct encoding and decoding of data
• Termination of read operation by the master
• Error detection and recovery
• For components that do not support HDR-DDR, ensuring that they properly ignore the traffic

I won't cover all the details of what type of tests are required. But to give a flavor, here is what Alex described for a slave (as opposed to master) DUT:

• General Write-Read – verifies proper operation of slave DUT in HDR-DDR mode
• Read Terminated by Master – verifies DUT ability to recognize and accept read termination by I3C master
• Write with invalid preamble – Active master VC generates invalid preamble in different kinds of DDR words written to slave DUT, in order to test DUT ability to detect, ignore, and recover from erroneous transmission
• Write with invalid parity - Active master VC generates invalid parity bits in different kinds of DDR words written to slave DUT, in order to test DUT ability to detect, ignore, and recover from erroneous transmission
• Write with invalid CRC5 - Active master VC generates invalid CRC5 word in DDR write message, in order to test DUT ability to detect, ignore, and recover from erroneous transmission

Alex described similar tests for the master and then progressed to the ternary modes, which are more complex still.

Of course, the most straightforward approach is not to try and build everything from scratch but to purchase verification IP (VIP) for I3C from Cadence. This covers all these conditions and others that are in the standard. It makes more sense to build on work that has already been done rather than duplicating it.

Details of the Cadence I3C VIP are here. It is compatible with the 0.7 version of the I3C spec. The full I3C spec should be finalized by the end of the year.

Next: Mellanox: Using Palladium ICA Mode

Previous: שלום from CDNLive Israel