Het nieuwe I3C-protocol - een waardig opvolger van I2C – of gebakken lucht?
Om de mogelijkheden en de beperkingen goed te begrijpen, moet je weten dat de I2C-bus tegenwoordig een rechtenvrije technologie is, nu de patenten van Philips verlopen zijn. Hoewel NXP, als opvolger van de halfgeleiderdivisie van Philips, nog steeds eigenaar is van de intellectuele rechten op het logo en de naam, kan de technologie nu door iedereen gratis worden gebruikt.
De discussie over I2C versus TWI is vrijwel verstomd, maar er zijn online nog steeds interessante uitspraken te vinden met de volgende teneur: “Het idee achter het betalen van licentierechten was om zeker te stellen dat mensen die zeiden dat ze I2C-technologie maakten (en die als I2C verkochten) de standaard ondersteunden en zo meehielpen die te laten groeien.”
Het resultaat was dat Philips de licentiehouders altijd aanmoedigde om de I2C-standaard volledig te implementeren. Daar hoorde het glitchfilter expliciet bij, wat in het verleden vaak conflicten opleverde tussen Philips Semiconductor en andere fabrikanten. Dit filter (we komen er later nog op terug) was misschien wel één van de redenen waarom Philips licentiebetalingen ging verlangen. Maar nu de patenten van Philips zijn verlopen, is het jachtseizoen geopend.
Helaas kan de werking van I2C-componenten in een I3C-bussysteem hooguit worden gezien als ofwel best practice of wishful thinking. Praktijktests zijn altijd nodig bij zulke gemengde systemen. Maar laten we eerst eens kijken wie of wat er achter de I3C-standaard zit.
I3C en de MIPI Alliance
De MIPI Alliance, een comité dat standaarden voor allerlei elektronica uitbrengt, is verantwoordelijk voor de I3C-standaard. De lidmaatschapsgelden voor de alliantie zijn niet gering, zoals blijkt uit de verborgen prijslijst (figuur 1).
Om de adoptie te stimuleren biedt het standaardiseringscomité een volledig gratis basisversie van de I3C-specificatie aan. Een lijst van geavanceerde functies (alleen beschikbaar voor leden van de MIPI Alliance) is hier te vinden. Op die pagina is ook te zien dat I3C staat voor Improved Inter Integrated Circuits. De auteur denkt dat als je I3C gebruikt in een commerciële schakeling, er alleen ‘gedoe’ met de MIPI Alliance kan ontstaan als je de interface zelf gaat implementeren, bijvoorbeeld in een FPGA of door bit-banging. Maar als je kiest voor kant-en-klare componenten (en het I3C-logo of de naam niet gebruikt in advertenties), zijn er geen problemen te verwachten.
Vaarwel open drain
I2C-bus-ontwikkelaars zijn van meet af aan geplaagd door kleine en grote irritaties. Om te beginnen is er altijd de vraag waar pull up-weerstanden (voor het ontladen van de buscapaciteit) moeten worden geplaatst. Verder is het meestal niet mogelijk om interrupts te triggeren vanuit een component die niet zelf het kloksignaal genereert. Als je een ‘clock sensing’-component interrupts wilt laten genereren, is altijd een extra I2C-verbinding nodig. Als je meerdere sensoren in het veld hebt, gaat dat ten koste van de GPIO-capaciteit van de component die het kloksignaal genereert.
De derde irritatie is de vrij lage snelheid: Philips specificeert een overdrachtssnelheid van 3 Mbps bij een werkfrequentie van 3,4 MHz. Het gevolg van deze traagheid is een groter energieverbruik, want hoe langer de data-overdracht tussen twee componenten duurt, des te langer het ook duurt voordat ze naar een energiezuinige rusttoestand overgaan. Het MIPI-diagram (figuur 2) maakt dit zonder meer aannemelijk.
En tenslotte: I2C-componenten kunnen andere componenten op de bus ‘voor eeuwig’ buitensluiten. Een schemadetail zoals in figuur 3 is in veel I2C-systemen te vinden.
Verwelkom de I3C-verbeteringen
De eerste verandering die I3C met zich meebrengt, is dat zowel SCL als SDA meestal in push/pull-modus werken. De SCL-pin werkt altijd in push/pull, de SDA-pin werkt onder bepaalde omstandigheden nog wel als open-drain. Om verschillende problemen bij de plaatsing van de pull up-weerstanden te voorkomen, schrijft de standaard voor dat die zich altijd in de component moeten bevinden die de klok genereert.
Een ander belangrijk punt is dat SCL altijd (afgezien van enkele bijzondere gevallen) wordt bestuurd door de component die het kloksignaal genereert. Als er op een bus meerdere klok-genererende componenten zijn aangesloten, is de component dat op dat moment de klok genereert verantwoordelijk voor het schakelen van de SCL-pin.
Bij een conventionele I2C-bus kan een slave-IC het kloksignaal pauzeren. In de I3C-specificatie wordt dat niet ondersteund. Zulke componenten kunnen daarom op een gemengde bus niet functioneren. In de praktijk heb ik weinig praktische toepassingen van deze techniek gezien.
Deze vereenvoudiging gaat gepaard met een vereenvoudiging van de I/O-pinnen op de microcontroller of het klok-genererende IC. Voor I2C moeten aparte GPIO-pinnen worden gereserveerd in verband met het eerder genoemde (50 ns) glitchfilter, maar de MIPI-specificatie specificeert alleen normale GPIO-pinnen die minimaal 4 mA kunnen leveren. Er staat ook expliciet in de specificatie dat glitchfilters niet vereist zijn.
De voordelen van snelheid
In figuur 4 zie je enkele golfvormen op de I3C-bus. Het glitchfilter is bij I3C alleen van belang als het SCL-signaal op de bus een duty-cycle heeft die afwijkt van 50%, zoals bij I2C doorgaans het geval is. Bij I3C is de tijd dat het signaal hoog is gedefinieerd als korter dan 45 ns, dus een I2C-component die conform de standaard is geïmplementeerd kan helemaal niets met het signaal op de SCL-lijn.
Na ontvangst van zo’n ‘onzichtbare’ SCL-transactie, kan het klokgenererende IC zijn SDA-pin of SDA-lijn ook in push/pull-modus zetten en de werkfrequentie opvoeren tot 12,5 MHz. In deze full-speed modus kan een overdrachtssnelheid tot 12,5 Mbps worden bereikt, conform de MIPI I3C-specificatie.
Hogere overdrachtssnelheden kunnen met I3C worden bereikt in één van de drie HDR-modi (High Data Rate), maar die kunnen alleen worden gebruikt in twee bijzondere gevallen. Het eerste van die gevallen betreft een bussysteem dat Pure I3C Bus wordt genoemd. Dit bestaat uit uitsluitend I3C-componenten. Het tweede betreft Mixed Fast Bus en kan I2C-componenten bevatten, maar alleen als die een glitchfilter hebben dat voldoet aan de specificatie.
De HDR-modi beginnen met een speciale reeks SCL-pulsen terwijl de SDA-lijn in de niet-actieve toestand verkeert. De eenvoudigste modus is HDR-DDR (Double Data Rate), waarmee snelheden tot 25 Mbps mogelijk zijn. Daarbij is elke flank van het SCL-signaal een geldige trigger voor het ontvangen van data. Met de HDR-TSP-modus (Ternary Symbol Pure) zijn snelheden van meer dan 30 Mbps mogelijk. In deze modus worden de SCL- en SDA-lijn in combinatie gebruikt voor de data-overdracht. Nog een andere modus is HDR-TSL (Ternary Symbol Legacy-inclusive), die TSP beter laat omgaan met gemengde bussen.
Automatische adrestoewijzing
Een ander probleem van I2C is dat de adressen meestal fysiek moeten worden toegewezen aan de individuele componenten. Bij veel componenten (zoals de HDC2010 in figuur 5) houdt dat in dat de beschikbare adresruimte van de standaard niet volledig kan worden gebruikt.
In plaats van de 10-bit adresmodus van I2C, beschikt I3C over dynamische zelfoconfiguratie. Verder biedt I3C Hot Join de mogelijkheid om I3C-componenten op de bus aan te sluiten terwijl die actief is, net zoals dat kan bij USB.
Op de achtergrond draait een address arbitration-procedure die voor het toewijzen van adressen aan de slave-IC’s zorgt. Voor dat doel krijgt elk I3C-IC drie parameters: twee 8-bit velden met statusinformatie plus een unieke 48-bit UID. De specificatie gaat er van uit dat elke UID (die Provisional ID wordt genoemd) op de bus uniek is.
Bij het opstarten van de I3C-bus gaat het klokgenererende IC alle IC’s op de bus nummeren en dynamisch een adres toewijzen. Dat lijkt op het arbitrageproces bij I2C: de I3C-component met de laagste UID-waarde krijgt als eerste een dynamisch adres. Het klokgenererende IC voert meerdere toewijzingscycli uit, totdat elk apparaat op de bus een tijdelijk ID heeft.
Adoptie van de standaard door fabrikanten
De lijst van MIPI-leden staat vol bekende namen uit de wereld van de halfgeleiderfabrikanten, van GigaDevice tot ST en Solomon Systech. Vrijwel alle belangrijke bedrijven staan op de lijst. Maar als je in de praktijk op zoek gaat naar componenten, is er weinig te vinden. Zo zijn er bij Mouser momenteel alleen componenten zoals de PI3CSW12 van Dialog te vinden. Zoals je ziet in figuur 6 zijn dat chips voor multiplexen en signaalconditionering.
Renesas heeft, in elk geval voorlopig, een vergelijkbare benadering met chips zoals de IMX3102. In de aankondiging lezen we onder andere: “I3C biedt snelheden tot 12,5 MHz en verslaat daarmee oudere oplossingen zoals I2C met zijn snelheid van 1 MHz en analoge passieve snelle schakelaars.”
Als je zoekt naar microcontrollers met I3C-ondersteuning, is de spoeling wel heel erg dun: de enige is momenteel de i.MX RT685 van NXP. Daar is ook een application note (AN12797) met voorbeeldsoftware voor. NXP biedt ook een soft core aan (soms gratis), en er is zelfs een speciale licentie voor gebruikers die geen MIPI-lid zijn. Als je bereid bent om te betalen voor soft core intellectueel eigendom (IP), vind je bij leveranciers zoals Silvaco en Arasan Chip Systems kant-en-klare I3C-VHDL-modules.
Zoek je displays met I3C-ondersteuning (die vaak genoemd worden in de specificatie), dan moet je nog wachten. De enige fysieke hardware die momenteel verkrijgbaar is, zijn enkele versnellingsopnemers (de BMI263 van Bosch en de LSM6DSO van ST) en de druksensor LPS22HH van Bosch.
Qua software is de situatie wel rooskleuriger: hier is een vrij gedetailleerde beschrijving beschikbaar van de interfacedriver in de Linux-kernel.
Hoe lang gaat het nog duren?
De grotere datasnelheid en de mogelijkheid om interrupts te genereren zonder speciale GPIO-ingangen kunnen mogelijk op den duur leiden tot een industriebrede adoptie van I3C, maar het is de vraag hoe lang dat nog gaat duren. Omdat er nog nauwelijks microcontrollers verkrijgbaar zijn met geschikte I3C-periferie, zou dat volgens mij nog wel eens tegen kunnen vallen.
Vragen of opmerkingen?
Hebt u vragen of opmerkingen naar aanleiding van dit artikel? Stuur een e-mail naar de auteur via tamhan@tamoggemon.com of naar de redactie van Elektor via redactie@elektor.com.
210640-03 (geplande) publicatie in Elektor maart/april 2023
Vertaling: Evelien Snel