I3C (buss)

I3C buss

Typ	Seriell kommunikationsbuss
Produktionshistorik
Designer	MIPI Alliance Sensor Working Group
Designad	2016 ( 2016 )
Hotpluggbar	Sann
Elektrisk
Signal	CMOS
Data
Datasignal	Öppna dränering eller tryck/drag
Bredd	2 trådar [data + klocka]
Bithastighet	12,5 Mbit/s (SDR, standard), 25 Mbit/s (DDR), 33 Mbit/s (ternär), äldre I²C-hastigheter 400 Kbits/s (FM), 1 Mbit/s (FM+)
Protokoll	Seriell , halv duplex

I3C är en specifikation för att möjliggöra kommunikation mellan datorchips genom att definiera den elektriska anslutningen mellan chipsen och signalmönster som ska användas. Förkortning för "Improved Inter Integrated Circuit", standarden definierar den elektriska anslutningen mellan chipsen till att vara en tvåtrådig, delad ( multidropp ), seriell databuss , en tråd ( SCL ) som används som en klocka för att definiera samplingstiderna, annan tråd ( SDA ) som används som en dataledning vars spänning kan samplas. Standarden definierar ett signaleringsprotokoll där flera chips kan styra kommunikationen och därigenom fungera som bussstyrenhet.

I3C-specifikationen har fått sitt namn från, använder samma elektriska anslutningar som, och tillåter viss bakåtkompatibilitet med, I²C- bussen, en de facto- standard för kommunikation mellan kretsar, som ofta används för låghastighets kringutrustning och sensorer i datorsystem. I3C-standarden är utformad för att bibehålla en viss bakåtkompatibilitet med I²C-systemet, vilket särskilt tillåter konstruktioner där befintliga I²C-enheter kan anslutas till en I3C-buss men ändå har bussen möjlighet att växla till en högre datahastighet för kommunikation med högre hastigheter mellan kompatibla I3C enheter. I3C-standarden kombinerar därigenom fördelen med den enkla, tvåtrådiga I²C-arkitekturen med de högre kommunikationshastigheterna som är vanliga för mer komplicerade bussar såsom Serial Peripheral Interface (SPI).

I3C-standarden utvecklades som ett samarbete mellan elektronik- och datorrelaterade företag under överinseende av Mobile Industry Processor Interface Alliance ( MIPI Alliance) . I3C-standarden släpptes först för allmänheten i slutet av 2017, även om åtkomst kräver avslöjande av privat information. Google och Intel har backat upp I3C som en sensorgränssnittsstandard för Internet of things (IoT)-enheter.

Historia

Målen för MIPI Sensor Working Group-insatsen tillkännagavs först i november 2014 vid MEMS Executive Congress i Scottsdale AZ.

Leverantörer av elektroniska designautomationsverktyg inklusive Cadence , Synopsys och Silvaco har släppt kontroller IP-block och tillhörande verifieringsprogram för implementering av I3C-bussen i nya integrerade kretsdesigner.

I december 2016 integrerade Lattice Semiconductor I3C-stöd i sin nya FPGA känd som en iCE40 UltraPlus.

2017 tillkännagav Qualcomm Snapdragon 845 mobil SOC med integrerat stöd för I3C-kontroller.

I december 2017 släpptes I3C 1.0-specifikationen för offentlig granskning. Ungefär samtidigt föreslog Boris Brezillon en Linux-kärnpatch som introducerade stöd för I3C.

2021 har DDR5 introducerat I3C.

I juni 2022 introducerade Renesas Electronics de första I3C Intelligent switch-produkterna.

Mål

Innan specifikationen offentliggjordes har en stor mängd allmän information om den publicerats i form av bilder från 2016 MIPI DevCon. Målen för detta gränssnitt baserades på en undersökning av MIPI-medlemsorganisationer och MEMS Industry Group (MIG) medlemmar. Resultaten av denna undersökning har offentliggjorts.

I3C v1.0

Den ursprungliga I3C-designen försökte förbättra över I²C på följande sätt:

