SLIMbuss

Serial Low-power Inter-chip Media Bus ( SLIMbus ) är ett standardgränssnitt mellan basband eller applikationsprocessorer och kringutrustning i mobila terminaler. Det utvecklades inom MIPI Alliance , grundat av ARM , Nokia , STMicroelectronics och Texas Instruments . Gränssnittet stöder många digitala ljudkomponenter samtidigt och bär flera digitala ljuddataströmmar med olika samplingshastigheter och bitbredder.

SLIMbus är implementerad som en synkron 2-tråds, konfigurerbar Time Division Multiplexed (TDM) ramstruktur. Den har stödjande bussarbitreringsmekanismer och meddelandestrukturer som tillåter omkonfigurering av bussens funktionsegenskaper till systemapplikationens behov vid körning. Fysiskt sammankopplar datalinjen (DATA) och klocklinjen (CLK) flera SLIMbus-komponenter i en multi-drop-busstopologi . SLIMbus-enheter kan dynamiskt "släppa av" bussen och "återansluta" till bussen efter behov genom att använda lämpliga protokoll som beskrivs i SLIMbus-specifikationen. När den används i en mobil terminal eller bärbar produkt kan SLIMbus ersätta äldre digitala ljudgränssnitt som PCM , I 2 S , och SSI (Synchronous Serial Interface for digital audio), såväl som vissa instanser av många digitala styrbussar som I 2 C-, SPI-, microWire- , UART- eller GPIO -stift på de digitala ljudkomponenterna.

Historia

  • MIPI Alliance bildades hösten 2003.
  • Gränssnittsarkitektur inklusive en låghastighetsmedialänkbuss (LowML) presenterad vid MIPI Alliances F2F-möte i Sophia Antipolis , Frankrike i mars 2004.
  • LML Investigation Group (LML-IG) skapades i juli 2004 av MIPI Alliance. Första mötet var en telefonkonferens den 3 augusti 2004.
  • LML Working Group (LML-WG) skapades under Q4 2004. LML WG Charter lämnades till MIPI-styrelsen i december 2004.
  • Första mötet som full arbetsgrupp den 12 april 2005.
  • LML-WG släppte första utkastet av SLIMbus med text i alla kapitel (v0.55) den 18 oktober 2005.
  • SLIMbus-specifikationen v1.00 släpptes för användare den 16 maj 2007.
  • Från juni 2007 till juni 2008, förbättring av SLIMbus-specifikationen (tvetydigheter, stavfel och buggar fixade) baserat på feedback från implementeraren.
  • SLIMbus-specifikationen V1.01 släpptes till användare den 3 december 2008 och rekommenderas för implementering.

SLIMbus-enheter och enhetsklasser

SLIMbus Device Class-definitioner är de som specificerar minimikraven för enhetskontrolldata, enhetsbeteende och stöd för datatransportprotokoll. Det finns fyra SLIMbus-enhetsklasser definierade vid releasen av version 1.01 av SLIMbus-specifikationen: Manager, Framer, Interface och Generic. Kompletta SLIMbus-system kan implementeras utan några ytterligare enhetsklasser.

Manager-enhet

Manager Device ansvarar för att konfigurera SLIMbus och utför bussadministration (administration av komponenter och enheter, busskonfiguration och dynamisk kanalallokering) och är vanligtvis placerad i ett basband eller applikationsprocessor snarare än i en perifer komponent.

Framer-enhet

Framern levererar en klocksignal på CLK-linjen till alla SLIMbus-komponenter och innehåller även logik för att överföra ramsynkroniserings- och raminformationskanalerna på DATA-linjen.

Gränssnittsenhet

Gränssnittsenheten tillhandahåller busshanteringstjänster, övervakar det fysiska lagret för fel, rapporterar information om statusen för en SLIMbus-komponent och hanterar på annat sätt komponenten så att enheterna i den kommer att fungera korrekt på bussen.

För att implementera en funktionell SLIMbus-komponent krävs alltid användning av en SLIMbus-gränssnittsenhet, plus den funktion som ska utföras, såsom DAC, ADC, digital förstärkare , och så vidare.

Generisk enhet (funktion)

