Jump to content

SLIMbus: Difference between revisions

Add links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Kdboyce (talk | contribs)
476 edits
No edit summary
Monkbot (talk | contribs)
Bots
3,695,952 edits
m Task 18 (cosmetic): eval 8 templates: hyphenate params (7×);
 
(469 intermediate revisions by 48 users not shown)
Line 1: Line 1:
{{multiple issues|{{more footnotes|date=January 2013}}
This article is not a substitute for any part of the SLIMbus<sup>SM</sup> Specification. For a complete description of operational capabilities for SLIMbus<sup>SM</sup>, please use the SLIMbus<sup>SM</sup> Specification which is available to Mobile Industry Processor Interface (MIPI) Alliance members through the MIPI Alliance, Inc.<br />
{{more citations needed|date=January 2013}}}}


The '''Serial Low-power Inter-chip Media Bus''' ('''SLIMbus''') is a standard interface between baseband or application processors and peripheral components in mobile terminals. It was developed within the [[MIPI Alliance]], founded by [[Arm Holdings|ARM]], [[Nokia]], [[STMicroelectronics]] and [[Texas Instruments]].<ref name=merritt>{{cite web|last=Merritt|first=Rick|title=Mobile chip interface gets real|url=http://eetimes.com/electronics-news/4058490/Mobile-chip-interface-gets-real|work=EETimes|access-date=17 January 2013|date=13 February 2006}}</ref> The interface supports many [[digital audio]] components simultaneously, and carries multiple digital audio data streams at differing sample rates and bit widths.
<center>MIPI Alliance, Inc.
c/o IEEE-ISTO
445 Hoes Lane
Piscataway, NJ 08854
http://www.mipi.org</center>


SLIMbus is implemented as a synchronous 2-wire, configurable [[Time-division multiplexing|Time Division Multiplexed]] (TDM) frame structure. It has supporting bus arbitration mechanisms and message structures which permit re-configuring the bus operational characteristics to system application needs at runtime. Physically, the data line (DATA) and the clock line (CLK) interconnect multiple SLIMbus components in a [[Multidrop bus|multi-drop bus]] topology. SLIMbus devices may dynamically “drop off” the bus and “reconnect” to the bus as required by using appropriate protocols outlined in the SLIMbus specification. When used in a mobile terminal or portable product, SLIMbus may replace legacy digital audio interfaces such as [[Pulse-code modulation|PCM]], [[I²S|I<sup>2</sup>S]],<ref>{{cite web|title=I2S bus specification|url=http://www.classic.nxp.com/acrobat_download2/various/I2SBUS.pdf|publisher=Philips Semiconductors|access-date=17 January 2013}}</ref> and [[Synchronous Serial Interface|SSI]] (Synchronous Serial Interface for digital audio), as well as some instances of many digital control buses such as I<sup>2</sup>C,<ref>{{cite web|title=The I2C-Bus Specification|url=http://www.classic.nxp.com/acrobat_download2/literature/9398/39340011.pdf|publisher=Philips Semiconductors|access-date=17 January 2013|date=January 2000}}</ref> SPI, [[Serial Peripheral Interface|microWire]],<ref>{{cite web|title=AN-452 MICROWIRE Serial Interface|url=http://www.ti.com/lit/an/snoa743/snoa743.pdf|publisher=Texas Instruments|access-date=17 January 2013}}</ref> [[Universal asynchronous receiver-transmitter|UART]], or [[General-purpose input/output|GPIO]] pins on the digital audio components.
The content of this article is largely based on the document "An Introduction to the Mobile Industry Processor Interface (MIPI) Alliance Standard Serial Low-power Inter-chip Media Bus (SLIMbus<sup>TM</sup>)" published by Kenneth Boyce of National Semiconductor, Inc., and is used herein with permission from National Semiconductor, Inc. The original document was published with the approval of the MIPI Alliance Board of Directors, and can found in its complete form in the MIPI Alliance here <ref>Introduction to SLIMbus : https://members.mipi.org/mipi-lml/file/An%20Introduction%20To%20SLIMbus_MIPI_COPY.pdf (MIPI Member login required)</ref> and at National Semiconductor here<ref>National Semiconductor SLIMbus article: http://www.national.com/appinfo/audio/files/intro_to_SLIMbus.pdf#page=1</ref>.


== History ==


*The [[MIPI Alliance]] was formed in fall of 2003.
== '''Introduction''' ==
* Interface architecture including a low speed media link bus (LowML) presented at the F2F meeting of MIPI Alliance in [[Sophia Antipolis]], France in March, 2004.
* LML Investigation Group (LML-IG) created in July 2004 by the MIPI Alliance. First meeting was a teleconference on August 3, 2004.
* LML Working Group (LML-WG) created in Q4 2004. LML WG Charter submitted to the MIPI Board in December, 2004.
*First meeting as a full Working Group on April 12, 2005.
* LML-WG released first draft of SLIMbus with text in all chapters (v0.55) on October 18, 2005.
* SLIMbus specification v1.00 was released to adopters on May 16, 2007.
* From June 2007 to June 2008, SLIMbus specification improvement (ambiguities, typos & bugs fixed) based on implementer feed-back.
* SLIMbus specification V1.01 was released to adopters on December 3, 2008 and is recommended for implementation.


== SLIMbus Devices and Device Classes ==


SLIMbus Device Class definitions are those which specify the minimum requirements for Device control data, Device behavior, and data Transport Protocol support. There are four SLIMbus Device Classes defined at the release of Version 1.01 of the SLIMbus specification: Manager, Framer, Interface, and Generic. Complete SLIMbus systems can be implemented without any additional Device Classes.
The Serial Low-power Inter-chip Media Bus (SLIMbus<sup>SM</sup>) is a standard interface between baseband or application processors and peripheral components in mobile terminals, and was developed within the MIPI Alliance by a dedicated group of MIPI member companies.


===Manager Device===
SLIMbus<sup>SM</sup> is a salesmark of MIPI Alliance, Inc.


The Manager Device is responsible for configuring SLIMbus, and performs bus administration (administration of Components and Devices, bus configuration, and dynamic channel allocation) and is typically located in a baseband or application processor rather than in a peripheral component.
SLIMbus development was driven by the increased demand for multimedia functions within mobile terminals and other portable entertainment devices, as well as the recognition that high quality digital audio is a major driver of unit growth and product differentiation.


===Framer Device===
SLIMbus addresses limitations of existing digital audio interfaces such as I2S <ref>I2S: Specification URL: http://www.nxp.com/acrobat_download/various/I2SBUS.pdf</ref> and PCM (which are primarily point-to-point connections between single components and support only one or two digital audio channels) by providing a scalable multi-drop architecture supporting many components and digital audio channels on a single bus structure.


The Framer delivers a [[clock signal]] on the CLK line to all SLIMbus Components, and also contains logic to transmit the Frame Sync and Framing Information channels on the DATA line.
For even greater flexibility and simplicity, SLIMbus eliminates the need for a separate control bus such as I2C (http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf), SPI (http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus), microWire™ (http://www.national.com/an/AN/AN-452.pdf#page=1), UART or GPIO pins on the digital audio components. Additionally, it may also reduce (or eliminate) instances of these bus structures on other types of low bandwidth components within the mobile terminal.


===Interface Device===
SLIMbus is implemented by a synchronous 2-wire, flexible TDM frame structure and surrounding bus arbitration mechanisms and message structures, which taken together establish flexible and robust data connections between SLIMbus Devices.
Although optimized for the transport of constant-rate media streams, SLIMbus can transport various types of asynchronous data as well as control data.


The Interface Device provides bus management services, monitors the Physical Layer for errors, reports information about the status of a SLIMbus Component, and otherwise manages the Component such that the Devices within it will function properly on the bus.
Most company participants in the development of the SLIMbus Specification have SLIMbus compatible product development underway. A list of participants may be found at: http://www.mipi.org/mcurrentmembers.asp.


To implement a functional SLIMbus component always requires the use of a SLIMbus Interface Device, plus the function to be performed, such as DAC, ADC, [[Class-D amplifier|digital amplifier]], and so on.
== '''SLIMbus Physical Description''' ==


===Generic Device (Function)===


A Generic Device is a Device other than a Manager, Framer, or Interface. A Generic Device is generally considered to be the device to provide certain application functionality, for example, conversion from digital audio to analog (DAC) and vice versa (ADC).
Physically, SLIMbus consists of two (2) terminals, the data line (DATA) and the clock line (CLK) which are used to interconnect multiple SLIMbus Devices.
SLIMbus uses a multidrop bus topology where all bus signals are common to all components on the bus. As such, all devices on the bus must use the same protocol for communication. This architecture was chosen as it significantly reduces bus interconnect wiring in any product using it, while at the same time allowing a multiplicity of devices and device types to be connected to the bus.


== SLIMbus Component ==
A multidrop connection requires that only one transmitter device communicate at any given time on the bus to one or more receivers. SLIMbus devices contend for the bus access through an arbitration procedure.


A SLIMbus Component contains two or more SLIMbus Devices. A SLIMbus Component will have only one SLIMbus Interface Device (INTERFACE), and may have one or more other types of SLIMbus devices which perform a particular function (FUNCTION).
SLIMbus uses a Time Division Multiplexed (TDM) architecture which allows multiple receiver and transmitter devices to reside on the bus and allows all devices to inter-communicate within allocated channels and time frames. SLIMbus supports both device to device communication as well as single device to multiple device broadcast communication.


A SLIMbus Port (P) provides the connection path for data flow between Devices. SLIMbus Ports are normally used for digital audio data flow, but may also be used for other digital data flow.
SLIMbus is not designed for hot-swap capability since the intended use is completely within a client terminal such as a cellular phone. However, SLIMbus devices may dynamically “drop off” the bus and “reconnect” to the bus as dictated by system usage requirements using appropriate protocols outlined in the SLIMbus specification.


Port capabilities vary depending upon the Device and are to be specified in the Component data sheet. Typical Port attributes include data direction, i.e. input-only (sink), output-only (source) or both input and output, supported Transport Protocols, and data width.


A simple SLIMbus Component example is shown in Figure 1 below, and a complex SLIMbus Component example is shown in Figure 2 below.
== '''SLIMbus Devices and Device Classes''' ==


{{center|
A SLIMbus Device is a logical implementation of a system function.
[[File:SLIMbusSimpleComponent.jpg|Simple SLIMbus Component]]
Devices in a Device Class category share certain characteristics and functions. SLIMbus Devices fall into Device Class definitions which specifies the minimum requirements for Device control information, Device behavior, data Transport Protocol support, and data storage necessary to implement a Device of that Device Class.
{{center|Figure 1: Simple SLIMbus Component}}
}}


{{center|
Requirements for all Device Classes are:
[[File:SLIMbusComplexComponent.jpg|Complex SLIMbus Component]]
{{center|Figure 2: Complex SLIMbus Component}}
}}


== SLIMbus DATA and CLK==
• The Device Class code, identifying the type of Device<br />
• The version number of the Device Class<br />
• Transport support requirements, e.g. the number of Ports and required attributes, directionality, and Transport Protocols, etc., that are supported by these Ports<br />
• Message support requirements, identifying which Messages in addition to Core Messages are supported by the Device.<br />
• Information support, identifying the Core Information Elements and associated codes that are supported by the Device.<br />
• Operation requirements, identifying all other behavior that is important to the operation of a Device that belongs to that Device Class.<br />


All SLIMbus Devices use DATA and CLK to synchronize with the bus configuration in use, to receive or transmit messages and data, and to implement bus arbitration, [[collision detection]], and contention resolution between devices.


For all SLIMbus Components (except one containing a Framer Device), the CLK terminal is input only. If a SLIMbus Component is the Framer Device, or contains a Framer Device, the CLK signal is bi-directional.
There are four (4) SLIMbus Device Classes defined at the release of Version 1.0 of the SLIMbus specification: Manager, Framer, Interface, and Generic. These Device Classes permit complete SLIMbus systems to be designed and implemented without any additional Device Classes. However, the set of Device Classes is expandable if desired. When additional Device Classes are defined, those Device Class codes will be allocated by the MIPI Alliance.


For all SLIMbus Components, the DATA line is bidirectional, and carries all information sent or received on the bus using [[Non-return-to-zero|Non-Return-to-Zero Inverted]] (NRZI) encoding.


The DATA line is driven on the positive edge and read on the negative edge of the CLK line. The DATA line can be driven high, driven low, or held at the high or low level by an internal [[bus-holder]] circuit, depending upon the particular operational mode of a SLIMbus Device.
== '''Manager Device''' ==


The SLIMbus interface DATA and CLK lines use [[CMOS]]-like single-ended, ground referenced, rail-to-rail, voltage mode signals, and signaling voltages are specified with respect to the interface supply voltage (+1.8Vdd or +1.2Vdd are permitted). For EMI performance reasons, slew rate limits have been specified for SLIMbus.


===SLIMbus Clock Frequencies and Gears===
A Manager Device is responsible for booting SLIMbus, and performs bus administration (enumeration of Components and Devices, bus configuration, and dynamic channel allocation).


The SLIMbus CLK line frequency is determined by a range of "Root" clock frequencies up to 28&nbsp;MHz, and 10 Clock Gears for altering the clock frequency by powers of 2 over a span of 512x from lowest to highest Gear. The Root Frequency is defined as 2<sup>(10-G)</sup> times the frequency of the CLK line. For G=10, the CLK line frequency and Root Frequency are equal.
In a typical SLIMbus system the Manager would be located in a baseband or application processor rather than in a peripheral component.
If a system contains two (2) Managers, only one is allowed to be active at any given time.


The SLIMbus CLK may also be stopped and restarted.


SLIMbus CLK frequencies and data transport protocols will support all common digital audio converter over-sampling frequencies and associated sample rates.
== '''Framer Device''' ==


== Cells, Slots, Subframes, Frames, and Superframes ==
The Framer delivers a clock signal on the CLK line to all SLIMbus Components, and also contains logic to transmit the Guide and Framing Channels (Framing Information) on the DATA line in order to establish the various possible TDM Frame Structure options of the bus and communicate that information to other SLIMbus Devices for establishing synchronization.


The SLIMbus Frame Structure has five building blocks: Cells, Slots, Frames, Subframes, and Superframes.
The SLIMbus clock may be a high quality clock useful for audio decoding and DACs or may be derived from other clock sources within the system.


===Cell===
== '''Interface Device''' ==


A Cell is defined as a region of the DATA signal that is bounded by two consecutive positive edges of the CLK line and holds a single bit of information.


{{center|
In each Component the Interface Device provides bus management services, controls the Frame Layer, monitors Message Protocols implemented by the Component, reports information about the status of the Component, and otherwise manages the Component such that the Devices within it will function properly on the bus.
[[File:SLIMbusCell.jpg|Cell Structure]]
{{center|Figure 3: Cell Structure}}
}}


===Slot===
== '''Generic Device (Function)''' ==


A Slot is defined as four contiguous Cells (4-bits transmitted in MSB to LSB order). Bandwidth allocation for various data organizations, from 4-bits to 32-bits or more, can be done by grouping 4-bit Slots.


===Frame===
A Generic Device is a Device other than a Manager, Framer, or Interface. A Generic Device is generally considered to be the device to provide certain application functionality, for example, conversion from digital audio to analog (DAC) and vice versa (ADC). For this reason, Generic Devices are labeled “Function Device” in block diagrams in this article.


A Frame is defined as 192 (0 through 191) contiguous Slots and are transmitted as S0, followed by S1, S2 ... S191 in that order. The first Slot (Slot 0) of each Frame is a Control Space slot which contains the four (4) bit Frame Sync symbol. Slot S96 of each Frame is also a Control Space slot which contains four (4) bits of Framing Information.
The Generic Device Class is used if no other specific device class for the application functionality exists. As an example, if a Microphone Device Class existed you would not ordinarily use a Generic Device class definition for microphone functionality.


The active Framer writes all Framing Information to the Data line at the appropriate time.
To implement a Functional SLIMbus Device also requires the use of a SLIMbus Interface Device, and the associated Enumeration and Logical Addresses (EA and LA), Information and Value Elements (IE and VE), and Ports (P) of each device, which are used to establish bus connections, control and status information flow, and digital audio (or other data) flow.


===Subframe===
Figure 1 below is an example showing a partial section of an Interface Device and a partial section of a Function Device and associated elements. Further detail is shown in Figure 2 in the SLIMbus Components section below.
'''Figure 1: Partial Sections of SLIMbus Interface Device and Function Device'''


A Subframe is defined as the division of the Frame Structure at which Control Space and Data Space are [[Forward error correction|interleaved]]. A Subframe is partitioned into 1 or more slots of Control Space, followed by 0 or more slots of Data Space.
== '''Device Information and Value Elements''' ==


As shown in Figure 4 below, the Subframe length is programmable to 6, 8, 24 or 32 contiguous Slots (24, 32, 96 or 128 Cells). The number of possible Subframes per Frame is therefore 32, 24, 8, or 6 respectively. The Subframe configuration used can be dynamically changed depending upon the data flow requirements of the applications being supported at the time.


{{center|
Information Elements (IE) and Value Elements (VE) are data storage elements used to hold status, configuration or other important information needed by a Device. The data stored may be Boolean in nature, or may have many values, depending upon the type of Device.
[[File:SLIMbusCellSlotFrameStructure.jpg|Cell, Slot, Subframe, Frame Structure]]
{{center|Figure 4: Cell, Slot, Subframe, Frame Structure}}
}}


4 of the Control space slots are reserved for a frame sync symbol, 4 bits if a Framing Information word, and 8 bits of Guide Byte. The remainder is available for more general control messages.
These IE and VE elements effectively replace registers typically found behind conventional control interfaces such as I2C or SPI.


Any Slots not allocated to Control Space are considered Data Space.
An Information Element is a specific piece of data that resides in a Device, and is available to other Devices via Messages. Categories of Information Elements are:


===Superframe===
• Core - Information Elements which are the same for all Devices of all Device Classes<br />
• Device Class-specific - Information Elements which are the same for all Devices of a particular Device Classe, but which may be different for all Devices of a different Device Class<br />
• User - Information Elements which are specific to a particular product or product family<br />


A Superframe is defined as eight contiguous Frames (1536 Slots). Frames within a Superframe are labeled Frame 0 through Frame 7.
A Value Element provides a standardized method to read and update Device parameters. Unlike an Information Element, a Value Element can be set to a specific value using a specific Message for the purpose.


The duration of a Superframe is fixed in terms of Slots (and, therefore, Cells), but not in terms of time. The Superframe rate can be dynamically changed on SLIMbus to suit the particular application by changing either SLIMbus Root Frequency or Clock Gear, or both.


== '''Device Addressing''' ==
== Channels ==


Information on the SLIMbus DATA line is allocated to Control Space and Data Space channels.


The Control Space carries bus configuration and synchronization information as well as inter-Device Message communication. The Control Space may be dynamically programmed to take as much of the SLIMbus bandwidth as required, even up to 100% at times.
SLIMbus uses a 48-bit Enumeration Addresses (EA) to uniquely identify Devices which can announce their presence on the bus. Each Device has an EA which incorporates Manufacturer ID, Product Code, Device Index, and Instance Value for a Device. The Manufacturer ID code is supplied by the MIPI Alliance and uniquely identifies the manufacturer of the Device, similar to the manufacturer ID’s used with PCI bus components. The Device Index code uniquely identifies multiple Devices within a single Component. The Instance Value code is for the case where multiple Devices of the same type or Class are attached to the bus.


Data Space, when present, carries application-specific information such as [[Isochronous timing|isochronous]] and [[Data transmission|asynchronous data]] streams.
After enumeration, the Active Manager assigns an 8-bit Logical Address to Device (LA) which speeds up communication with devices, and is typically used until the bus is powered down. On the next bus power up, or if the Device drops off the bus and re-connects, it is entirely possible that a new Logical Address is assigned.


SLIMbus Components convey control and data information between each other using Control and Data Channels with Transport Protocols to achieve the required system operation. Messages are used for Control functions.


Channels can be established between a pair of Devices (inter-Device communication), or between one Device and many Devices (broadcast communication), or in the case of the Message Channel, from all devices to all other devices (shared).
== '''Ports''' ==


===Control Channels===


Control Space is divided into three types of channels: Framing, Guide, and Message.
A Port provides the connection path to data flow between Devices. A particular Device may have up to sixty-four Ports.


The Framing Channel occupies Slots 0 and 96 of each Frame. (Since all Subframe lengths divide 96, these Slots are always available for the purpose.) Slot 0 holds a fixed Frame Sync symbol (1011<sub>2</sub>), while Slot 96 holds 4 bits of a Framing Information word. Over the course of a Superframe, 32 bits of Framing Information are available. Some of these hold a fixed bit pattern used to acquire Superframe synchronization (0''x''011''xxx''<sub>2</sub>), while the others hold other critical configuration information.
Port capabilities vary depending upon the Device and are to be specified in the Component data sheet. Typical Port attributes include data directionality, i.e. input-only (sink), output-only (source), or both input and output; supported Transport Protocols; and data width. For example, the Port attributes for a MEMS microphone could be output-only, Isochronous Transport Protocol and 16-bit data width.


The Guide Channel consists of the first 2 non-Framing control Slots in each Superframe. This "guide byte" is normally 0, but if a control message straddles a Superframe boundary, it indicates the number of bytes until the end of that message.
A Port status moves through states prior to being used for data transfer.
The power on, or reset, condition of a Port is in the Disconnected state, and the Port does not produce or consume any data.


The Message Channel consists of all remaining Slots. It carries various types of information including bus configuration announcements, Device control and Device status.
When the Port is connected to a Data Channel, it moves to the Unconfigured state and also does not produce or consume any data.


The format of Control Space is determined by a 5-bit Subframe mode identifier transmitted in the Framing Information word. This communicates the Subframe length and the number of control Slots. The number of control Slots is limited to the choices of 1, 2, 3, 4, 6, 8, 12, 16, or 24. Adding the limitations that the number of control Slots must be less than the Subframe length produces 26 valid combinations. A special encoding for "100% Control Space", in which case the Subframe length is unimportant, produces 27 valid modes. (Modes 1–3, 20 and 30 are not valid.)
Once in the Unconfigured state, the Port receives channel configuration Messages and acts on them accordingly.


===Data Channels===
After receiving all necessary configuration parameters, the Port state changes to the Configured state, and the Port is now ready for data transport.


Data Channels are one or more contiguous Data Slots (Segments) and are dynamically created by the active Manager depending on the application and size of Data Space available. A Data Channel, and therefore the structure of a Segment, is defined by parameters such as Data rate, type, field length, and required Transport Protocol.


Segments repeat at known intervals and behave as virtual bus's with their own bandwidth guarantee and latency.
== '''SLIMbus Component''' ==


A Segment, shown below in Figure 5, has TAG (2 Slots), AUX (2 Slots), and DATA fields. The TAG and AUX fields are optional. If used, the TAG bits carry flow control information for the data channel, while the auxiliary (AUX) bits carry side information relating to the content of the DATA field. The data payload may or may not fill the entire allotted DATA field.


{{center|
A SLIMbus Component contains two or more SLIMbus Devices. A SLIMbus Component will generally have only one SLIMbus Interface Device, and may have one or more other types of SLIMbus devices.
[[File:SLIMbusSegmentOrganization.jpg|Segment Organization]]

{{center|Figure 5: Segment Organization}}
In the case of a multiple chip(die)in one package solution, it could be possible to have more than one SLIMbus Interface Device. In that case, externally, any separate CLOCK lines would be tied together, and any separate DATA lines would be tied together.
}}

A simple SLIMbus Component example is shown in Figure 2 below, and a complex SLIMbus Component example is shown in Figure 3 below.

'''Figure 2: Simple SLIMbus Component'''

'''Figure 3: Complex SLIMbus Component'''

As shown in the Figure 3, Data and Control information sent from a Device are first encoded using the Message Protocol for control information and the Transport Protocol for data. The data and control streams are interleaved by the Frame Layer and converted by the Physical Layer into electrical signals on the DATA line, and sent out a bit at a time during each clock cycle.

In the opposite direction, the signals on the CLK and DATA lines are translated by the Physical Layer into a bit stream, which is then split into Data and Control streams by the Frame Layer, which, in turn, are decoded by the corresponding protocols and sent to the appropriate Devices within the Component.

== '''SLIMbus DATA and CLK''' ==


The DATA and CLK lines are typically attached to two (2) or more SLIMbus Devices contained in one or more SLIMbus Components to form a SLIMbus system.
All SLIMbus Devices use DATA and CLK to synchronize with the bus configuration in use, to receive or transmit messages and data, and to implement bus arbitration, collision detection, and contention resolution between devices.
For all SLIMbus Components (except one containing a Framer Device), the CLK terminal is input only.

If a SLIMbus Component is the Framer Device, or contains a Framer Device, the CLK signal is bi-directional. This is because the Framer Device is the only SLIMbus device allowed to control the CLK line. The CLK line has only two states; driven high or driven low. The Component that contains the active Framer is called the Clock Source Component.

For all SLIMbus Components, the DATA line is bidirectional, and carries all information sent or received on the bus using Non-Return-to-Zero Inverted, or NRZI encoding. The DATA line is driven on the positive edge and read on the negative edge of the CLK line. The DATA line can be driven high, driven low, or held at the high or low level, depending upon the particular operational mode of a SLIMbus Device.

The SLIMbus interface DATA and CLK lines use CMOS-like single-ended, ground referenced, rail-to-rail, voltage mode signals, and signaling voltages are specified with respect to the interface supply voltage.
In the SLIMbus specification, interface supply voltages +1.8Vdd and +1.2Vdd are recommended even though other parts of a SLIMbus device may use different supply voltages.


== '''SLIMbus System''' ==


A possible SLIMbus system for illustrative purposes only is shown in Figure 4 below. All of the Components are different from each other. Note that the upper left SLIMbus Component in this example contains a Framer Device, and therefore the CLK signal for this component is bidirectional.
The upper left SLIMbus Component also contains a Manager Device. However, there is no requirement that the Manager and the Framer Devices be in the same SLIMbus Component.

'''Figure 4: An Illustrative SLIMbus System'''

All of the elements shown in the upper left SLIMbus Component can also be incorporated into baseband and/or applications processors (Figure 5) typically used to build mobile terminals.

'''Figure 5: SLIMbus System with Manager and Framer in Processor'''



== '''SLIMbus Model and Operational Description''' ==


A SLIMbus system model consists of a set of SLIMbus Devices in Components communicating with each other using a shared data (DATA) line, and common clock (CLK) signal.

Information on the SLIMbus DATA line is allocated to Control Space and Data Space channels.

The Control Space carries bus configuration and synchronization information as well as inter-Device Message communication. The Control Space may be dynamically programmed to take as much of the SLIMbus bandwidth as required, even up to 100% at times.

Data Space, when present, carries application-specific information such as isochronous, near-isochronous and asynchronous data streams.

SLIMbus Component Devices convey control and data information between each other using Control and Data Channels with Transport Protocols to achieve the required system operation. Messages are used for Control functions. Transport Protocols handle both Control data and Application data flow types.


== '''Channels''' ==


Channels can be established between a pair of Devices (inter-Device communication), or between one Device and many Devices (broadcast communication).


== '''Control Channels''' ==

Control Space or Control Channels are actually three (3) different types of channels: Framing, Guide, and Message, with each one having a specific purpose.
The Framing Channel carries Frame Sync symbol and Framing Information in two (2) Slots of each Frame which conveys bus configuration parameters so that all Components can properly synchronize to the bus configuration being used at the time. Flow control is not available. The channel width is fixed.

The Guide Channel is carried in one (1) Slot for the first and second Frame of a Superframe, and provides the necessary information for a Component to acquire and verify Message synchronization in the Message Channel. Flow control is not available. The channel width is fixed.

The Message Channel carries various types of information including bus configuration, Device control and Device status. Flow control is implemented by an acknowledgment symbol. Channel width is programmable.


== '''Data Channels''' ==


Any SLIMbus bandwidth not allocated to Control Space is available for Data Space (Data Channels). Data Space is composed of one or more Data Channels that are dynamically created by the active Manager depending on the application. The number of Data Channels depends on the size of Data Space and type of data streams carried by the channels. Data Space can contain up to 256 Data Channels.

A Data Channel is a stream of one or more contiguous Data Slots that repeats at a fixed interval. The group of contiguous Slots within a Data Channel is known as a Segment. Because Segments repeat at known intervals relative to Superframe boundaries, Data Channels can be viewed as a virtual bus with their own bandwidth guarantee and latency.

A Segment is composed of three fields called the TAG, AUX, and DATA fields. Note the TAG and AUX fields are optional and may be omitted. These fields are organized within the Segment as shown in Figure 6.
'''Figure 6 Segment Organization'''

The TAG bits carry flow control information if any is needed for the data channel.
The auxiliary (AUX) bits carry side information linked to the content of the DATA field.

The exact composition of the Segment depends on the Transport Protocol being used for the Data Channel.
The active Manager initializes a Data Channel and communicates the related content parameters to all Devices using that Data Channel.

A Data Channel is additionally defined by the parameters; Channel Definition and Content Definition, where each Definition contains a number of other parameters such as, but not limited to, Data rate, type, and field length, active/non-active status, and Transport Protocol to use. Thus, information needed to use the Channel is completely described and is made available to all Devices involved in using a particular Data Channel.
Figure 7 below shows a conceptual view of a SLIMbus system.


'''Figure 7: SLIMbus Model Representation'''


== '''Data Channel Transport Protocols and Flow Control''' ==

Information carried by a Data Channel is application specific and many different data formats can co-exist.
SLIMbus not directly support various data formats. Instead, to transport any data format, a small group of frequently used Transport Protocols (including a User Defined Transport Protocol) are specified which define data flow type, flow control mechanism, and a side-channel (if any) for any additional application-specific information.

Data flow between Ports is by one of several Transport Protocols.
SLIMbus Device Ports are associated with channels using appropriate channel connection and dis-connection Messages.
Transport Protocols are either Uni-cast or Multi-cast types. The types of Transport Protocols defined in SLIMbus are summarized in Table 1 below.

Isochronous (Multi-cast) Pushed (Multi-cast) Pulled
Asynchronous - Simplex Asynchronous – Half duplex Extended Asynchronous - Simplex
Extended Asynchronous – Half duplex Locked (Multi-cast) User Defined 1 & 2


'''TABLE 1: SLIMbus Supported Transport Protocols'''


== Data Channel Transport Protocols and Flow Control==


A Data Channel has exactly one data source at a time and may have one or more data sinks depending upon the Transport Protocol used in the channel.
A Data Channel has exactly one data source at a time and may have one or more data sinks depending upon the Transport Protocol used in the channel.
Flow Control in the Channel, if needed, depends on the Devices and the type of Data involved. TAG bits are used to carry the flow control information.

No flow control is needed if the frequency of the CLK line is an integer multiple of the data flow rate. Therefore, the Isochronous Transport Protocol can be used.
If flow control is needed, one of the two supported styles of flow control needs to be selected: Single-ended, or Double-ended flow control.

Single-ended data flows are regulated by a shared algorithm (for the Locked Protocol), or by the use of a ‘Presence’ bit (for the Pulled and Pushed Protocol respectively). These protocols are designed to optimally carry constant rate media streams (such as LPCM audio) where the actual control method used for a flow depends on the bus Root Frequency, as well as the characteristics of the flow.
When the Pushed protocol is used to carry data whose rate is equal to, or lower than, the channel rate, the source Device drives the data flow and the TAG bits indicate availability of data in the DATA field. A Pushed Protocol Data Channel can be connected to multiple sinks (multicast) since there is no feedback from the sinks.

When the Pulled Transport Protocol is used, the sink Device requests, or pulls, data from the source Device when needed and the TAG bits indicate availability of data in the DATA field.

With double-ended handshaking, either Device involved in the data transfer can stop or start the transfer using two or more flow control bits in every Data Segment’s TAG field. The four Asynchronous Transport Protocols all use this type of flow control. These Transport Protocols have been designed to optimally support asynchronous data flow.

The Extended Asynchronous Protocols have 2 TAG fields plus a DATA field size that can range from 2 to 28 Slots inclusive by increments of 2 Slots, and is used when the channel rate is low and the data rate is high.

User 1 & 2 protocols are used to extend SLIMbus's data transmission mechanisms and it is assumed that a Device connected to a User Protocol Data Channel knows the definition of the TAG and AUX bits and how they are used. For example, a User Protocol could be created to support SPDIF (IEC 60958) digital audio data flows on SLIMbus.


== '''SLIMbus Frame Structure''' ==


SLIMbus uses a synchronous, two-wire bus to carry information between Devices. The SLIMbus bit stream is organized in a Time Domain Multiplexed (TDM) configuration. The organization of information on the bus is called the Frame Structure.
As stated before, SLIMbus Control Space and Data Space information is transported in channels, with each channel representing a particular information flow. The bandwidth used by the Control Space and Data Space is configurable so that the bus can be adapted to virtually any application.


== '''Cells, Slots, Subframes, Frames, and Superframes''' ==


The Frame Structure has five building blocks: Cells, Slots, Frames, Subframes, and Superframes.

'''Cell'''

The smallest subdivision of a SLIMbus data flow is the Cell. A Cell is defined as a region of the DATA signal that is bounded by two consecutive positive edges of the CLK line. Each Cell can hold a single bit of information.

'''Slot'''

A Slot is defined as four contiguous Cells (4-bits) and is the unit of bandwidth allocation on SLIMbus. Cells within a Slot are labeled C0 through C3, and are transmitted in MSB to LSB order. A variety of data bit sizes, from 4-bits to 32-bits or more, can be easily accommodated by groups of 4-bit Slots.

'''Frame'''

A Frame is defined as 192 contiguous Slots. Slots within a Frame are labeled S0 through S191, and are transmitted as S0, followed by S1, S2 … S191 in that order.
The first Slot (Slot 0) of each Frame is a Control Space slot which contains the four (4) bit Frame Sync symbol. Slot S96 of each Frame is also a Control Space slot which contains four (4) bits of Framing Information.

A Component uses the Frame Sync data and 32 bits of Framing Information to synchronize to the bus. Therefore, to receive all 32 bits of the Framing Information, data must be read from eight (8) successive Frames, called a Superframe. See description below.

Included in the Framing Information is an encoded Whitening Signal which is used to reduce the autocorrelation properties and electromagnetic spectrum of the data.


Flow Control in the Channel, if needed, depends on the Devices and the type of Data involved. TAG bits are used to carry the flow control information.
Additionally, the Framing Information also contains a 25 Hz timing reference signal, which is the highest common factor of many common audio sample rates.
Further discussion of the creation and use of the Whitening Signal or the 25 Hz timing reference signal is beyond the scope of this article.
SLIMbus Device Ports are associated with Data Channels using appropriate channel connection and dis-connection Messages. For data flow between Ports attached to Channels, SLIMbus supports a small group of frequently used Transport Protocols (including a User Defined Transport Protocol) which define data flow type, flow control mechanism, and a side-channel (if any) for any additional application-specific information. A summary of the Transport Protocols is shown in Table 1.
The active Framer writes all Framing Information to the Data line at the appropriate time.


<div style="float:left; position:relative; left:50%"><div style="float:left; position:relative; left:-50%">
'''Subframe'''
{| class="wikitable"
|-
! |TP
! |Protocol Name
! |Type
! |# of TAG field Slots
|-
| |0
| |Isochronous
| |Multicast
| style="text-align:center" |0
|-
| |1
| |Pushed
| |Multicast
| style="text-align:center" |1
|-
| |2
| |Pulled
| |Unicast
| style="text-align:center" |1
|-
| |3
| |Locked
| |Multicast
| style="text-align:center" |0
|-
| |4
| |Asynchronous – Simplex
| |Unicast
| style="text-align:center" |1
|-
| |5
| |Asynchronous – Half-duplex
| |Unicast
| style="text-align:center" |1
|-
| |6
| |Extended Asynchronous – Simplex
| |Unicast
| style="text-align:center" |2
|-
| |7
| |Extended Asynchronous – Half duplex
| |Unicast
| style="text-align:center" |2
|-
| |8 to 13
| |Reserved
| style="text-align:center" |-
| style="text-align:center" |-
|-
| |14
| |User Defined 1
| style="text-align:center" |-
| style="text-align:center" |1
|-
| |15
| |User Defined 2
| style="text-align:center" |-
| style="text-align:center" |2
|}
{{center|Table 1: SLIMbus Supported Transport Protocols}}
</div></div>
{{clear}}


User 1 & 2 protocols are used to extend SLIMbus's data transmission mechanisms and it is assumed that a Device connected to a User Protocol Data Channel knows the definition of the TAG and AUX bits and how they are used.
A Subframe is defined as the division of the Frame Structure at which Control Space and Data Space are interleaved. The first Slot of a Subframe is always allocated to Control Space.
Subframes do not have a single, fixed length. As shown in Figure 8 below, the Subframe length is programmable to 6, 8, 24 or 32 contiguous Slots (24, 32, 96 or 128 Cells). The number of possible Subframes per Frame is therefore, 32, 24, 8, or 6 respectively. The Subframe configuration used can be dynamically changed, and depends upon the data flow requirements of the applications being supported at the time.

'''Figure 8: Cell, Slot, Subframe, Frame Structure'''


A discussion of the reasons behind the particular SLIMbus Subframe organization is beyond the scope of this article.

Recall that Control Space is composed of three (3) different types of channels: Framing (Frame Sync and Framing Information), Guide, and Message. However, Frame Sync and Framing Information only occupy 2 slots per Frame or the first slot in 2 different Subframes in a Frame. This means that the first slots in the remaining Subframes of a Frame are used to transmit the other Control Space information, e.g. Guide Channel and Message Channel. See Figure 8 above.


== SLIMbus System ==
Any Slots not allocated to Control Space are considered Data Space. One possible example within a single Frame is shown in Figure 9 below.


A SLIMbus system for illustrative purposes only is shown in Figure 7 below. All of the Components are different from each other. Note that the upper left SLIMbus Component in this example contains a Framer Device (F), and therefore the CLK signal for this component is bidirectional.
The upper left SLIMbus Component also contains a Manager Device (M). However, there is no requirement that the Manager and the Framer Devices be in the same SLIMbus Component.
'''Figure 9: One Possible Bus Configuration Arrangement of Control Space and Data Space'''
(Example from SLIMbus Specification, Version 1.0. Used with permission)


{{center|
'''Superframe'''
[[File:SLIMbusSystem.jpg|An Illustrative SLIMbus System]]
{{center|Figure 7: An Illustrative SLIMbus System}}
}}


The Manager and/or Framer Device shown in the upper left SLIMbus Component can also be incorporated into baseband and/or applications processors typically used to build mobile terminals.
A Superframe is defined as eight contiguous Frames (1536 Slots). Frames within a Superframe are labeled Frame 0 through Frame 7.


Figure 8 below shows a conceptual view of a possible real world SLIMbus system. The "M" and "F" represents the Manager and Framer Devices respectively. Alternatively, the multi-mic array could replace the single mic in the system. Any mixture of audio related blocks could be attached.
Each Frame of a Superframe contains the Frame Sync symbol in Slot 0. The first Frame (Frame 0) of a Superframe contains the first four (4) bits of a total of thirty-two (32) bits of Framing Information in Slot 96. Frames 1 through Frame 7 successively also contain four (4) bits of Framing Information in Slot 96 with Frame 7 carrying the last four (4) bits of Framing Information.
The beginning of a Superframe is defined by a Superframe Sync pattern transmitted one (1) bit at a time in five (5) successive Frames.


{{center|
A Component uses a complete set of Framing Information (32-bits over 8 Frames, 4-bits per Frame) and Superframe Sync to achieve Superframe synchronization.
[[File:SLIMbusConceptualSystem.jpg|SLIMbus System]]
The Guide Channel (used for Message Synchronization) consists of 2 slots, one carried in the first Frame of a Superframe, and one carried in the second Frame of a Superframe.
{{center|Figure 8: Conceptual SLIMbus System}}
}}


== References ==
The duration of a Superframe is fixed in terms of Slots (and, therefore, Cells), but not in terms of time. The Superframe rate can be dynamically changed on SLIMbus to suit the particular application by changing either SLIMbus Root Frequency or Clock Gear, or both.



'''SLIMbus Clock Frequencies and Gears'''


The SLIMbus specification does not specify a particular SLIMbus CLK frequency. Instead, 3 frequency definitions are provided: Root, Natural, and Cardinal.
The use of Natural Frequencies or Cardinal Frequencies is often convenient, but is not mandated on SLIMbus.

Also included is the Clock Gear construct which provides 10 Gears for altering the clock frequency by powers of 2.

There is also a defined procedure to pause or stop the CLK signal and re-start it.

'''Root Frequency'''

The Root Frequency is defined as 2(10-G) times the frequency of the CLK line, where G is the current Clock Gear. In Gear 10, the CLK frequency is the same as the Root Frequency.

The Root Frequency may be a Natural or a Cardinal Frequency, but is not mandated to be so. The Root Frequency may be any frequency up to 28MHz.
The Root Frequency may be changed while the bus is active while leaving the Frame Structure un-changed, thus allowing scaling the bus power consumption according to the application.

'''Natural Frequencies'''

A Natural Frequency is defined as a CLK frequency that allows a family of isochronous data flows to be supported without flow control, thereby simplifying channel allocation on SLIMbus.

For example, Natural Frequencies for 11.025 kHz and 44.1 kHz digital audio sample rate flows include 5.6448 MHz, 11.2896 MHz, and 22.5792 MHz. Similarly, Natural Frequencies for 8 kHz and 48 kHz digital audio sample rate flows include 6.144 MHz, 12.288 MHz, and 24.576 MHz.

The different sample rate flows can be optimally supported by changing a particular Natural Frequency by 0.5X or 2X using the Clock Gear.

'''Cardinal Frequencies'''

In audio applications, one important family of sample rates is comprised entirely of multiples of 4 kHz, i.e. 8, 12, 16, 24, 32, 48, 96 kHz, etc. Another sample rate family is comprised entirely of multiples of 11.025 kHz, i.e. 11.025, 22.05, 44.1, 88.2 kHz, etc.

Concurrent support for digital audio data flows, or families of flows, with non-integer frequency relationships is sometimes required, e.g. 8 kHz and 44.1 kHz sample rates. In these cases, the CLK line cannot be set to a frequency that is a Natural Frequency for all flows on the bus.

The CLK line frequencies 24.576 MHz, 12.288 MHz, 6.144 MHz, etc. have special significance because they can carry the 4 kHz family of flows isochronously, and the 11.025 kHz family of flows with relatively high efficiency (using push or pull flow control techniques). For this reason, these clock frequencies are referred to as Cardinal Frequencies.

'''Clock Gears'''

There are ten Clock Gears (1 to 10), providing a frequency span of 512 from lowest to highest Gear. Clock Gears provide a range of power-of-2 frequency steps for operating SLIMbus. For example, increasing to the next Clock Gear without changing the Root Frequency doubles the SLIMbus CLK frequency, while decreasing the next Clock Gear without changing the Root Frequency will halve the SLIMbus CLK frequency.

== '''SLIMbus Messaging''' ==

SLIMbus provides a robust set of Messages for bus management, Device control, and data transfer. Basic types of Messages are:

• Device Management Messages
• Data Channel Management Messages
• Information Management Messages
• Reconfiguration Messages
• Value Management Messages<br /><br />
• Destination-referred Device Class-specific Message
• Destination-referred User Message
• Source-referred Device Class-specific Message
• Source-referred User Message
• Escape

'''Message Channel'''

The Message Channel is used by a Device for sending Messages to other Devices on the bus. In order to transmit or receive Messages, a Component shall first acquire Message Synchronization. Prior to sending any Messages, each SLIMbus Device uses a priority-based Arbitration mechanism to gain access to the Message Channel.
'''Message Channel Size'''

Messages are carried in Message Channels in the Control Space.

Recall from Figure 8 above that there are four (4) possible subframe modes in SLIMbus. Each Subframe has at least 1 Slot as Control Space. The Framing Channel occupies two (2) Slots per Frame, or sixteen (16) Slots per Superframe. The Guide Channel (used for Message Synchronization) occupies two (2) Slots per Superframe for all bus configurations. Therefore, a total of eighteen (18) Slots of available Control Space per Superframe are allocated to specific purposes.

Control Space Slots not used for the Framing Channel or the Guide Channel are available for the Message Channel, or a mix of Message Channel and Data Channels. Therefore, the size of the Message Channel varies according to the bus configuration.

A minimum number of Slots for Message Channel use occurs in the 6 Subframes/Frame mode. So, there is a minimum of 6 Control Space Slots per Frame, and therefore, 48 Control Space Slots per Superframe. Since 18 Slots are allocated for bus purposes, then that leaves 30 (48 -18 = 30) Control Space Slots available for Message Channel use.

The maximum number of Slots for Message Channel use would just be the total number of Slots in a Superframe less the pre-allocated 18 Slots for bus purposes; e.g. 1536-18 = 1518.

'''Message Syntax'''

Messages which are exchanged between Devices consist of four fields; Arbitration, Header, Payload, and Integrity/Response. All messages must contain the Arbitration, Header, and Integrity/Response fields.
The Arbitration field is present in all Messages and varies in size (2 or 7 bytes) because the Source Address of the Device requesting arbitration could be either an 8-bit Logical Address (LA) or a 48-bit Enumeration Address (EA).

The Header field is present in all Messages and varies in size (3, 4 or 9 bytes) because it, too, may use either no address, the Destination Device Logical Address or Enumeration Address. If all Devices receive a Broadcast Message, then the LA or the EA are not used.

Depending upon the type of message, the Message Payload field may be of zero (0) length. The maximum length of the Message Payload field varies between 22 or 28 bytes depending upon message-specific parameters and data.
The Integrity/Response field is a fixed length of four (4) bytes. The Primary and Message Integrity Fields provide full CRC coverage of the Message contents.
All Messages are associated with Message Codes which are specific to a Message Type.
The maximum Message length is thirty-nine (39) bytes.

A discussion of the contents of all the Message Fields is beyond the scope of this article.

'''Core Messages'''

Core Messages are messages which are interpreted in the same way by all Devices. They are intended for managing and operating the SLIMbus and SLIMbus Devices, and consist of Device Management, Data Channel Management, Information and Value Element Management, and Bus Reconfiguration messages.
Depending upon the type of Device, the Device may or may not support all Core Messages.

However, there is a subset of the Core Messages that exist in each of the four (4) Device Classes defined in the SLIMbus Specification which all Devices must support. Accordingly, depending upon the type of Device, there may also be a subset of support required in Devices for Information and/or Value Element data read and write.

'''Other SLIMbus Messages'''

In addition to the Core Messages, additional message types are:

• Destination-referred Device Class specific Message
• Destination-referred User Message
• Source-referred Device Class specific Message
• Source-referred User Message
7 Bus Boot and Bus Processes

The bus boot process is defined relative to Components, so the terms Clock Source Component and Clock Receiver Component are used to distinguish the Component that contains the active Framer from other Components.

The Clock Source Component has its own boot process, while the Clock Receiver Component type follows a different, but defined, boot process. The boot process occurs as each Component progresses in stages from an Undefined state to an Operational state.

The only time there is a single state that represents all Components on the bus is when all Components are in their respective Operational state at the same time.
A Component joins the bus by following its appropriate boot process.
In order to have more control over system power consumption, the SLIMbus protocol allows a Component to stop participating on the bus while the SLIMbus is active, and rejoin at a later time.

Rules related to each state allow Components that lose sync for whatever reason to drop to the next lower state or the Reset state and attempt the boot process again.


== '''Clock Source Boot Sequence''' ==


The Clock Source Component boots SLIMbus by a specific sequence of operations for starting CLK, and for writing the information in the Framing Channel and Guide Channel on the DATA line.

During the boot process, the Clock Source Component moves through five different states: Undefined, CheckingDataLine, StartingClock, StartingData, and Operational.
A power on reset signal or other specific external event is used to initially move from the Undefined state to the CheckingDataLine state.

Upon reaching the Operational state, the Clock Source Component has successfully written all the necessary Framing Information on the DATA line, and has initially configured the bus in terms of CLK Frequency and Subframe mode. Lastly, it will also report its presence (REPORT_PRESENT Message) on the Bus via the Message Channel.


== '''Clock Receiver Boot Sequence''' ==


Any other Device within a Component on the bus that is not a Framer is, by definition, a Clock Receiver Component. Clock Receiver Components have their own bus boot process which occurs concurrently with the Clock Source Component, but completes after the Clock Source Component has completed its boot process.

During the boot sequence, a Clock Receiver Component extracts any necessary information about the current state of the bus by monitoring the DATA and CLK lines. During the boot process, Clock Receiver Components move through various states; Undefined, Reset, SeekingFrameSync, SeekingSuperframeSync, SeekingMessageSync, and finally, Operational.

A power on reset signal or other specific external event is used to initially move from the Un-defined state to the Reset state.

Once the Operational state is achieved, a Clock Receiver Component has all of the Framing Information about the Bus Configuration, has access to the Message Channel, and is now able to perform its function when required. It, too, announces its presence on the bus by a REPORT_PRESENT Message.


== '''Device Discovery''' ==


As Devices become Operational after Bus Boot, they arbitrate for the Message Channel, and send REPORT_PRESENT Messages to the Active Manager. These messages identify the Device Class code and version and the Enumeration Address of the reporting Device.

Upon acknowledgement of the REPORT_PRESENT message by the Manager, the Device waits for the Manager to assign a Logical Address, which is needed in order to receive and send data Source and Sink types of messages. Once the Logical Address is assigned, the Device is considered to be in the Enumerated state, and ready for functional operation.

The active Manager assigns unique Logical Addresses at the bus level so that no two Devices try to use the same Logical Address at the same time.
If for any reason the Device loses Message Sync after receiving its Logical Address, there is no need to assign a new Logical Address after the Device recovers Message Sync and re-joins the bus.


A Component Reset will cause the loss of an assigned Logical Address, and the Device Discovery process will need to be run again on that Component before it can join the bus.


== '''Bus Management''' ==


Many SLIMbus processes require that all active Components change state at exactly the same time, e.g. at a Superframe boundary. This is accomplished by a Message string which begins with a BEGIN_RECONFIGURATION Message, followed by a number of Reconfiguration Messages, and ending with a RECONFIGURE_NOW Message.

The Reconfiguration Messages are also used to adapt SLIMbus to the CLK frequency, data rate, and numbers of data channels to match the particular application demands running at the time. Thus, bus power consumption is also managed.



== '''Conclusion''' ==


SLIMbus is a highly configurable multi-drop bus structure able to support many components simultaneously. In addition, there are powerful messaging constructs to set up and manage data flow between components on the bus. SLIMbus also provides the ability to re-configure the bus operational characteristics on-the-fly to adapt to particular system application needs at runtime.

Unlike traditional digital audio bus structures, SLIMbus has the ability to simultaneously and efficiently carry multiple digital audio data streams at widely differing sample rates and bit widths.
When using existing digital audio interfaces (PCM, I2S, SSI, AC-97), adding functions and digital audio channels to mobile terminals beyond those for voice communication and simple stereo music applications is very difficult without increasing the number of bus structures in the mobile terminal. This is because these legacy interfaces are primarily point to point (peer to peer) connections with limited channel capacity, and any new device in the system requires its own interface connection.

Though legacy interface systems are scalable just by duplicating interface structures, this approach limits design flexibility, and is costly in terms of pin count, package size, PCB layout area, and power consumption.

SLIMbusTM provides the mobile terminal industry and other small form factor product makers a standard, robust, scalable, low-power, high-speed, cost-effective, two wire multi-drop interface that supports a wide range of digital audio and control solutions. As such, it effectively replaces legacy digital audio interfaces such as PCM, I2S, and SSI in such products.

SLIMbus can also effectively replace some instances of many digital control buses such as I2C, SPI, or UART and GPIO, in a mobile terminal or portable product by providing flexible and dynamic assignment of bus bandwidth between digital audio and non-audio control and data functions.

SLIMbus is not backward compatible with any current digital audio bus or digital control bus.

Implementing the SLIMbus standard greatly increases the flexibility for designers to realize multiple products within a product line quickly, each with widely varying digital audio and user interface features. This can all be done without the duplication of multiple bus structures within the product.

SLIMbus reduces the time-to-market and design cost of mobile terminals and other portable devices by simplifying the interconnection of various functional products from different manufacturers.

As this article is being written (May 2007), most company participants in the creation of the SLIMbus Specification have SLIMbus compatible product development underway with the goal that products suitable for a basic SLIMbus system would be available to the industry in 2008.

'''SLIMbus Features Highlights'''

A partial, but representative, listing of the features of SLIMbus is given below.<br />
• Audio, data, bus and Device control on a single bus<br />
• Reduced pin count for lower overall product cost<br />
• Support for multiple, high quality audio channels<br />
• Multiple, concurrent sample rates on a single bus<br />
• Efficient, host-less, peer-to-peer generic data communication<br />
• Standardized Message set for improved software reuse and increased interoperability<br />
• Use of common digital audio clocks as well as established system clocks<br />
• Dynamic clock frequency changes for optimizing bus power consumption<br />



<p>
<h2><span class="editsection"></span> <span class="mw-headline">References</span></h2>
{{reflist}}
{{reflist}}


== External links==
<div class="references-small">
A partial list of SLIMbus implementer information can be found at the following:

* [http://www.arasan.com/product/mipi-solutions Arasan Chip Systems]
<ol class="references">
* [http://www.lnk-tools.com/index.php LNK Tools]
<li id="cite_note-0"><b><a href="#cite_ref-0" title="">^</a></b> <a href="http://research.nokia.com/publications/embedded_network_architectures_mobile_devices" class="external text" title="http://research.nokia.com/publications/embedded_network_architectures_mobile_devices" rel="nofollow">Nokia's Discobus research project</a>, lead by Michel Gillet</li>
* [http://www.evatronix-ip.com/ip-cores/multimedia/mipi-slimbus.html Evatronix]
<li id="cite_note-1"><b><a href="#cite_ref-1" title="">^</a></b> The UniPro team at Philips Research later became part of the wireless joint venture between ST and NXP.</li>
<li id="cite_note-UniPro1.0-2">^ <a href="#cite_ref-UniPro1.0_2-0" title=""><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-UniPro1.0_2-1" title=""><sup><i><b>b</b></i></sup></a> <a href="https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v01-00-00.pdf" class="external text" title="https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v01-00-00.pdf" rel="nofollow">UniPro 1.00 spec</a>, requires an account at the MIPI website</li>

<li id="cite_note-3"><b><a href="#cite_ref-3" title="">^</a></b> ATI Technologies was later acquired by AMD</li>
<li id="cite_note-4"><b><a href="#cite_ref-4" title="">^</a></b> <a href="http://www.ieee-isto.org" class="external text" title="http://www.ieee-isto.org" rel="nofollow">IEEE-ISTO</a> provides program management and infrastructural support for the MIPI Alliance.</li>
<li id="cite_note-5"><b><a href="#cite_ref-5" title="">^</a></b> <a href="http://www.arasan.com/products/prod_overview/mipi/UniPro-Flyer-v1.0.pdf" class="external text" title="http://www.arasan.com/products/prod_overview/mipi/UniPro-Flyer-v1.0.pdf" rel="nofollow">Arasan Chip Systems</a>, UniPro IP vendor</li>
<li id="cite_note-6"><b><a href="#cite_ref-6" title="">^</a></b> <a href="http://www.dice.at/unipro.htm" class="external text" title="http://www.dice.at/unipro.htm" rel="nofollow">DICE</a>, UniPro IP vendor</li>

<li id="cite_note-7"><b><a href="#cite_ref-7" title="">^</a></b> <a href="https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20D-PHY%20Specification_v00-90-00_final_11152007132023.pdf" class="external text" title="https://members.mipi.org/mipi-adopters/file/Specifications/Board%20Approved/MIPI%20D-PHY%20Specification_v00-90-00_final_11152007132023.pdf" rel="nofollow">MIPI D-PHY 0.90 specification</a>,requires an account at the MIPI website</li>
<li id="cite_note-8"><b><a href="#cite_ref-8" title="">^</a></b> <a href="/enwiki/wiki/Metcalfe%27s_law" title="Metcalfe's law">Metcalfe's law</a>, postulates that the value of a network is proportional to the square of the number of users</li>
<li id="cite_note-market_share-9"><b><a href="#cite_ref-market_share_9-0" title="">^</a></b> <a href="http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=210600169" class="external text" title="http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=210600169" rel="nofollow">Nokia market share</a>, September 8 2008</li>
<li id="cite_note-10"><b><a href="#cite_ref-10" title="">^</a></b> <a href="/enwiki/wiki/Network_on_Terminal_Architecture" title="Network on Terminal Architecture">NoTA</a>, messaging protocol and library</li>


===Press coverage===
<li id="cite_note-11"><b><a href="#cite_ref-11" title="">^</a></b> <a href="http://www.mipi.org/MIPI-MA-2006.pdf" class="external text" title="http://www.mipi.org/MIPI-MA-2006.pdf" rel="nofollow">MIPI Membership Agreement</a>, November 1, 2006</li>
*{{cite web|title=MIPI Alliance Rolls Out SLIMbus®|url=http://www.mipi.org/content/mipi-alliance-rolls-out-slimbus%C2%AE|work=MIPI Alliance|publisher=MIPI Alliance, Inc.|access-date=17 January 2013|date=9 July 2007}}
<li id="cite_note-12"><b><a href="#cite_ref-12" title="">^</a></b> <a href="http://www.mipi.org" class="external text" title="http://www.mipi.org" rel="nofollow">MIPI Alliance web site</a></li>
*{{cite conference|last=Backman|first=Juha |author2=Boyce, Kenneth |author3=Kavanagh, Peter |author4=Lambrecht, Xavier |author5=Schuessler, James |author6=Travis, Chris |author7=van Vlimmeren, Bernard |author8=Vansteeg, Genevieve |title=Slimbus: An Audio, Data And Control Interface For Mobile Devices|conference=29th International Conference: Audio for Mobile and Handheld Devices|date=September 2006|url=http://www.aes.org/e-lib/browse.cfm?elib=13869}}
*{{cite web |last=Lee|first=Yong-Hwan |author2=Hoon-Ju Chung |author3=Chang-Gu Rho |title=Design of Clock Gears for Low-power Media Bis |work=The 23rd International Technical Conference on Circuits/Systems, Computers and Communications|year=2008|url=http://www.ieice.org/proceedings/ITC-CSCC2008/pdf/p1089_P1-22.pdf|access-date=17 January 2013}}
*{{cite news|title=MIPI® Alliance Delivers Seven Vital Mobile Device Interface Specifications in 2008|url=http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20090209005179&newsLang=en|access-date=17 January 2013|newspaper=Business Wire|date=9 February 2009}}


{{DEFAULTSORT:Slimbus}}
<li id="cite_note-11"><b><a href="#cite_ref-11" title="">^</a></b> <a href="http://www.national.com/appinfo/audio/files/intro_to_SLIMbus.pdf#page=1 class="external text" title="http://www.national.com/appinfo/audio/files/intro_to_SLIMbus.pdf#page=1" rel="nofollow">MIPI National Semiconductor article</a>, September, 2007</li>
[[Category:Computer buses]]
</ol>
[[Category:MIPI Alliance standards]]

Latest revision as of 19:47, 27 January 2021

The Serial Low-power Inter-chip Media Bus (SLIMbus) is a standard interface between baseband or application processors and peripheral components in mobile terminals. It was developed within the MIPI Alliance, founded by ARM, Nokia, STMicroelectronics and Texas Instruments.[1] The interface supports many digital audio components simultaneously, and carries multiple digital audio data streams at differing sample rates and bit widths.

SLIMbus is implemented as a synchronous 2-wire, configurable Time Division Multiplexed (TDM) frame structure. It has supporting bus arbitration mechanisms and message structures which permit re-configuring the bus operational characteristics to system application needs at runtime. Physically, the data line (DATA) and the clock line (CLK) interconnect multiple SLIMbus components in a multi-drop bus topology. SLIMbus devices may dynamically “drop off” the bus and “reconnect” to the bus as required by using appropriate protocols outlined in the SLIMbus specification. When used in a mobile terminal or portable product, SLIMbus may replace legacy digital audio interfaces such as PCM, I2S,[2] and SSI (Synchronous Serial Interface for digital audio), as well as some instances of many digital control buses such as I2C,[3] SPI, microWire,[4] UART, or GPIO pins on the digital audio components.

History

[edit]
  • The MIPI Alliance was formed in fall of 2003.
  • Interface architecture including a low speed media link bus (LowML) presented at the F2F meeting of MIPI Alliance in Sophia Antipolis, France in March, 2004.
  • LML Investigation Group (LML-IG) created in July 2004 by the MIPI Alliance. First meeting was a teleconference on August 3, 2004.
  • LML Working Group (LML-WG) created in Q4 2004. LML WG Charter submitted to the MIPI Board in December, 2004.
  • First meeting as a full Working Group on April 12, 2005.
  • LML-WG released first draft of SLIMbus with text in all chapters (v0.55) on October 18, 2005.
  • SLIMbus specification v1.00 was released to adopters on May 16, 2007.
  • From June 2007 to June 2008, SLIMbus specification improvement (ambiguities, typos & bugs fixed) based on implementer feed-back.
  • SLIMbus specification V1.01 was released to adopters on December 3, 2008 and is recommended for implementation.

SLIMbus Devices and Device Classes

[edit]

SLIMbus Device Class definitions are those which specify the minimum requirements for Device control data, Device behavior, and data Transport Protocol support. There are four SLIMbus Device Classes defined at the release of Version 1.01 of the SLIMbus specification: Manager, Framer, Interface, and Generic. Complete SLIMbus systems can be implemented without any additional Device Classes.

Manager Device

[edit]

The Manager Device is responsible for configuring SLIMbus, and performs bus administration (administration of Components and Devices, bus configuration, and dynamic channel allocation) and is typically located in a baseband or application processor rather than in a peripheral component.

Framer Device

[edit]

The Framer delivers a clock signal on the CLK line to all SLIMbus Components, and also contains logic to transmit the Frame Sync and Framing Information channels on the DATA line.

Interface Device

[edit]

The Interface Device provides bus management services, monitors the Physical Layer for errors, reports information about the status of a SLIMbus Component, and otherwise manages the Component such that the Devices within it will function properly on the bus.

To implement a functional SLIMbus component always requires the use of a SLIMbus Interface Device, plus the function to be performed, such as DAC, ADC, digital amplifier, and so on.

Generic Device (Function)

[edit]

A Generic Device is a Device other than a Manager, Framer, or Interface. A Generic Device is generally considered to be the device to provide certain application functionality, for example, conversion from digital audio to analog (DAC) and vice versa (ADC).

SLIMbus Component

[edit]

A SLIMbus Component contains two or more SLIMbus Devices. A SLIMbus Component will have only one SLIMbus Interface Device (INTERFACE), and may have one or more other types of SLIMbus devices which perform a particular function (FUNCTION).

A SLIMbus Port (P) provides the connection path for data flow between Devices. SLIMbus Ports are normally used for digital audio data flow, but may also be used for other digital data flow.

Port capabilities vary depending upon the Device and are to be specified in the Component data sheet. Typical Port attributes include data direction, i.e. input-only (sink), output-only (source) or both input and output, supported Transport Protocols, and data width.

A simple SLIMbus Component example is shown in Figure 1 below, and a complex SLIMbus Component example is shown in Figure 2 below.

Simple SLIMbus Component

Figure 1: Simple SLIMbus Component

Complex SLIMbus Component

Figure 2: Complex SLIMbus Component

SLIMbus DATA and CLK

[edit]

All SLIMbus Devices use DATA and CLK to synchronize with the bus configuration in use, to receive or transmit messages and data, and to implement bus arbitration, collision detection, and contention resolution between devices.

For all SLIMbus Components (except one containing a Framer Device), the CLK terminal is input only. If a SLIMbus Component is the Framer Device, or contains a Framer Device, the CLK signal is bi-directional.

For all SLIMbus Components, the DATA line is bidirectional, and carries all information sent or received on the bus using Non-Return-to-Zero Inverted (NRZI) encoding.

The DATA line is driven on the positive edge and read on the negative edge of the CLK line. The DATA line can be driven high, driven low, or held at the high or low level by an internal bus-holder circuit, depending upon the particular operational mode of a SLIMbus Device.

The SLIMbus interface DATA and CLK lines use CMOS-like single-ended, ground referenced, rail-to-rail, voltage mode signals, and signaling voltages are specified with respect to the interface supply voltage (+1.8Vdd or +1.2Vdd are permitted). For EMI performance reasons, slew rate limits have been specified for SLIMbus.

SLIMbus Clock Frequencies and Gears

[edit]

The SLIMbus CLK line frequency is determined by a range of "Root" clock frequencies up to 28 MHz, and 10 Clock Gears for altering the clock frequency by powers of 2 over a span of 512x from lowest to highest Gear. The Root Frequency is defined as 2(10-G) times the frequency of the CLK line. For G=10, the CLK line frequency and Root Frequency are equal.

The SLIMbus CLK may also be stopped and restarted.

SLIMbus CLK frequencies and data transport protocols will support all common digital audio converter over-sampling frequencies and associated sample rates.

Cells, Slots, Subframes, Frames, and Superframes

[edit]

The SLIMbus Frame Structure has five building blocks: Cells, Slots, Frames, Subframes, and Superframes.

Cell

[edit]

A Cell is defined as a region of the DATA signal that is bounded by two consecutive positive edges of the CLK line and holds a single bit of information.

Cell Structure

Figure 3: Cell Structure

Slot

[edit]

A Slot is defined as four contiguous Cells (4-bits transmitted in MSB to LSB order). Bandwidth allocation for various data organizations, from 4-bits to 32-bits or more, can be done by grouping 4-bit Slots.

Frame

[edit]

A Frame is defined as 192 (0 through 191) contiguous Slots and are transmitted as S0, followed by S1, S2 ... S191 in that order. The first Slot (Slot 0) of each Frame is a Control Space slot which contains the four (4) bit Frame Sync symbol. Slot S96 of each Frame is also a Control Space slot which contains four (4) bits of Framing Information.

The active Framer writes all Framing Information to the Data line at the appropriate time.

Subframe

[edit]

A Subframe is defined as the division of the Frame Structure at which Control Space and Data Space are interleaved. A Subframe is partitioned into 1 or more slots of Control Space, followed by 0 or more slots of Data Space.

As shown in Figure 4 below, the Subframe length is programmable to 6, 8, 24 or 32 contiguous Slots (24, 32, 96 or 128 Cells). The number of possible Subframes per Frame is therefore 32, 24, 8, or 6 respectively. The Subframe configuration used can be dynamically changed depending upon the data flow requirements of the applications being supported at the time.

Cell, Slot, Subframe, Frame Structure

Figure 4: Cell, Slot, Subframe, Frame Structure

4 of the Control space slots are reserved for a frame sync symbol, 4 bits if a Framing Information word, and 8 bits of Guide Byte. The remainder is available for more general control messages.

Any Slots not allocated to Control Space are considered Data Space.

Superframe

[edit]

A Superframe is defined as eight contiguous Frames (1536 Slots). Frames within a Superframe are labeled Frame 0 through Frame 7.

The duration of a Superframe is fixed in terms of Slots (and, therefore, Cells), but not in terms of time. The Superframe rate can be dynamically changed on SLIMbus to suit the particular application by changing either SLIMbus Root Frequency or Clock Gear, or both.

Channels

[edit]

Information on the SLIMbus DATA line is allocated to Control Space and Data Space channels.

The Control Space carries bus configuration and synchronization information as well as inter-Device Message communication. The Control Space may be dynamically programmed to take as much of the SLIMbus bandwidth as required, even up to 100% at times.

Data Space, when present, carries application-specific information such as isochronous and asynchronous data streams.

SLIMbus Components convey control and data information between each other using Control and Data Channels with Transport Protocols to achieve the required system operation. Messages are used for Control functions.

Channels can be established between a pair of Devices (inter-Device communication), or between one Device and many Devices (broadcast communication), or in the case of the Message Channel, from all devices to all other devices (shared).

Control Channels

[edit]

Control Space is divided into three types of channels: Framing, Guide, and Message.

The Framing Channel occupies Slots 0 and 96 of each Frame. (Since all Subframe lengths divide 96, these Slots are always available for the purpose.) Slot 0 holds a fixed Frame Sync symbol (10112), while Slot 96 holds 4 bits of a Framing Information word. Over the course of a Superframe, 32 bits of Framing Information are available. Some of these hold a fixed bit pattern used to acquire Superframe synchronization (0x011xxx2), while the others hold other critical configuration information.

The Guide Channel consists of the first 2 non-Framing control Slots in each Superframe. This "guide byte" is normally 0, but if a control message straddles a Superframe boundary, it indicates the number of bytes until the end of that message.

The Message Channel consists of all remaining Slots. It carries various types of information including bus configuration announcements, Device control and Device status.

The format of Control Space is determined by a 5-bit Subframe mode identifier transmitted in the Framing Information word. This communicates the Subframe length and the number of control Slots. The number of control Slots is limited to the choices of 1, 2, 3, 4, 6, 8, 12, 16, or 24. Adding the limitations that the number of control Slots must be less than the Subframe length produces 26 valid combinations. A special encoding for "100% Control Space", in which case the Subframe length is unimportant, produces 27 valid modes. (Modes 1–3, 20 and 30 are not valid.)

Data Channels

[edit]

Data Channels are one or more contiguous Data Slots (Segments) and are dynamically created by the active Manager depending on the application and size of Data Space available. A Data Channel, and therefore the structure of a Segment, is defined by parameters such as Data rate, type, field length, and required Transport Protocol.

Segments repeat at known intervals and behave as virtual bus's with their own bandwidth guarantee and latency.

A Segment, shown below in Figure 5, has TAG (2 Slots), AUX (2 Slots), and DATA fields. The TAG and AUX fields are optional. If used, the TAG bits carry flow control information for the data channel, while the auxiliary (AUX) bits carry side information relating to the content of the DATA field. The data payload may or may not fill the entire allotted DATA field.

Segment Organization

Figure 5: Segment Organization

Data Channel Transport Protocols and Flow Control

[edit]

A Data Channel has exactly one data source at a time and may have one or more data sinks depending upon the Transport Protocol used in the channel.

Flow Control in the Channel, if needed, depends on the Devices and the type of Data involved. TAG bits are used to carry the flow control information.

SLIMbus Device Ports are associated with Data Channels using appropriate channel connection and dis-connection Messages. For data flow between Ports attached to Channels, SLIMbus supports a small group of frequently used Transport Protocols (including a User Defined Transport Protocol) which define data flow type, flow control mechanism, and a side-channel (if any) for any additional application-specific information. A summary of the Transport Protocols is shown in Table 1.

TP Protocol Name Type # of TAG field Slots
0 Isochronous Multicast 0
1 Pushed Multicast 1
2 Pulled Unicast 1
3 Locked Multicast 0
4 Asynchronous – Simplex Unicast 1
5 Asynchronous – Half-duplex Unicast 1
6 Extended Asynchronous – Simplex Unicast 2
7 Extended Asynchronous – Half duplex Unicast 2
8 to 13 Reserved - -
14 User Defined 1 - 1
15 User Defined 2 - 2
Table 1: SLIMbus Supported Transport Protocols

User 1 & 2 protocols are used to extend SLIMbus's data transmission mechanisms and it is assumed that a Device connected to a User Protocol Data Channel knows the definition of the TAG and AUX bits and how they are used.

SLIMbus System

[edit]

A SLIMbus system for illustrative purposes only is shown in Figure 7 below. All of the Components are different from each other. Note that the upper left SLIMbus Component in this example contains a Framer Device (F), and therefore the CLK signal for this component is bidirectional.

The upper left SLIMbus Component also contains a Manager Device (M). However, there is no requirement that the Manager and the Framer Devices be in the same SLIMbus Component.

An Illustrative SLIMbus System

Figure 7: An Illustrative SLIMbus System

The Manager and/or Framer Device shown in the upper left SLIMbus Component can also be incorporated into baseband and/or applications processors typically used to build mobile terminals.

Figure 8 below shows a conceptual view of a possible real world SLIMbus system. The "M" and "F" represents the Manager and Framer Devices respectively. Alternatively, the multi-mic array could replace the single mic in the system. Any mixture of audio related blocks could be attached.

SLIMbus System

Figure 8: Conceptual SLIMbus System

References

[edit]
  1. ^ Merritt, Rick (13 February 2006). "Mobile chip interface gets real". EETimes. Retrieved 17 January 2013.
  2. ^ "I2S bus specification" (PDF). Philips Semiconductors. Retrieved 17 January 2013.
  3. ^ "The I2C-Bus Specification" (PDF). Philips Semiconductors. January 2000. Retrieved 17 January 2013.
  4. ^ "AN-452 MICROWIRE Serial Interface" (PDF). Texas Instruments. Retrieved 17 January 2013.
[edit]

A partial list of SLIMbus implementer information can be found at the following:

Press coverage

[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=SLIMbus&oldid=1003178230"