I3C is coming - Page 1
Forum section: electronics / general

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 27, 2023, 10:08:39 pm
content: Up to 12.5MHz, still 2 wires and backward compatible with I2C.https://www.mipi.org/specifications/i3c-sensor-specificationVendors are starting to deploy it:https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/i3c-interface-devices:I3Chttps://www.microchip.com/en-us/product/PIC18F16Q20

author: ataradov
author_rank: Super Contributor
timestamp: October 27, 2023, 10:31:50 pm
content: I don't see that having a huge success. Just like there are not a lot of I2C HS devices out there.If MIPI forces this into their stuff, it would be one place where it is used. Otherwise, if you really need speed, SPI works. Shared bus in that case does not help. And layout requirements become to strict for that to be an easy to use interface.

author: ataradov
author_rank: Super Contributor
timestamp: October 27, 2023, 10:35:23 pm
content: It is also backwards compatible with I2C devices that implement proper glitch filtering. And there are a lot of devices that either don't implement it, or it is not fully compliant to the spec for various implementation reasons. Things are still likely to work, but you would have to test coexistence really well.

author: woofy
author_rank: Frequent Contributor
timestamp: October 28, 2023, 09:46:06 am
content: If I3C was there on a device I needed to use and an easy controller available in my chosen MPU, then I would probable use it, but I really don't see the point of it. I3C seems to have no advantages of importance over what we have now. I2C, SPI and UART's cover all the low speed comms I need. Its just another protocol for the sake of it. Unless I absolutely must use it because of a needed functionality not available elsewhere, I wouldn't bother.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 28, 2023, 09:52:32 am
content: What bullshit. I2C is already complicated by earlier "speed improvements" no one wants and no one uses, and again no one has asked for yet another "improvement".

author: janoc
author_rank: Super Contributor
timestamp: October 28, 2023, 12:30:06 pm
content: This is old news. I3C has been around since 2016 - and didn't exactly take off like a wildfire in that time.

author: ejeffrey
author_rank: Super Contributor
timestamp: October 28, 2023, 02:25:52 pm
content: Quote from: woofy on October 28, 2023, 09:46:06 amThe only real point I can see is basically the MIPI situation. If you have a standardized interface that specifies an i2C auxillary channel that you wish was faster. I3C would seem to get you a migration path that was backwards compatible with existing devices. If you aren't in that situation just use SPI.