En generisk enhet är en annan enhet än en Manager, Framer eller Interface. En generisk enhet anses generellt vara enheten för att tillhandahålla viss applikationsfunktionalitet, till exempel konvertering från digitalt ljud till analogt (DAC) och vice versa (ADC).

SLIMbus-komponent

En SLIMbus-komponent innehåller två eller flera SLIMbus-enheter. En SLIMbus-komponent kommer endast att ha en SLIMbus-gränssnittsenhet (INTERFACE), och kan ha en eller flera andra typer av SLIMbus-enheter som utför en viss funktion (FUNCTION).

En SLIMbus-port (P) tillhandahåller anslutningsvägen för dataflödet mellan enheter. SLIMbus-portar används normalt för digitalt ljuddataflöde, men kan även användas för andra digitala dataflöden.

Portkapaciteten varierar beroende på enheten och ska specificeras i komponentdatabladet. Typiska portattribut inkluderar datariktning, dvs. endast ingång (sink), endast utgång (källa) eller både ingång och utgång, transportprotokoll som stöds och databredd.

Ett enkelt exempel på SLIMbus-komponent visas i figur 1 nedan och ett komplext exempel på SLIMbus-komponent visas i figur 2 nedan.

Simple SLIMbus Component

Figur 1: Enkel SLIMbus-komponent

Complex SLIMbus Component

Figur 2: Komplex SLIMbus-komponent

SLIMbus DATA och CLK

Alla SLIMbus-enheter använder DATA och CLK för att synkronisera med busskonfigurationen som används, för att ta emot eller sända meddelanden och data och för att implementera bussarbitrering, kollisionsdetektering och konfliktlösning mellan enheter.

För alla SLIMbus-komponenter (förutom en som innehåller en Framer-enhet) är CLK-terminalen endast ingång. Om en SLIMbus-komponent är Framer-enheten, eller innehåller en Framer-enhet, är CLK-signalen dubbelriktad.

För alla SLIMbus-komponenter är DATA-linjen dubbelriktad och bär all information som skickas eller tas emot på bussen med hjälp av Non-Return-to-Zero Inverted (NRZI)-kodning.

DATA-linjen drivs på den positiva kanten och läses på den negativa kanten av CLK-linjen. DATA-linjen kan drivas högt, drivas lågt eller hållas på hög eller låg nivå av en intern busshållarkrets , beroende på det speciella driftsläget för en SLIMbus-enhet.

SLIMbus-gränssnittets DATA- och CLK-linjer använder CMOS -liknande enkeländade, jordreferens, rail-to-rail, spänningslägessignaler, och signaleringsspänningar är specificerade med avseende på gränssnittets matningsspänning (+1,8Vdd eller +1,2Vdd är tillåtna ). Av EMI-prestandaskäl har svänghastighetsgränser specificerats för SLIMbus.

SLIMbus klockfrekvenser och växlar

SLIMbus CLK-linjefrekvensen bestäms av ett intervall av "Root"-klockfrekvenser upp till 28 MHz, och 10 klockväxlar för att ändra klockfrekvensen med 2 potenser över ett intervall på 512x från lägsta till högsta växeln. Rotfrekvensen definieras som 2 (10-G) gånger frekvensen för CLK-linjen. För G=10 är CLK-linjefrekvensen och rotfrekvensen lika.

SLIMbus CLK kan också stoppas och startas om.

SLIMbus CLK-frekvenser och datatransportprotokoll kommer att stödja alla vanliga digitala ljudomvandlare översamplingsfrekvenser och tillhörande samplingsfrekvenser.

Celler, Slots, Subframes, Frames och Superframes

SLIMbus ramstruktur har fem byggstenar: Celler, Slots, Frames, Subframes och Superframes.

Cell

En cell definieras som en region av DATA-signalen som är begränsad av två på varandra följande positiva flanker av CLK-linjen och innehåller en enda bit information.

Cell Structure

Figur 3: Cellstruktur

Spår

En lucka definieras som fyra angränsande celler (4-bitar sänds i MSB till LSB-ordning). Bandbreddsallokering för olika dataorganisationer, från 4-bitar till 32-bitar eller mer, kan göras genom att gruppera 4-bitars platser.

Ram