• Tvåstiftsgränssnitt som är en superset av I²C-standarden. Legacy I²C-målenheter kan anslutas till den nyare bussen.
• Energisnål och utrymmeseffektiv design avsedd för mobila enheter (smartphones och IoT -enheter.)
• In-band-avbrott över seriebussen snarare än att kräva separata stift. I I²C kräver avbrott från kringutrustning vanligtvis ett extra icke-delat stift per paket.
• Standard Data Rate (SDR) genomströmning mellan 10 och 12,5 Mbit/s med CMOS I/O-nivåer.
• High Data Rate (HDR)-lägen som tillåter flera bitar per klockcykel. Dessa stödjer en genomströmning som är jämförbar med SPI medan de bara kräver en bråkdel av I²C Fast Mode-effekt.
• En standardiserad uppsättning vanliga kommandokoder
• Kommandokö stöd
• Felidentifiering och återställning (paritetskontroll i SDR-läge och 5-bitars CRC för HDR-lägen)
• Dynamisk adresstilldelning (DAA) för I3C-mål, samtidigt som det stöder statiska adresser för äldre I²C-enheter
• I3C-trafik är osynlig för äldre I²C-enheter när de är utrustade med I²C spikfilter, uppnådda med SCL HIGH-tider på mindre än 50 ns
• Hot-join (vissa enheter på bussen kan slås på/av under drift)
• Multikontrollerdrift med ett väldefinierat protokoll för hand-off mellan kontroller

I3C grundläggande specifikation

Efter att ha gjort I3C 1.0-standarden allmänt tillgänglig publicerade organisationen I3C Basic-specifikationen, en delmängd avsedd att kunna implementeras av icke-medlemsorganisationer under en RAND-Z- licens. I3C Basic tillåter royaltyfri implementering av I3C och är avsedd för organisationer som kan se MIPI-medlemskap som ett hinder för adoption. Den grundläggande versionen innehåller många av protokollinnovationerna i I3C 1.0, men saknar några av de potentiellt svårare att implementera, såsom de valfria lägena för hög datahastighet (HDR) som DDR. Icke desto mindre är standard SDR-läget på upp till 12,5 Mbit/s en stor hastighet/kapacitetsförbättring jämfört med I²C.

I3C v1.1

Denna specifikation publicerades i december 2019 och är endast tillgänglig för MIPI-medlemmar.

I3C v1.1.1

Den publicerades i juni 2021 och har fasat ut termerna "mästare/slav" och använder nu de uppdaterade normativa termerna "kontrollant/mål". De tekniska definitionerna av sådana enheter, och deras roller på en I3C-buss, förblir oförändrade.

Nomenklatur

Signalstift

I3C använder samma två signalstift som I²C, kallat SCL (seriell klocka) och SDA (seriell data). Den primära skillnaden är att I²C använder dem som öppna dräneringsutgångar hela tiden, så dess hastighet begränsas av den resulterande långsamma signalstigtiden . I3C använder öppet dräneringsläge när det är nödvändigt för kompatibilitet, men växlar till push-pull-utgångar när det är möjligt och inkluderar protokolländringar för att göra det möjligt oftare än i I²C.

• SCL är en konventionell digital klocksignal , driven med en push-pull-utgång av den aktuella bussstyrenheten under dataöverföringar. (Klocksträckning, en sällan använd I²C-funktion, stöds inte.) I transaktioner som involverar I²C-målenheter har denna klocksignal i allmänhet en arbetscykel på cirka 50 %, men när den kommunicerar med kända I3C-mål, bussstyrenheten kan växla till en högre frekvens och/eller ändra arbetscykeln så att SCL-högperioden begränsas till högst 40 ns.
• SDA bär den seriella dataströmmen, som kan drivas av antingen styrenhet eller mål, men drivs med en hastighet som bestäms av styrenhetens SCL-signal. För kompatibilitet med I²C-protokollet börjar varje transaktion med SDA som fungerar som en öppen utloppsutgång, vilket begränsar överföringshastigheten. För meddelanden adresserade till ett I3C-mål växlar SDA-drivrutinläget till push-pull efter de första bitarna i transaktionen, vilket gör att klockan kan ökas ytterligare upp till 12,5 MHz. Denna medelhastighetsfunktion kallas standarddatahastighetsläge (SDR).