author: Scrts
author_rank: Frequent Contributor
timestamp: October 30, 2023, 01:30:57 am
content: This will be very helpful in automotive, especially radars and cameras.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 01:59:35 am
content: The first revision may date back to 2016, but MCUs and peripherals are starting to appear from major vendors (STM, NXP, Microchip...), some of them having made recent announcements (hence the topic, it's not just "old news") and after reading the specs I find it a nice addition. I'll certainly use it if it's available for the parts I need. The STM32H5 series, which was released a few months ago, embed I3C peripherals.Yes it's from MIPI, so what? I2C was from Philips and people were probably whining as well for years until it became mainstream. SPI is no direct substitute for a two-wire, multi-device bus.The ideas behind it are quite simple in fact, but unfortunately, it always has to be "owned" by some organization to see standardization and widespread use. The value of these "standards" is all in that, the fact they are standards. It's not particularly the technical aspects, which are not revolutionary by any means.Contrary to SPI, the idea that synchronous communication between devices is rarely required to be full-duplex (the need for full-duplex being usually the exception rather than the norm), using a single wire for bidirectional data sounds pretty obvious. The same has been used for SWD, and actually for QSPI as well.

author: ataradov
author_rank: Super Contributor
timestamp: October 30, 2023, 02:09:24 am
content: I2C sucked at the very beginning with Philips trying to charge license fees (hence generic TWI in Atmel parts). And their idea of manually assigning addresses from 7 bit range was "interesting".I'm all for a fast and simple addressable bus, it would be great to have as an option. But I don't think peripheral adoption outside of the mandated by MIPI devices would be good. This is my only concern and this is the only reason I'm not too excited.For a fast bus like this peripheral support follows the MCU anyway, so we need to get to the point where it is not an exciting announcement, but an expectation that a random MCU you buy will support I3C.With I2C you can trivially bit-bang the whole thing, not so much with I3C.

author: westfw
author_rank: Super Contributor
timestamp: October 30, 2023, 03:01:46 am
content: What about single pair Ethernet?

author: ataradov
author_rank: Super Contributor
timestamp: October 30, 2023, 03:14:21 am
content: It would be fine if it replaces CAN. There is no issue with the MCU side - both RMII and SPI transceivers exist. So, it can be readily used with any existing MCUs. And the supporting components and circuits are very simple.I've been looking at it for personal projects, but the existing transceivers are quite expensive in low quantities. I assume things will get cheaper if it gets any adoption. From what I hear, there is a lot of interest for automotive applications. But they also have a ton of inertia, so it would be interesting to see what vendors adopts it first.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 30, 2023, 07:51:15 pm
content: Quote from: ataradov on October 30, 2023, 02:09:24 amWe'll see about further adoption. But while I would also like options, and possibly options that are fully open, that looks like something not very likely to happen.Surely we can design a synchronous two-wire bus, even faster than I3C and release an open standard. The issue will be adoption.I would like to see something like the RISC-V ISA, but for busses.

author: Fredderic
author_rank: Regular Contributor
timestamp: October 31, 2023, 06:31:27 am
content: The new EEVBus?

author: mike449
author_rank: Contributor
timestamp: November 11, 2023, 04:47:07 am
content: The group I worked in couple years ago looked at implementing I3C target device (we are not allowed to use the s* word anymore). It is actually fairly difficult from the timing point of view and requires using custom I/O cells to meet the timing spec.Then there is lack of test equipment and adapters to connect devices to PC on the bench.Maybe just my limited perspective, but chip designers don't like I3C.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: November 11, 2023, 08:47:02 am
content: Qualcomm SoCs (a quite widespread thing, check your phone) support I3C for years already (as one of many modes of their “generic serial” QUP peripheral), but I’ve never seen a device having something connected via it yet. These SoCs also have MIPI DSI/CSI ports, perhaps I3C just came in bundle with them.

author: SiliconWizard
author_rank: Super Contributor
timestamp: November 11, 2023, 09:09:10 pm
content: Quote from: mike449 on November 11, 2023, 04:47:07 amI'm reading the specs (446 pages), and it's quite complex, at least if one wants to implement the full specs with all supported modes (there are many). It supports DDR and even ternary symbols. Full compliance looks like a big endeavor.

author: Darkover
author_rank: Regular Contributor
timestamp: November 12, 2023, 06:44:07 am
content: > I'm reading the specs (446 pages), and it's quite complex,I agree with that. It will be interested to read the error list of the first implementations.So I think it will need 5-10years before I will look in it.Olaf

author: mtwieg
author_rank: Frequent Contributor
timestamp: November 16, 2023, 02:27:45 pm
content: From what I understand, I see two major roadblocks:1. Getting this to work is likely going to put big constraints on the number of devices on the bus, and the way the bus is laid out. For example, with I2C I can take a random slave on a breakout board and connect it to an existing I2C bus with a few feet of hookup wire. I'm betting that would not work with I3C. Even if the new slave is just I2C compliant, the presence of those long, uncontrolled transmission lines will probably destroy signal integrity for any I3C communications on that bus.2. The interoperability of I2C and I3C devices depends on the I2C devices ignoring SCL pulses less than 50ns wide. I'd surprised if most slave devices out there actually implemented this at all, which means they couldn't be used on an I3C bus.I'm guessing these challenges could be overcome by sprinkling buffers/repeaters along the bus. More sales for NXP...

author: mark03
author_rank: Frequent Contributor
timestamp: November 16, 2023, 10:31:55 pm
content: Real question is, do you pronounce it "eye-three-see" or "eye-cubed-see"?