En ram definieras som 192 (0 till 191) sammanhängande luckor och sänds som SO, följt av S1, S2 ... S191 i den ordningen. Den första luckan (plats 0) i varje ram är en kontrollutrymmeslucka som innehåller fyra (4) bitars ramsynkroniseringssymbol. Slot S96 i varje ram är också en kontrollutrymmeslucka som innehåller fyra (4) bitar av raminformation.

Den aktiva framaren skriver all raminformation till dataraden vid lämplig tidpunkt.

Underram

En underram definieras som uppdelningen av ramstrukturen där kontrollutrymme och datautrymme är sammanflätade . En underram är uppdelad i 1 eller flera fack med kontrollutrymme, följt av 0 eller fler fack med datautrymme.

Som visas i figur 4 nedan är underramslängden programmerbar till 6, 8, 24 eller 32 angränsande luckor (24, 32, 96 eller 128 celler). Antalet möjliga underramar per ram är därför 32, 24, 8 respektive 6. Subframe-konfigurationen som används kan ändras dynamiskt beroende på dataflödeskraven för de applikationer som stöds vid tillfället.

Cell, Slot, Subframe, Frame Structure

Figur 4: Cell, slits, underram, ramstruktur

4 av kontrollutrymmesluckor är reserverade för en ramsynkroniseringssymbol, 4 bitar om ett raminformationsord och 8 bitar guidebyte. Resten är tillgänglig för mer allmänna kontrollmeddelanden.

Alla platser som inte är allokerade till kontrollutrymmet betraktas som datautrymme.

Superframe

En Superframe definieras som åtta sammanhängande ramar (1536 platser). Ramar i en Superframe är märkta Frame 0 till Frame 7.

Varaktigheten för en Superframe är fast i termer av slots (och därför celler), men inte i termer av tid. Superframe-hastigheten kan ändras dynamiskt på SLIMbus för att passa den specifika applikationen genom att ändra antingen SLIMbus Root Frequency eller Clock Gear, eller båda.

Kanaler

Information på SLIMbus DATA-linjen allokeras till kanalerna Control Space och Data Space.

Kontrollutrymmet bär busskonfigurations- och synkroniseringsinformation samt kommunikation mellan enheter. Kontrollutrymmet kan programmeras dynamiskt för att ta så mycket av SLIMbus-bandbredden som krävs, till och med upp till 100 % ibland.

Data Space, när det finns, bär applikationsspecifik information såsom isokrona och asynkrona dataströmmar .

SLIMbus-komponenter förmedlar kontroll- och datainformation mellan varandra med hjälp av kontroll- och datakanaler med transportprotokoll för att uppnå den systemdrift som krävs. Meddelanden används för kontrollfunktioner.

Kanaler kan upprättas mellan ett par enheter (kommunikation mellan enheter), eller mellan en enhet och många enheter (sändningskommunikation), eller i fallet med meddelandekanalen, från alla enheter till alla andra enheter (delade).

Kontrollkanaler

Kontrollutrymme är uppdelat i tre typer av kanaler: Inramning, Guide och Meddelande.

Ramkanalen upptar plats 0 och 96 i varje ram. (Eftersom alla underramslängder delar 96 är dessa luckor alltid tillgängliga för ändamålet.) Slot 0 innehåller en fast ramsynkroniseringssymbol (1011 2 ), medan lucka 96 rymmer 4 bitar av ett raminformationsord. Under loppet av en Superframe är 32 bitar av raminformation tillgänglig. Vissa av dessa har ett fast bitmönster som används för att förvärva Superframe-synkronisering (0 x 011 xxx 2 ), medan andra har annan kritisk konfigurationsinformation.

Guidekanalen består av de första 2 icke-framing kontrollslots i varje Superframe. Denna "guidebyte" är normalt 0, men om ett kontrollmeddelande går över en Superframe-gräns, indikerar det antalet byte till slutet av det meddelandet.

Meddelandekanalen består av alla återstående platser. Den bär olika typer av information inklusive busskonfigurationsmeddelanden, enhetskontroll och enhetsstatus.