I allmänhet ändras SDA precis efter den fallande flanken av SCL, och det resulterande värdet tas emot på följande stigande flank. När styrenheten lämnar över SDA till målet, gör den det på samma sätt på den fallande kanten av SCL. Men när målet lämnar tillbaka kontrollen över SDA till styrenheten (t.ex. efter att ha bekräftat sin adress före en skrivning), släpper den SDA på den stigande kanten av SCL, och styrenheten är ansvarig för att hålla det mottagna värdet under SCL hög. (Eftersom styrenheten driver SCL, kommer den att se den stigande kanten först, så det blir en kort period av överlappning när båda kör SDA, men eftersom de båda kör samma värde uppstår ingen busstvist . )

Inramning

All kommunikation i I²C och I3C kräver inramning för synkronisering. Inom en ram bör förändringar på SDA-linjen alltid ske medan SCL är i lågt tillstånd, så att SDA kan anses vara stabil på låg-till-hög-övergången av SCL. Brott mot denna allmänna regel används för inramning (åtminstone i äldre och standarddatahastighetslägen).

Mellan dataramar håller bussstyrenheten SCL högt, vilket i själva verket stoppar klockan, och SDA-drivrutiner är i ett högimpedanstillstånd, vilket tillåter ett pull-up-motstånd att flyta det till högt. En hög-till-låg-övergång av SDA medan SCL är hög är känd som en START-symbol och signalerar början av en ny dataram. En låg-till-hög övergång på SDA medan SCL är hög är STOP-symbolen, som avslutar en dataram.

En START utan föregående STOPP, kallad "upprepad START", kan användas för att avsluta ett meddelande och påbörja ett annat inom en enda busstransaktion.

I I²C genereras START-symbolen vanligtvis av en busskontroller, men i I3C kan till och med målenheter dra låg SDA för att indikera att de vill starta en ram. Detta används för att implementera vissa avancerade I3C-funktioner, såsom avbrott i bandet, stöd för flera kontroller och hot-joins. Efter starten startar bussstyrenheten om klockan genom att köra SCL, och påbörjar bussarbiteringsprocessen.

Nionde biten

Precis som I²C använder I3C 9 klockcykler för att skicka varje 8-bitars byte. Den 9:e cykeln används dock annorlunda. I²C använder den sista cykeln för en bekräftelse som skickas i motsatt riktning till de första 8 bitarna. I3C fungerar på samma sätt för den första (adress) byten av varje meddelande, och för I²C-kompatibla meddelanden, men när man kommunicerar med I3C-mål använder meddelandebytes efter den första den 9:e biten som en udda paritetsbit vid skrivning och ett slut -of-data flagga på läsningar.

Skrivningar får endast avslutas av styrenheten.

Antingen styrenheten eller målet kan avsluta en läsning. Målet sätter SDA lågt för att indikera att ingen mer data finns tillgänglig; regulatorn svarar genom att ta över SDA och generera ett STOPP eller upprepad START. För att tillåta en läsning att fortsätta, driver målet SDA hög medan SCL är låg före den 9:e biten, men låter SDA flyta (open-drain) medan SCL är hög. Styrenheten kan köra SDA låg (ett upprepat START-tillstånd) vid denna tidpunkt för att avbryta avläsningen.

Buss skiljedom

Vid början av en ram kan flera anordningar tävla om användning av bussen, och bussarbitreringsprocessen tjänar till att välja vilken anordning som erhåller kontroll av SDA-linjen. I både I²C och I3C görs bussarbitrering med SDA-linjen i öppet dräneringsläge, vilket gör att enheter som sänder en binär 0 (låg) kan åsidosätta enheter som sänder en binär 1. Tävlande enheter övervakar SDA-linjen medan de kör den i öppen- dräneringsläge. Närhelst en enhet upptäcker ett lågt tillstånd (0 bitar) på SDA medan den sänder ett högt tillstånd (1 bit), har den förlorat skiljedom och måste sluta tävla tills nästa transaktion börjar.

