UniPro protocol stack: Difference between revisions

Content deleted Content added
m top: Typo fixing, replaced: Iterface → Interface
 
(11 intermediate revisions by 7 users not shown)
Line 1:
{{short description|Interface technology communication architecture}}
{{About|a technical explanation of the architecture of the [[UniPro]]<sup>SM</sup> protocol stack|an overview of the protocol stack, its purpose, usage and status|UniPro}}
 
In mobile-telephone technology, the '''UniPro protocol stack'''<ref name="UniPro1.1">[https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_UniPro_Specification_v01-10-01a.pdf MIPI Alliance Specification for Unified Protocol (UniPro<sup>SM</sup>) v1.10.01 ], requires an account at the MIPI website</ref> follows the architecture of the classical [[OSI model|OSI Reference Model]]. In [[UniPro]], the OSI Physical Layer is split into two sublayers: Layer 1 (the actual physical layer) and Layer 1.5 (the PHY Adapter layer) which abstracts from differences between alternative Layer 1 technologies. The actual physical layer is a separate specification as the various PHY options are reused<ref>[http://www.mipi.org/specifications Overview of MIPI specifications], D-PHY is used in the DSI, CSI, and UniPro specifications, M-PHY is used in the UniPro, DigRFv4 and LLI specifications</ref> in other [[Mobile Industry Processor Interface|MIPI Alliance]] specifications.
Line 48 ⟶ 49:
 
===D-PHY===
Versions 1.0 and 1.1 of UniPro use MIPI's [[D-PHY]] technology for the off-chip Physical Layer. This PHY allows inter-chip communication. Data rates of the D-PHY are variable, but are in the range of 500-1000 &nbsp;Mbit/s (lower speeds are supported, but at decreased power efficiency). The D-PHY was named after the Roman number for 500 ("D").
 
The [[D-PHY]]<ref>[https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_D-PHY_specification_v01-00-00.pdf MIPI Alliance Specification for D-PHY v1.00.00] {{Webarchive|url=https://web.archive.org/web/20110727084541/https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_D-PHY_specification_v01-00-00.pdf |date=2011-07-27 }}, requires an account at the MIPI website</ref> uses differential signaling to convey PHY symbols over micro-stripline wiring. A second differential signal pair is used to transmit the associated clock signal from the source to the destination. The D-PHY technology thus uses a total of 2 clock wires per direction plus 2 signal wires per lane and per direction. For example, a D-PHY might use 2 wires for the clock and 4 wires (2 lanes) for the data in the forward direction, but 2 wires for the clock and 6 wires (3 lanes) for the data in the reverse direction. Data traffic in the forward and reverse directions are totally independent at this level of the protocol stack.
 
In UniPro, the D-PHY is used in a mode (called "8b9b" encoding) which conveys 8-bit bytes as 9-bit symbols. The UniPro protocol uses this to represent special control symbols (outside the usual 0 to 255 values). The PHY itself uses this to represent certain special symbols that have meaning to the PHY itself (e.g. IDLE symbols). Note that the ratio 8:9 can cause some confusion when specifying the data rate of the D-PHY: a PHY implementation running with a 450&nbsp;MHz clock frequency is often rated as a 900 &nbsp;Mbit/s PHY, while only 800 &nbsp;Mbit/s is then available for the UniPro stack.
 
The D-PHY also supports a Low-Power Data Transmission (LPDT) mode and various other low-power modes for use when no data needs to be sent.
 
==={{Anchor|M-PHY}}M-PHY===
Versions 1.4 and beyond of UniPro support both the [[D-PHY]] as well as [[M-PHY]]<ref>[https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_M-PHY_specification_v1-00-00.pdf MIPI Specification for M-PHY version 1.00.00] {{Webarchive|url=https://web.archive.org/web/20111007190626/https://members.mipi.org/mipi-adopters/file-fix/Specifications/Board%20Approved/mipi_M-PHY_specification_v1-00-00.pdf |date=2011-10-07 }}, requires an account at the MIPI website</ref> technology. The M-PHY technology is still in draft status, but supports high-speed data rates starting at about 1000 &nbsp;Mbit/s (the M-PHY was named after the Roman number for 1000). 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 [[8B/10B encoding|8b10b encoding]]. Again, a PHY capable of transmitting user data at 1000 &nbsp;Mbit/s is typically specified as being in 1250 &nbsp;Mbit/s mode due to the 8b10b encoding.
 
{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"
Line 67 ⟶ 68:
| align="center" | 1.2/September 2014
| align="center" | 8b/9b
| align="center" | 4.5 GbpsGbit/s/lane
| align="center" | 4 lane port
| align="center" |
Line 74 ⟶ 75:
| align="center" | 3.1/June 2014
| align="center" | 8b/10b
| align="center" | 11.6 GbpsGbit/s/lane
| align="center" | 4+1 lane port
| align="center" |
Line 81 ⟶ 82:
| align="center" | 1.00.00 / October 2014
| align="center" |
| align="center" | ? 2.28Gbps5Gbit/s/lane ?
| align="center" | 3 lane port
| align="center" |
Line 90 ⟶ 91:
===Low speed modes and power savings===
 
It is worth noting that UniPro supports the power efficient low speed communication modes provided by both the D-PHY (10 &nbsp;Mbit/s) and M-PHY (3 &nbsp;Mbit/sec up to 500 &nbsp;Mbit/s). In these modes, power consumption roughly scales with the amount of data that is sent.
Furthermore, both PHY technologies provide additional power saving modes because they were optimized for use in battery-powered devices.
 
Line 101 ⟶ 102:
|+ ''Example sequence of a UniPro's 17-bit L1.5 symbols''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00
|- style="background:#F8F8F8; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 163 ⟶ 164:
|+ ''Example UniPro Data Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 197 ⟶ 198:
|+ ''Example UniPro Control Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 212 ⟶ 213:
High speed communication at low power levels can lead to occasional errors in the received data. The Data Link layer contains a protocol to automatically acknowledge correctly received data frames (using AFC control frames) and to actively signal errors that can be detected at L2 (using NAC control frames). The most likely cause of an error at L2 is that a data frame was corrupted at the electrical level (noise, EMI). This results in an incorrect data or control frame checksum at the receiver side and will lead to its automatic retransmission. Note that data frames are acknowledged (AFC) or negatively acknowledged (NAC). Corrupt control frames are detected by timers that monitor expected or required responses.
 
A bandwidth of 1 &nbsp;Gbit/s and a bit-error rate of 10<sup>−12</sup> at a speed of 1 gigabit/s would imply an error every 1000 seconds or once every 1000th transmitted Gbit. Layer 2 thus automatically corrects these errors at the cost of marginal loss of bandwidth and at the cost of buffer space needed in L2 to store copies of transmitted data frames for possible retransmission or "replay".
 
===L2 flow control===
Line 249 ⟶ 250:
===L3 short-header packet structure===
 
UniPro short-header packets use a single header byte for L3 information. It includes the 7-bit L3 destination address. The remaining bit indicates the short-header packet format. For short-header packets, the L3 source address is not included in the header because it is assumed that the two communicating devices have exchanged such information beforehand ([[connection-oriented]] communication]]).
 
{| border="1" cellpadding="3" style="margin: 1em auto 1em auto"
|+ ''UniPro Short-Header Packet within a Data Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1
Line 308 ⟶ 309:
|+ ''UniPro Segment within a Data Frame''
|- style="background:#D8D8D8; color:black"
| align="center background:#FF1804;" | ctl || b15 || b14 || b13 || b12 || b11 || b10 || b09 || b08 || b07 || b06 || b05 || b04 || b03 || b02 || b01 || b00
|- style="background:#FF9400; color:black" align="center"
| style="background:#FF1804; color:white" | 1