Formatet för styrutrymme bestäms av en 5-bitars underramsmodidentifierare som sänds i raminformationsordet. Detta kommunicerar underramens längd och antalet kontrollplatser. Antalet kontrollplatser är begränsat till valen 1, 2, 3, 4, 6, 8, 12, 16 eller 24. Lägga till begränsningarna att antalet kontrollplatser måste vara mindre än underramslängden ger 26 giltiga kombinationer . En speciell kodning för "100 % kontrollutrymme", i vilket fall underramslängden är oviktig, ger 27 giltiga lägen. (Lägen 1–3, 20 och 30 är inte giltiga.)

Datakanaler

Datakanaler är en eller flera sammanhängande dataplatser (segment) och skapas dynamiskt av den aktiva hanteraren beroende på applikationen och storleken på tillgängligt datautrymme. En datakanal, och därför strukturen för ett segment, definieras av parametrar som datahastighet, typ, fältlängd och obligatoriskt transportprotokoll.

Segment upprepas med kända intervall och beter sig som virtuella bussar med sin egen bandbreddsgaranti och latens.

Ett segment, som visas nedan i figur 5, har TAG (2 platser), AUX (2 platser) och DATA-fält. Fälten TAG och AUX är valfria. Om de används bär TAG-bitarna flödesstyrningsinformation för datakanalen, medan hjälpbitarna (AUX) bär sidoinformation som hänför sig till innehållet i DATA-fältet. Datanyttolasten kan fylla hela det tilldelade DATA-fältet eller inte.

Segment Organization

Figur 5: Segmentorganisation

Datakanalstransportprotokoll och flödeskontroll

En datakanal har exakt en datakälla åt gången och kan ha en eller flera datasänkor beroende på vilket transportprotokoll som används i kanalen.

Flödeskontroll i kanalen, om det behövs, beror på enheterna och typen av data som är involverade. TAG-bitar används för att bära flödeskontrollinformationen.

SLIMbus-enhetsportar är associerade med datakanaler med hjälp av lämplig kanalanslutning och frånkopplingsmeddelanden. För dataflöde mellan portar kopplade till kanaler, stöder SLIMbus en liten grupp av ofta använda transportprotokoll (inklusive ett användardefinierat transportprotokoll) som definierar dataflödestyp, flödeskontrollmekanism och en sidokanal (om någon) för ytterligare applikationer -specifik information. En sammanfattning av transportprotokollen visas i tabell 1.

TP Protokollnamn Typ Antal TAG-fältplatser
0 Isokron Multicast 0
1 Tryckte Multicast 1
2 Drog Unicast 1
3 Låst Multicast 0
4 Asynkron – Simplex Unicast 1
5 Asynkron – Halvduplex Unicast 1
6 Utökad Asynkron – Simplex Unicast 2
7 Utökad asynkron – halv duplex Unicast 2
8 till 13 Reserverad - -
14 Användardefinierad 1 - 1
15 Användardefinierad 2 - 2
Tabell 1: SLIMbus-stödda transportprotokoll

User 1 & 2 protokoll används för att utöka SLIMbus dataöverföringsmekanismer och det antas att en Device ansluten till en User Protocol Data Channel känner till definitionen av TAG- och AUX-bitarna och hur de används.

SLIMbus system

Ett SLIMbus-system endast i illustrativt syfte visas i figur 7 nedan. Alla komponenter är olika från varandra. Observera att den övre vänstra SLIMbus-komponenten i detta exempel innehåller en Framer Device (F), och därför är CLK-signalen för denna komponent dubbelriktad.

Den övre vänstra SLIMbus-komponenten innehåller också en Manager Device (M). Det finns dock inget krav på att Manager och Framer-enheter ska vara i samma SLIMbus-komponent.

An Illustrative SLIMbus System

Figur 7: Ett illustrativt SLIMbus-system

Manager- och/eller Framer-enheten som visas i den övre vänstra SLIMbus-komponenten kan också integreras i basbands- och/eller applikationsprocessorer som vanligtvis används för att bygga mobila terminaler.

Figur 8 nedan visar en konceptuell vy av ett möjligt verkligt SLIMbus-system. "M" och "F" representerar Manager- och Framer-enheterna. Alternativt kan multi-mic-arrayen ersätta den enda mikrofonen i systemet. Vilken blandning av ljudrelaterade block som helst kan bifogas.

SLIMbus System

Figur 8: Konceptuellt SLIMbus-system

externa länkar

En ofullständig lista över SLIMbus-implementeringsinformation finns på följande:

Pressbevakning