Varje transaktion börjar med måladressen och implementeringen prioriterar lägre numrerade måladresser. Skillnaden är att I²C inte har någon gräns för hur länge skiljeförfarandet kan pågå (i den sällsynta men lagliga situationen för flera enheter som tävlar om att skicka ett meddelande till samma enhet, kommer påståendet inte att upptäckas förrän efter adressbyten). I3C garanterar dock att skiljeförfarandet kommer att vara slutfört senast i slutet av den första byten. Detta gör att push-pull-drivrutiner och snabbare klockfrekvenser kan användas den stora majoriteten av tiden.

Detta görs på flera sätt:

• I3C stöder flera kontroller, men de är inte symmetriska; en är den nuvarande styrenheten och ansvarig för att generera klockan. Andra enheter som skickar ett meddelande på bussen (in-band avbrott eller sekundära styrenheter som vill använda bussen) måste medla med sin egen adress innan de skickar andra data. Således delar inga två legala bussmeddelanden samma första byte förutom om styrenheten och en annan enhet samtidigt kommunicerar med varandra.
• I3C, liksom I²C, tillåter flera meddelanden per transaktion separerade med "upprepad START"-symboler. Skiljeförfarande är per transaktion, så dessa efterföljande meddelanden är aldrig föremål för skiljedom.
• De flesta I3C-kontrollertransaktioner börjar med den reserverade adressen 0x7E (1111110 ₂ ). Eftersom detta har en lägre prioritet än någon I3C-enhet, när den väl har passerat skiljeförfarande, vet styrenheten att ingen annan enhet tävlar om bussen.
• Som ett specialfall, om I3C-enheter tilldelas låga adresser (I3C stöder dynamisk, kontrollerkontrollerad adresstilldelning), så så snart 0x7E-adressen har vunnit skiljedom för tillräckligt många inledande bitar för att skilja den från vilken som helst tilldelad adress, vet styrenheten att skiljeförfarandet är slutfört och det kan gå över till push-pull-drift på SDA. Om alla tilldelade adresser är mindre än 0x40 är detta efter den första biten. Om alla adresser är mindre än 0x60 är detta efter den andra biten, och så vidare.
• I det ovan beskrivna fallet där den aktuella styrenheten påbörjar en transaktion med adressen till en anordning som själv tävlar om användning av bussen, kommer båda att sända sina adressbytes framgångsrikt. Emellertid kommer var och en att förvänta sig att den andra bekräftar adressen (genom att dra ner SDA) för följande bekräftelsebit. Följaktligen kommer ingen av dem, och båda kommer att observera bristen på erkännande. I det här fallet skickas inte meddelandet, men kontrollanten vinner skiljedom: den kan skicka en upprepad start, följt av ett nytt försök som kommer att lyckas.

Vanliga kommandokoder

En skrivning adresserad till den reserverade adressen 0x7E används för att utföra ett antal specialoperationer i I3C. Alla I3C-enheter måste ta emot och tolka skrivningar till denna adress utöver sina individuella adresser.

Först och främst har en skrivning som bara består av adressbyte och inga databyte ingen effekt på I3C-mål, men kan användas för att förenkla I3C-arbitrering. Som beskrivits ovan kan detta prefix påskynda skiljeförfarandet (om styrenheten stöder optimeringen av att byta till push-pull mid-byte), och det förenklar styrenheten genom att undvika ett lite knepigt skiljeförfarande.

Om skrivningen följs av en databyte, kodar byten en "gemensam kommandokod", en standardiserad I3C-operation. Kommandokoder 0–0x7F är sändningskommandon adresserade till alla I3C-mål. De kan följas av ytterligare kommandospecifika parametrar. Kommandokoder 0x80–0xFE är direkta kommandon riktade till individuella mål. Dessa följs av en serie upprepade START och skrivningar eller läsningar till specifika mål.

Medan ett direkt kommando är aktivt, skriver eller läser per mål kommandospecifika parametrar. Denna operation är i stället för målets normala svar på ett I3C-meddelande. Ett direkt kommando kan följas av flera per-målmeddelanden, vart och ett föregås av en upprepad START. Detta specialläge slutar vid slutet av transaktionen (STOPP-symbol) eller nästa meddelande adresserat till 0x7E .

