DSP

SLIMbus

2019-07-13 18:33发布

站内文章 / DSP
16115 0 1069

SLIMbus

From Wikipedia, the free encyclopedia [hide]This article has multiple issues. Please help improve it or discuss these issues on the talk page. This article needs more links to other articles to help integrate it into the encyclopedia. (October 2012) This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (January 2013) This article needs additional citations for verification. (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, 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.

Contents

  [hide] 

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 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[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. Jump up^ Merritt, Rick (13 February 2006). "Mobile chip interface gets real". EETimes. Retrieved 17 January 2013.
  2. Jump up^ "I2S bus specification". Philips Semiconductors. Retrieved 17 January 2013.
  3. Jump up^ "The I2C-Bus Specification". Philips Semiconductors. January 2000. Retrieved 17 January 2013.
  4. Jump up^ "AN-452 MICROWIRE Serial Interface". Texas Instruments. Retrieved 17 January 2013.

External links[edit]

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

Press coverage[edit]

Categories: 

热门文章