Patent Application
20140119463
The present application claims priority to and incorporates by reference European Patent Application number, EP12290373.5, filed Oct. 29, 2012, entitled “Scalable Multifunction Serial Link Interface”.
This invention generally relates to communication interfaces using multiple serial links, and in particular to the use of M-PHY for communication.
Mobile devices face increasing bandwidth demands for each of its functions as well as an increase of the number of functions integrated into the system. This requires wide bandwidth, low-pin count, and highly power-efficient interfaces that provides sufficient flexibility to be attractive for multiple applications, but which can also be covered with one physical layer technology.
The Mobile Industry Processor Interface (MIPI) Alliance has created standards for a number of mobile device interfaces. One critical component of any mobile device is the physical layer (PHY). The first PHY specification that the MIPI Alliance released in 2009 was the D-PHY. The D-PHY currently operates at rates up to 1 Gbps and supports both camera serial interface (CSI-2) and display serial interface (DSI), which are increasingly used in both feature and smart phones. M-PHY is the successor of D-PHY, requiring fewer pins and providing more bandwidth per pin pair with improved power efficiency. The M-PHY technology supports high-speed data rates starting at about 1000 Mbit/s. In addition to higher speeds, the M-PHY will use fewer signal wires because the clock signal is embedded with the data through the use of industry-standard 8b10b encoding. An M-PHY link capable of transmitting user data at 1000 Mbit/s is typically specified as being in 1250 Mbit/s mode due to the 8b10b encoding.
The Unified Protocol (UniPro), defined by the MIPI Alliance, defines a layered protocol for interconnecting devices and components within mobile device systems. It is applicable to a wide range of component types including application processors, co-processors and modems, as well as different types of data traffic including control messages, bulk data transfer, and packetized streaming. Implementing the UniPro specification reduces time-to-market and design costs by simplifying the interconnection of peripherals. In addition, the extensible nature of the specification simplifies new feature implementation. Versions 1.4 and beyond of UniPro support both the D-PHY as well as M-PHY technology. Target applications for UniPro include wireless handsets, tablets/netbooks, digital cameras, and multimedia devices. UniPro is optimized for mobile applications and scalable from a single link to full network.
The Low Latency Interface (LLI), defined by the MIPI Alliance, is a point-to-point interconnect that allows two devices on separate chips to communicate as if a device attached to the remote chip is resident on the local chip. The connection between devices is at their respective interconnect level, e.g. OCP (On Chip Bus), AMBA® (Advanced Microcontroller Bus Architecture) protocols, using memory mapped transactions. A LLI Link is a bidirectional interface allowing either device to initiate transactions. LLI primarily targets low-latency cache refill transactions. The low latency use cases are supported by the dedicated Low Latency traffic class (LL TC). The LLI specification is expressed as a layered, transaction level protocol, where Targets and Initiators on two linked chips exchange Transactions without software intervention. Software is used only to configure the LLI Link, for error handling and potentially, to initialize the LLI Stack. This configuration reduces latency and allows software compatibility regardless of the partitioning of the hardware on the two linked chips
Particular embodiments in accordance with the invention will now be described, by way of example only, and with reference to the accompanying drawings:
Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.
Specific embodiments of the invention will now be described in detail with reference to the accompanying figures. Like elements in the various figures are denoted by like reference numerals for consistency. In the following detailed description of embodiments of the invention, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to one of ordinary skill in the art that the invention may be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.
A mobile device, such as a smart phone or other type of digital assistant, may include several different integrated circuits that are interconnected. D-PHY or M-PHY serial links may be used in many applications to provide a high speed, low pin count interconnect between the various integrated circuits. Controller logic gets smaller as silicon geometry scales down; however, D-PHY and M-PHY physical interfaces are expansive in silicon and do not shrink easily with smaller silicon geometry, due to the requirements of the electrical or optic driver circuits. Typically, one or several D-PHY or M-PHY lanes are connected to each controller, such as LLI, Unipro, or CSI3. Together they provide a fixed functionality and fixed performance that is provided by the controller and the fixed number of lanes connected to each controller.
Embodiments of the invention allow a chip manufacturer to provide flexibility in the number of controller interfaces and in the performance of those interfaces. Embodiments of the invention allow a chip manufacturer to provide an implementation using minimum silicon area with minimum number of pins. As will be described in more detail below, embodiments of the invention provide a flexible interface that can connect, at configuration time, a set of controllers that provide a required functionality to a selected number of M-PHY Interface lanes in order to provide a required performance level. Configuration may be performed each time the system is powered on. In some embodiments, a reconfiguration may be performed during the course of operation to support a new or different application, such as a new software load, use of different protocols, etc. In this manner, a single version of an IC may be manufactured and then the serial communication lanes may be configured as needed for different system embodiments.
The following description will focus on the use of M-PHY lanes; however, another embodiment may provide a similar flexible interface that can provide similar benefits using a set of D-PHY lanes or other types of point to point serial lanes.
At the end of each link 100 is a port. Port 140 includes two M-TX and one M-RX that are managed by lane management logic 102 and thereby coupled to controller 150. Similarly, port 144 includes one M-TX and two M-RX that are managed by lane management logic 104 and thereby coupled to controller 152. Lane management logic 102, 104 converts the unidirectional data flow on sublinks 110, 112 into bidirectional data flow for controllers 150, 152. Lane management logic 102, 104 also parses a flow of data from controller 150, for example, into two separate data sequences that are then transmitted via lanes 120 and 121 to lane management logic 104 which reassembles the parsed data stream and provides it to controller 152.
Each port includes physical drivers and receivers that are connected to the external pins of an integrated circuit that contains the port. For example, pins 133, 134 provide the connection points between differential line 130 and transmitter M-TX 132. Likewise, pins 135, 136 provide the connection points between differential line 130 and receiver M-RX 138.
The specific electrical characteristics and timing of link 100 are defined by the M-PHY standard available from the Mobile Industry Processor Interface (MIPI) Alliance. The operation of each M-PHY link is completely defined in the context of a protocol definition, such as LLI, DSI (digital serial interface), CSI (camera serial interface), UniPro, or DigRF (digital RF) which may be used by a controller that is managing the lane, as defined in respective MIPI Alliance standards.
Each controller 210-213 includes a respective physical adaptor 220-223. Each physical adaptor, such as physical adaptor 220 connected to LLI controller 210, is implemented when the integrated circuit is designed to parse transmitted traffic from controller 210 onto each of the transmit lanes MPHY-1 TX through MPHY-n TX and to merge all traffic received via receive lanes MPHY-1 RX through MPHY-m RX to provide a single received stream to controller 210. In this example, the parsing and merging operation of the physical adaptors is performed according to a relevant MIPI standard for each controller type.
Each physical adaptor 320-324 is implemented to support a number of M-PHY lanes, which will be referred to as the maximum number of lanes for a particular controller. For example, physical adaptor 320 may support a maximum number of twelve M-PHY lanes for LLI controller 310, while adaptor 322 may only support a maximum number of four M-PHY lanes for UniPro controller 312. The physical adaptors of
A pool of M-PHY transmit lane ports 330 and a pool of M-PHY receive lane ports 332 are implemented. Each of the transmit lane ports in pool 330 and receive lane ports in pool 350 are coupled to pins 334 of integrated circuit 300 to provide an interface to other integrated circuits. In
A multiplexor 340 and a demultiplexor 350 provide a flexible interconnect between the physical adaptors 320-324 of each of the controllers 310-314 and the interface pins 334 of IC 300. Inputs of a multiplexor 340 are coupled to all of the transmit lane terminals from all of physical adaptors 320-324. Outputs from multiplexor 340 are coupled to all of the transmit lane ports in M-PHY transmit lane pool 330. Similarly, inputs of a demultiplexor 350 are coupled to all of the receive lane ports in M-PHY receive lane pool 332. Outputs from demultiplexor 350 are coupled to all of the receive lane terminals for all of physical adaptors 320-324.
Multiplexor 340 and demultiplexor 350 may be configured to couple various numbers of transmit lanes in pool 330 and receive lanes in pool 350 to each of controllers 310-314. The number of transmit lanes and receive lanes coupled to a controller may be different. Configuration of multiplexor 340 and demultiplexor 350 may be performed by software executed on a CPU in processing logic 302 each time IC 300 is powered on. Additionally, in some embodiments, configuration of multiplexor 340 and demultiplexor 350 may be performed by software executed on a CPU in processing logic 302 when a new application program is initiated by processing logic 302, for example.
In some embodiments, multiplexor 340 and demultiplexor 350 may function as a complete cross-point switch and allow any transmit lane port to be coupled to any physical adaptor transmit lane terminal and allow receive lane port to be coupled to any physical adaptor receive lane terminal. In other embodiments, timing restrictions may limit the cross-point interconnect capability to a subset of all possible connections.
In some embodiments, configuration of multiplexor 340 and demultiplexor 350 may be performed by software executed on a CPU in processing logic 302 to optimize performance of one or more application programs being executed by processing logic 302, for example. For example, if an application is being executed that uses LLI controller 310 heavily, but uses LLI controller 311 only lightly, or not at all, extra lanes may be allocated to LLI controller 310 and taken away from LLI controller 311. When a second application begins executing that may use LLI controller 311 more heavily, lanes may be reshuffled again to optimize the performance of the second application.
In this manner, rather than implementing a maximum number of M-PHY lane ports for all of the controllers 310-314, as done in prior art, a reduced set of M-PHY lanes may be implemented in transmit lane pool 330 and receive lane pool 332 and be configured as needed depending on what application is being performed by IC 300. When IC 300 is designed, the size of M-PHY transmit lane pool 330 and M-PHY receive lane pool 332 may be selected based on an amount of real estate available on the chip, for example.
Demultiplexor 350 is configured by software to couple a number m receive lane ports 351 to LLI controller 310, a number q receive lane ports 352 to UniPro controller 312, and a number s receive lane ports 353 to LLI controller 311. m is less than or equal to the maximum number of receive lanes that physical adaptor 320 can support. q is less than or equal to the maximum number of receive lanes that physical adaptor 322 can support. s is less than or equal to the maximum number of receive lanes that physical adaptor 321 can support.
In example configuration 2, multiplexor 340 is configured by software to couple two transmit lanes 441 to LLI controller 310, two transmit lanes 441 to UniPro controller 312, ten transmit lanes 443 to LLI controller 311, and one transmit lane 444 to LLI controller 313, for example.
Demultiplexor 350 is configured by software to couple ten receive lanes 451 to LLI controller 310, two receive lanes 452 to UniPro controller 312, one receive lane 453 to LLI controller 311, and ten receive lanes 454 to LLI controller 313, for example.
Note that in some configurations, some of the controllers or some of the M-PHY lanes may be used.
In this example, multiplexor 340 may be implemented as forty individual multiplexors, where each of the forty multiplexors is connected to one of the M-PHY TX lane ports in transmit pool 330. Each of the forty multiplexors may be configured to select any M-PHY transmit lane from any one of the physical adaptors 320-324, as described above. Similarly, demultiplexor 350 may be implemented as forty individual demultiplexors, where each of the forty demultiplexors is connected to one of the M-PHY RX lane ports in receive pool 332. Each of the forty demultiplexors may be configured to select any M-PHY receive lane from any one of the physical adaptors 320-324, as described above. Other embodiments may implement multiplexor 340 and demultiplexor 350 using multiplexor/demultiplexor or cross bar technology now known or later developed.
A fixed set of lanes 522 are coupled between the input/output pins on IC 501 and IC 510 that couple to M-PHY interconnect 504 and 514. From this fixed set of lanes, a selectable number of lanes may be allocated to M-PHY link 521 and 522. As described above, the number of lanes allocated to each M-PHY link 521, 522 may be dynamically configured at power up and later during operation of system 500 to optimize performance of ICs 501, 510. In this example, LLI controllers 502 and 512 and M-PHY link 522 allow CPU 516 on IC 510 to access DDR (dual data rate) memory 530 that is coupled to IC 501 just as if DDR memory 530 was coupled directly to IC 510. UniPro controllers 503 and 513 and M-PHY link 521 may be used for other types of communication between IC 501 and IC 510.
In the example of system 500, IC 501 is the System Master, and IC 510 the System Slave. Devices on the Master Chip and the Slave Chip attached to LLI Link 522 are memory-mapped for easy device addressing. The Master Chip controls the Slave Chip and manages the overall system memory map. Thus, the Master Chip sees devices on the Slave Chip as if they are attached to its own interconnect. A LLI resource appears as a device on both the Master Chip interconnect and the Slave Chip interconnect. The control of the local and remote LLI resource are similar to control of a resource connected to the local interconnect, simplifying system design. Configuration, boot interface and management of the physical layer, e.g. M-PHYSM GEAR change, M-PHY power mode, etc., are part of the system software (drivers) and may be implemented in conformance with MIPI standards.
The system on master chip 501 may control the power management of the LLI resources located on slave chip 510 thanks to service transactions. The system also controls power management of the local LLI resources. Service transactions may also used to transfer signal values between the two chips.
A LLI stack receives a Transaction Fragment from the local interconnect and converts it to an appropriate PHIT for transmission by the physical layer (PHY) to the remote chip. The PHY Layer converts the PHIT to PHY Symbols and sends the Symbols to the remote chip. A LLI stack receives one or more PHITs from the remote chip, via the local PHY Layer, and converts them into the original Transaction Fragment that is then executed by the Target on the local interconnect. Transaction Fragments are passed to and from the local interconnect using service access points (SAPs). A SAP provides service primitives to transfer Transaction Fragments to, or from, the LLI stack. Since transactions with the remote device can take longer to execute than transactions with local devices, a SAP also provides service primitives to communicate transaction status. A LLI stack can also communicate with devices using signals. Signals are individual signal lines that are converted by the Interconnect Adaptation Layer to Transaction Fragments that are then passed to the remote LLI stack in the same manner as if the Transaction Fragments were received through a SAP. At the remote LLI stack, the Transaction Fragments are converted back to signals.
The Interconnect Adaptation Layer is responsible for adapting the LLI Transaction Layer to a transaction-based interconnect that manages communications inside a chip. An interconnect transaction is typically composed of one or more read or write request transfer cycles, optional write data transfer cycles, and zero or more response transfer cycles. From the Interconnect Adaptation Layer point of view, a LLI Transaction is composed of a LLI Request Unit and a LLI Response Unit, each of which is composed of one or more LLI Fragments. Where the LLI Link acts as a target of the interconnect (LLI Target SAP), the Interconnect Adaptation Layer maps interconnect request and write data transfer cycles to LLI Fragments forming one or more LLI Request Units, and also maps the associated returned LLI Fragments forming the LLI Response Units to the proper response transfer cycles according to the interconnect protocol. In general, a single LLI transaction, i.e., a single pair of LLI Transaction Request and Response Units, is all that is needed for a given interconnect transaction, but in some cases several such pairs might be necessary. For example, if the interconnect transaction has a length greater than the maximum LLI Transaction length, the interconnect transaction must be split by the Interconnect Adaptation Layer into several LLI Request Units and associated Response Units, each of which is composed of its LLI Fragments. It is then the responsibility of the Interconnect Adaptation Layer to process and merge the LLI Response Units to create the appropriate interconnect response transfer cycles for the single interconnect transaction. After being transported through the local LLI stack, LLI Transaction Fragments constituting Request Units reach the remote LLI stack on a LLI Initiator SAP where the remote Interconnect Adaptation Layer converts them to interconnect request and write data transfer cycles. Note that the local interconnect protocol might differ from the remote interconnect protocol, so that the interconnect transfer cycles usually differ between the local and remote sides of the LLI Link. At an LLI Initiator SAP, the Interconnect Adaptation Layer also maps interconnect response transfer cycles to LLI Transaction Fragments constituting a LLI Response Unit corresponding to the associated LLI Request Unit. These LLI Transaction Fragments are transported back through the LLI stack to the target SAP that originated the LLI Transaction; where the Interconnect Adaptation Layer converts them into the appropriate interconnect response transfer cycles.
A detailed description of an LLI controller requirement is provided in the “MIPI Alliance Specification for Low Latency Interface (LLI),” which is available from the MIPI Alliance.
As described in more detail above, embodiments of the invention allow the number of M-PHY lanes allocated to a particular LLI protocol to be dynamically configured based on what application is being executed in a system. For example, a single lane 735 may be allocated for low performance needs, while additional lanes 734 may be allocated to an LLI controller to provide a higher level of communication performance. The number of lanes that are recognized by the LLI protocol stack is controlled by PA configuration registers 643.
In a similar manner, a UniPro protocol stack or other defined communication protocols may be dynamically configured to respond to a dynamically configured number of M-PHY lanes that are allocated to a controller for that protocol.
The system is turned on and each of the integrated circuits is initialized 802. Typically, an integrated circuit may be initialized by executing a boot program that is stored in non-volatile memory by a CPU within the integrated circuit. The cross-point switch may be initialized to a default configuration by a power-on reset signal. After completing the boot procedure, or as part of the boot procedure, a program may be executed that may further con
As described above in more detail, the cross-point switch is coupled between a set of communication controllers and a set of serial communication lane ports that drive and receive data from external pins on the IC. The cross-point switch is configured to allocate 804 a first portion of the set of point to point serial communication lane ports for use by one of the communication controllers in the IC and a second portion of the set of point to point serial communication lane ports for use by a second communication controller in the IC. If there are more than two communication controllers in the IC, portions of the set of point to point serial communication lanes may be allocated to them also.
Once the cross-point switch is configured, an application program being executed in the system may transmit and receive data 806 via the first communication controller using the first portion of serial communication lanes and via the second communication controller using the second portion of serial communication lanes.
At some point in time, a different application program may be executed 808. The cross-point switch may be reconfigured 810 to couple a different number of transmit lanes and/or receive lanes to some or all of the communication controllers. Once the cross-point switch is reconfigured, the different application program being executed in the system may transmit and receive data 806 via the first communication controller using the new allocation of serial communication lanes and via the second communication controller using the new allocation of serial communication lanes.
Different application programs may also configure a particular communication controller to use different protocols at different times. For example, a controller may communicate using an LLI protocol for a period of time, and then communicated using a UniPort, or other type of protocol for another period of time. The number of serial lanes allocated to the controller may be adjusted based on what protocol is being used at the time.
The serial communication lanes may be a set of M-PHY lanes, or may be a set of D-PHY lanes, for example. In another embodiment, other types of serial point to point communication lanes may be used, such a PCI Express lanes, for example.
IC 902 is coupled to modem IC 904 that performs audio signal conversion and radio frequency signal conversion. IC 902 is coupled to modem IC 904 via LLI link 924 and UniPro link 925. IC 902 is coupled to bridge IC 903 via LLI link 927 and UniPro link 926. Modem IC 903 is coupled to radio frequency transceiver IC 905 via DigRF link 928.
All of the M-PHY links 921-928 contain a number of serial transmit and receive lanes, as described in more detail above. Application processor IC 902 includes a cross-point switch as described in more detail above that allows the number of serial lanes allocated to each link 921-927 to be configured when the smart phone is powered on. This allows IC 902 to be used in system 900 with a selected number of lanes allocated to links 921-927, but allows the same version of IC 902 to be used in a different system in which a different allocation of links may be needed. In this manner, a single version of IC 902 may be manufactured and then the serial communication lanes may be configured as needed for different system implementations.
While the invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various other embodiments of the invention will be apparent to persons skilled in the art upon reference to this description. For example, embodiments of the invention may include smart phones, laptop computers, computer tablets, and all manner of portable computing systems in which the same version of an integrated circuit may be used in different products and configured when the product is turned on to allocate pins on the integrated circuit that provide serial communication lanes to different combinations of communication links on each of the different products. Likewise, embodiments of the invention may included personal computers, mainframe computers and all manner of fixed computing systems in which the same version of an integrated circuit may be used in different systems or in different portions of a same system and configured when the system is turned on to allocate pins on the integrated circuit that provide serial communication lanes to different combinations of communication links on each of the different systems.
While embodiments of the invention have been described with reference to LLI, UniPro, CSI, etc, SerDes (serializer-deserializer) interfaces, other embodiments may include other types of SerDes interfaces that are now known or later developed.
While embodiments of the invention have been described with reference to M-PHY physical lanes, other embodiments may use D-PHY lanes, PCIe lanes, or other physical types of serial communication channels now known or later developed.
In some embodiments, the multiplexor and demultiplexor may function as a complete cross-point switch and allow any transmit lane to be coupled to any physical adaptor transmit lane terminal and allow receive lane to be coupled to any physical adaptor receive lane terminal. In other embodiments, timing restrictions may limit the cross-point interconnect capability to a subset of all possible connections.
The techniques described in this disclosure may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the software may be executed in one or more processors, such as a microprocessor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), or digital signal processor (DSP). The software that executes the techniques may be initially stored in a computer-readable medium such as compact disc (CD), a diskette, a tape, a file, memory, or any other computer readable storage device and loaded and executed in the processor. In some cases, the software may also be sold in a computer program product, which includes the computer-readable medium and packaging materials for the computer-readable medium. In some cases, the software instructions may be distributed via removable computer readable media (e.g., disk, optical disk, flash memory, USB key), via a transmission path from computer readable media on another digital system, etc.
Certain terms are used throughout the description and the claims to refer to particular system components. As one skilled in the art will appreciate, components in digital systems may be referred to by different names and/or may be combined in ways not shown herein without departing from the described functionality. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” and derivatives thereof are intended to mean an indirect, direct, optical, and/or wireless electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, through an indirect electrical connection via other devices and connections, through an optical electrical connection, and/or through a wireless electrical connection.
Although method steps may be presented and described herein in a sequential fashion, one or more of the steps shown and described may be omitted, repeated, performed concurrently, and/or performed in a different order than the order shown in the figures and/or described herein. Accordingly, embodiments of the invention should not be considered limited to the specific ordering of steps shown in the figures and/or described herein.
It is therefore contemplated that the appended claims will cover any such modifications of the embodiments as fall within the true scope and spirit of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 12290373.5 | Oct 2012 | EP | regional |