Vissa kommandokoder finns i både sändnings- och direktform. Till exempel kan kommandon för att aktivera eller inaktivera avbrott inom bandet skickas till individuella mål eller sändas till alla. Kommandon för att hämta parametrar från ett mål (till exempel kommandot GETHDRCAP för att fråga en enhet vilka högdatahastighetslägen den stöder) finns bara i direkt form.

Enhetsklasser

På en I3C-buss i dess standardläge (SDR) kan fyra olika klasser av enheter stödjas:

• I3C huvudkontroll
• I3C sekundär styrenhet
• I3C-mål
• I²C Target (äldre enheter)

Alternativ för hög datahastighet (HDR).

Varje I3C-busstransaktion börjar i SDR-läge, men I3C-styrenheten kan utfärda ett "Enter HDR" CCC-sändningskommando som talar om för alla I3C-mål att transaktionen kommer att fortsätta i ett specificerat HDR-läge. I3C-mål som inte stöder HDR kan sedan ignorera busstrafiken tills de ser en specifik "HDR-utgång"-sekvens som informerar dem om att det är dags att lyssna på bussen igen. (Kontrollenheten vet vilka mål som stöder HDR så kommer aldrig att försöka använda HDR för att kommunicera med ett mål som inte stöder det.)

Vissa HDR-lägen är också kompatibla med I²C-enheter om I²C-enheterna har ett 50 ns spikfilter på SCL-linjen; det vill säga de kommer att ignorera en hög nivå på SCL-linjen som varar mindre än 50 ns. Detta krävs av I²C-specifikationen, men inte universellt implementerat, och inte alla implementeringar ignorerar ofta upprepade toppar, så I3C HDR-kompatibilitet måste verifieras. De kompatibla HDR-lägena använder SCL-pulser på högst 45 ns så att I²C-enheter ignorerar dem.

HDR-DDR-läget använder signalering med dubbel datahastighet med en 12,5 MHz klocka för att uppnå en 25 Mbit/s rådatahastighet (20 Mbit/s effektiv). Detta kräver att SDA-linjen ändras medan SCK är hög, ett brott mot I²C-protokollet, men I²C-enheter kommer inte att se den korta höggående pulsen på SCL och därför inte märker avbrottet.

HDR-TSP- och HDR-TSL-lägena använder en av tre symboler som ternära siffror (trits):

0. En övergång av både SDA och SCL (mottagna inom 12,8 ns från varandra),
1. En övergång av endast SCL, eller
2. Endast en övergång av SDA.

Två byte plus två paritetsbitar (18 bitar totalt) delas upp i sex 3-bitars tripletter, och varje triplett kodas som två trits. Skickas med 25 Mtrit/s, detta uppnår en effektiv datahastighet på 33,3 Mbit/s.

Trit-paret som består av två övergångar av endast SDA används inte för att koda data, utan används istället för inramning, för att markera slutet på en HDR-sekvens. Även om detta begränsar den maximala tiden mellan SCL-övergångar till tre trittider, överskrider det gränsen på 50 ns för äldre I²C-enheter, så HDR-TSP-läge (ternär symbol, ren) får endast användas på en buss utan äldre I²C-enheter.

För att tillåta bussar inklusive I²C-enheter (med spikfilter) måste läget HDR-TSL (ternär symbol, äldre) användas. Detta bibehåller I²C-kompatibilitet genom trit-stuffing : efter varje stigande flank på SCL, om följande trit inte är 0, infogas en 1 trit (övergång endast på SCL) av avsändaren och ignoreras av mottagaren. Detta säkerställer att SCL aldrig är hög under mer än en trittid.

I²C-funktioner stöds inte i I3C

• Pull-up-motstånd tillhandahålls av I3C-styrenheten. Externa pull-up motstånd behövs inte längre.
• Clock Stretching – enheter förväntas vara tillräckligt snabba för att fungera med busshastighet. I3C-styrenheten är den enda klockkällan.
• I²C Utökade (10-bitars) adresser. Alla enheter på en I3C-buss adresseras med en 7-bitars adress. Native I3C-enheter har en unik 48-bitars adress som endast används under dynamiska adresstilldelningar.

Vidare läsning

• I2C-vs-I3C-Protocol-Analyzers-Differences-and-Similarities

externa länkar

• I3C-specifikation - MIPI