SLIM 接口

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. 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,[1] and SSI (Synchronous Serial Interface for digital

audio), as well as some instances of many digital control buses such as I2C,[2] SPI,

microWire,[3] UART, or GPIO pins on the digital audio components.

Contents

[hide]























1 History

2 SLIMbus Devices and Device Classes

o

2.1 Manager Device

o

2.2 Framer Device

o

2.3 Interface Device

o

2.4 Generic Device (Function)

3 SLIMbus Component

4 SLIMbus DATA and CLK

o

4.1 SLIMbus Clock Frequencies and Gears

5 Cells, Slots, Subframes, Frames, and Superframes

o

5.1 Cell

o

5.2 Slot

o

5.3 Frame

o

5.4 Subframe

o

5.5 Superframe

6 Channels

o

6.1 Control Channels

o

6.2 Data Channels

7 Data Channel Transport Protocols and Flow Control

8 SLIMbus System

9 References

10 Press and Article Coverage

11 External links

[edit] History



















The MIPI Alliance was formed in the 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 3-Aug-04.

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 12-April-05.

LML-WG released first draft of SLIMbus with text in all chapters (v0.55) on

18-October-2005.

SLIMbus specification v1.00 was released to adopters on 16 May 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 3 Dec 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.

[edit] Manager Device

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.

[edit] Framer Device

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.

[edit] Interface Device

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.

[edit] 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).

[edit] SLIMbus Component

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.

Figure 1: Simple SLIMbus Component

Figure 2: Complex SLIMbus Component

SLIMbus DATA and CLK

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.

[edit] SLIMbus Clock Frequencies and Gears

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 1024 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.

[edit] Cells, Slots, Subframes, Frames, and

Superframes

The SLIMbus Frame Structure has five building blocks: Cells, Slots, Frames,

Subframes, and Superframes.

[edit] Cell

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.

Figure 3: Cell Structure

[edit] Slot

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.

[edit] Frame

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.

[edit] Subframe

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.

A Data Space channel cannot be set up to overlap with Control 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.

Figure 4: Cell, Slot, Subframe, Frame Structure

Frame Sync and Framing information only occupy two slots per Frame or the first slot

in two different Subframes in a Frame. The first slots in the remaining Subframes of a

Frame are used to transmit the other Control Space information.

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

[edit] Superframe

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.

[edit] 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.

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).

[edit] Control Channels

There are three types of channels: Framing, Guide, and Message.



The Framing Channel carries a Frame Sync symbol and Framing Information

(bus configuration parameters) in two (2) Slots (fixed channel width) of each

Frame.

The Guide Channel is carried in the first two (2) Slots (fixed channel width)

allocated to Control Channels and displaces the Message Channel, and is used

to acquire and verify Message synchronization in the Message Channel.

The Message Channel is a programmable width channel that carries various

types of information including bus configuration announcements, Device

control and Device status.





[edit] Data Channels

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.

Figure 5: Segment Organization

[edit] 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.

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

0

1

2

3

4

5

6

7

14

15

Pushed

Pulled

Locked

Asynchronous – Simplex

Asynchronous – Half-duplex

Extended Asynchronous – Simplex

Protocol Name

Isochronous

Type

Multicast

Multicast

Unicast

Multicast

Unicast

Unicast

Unicast

-

-

-

# of TAG field Slots

0

1

1

0

1

1

2

2

-

1

2

Extended Asynchronous – Half duplex Unicast

User Defined 1

User Defined 2

8 to 13 Reserved

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.

[edit] SLIMbus System

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 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.

Figure 8: Conceptual SLIMbus System