Mipi Unipro Specification v14000 PDF
Mipi Unipro Specification v14000 PDF
Mipi Unipro Specification v14000 PDF
* CAUTION TO IMPLEMENTERS *
Implementers should be aware that a licensing objection was received from Intel in regard to
version 0.80.00 of this specification, MIPI Alliance Standard for Unified Protocol (UniPro), Version
0.80.00, dated 6 September 2006 and adopted by the MIPI Board of Directors on 26 February 2007
(UniPro v0.80.00). The UniPro v0.80.00 Specification is available at https://members.mipi.org/mipi-
adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v00-80-00.pdf.
Intel's licensing objection is available at https://members.mipi.org/mipi-
adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v00-80-
00_Intel%20Licensing%20Objection.pdf.
Licensing objections are defined in Article X, Section 1 of the MIPI Bylaws. Member companies
considering implementation or use of this standard are strongly encouraged to review this
information.
UniPro v0.90.00 was drafted by the MIPI UniPro Working Group taking into account the Licensing
Objection of Intel with respect to UniPro v0.80.00. UniPro v0.90.00 was renumbered to v1.00.00
upon approval by the MIPI Board as a MIPI Specification. The UniPro v1.00.00 Specification is
available at https://members.mipi.org/mipi-
adopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v01-00-00.pdf.
Following the WG completion of UniPro v0.90.00, Intel expressed the following view:
Intel notes that the same Necessary Claims identified in our prior License
Objection are applicable to this latest Draft. However, Article X, Sec 1(3) of the
Bylaws provides that since Intel properly submitted its Licensing Objection,
“[Intel's] licensing obligations under the terms of its MIPI Membership Agreement
shall terminate” with respect to those identified Necessary Claims. Accordingly,
since those Necessary Claims are no longer subject to any MIPI licensing
* NOTE TO IMPLEMENTERS *
This document is a MIPI Specification adopted by the MIPI Board of Directors. MIPI member
companies’ rights and obligations apply to this MIPI Specification as defined in the MIPI
Membership Agreement and MIPI Bylaws.
This UniPro v1.40.00 draft specification is an update to the UniPro v1.10.01 specification.
The UniPro v1.40.00 specification consists of two separate physical documents:
• MIPI Alliance Specification for Unified Protocol (UniProSM), Version 1.40.00
• MIPI Alliance Specification for Unified Protocol (UniProSM): SDL State Machines, Version
1.40.00.
It also references MIPI Alliance Specification for M-PHY, Version 1.00.00 to define the underlying
physical layer.
The SDL document is a part of the UniPro v1.40.00 specification. It provides a formal model of the
behavior of the specified algorithms. Note that in UniPro v1.40.00, an SDL model for all Layers
(PHY Adapter–M-PHY only, Data Link, Network and Transport) and Device Management Entity
(DME) is provided. The SDL model is intended to be consistent with the textual descriptions in the
first document. In case of ambiguity in the text or an unintended discrepancy between the
documents, implementers should refer to the SDL model.
Backwards Compatibility
The UniPro v1.40.00 specification with D-PHY physical layer was designed to ensure
interoperability with UniPro v1.10.01 and UniPro v1.00.00 versions.
Main Changes
This release contains editorial and non-editorial updates to the previous release. These updates
address typographical and grammatical errors, inconsistencies in terminology and labeling, and
incomplete cross-references. The updates also provide clarification of key concepts based on
working group member company feedback. This release adds support for the option of disabling
the CSV feature of the Transport Layer (L4).
Further technical changes to this document are expected as work continues in the UniPro Working Group
NOTICE OF DISCLAIMER
The material contained herein is not a license, either expressly or implicitly, to any IPR owned or controlled
by any of the authors or developers of this material or MIPI®. The material contained herein is provided on
an “AS IS” basis and to the maximum extent permitted by applicable law, this material is provided AS IS
AND WITH ALL FAULTS, and the authors and developers of this material and MIPI hereby disclaim all
other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if
any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of
accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of
negligence.
All materials contained herein are protected by copyright laws, and may not be reproduced, republished,
distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior
written permission of MIPI Alliance. MIPI, MIPI Alliance and the dotted rainbow arch and all related
trademarks, tradenames, and other intellectual property are the exclusive property of MIPI Alliance and
cannot be used without its express prior written permission.
ALSO, THERE IS NO WARRANTY OF CONDITION OF TITLE, QUIET ENJOYMENT, QUIET
POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD
TO THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT. IN NO EVENT WILL ANY
AUTHOR OR DEVELOPER OF THIS MATERIAL OR THE CONTENTS OF THIS DOCUMENT OR
MIPI BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS
OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,
CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER
CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY
OTHER AGREEMENT, SPECIFICATION OR DOCUMENT RELATING TO THIS MATERIAL,
WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH
DAMAGES.
Without limiting the generality of this Disclaimer stated above, the user of the contents of this Document is
further notified that MIPI: (a) does not evaluate, test or verify the accuracy, soundness or credibility of the
contents of this Document; (b) does not monitor or enforce compliance with the contents of this Document;
and (c) does not certify, test, or in any manner investigate products or services or any claims of compliance
with the contents of this Document. The use or implementation of the contents of this Document may
involve or require the use of intellectual property rights (“IPR”) including (but not limited to) patents, patent
applications, or copyrights owned by one or more parties, whether or not Members of MIPI. MIPI does not
make any search or investigation for IPR, nor does MIPI require or request the disclosure of any IPR or
claims of IPR as respects the contents of this Document or otherwise.
Questions pertaining to this document, or the terms or conditions of its provision, should be addressed to:
MIPI Alliance, Inc.
c/o IEEE-ISTO
445 Hoes Lane
Piscataway, NJ 08854
Attn: Board Secretary
Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Release History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Architecture Overview (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 UniPro Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 The UniPro SDL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Comparison of UniPro to the OSI/RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 Service Access Points (SAP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.2 SAP Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Data Flow through the Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Signal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.1 CPort Signal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.2 Interface to the Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.3 T-PPI Interface for Testing (D-PHY oriented). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.4 T-MPI Interface for Testing (M-PHY oriented). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Protocol Data Units (PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7 Physical Layer (L1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7.1 D-PHY and M-PHY Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7.2 L1 Symbol Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.3 D-PHY Data Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.4 M-PHY Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7.5 D-PHY Power States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7.6 M-PHY Power States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7.7 L1 Idles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8 PHY Adapter Layer (L1.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8.1 L1.5 Multi-lane Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8.2 L1.5 Power States and Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.8.3 L1.5 and Symbol Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8.4 PACP Frames as Used with M-PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8.5 L1.5 Automatic Capability Discovery (M-PHY only) . . . . . . . . . . . . . . . . . . . . . . . 45
Figures
Figure 1 Scope of the UniPro Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2 Comparison of UniPro and OSI/RM Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 3 Simplified Model of a Single UniPro Link Connecting Two Devices. . . . . . . . . . . . 36
Figure 4 17-bit PHY Adapter Layer Symbol Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 5 PACP Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 6 Example Data Frame with an Even Number of Payload Bytes . . . . . . . . . . . . . . . . . 46
Figure 7 Example Data Frame with an Odd Number of Payload Bytes. . . . . . . . . . . . . . . . . . 46
Figure 8 AFC Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 9 NAC Control Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 10 Example Short Header Packet Encapsulated within an L2 Data Frame . . . . . . . . . . 49
Figure 11 Example of a Short Header Segment in a Short Header Packet in an L2 Frame . . . . 50
Figure 12 Point-to-Point Configuration Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 13 UniPro Network Configuration Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 14 PHY Adapter Layer SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 15 Data PA_PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 16 Escaped Data PA_PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 17 DL Escaped Data PA_PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 18 DL Escaped Data PA_PDU with EscType=ESC_DL . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 19 PA Escaped Data PA_PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 20 PHY Adapter PDU Ordering in a Single Lane Configuration . . . . . . . . . . . . . . . . . . 89
Figure 21 PHY Adapter PDU Ordering in a Dual Lane Configuration . . . . . . . . . . . . . . . . . . . 89
Figure 22 PHY Adapter PDU Ordering in a Three Lane Configuration . . . . . . . . . . . . . . . . . . 89
Figure 23 PHY Adapter PDU Ordering in a Four Lane Configuration . . . . . . . . . . . . . . . . . . . 90
Figure 24 Power Mode Change Procedure for D-PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 25 Link Startup Sequence Example with One Node Initiating the Sequence (D-PHY only)
96
Figure 26 Link Startup Sequence Example with Both Nodes Initiating the Sequence (D-PHY on-
ly)98
Figure 27 Encoded D-PHY Symbol Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 28 End of Burst Sequence with PA_TxTrailingClocks = 3, PA_ActiveTxDataLanes = 2,
and Odd Number of PA_PDUs (informative)107
Figure 29 PACP Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 62 Definition of Frame Acknowledgment Timer and Replay Timer for TC0 . . . . . . . 183
Figure 63 CRC Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Figure 64 Bit Allocation for CRC-16 Checksum in DL Layer Data Symbol. . . . . . . . . . . . . . 191
Figure 65 Initial Credit Exchange Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 66 Network Layer SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 67 N_SAPs, Network Address and DeviceID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Figure 68 Network Layer Data Transfer Using Different Traffic Classes . . . . . . . . . . . . . . . . 201
Figure 69 Relationship of Network Service Characteristics and Underlying Services . . . . . . 202
Figure 70 Network Layer Data N_PDU with Short Header (DT SH N_PDU) . . . . . . . . . . . . 217
Figure 71 Network Layer Composition Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Figure 72 Network Layer Decomposition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 73 Transport Layer SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 74 T_SAPs, Transport Address and CPortID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Figure 75 Concept of a Transport-level Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Figure 76 Data T_PDU with Short Header (DT SH T_PDU) . . . . . . . . . . . . . . . . . . . . . . . . . 244
Figure 77 Transport Layer Segmentation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure 78 Transport Layer Reassembly Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 79 Transport Layer Composition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure 80 Transport Layer Decomposition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure 81 Data Transmission using E2E FC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Figure 82 Interrupted Data Transmission using E2E FC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Figure 83 Discard of Segment Payload Due to Lack of Credits. . . . . . . . . . . . . . . . . . . . . . . . 256
Figure 84 Successful Data Transmission with Controlled Segment Dropping . . . . . . . . . . . . 257
Figure 85 Unsuccessful Data Transmission Due to Interim Lack of Credits . . . . . . . . . . . . . . 258
Figure 86 Test Feature Location within the Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Figure 87 Inter-message Gap Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Figure 88 E2EFC Behavior in TstDst Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Figure 89 MSC of Network Layer and Transport Layer Interaction . . . . . . . . . . . . . . . . . . . . 274
Figure 90 Device Management Entity SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Figure 91 Attribute Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Figure 92 Hibernating a Peer-to-Peer Link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 93 Hibernate High Level Entry Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Figure 94 Hibernate Entry Flow Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Tables
Table 1 PA_SAP Data Transfer Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 2 PA_SAP Data Transfer Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 3 PA_SAP Control Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table 4 PA_SAP Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table 5 PA_SAP Status Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 6 PA_SAP Status Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 7 PA_LM Configuration Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 8 Configuration Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 9 PowerChangeResultCode Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 10 PA_LM Control Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 11 PA_LM Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Table 12 PA_LM_SAP Status Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 13 PA_LM_SAP Status Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 14 UniPro Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 15 Link Startup Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Table 16 Encoded D-PHY Low Symbol Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 17 Encoded D-PHY High Symbol Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table 18 Encoded D-PHY Symbol Mapping Example (informative) . . . . . . . . . . . . . . . . . . 100
Table 19 UniPro Power State to D-PHY State Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table 20 D-PHY to UniPro Error Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table 21 Low-speed Trigger Event to D-PHY Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table 22 High-speed Trigger Event to D-PHY Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Table 23 Global Operation Timing Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 24 UniPro Power State to M-PHY State Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table 25 TRG_UPR0 Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 26 TRG_UPR1 Mapping Examples (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Table 27 PACP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 28 PACP_PWR_cnf Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 29 PHY Test Pattern PACP Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table 30 CJTPAT Test Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Table 31 CRPAT Test Pattern PA Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Table 32 PHY Adapter Protocol Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Table 33 PHY Adapter (gettable, settable) Common Attributes. . . . . . . . . . . . . . . . . . . . . . . 136
Table 34 PHY Adapter (gettable, static) Common Attributes. . . . . . . . . . . . . . . . . . . . . . . . . 136
Table 35 PHY Adapter (gettable, dynamic) Common Attributes . . . . . . . . . . . . . . . . . . . . . . 137
Release History
Date Release Description
2011-04-28 1.40.00 Board approved release.
1 Introduction
1 The MIPI Alliance Specification for Unified Protocol (UniPro) defines a layered protocol for interconnecting
Devices and components within mobile systems such as cellular telephones, handheld computers, digital
cameras, and multimedia Devices. UniPro enables these Devices and components to utilize MIPI PHY layers
in order to exchange data at high data rates, with low pin counts and at low energy per transferred bit. UniPro
is applicable to a wide range of component types such as Application processors, co-processors, modems, etc.
and to different types of data traffic such as control messages, bulk data transfer, packetized streaming.
2 This document refers to MIPI Alliance Specification for UniPro: SDL State Machines [MIPI02] for formal
definition of PHY Adapter for M-PHY (L1.5), Data Link (L2), Network (L3), Transport (L4), layer protocols
and Device Management Entity (DME). In addition, other MIPI Alliance specifications are used for
definition of physical layer and Application Layer protocols. As such, this specification can be thought of as
a member of a family of specifications.
3 To aid in understanding the concepts presented in this specification, the UniPro description is loosely based
on the ISO OSI Reference Model (OSI/RM). See Section 4.3 for more information on the similarities and
differences to the OSI/RM.
1.1 Scope
4 This document defines the protocol used to transfer data between Devices that implement the UniPro
specification. This includes definitions of data structures, such as Packets and Frames, used to convey
information across the Network. In addition, flow control, error handling, power and state management, and
connection services are also within the scope of this document.
5 The PHY Adapter, Data Link, Network and Transport layer protocols are described in Section 5, Section 6,
Section 7 and Section 8, respectively, as well as in [MIPI02]. The DME (Section 9) is also described in
[MIPI02].
6 The electrical interface, physical layer timing and encoding, Application-specific protocols and command
sets are out of scope for this document.
7 Figure 1 shows the scope of this document as it relates to the OSI/RM. Throughout this document, layer
references are to the UniPro layering scheme unless otherwise indicated.
Application-specific Protocols
Network (L3)
PHY (L1)
Medium
1.2 Purpose
8 This specification can be used by manufacturers to design products that adhere to MIPI Alliance
specifications for host processor and peripheral interfaces.
9 Implementing the UniPro specification reduces the time-to-market and design cost of mobile Devices by
simplifying the interconnection of products from different manufacturers. In addition, implementing new
features is simplified due to the extensible nature of the UniPro specification.
2 Terminology
10 The MIPI Alliance has adopted Section 13.1 of the IEEE Specifications Style Manual, which dictates use of
the words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:
11 The word shall is used to indicate mandatory requirements strictly to be followed in order
to conform to the Specification and from which no deviation is permitted (shall equals is
required to).
12 The use of the word must is deprecated and shall not be used when stating mandatory
requirements; must is used only to describe unavoidable situations.
13 The use of the word will is deprecated and shall not be used when stating mandatory
requirements; will is only used in statements of fact.
14 The word should is used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of
action is preferred but not necessarily required; or that (in the negative form) a certain
course of action is deprecated but not prohibited (should equals is recommended that).
15 The word may is used to indicate a course of action permissible within the limits of the
Specification (may equals is permitted).
16 The word can is used for statements of possibility and capability, whether material,
physical, or causal (can equals is able to).
17 All sections are normative, unless they are explicitly indicated to be informative.
18 Numbers are decimal unless otherwise indicated. A prefix of 0x indicates a hexadecimal number, while a
prefix of 0b indicates a binary number.
19 This document uses the C/Verilog representation for operators where bitwise AND is represented by ‘&’,
bitwise OR is represented by ‘|’, bitwise XOR is represented by ‘^’ and 1’s complement (negation) is
represented by ‘~’.
20 Named constants, e.g. FAST_STATE, and Service Primitive names (Section 2.2) are shown in all capital
letters.
2.1 Definitions
21 Application (Layer): Logic or functionality within a Device that uses the services provided by the Transport
Layer as provided by the UniPro stack.
22 Attribute: Atomic unit of information that can be read or written from an Application using DME_GET or
DME_SET primitives, and DME_PEER_GET or DME_PEER_SET primitives. Attributes can be used to
configure the behavior of a UniPro stack, to determine the current state of the interface or to determine the
availability of interface options and interface capabilities.
23 Big-endian: This term describes the order in which a sequence of bytes are stored in computer memory. Big-
endian is an order in which the “big end” (most significant value in the sequence) is stored at the lowest
memory address.
24 Checksum: See Cyclic Redundancy Check (CRC).
25 Clock Lane: A unidirectional interconnect between two UniPorts which carries clock information needed for
decoding the data on the Data Lanes. Some PHY technologies require this. The PHY Adapter Layer abstracts
from whether or not a Clock Lane is required.
26 Component: A physical entity such as an integrated circuit containing at least one Device or switch.
27 Composition: The process of adding header, and possibly trailer, information to the PDU of an upper layer to
build a lower layer PDU.
28 Connection: A Connection is a bidirectional, logical communication channel between two CPorts. It is a
concept used for Connection-oriented data transmission, whereby two Devices need to be connected before
data can be exchanged.
29 Connection-oriented data transmission: The transfer of a SDU from a source Service Access Point to a
destination Service Access Point within the context of a Connection that has previously been established.
30 CPort: A CPort is a Service Access Point on the Transport Layer (L4) within a Device that is used for
Connection-oriented data transmission.
31 CPort Safety Valve: A mechanism whereby a CPort discards received data whenever the CPort cannot
deliver Segments at the rate at which they arrive. The mechanism is intended to manage Network congestion
and avoid certain types of system-level deadlocks.
32 Critical (M-PHY) Attributes: A set of control Attributes for M-PHY MODULEs that get special treatment
within UniPro L1.5 because they are set using the UniPro PA Control Protocol (PACP).
33 Cyclic Redundancy Check (CRC): A coding scheme to detect errors in transferred data. The CRC is used to
produce a checksum, which is typically a small number of bits, for a larger block of data, such as a Packet.
34 Credit-based Flow Control: A method to control the speed of data transfer between two entities. The
receiving side notifies the sending side that space is available in the receiving side buffer by issuing credits.
The sending side may then transfer data up to the credit limit.
35 D-PHY: High-speed serial interconnect technology, based on source synchronous signaling, that is defined
in MIPI Alliance Specification for D-PHY [MIPI01].
36 Data Lane: A physical interconnect between two UniPorts which carries data. A Link can consist of 1, 2, 3 or
4 Data Lanes per direction. A Data Lane in UniPro is used unidirectionally. A Lane with embedded clocking
information is also considered a Data Lane.
37 Data Link (DL) Layer (L2): A Protocol Layer. The Data Link Layer provides the functional and procedural
means to transfer data between two adjacent L2 instances. The Data Link Layer also detects, and possibly
corrects, errors that may occur in the Physical Layer. In addition, the Data Link Layer maintains Flow Control
between the L2 entities.
38 (Data Link Layer) Control Frame: A Layer 2 PDU, which is consumed by the Data Link Layer.
39 (Data Link Layer) Data Frame: A Layer 2 PDU whose SDU is passed on to upper layers.
40 Data Link Layer Flow Control: Flow Control implemented on Data Link Layer (L2) using credits. Data
Link Layer Flow Control is also referred to as Link-Level Flow Control.
41 (Data Link Layer) Frame: A Layer 2 PDU for point-to-point transmission across an individual Link.
Frames may be either Data Frames or Control Frames.
42 Data Link Layer Symbol: The DL Layer data stream is constructed of atomic 17-bit symbols. These
symbols can be either control or data symbols.
43 Decomposition: The process of removing header, and possibly trailer, information from the PDU of a lower
layer to extract an upper layer PDU.
44 Device: An addressable node on the Network. A Device needs to comply with Network Layer and Transport
Layer (L3 and L4) requirements as defined in the UniPro specification. An off-chip Link also needs to
comply with PHY Adapter Layer and Data Link Layer (L1.5 and L2) requirements as defined in the UniPro
specification, and with a Physical Layer (L1) as defined in [MIPI01] or [MIPI05].
45 DeviceClass: A property of a UniPro Device that indicates what the UniPro Device does and what
Application-level protocols it supports. Note that the DeviceClass concept defined here is intended to match
that used in [MIPI04].
46 DeviceID: A number which uniquely identifies a Device on the Network.
47 Device Management Entity (DME): The Device Management Entity is a layer-independent entity
interfacing with all UniPro Protocol Layers and the Application Layer. The DME may set or get layer
Attributes and signal and control the resetting of individual layers.
48 Dual Simplex: Supporting independent communication in forward and reverse direction simultaneously.
49 Endpoint: Device that is a leaf of a Network.
50 End-to-End Flow Control (E2E FC): A credit-based flow control method that is implemented in the
Transport Layer (L4) on a Connection.
51 Fragment: A portion of a Message that can be passed to, or received by, a CPort. Received Fragments are not
generally identical to transmitted Fragments.
52 Flow Control: The process of managing the flow of data from one entity to another to ensure that the
receiving entity can handle all of the incoming data.
53 Frame: see Data Link Layer Frame.
54 Gear: A mechanism defined in [MIPI05] that provides control over the speed of the Link in steps of 2x.
Higher values of HS Gear or PWM Gear imply higher frequencies and higher bandwidths.
55 Get command: A command used to read the value of an Attribute.
56 Host: This is a Device that has computation and storage capabilities that allow it to control and manage other
Devices on a network. A host is associated sometimes with the main CPU.
57 Lane: Data or Clock Lane.
58 Link: A bidirectional interconnection between two Devices or Switches.
59 Link Startup Sequence: The Link Startup sequence is an L1.5 handshake to establish initial Link
communication between two directly attached UniPorts.
60 Logical Lane Number (M-PHY): A number assigned by a Device to its outbound Data Lanes after the Link
Startup Sequence. It is used for L1.5 Lane mapping whereby only the usable Physical Lanes are assigned a
Logical Lane Number.
61 Long Header Packet: Packet that has an extended L3 header. Long Header packets are handled by the using
the Long Header Trap feature.
62 Long Header Trap: A UniPro L3 feature that allows received Long Header Packets to be passed directly to
the Application Layer as well as allowing the Application Layer to send Long Header Packets.
63 Master (entity): The master within a pair of peer entities is the side that takes the initiative and that selects
the slave entity to communicate with. Note that for Notifications, however, the slave sends the Notification to
the master.
64 Maximum Transfer Unit (MTU): A term for the size of the largest SDU that can be transferred in a single
PDU of a given Protocol Layer.
65 Message: The PDU of the Application Layer (LA).
66 M-PHY: High-speed serial interconnect technology, based on clock embedding, as defined in [MIPI05].
67 Network: Communication structure allowing two or more Devices to exchange data via a communication
protocol.
68 Network Layer (L3): A Protocol Layer. The part of the communication protocol that manages the Network
and routes Packets to their destinations.
69 Operating Modes: UniPort-specific operating modes for power consumption and performance.
70 (OSI) Layer 2: See Data Link Layer.
71 (OSI) Layer 3: See Network Layer.
72 (OSI) Layer 4: See Transport Layer.
73 (PA) Symbol: The PDU of the PHY Adapter Layer (L1.5).
74 Packet: The PDU of the Network Layer (L3).
75 PACP (Control) Frame: A PDU used by PACP for power control purposes, peer Device Attribute setting
and getting, and M-PHY testing.
76 Peer: In the definition of a protocol layer two entities are peers if the protocol can be defined as an interaction
between both entities. Typically, peers reside at the two ends of a Link (for lower OSI layers) or serve as
communicating endpoints on the network (for higher OSI layers).
77 Peripheral: Any external Device that provides input or output services for the Host.
78 PHY Adapter Control Protocol (PACP): A control protocol within the PHY Adapter Layer (L1.5) used for
setting power modes, peer Device Attribute setting and getting, and M-PHY testing handling.
79 PHY Adapter Layer (L1.5): A Protocol Layer. The PHY Adapter Layer presents a common interface to the
Data Link Layer for the supported Physical Layer.
80 PHY-Protocol Interface (PPI): The Interface between the Physical Layer (PHY) and the PHY Adapter
Layer.
81 Physical Lane Number (M-PHY): A static number assigned at the implementation phase of a Device to its
outbound and inbound Data Lanes. The Physical Lane Number plays a role in the L1.5 Lane remapping to
compensate for wiring topology.
82 Pin Count: Number of pins required to implement a physical port. Typically includes signal, power, and
control pins.
83 Power Mode: The UniPro Power Mode is a configurable Attribute used to control the UniPro Power State.
Various Power Modes have a one-to-one mapping to Power States while other Power Modes give the PHY
Adapter Layer (L1.5) the freedom to autonomously switch between two pre-determined Power States.
84 PHY Power State: The PHY power state is defined in [MIPI01] for D-PHY and in [MIPI05] for M-PHY.
Please see the relevant document for further details.
85 UniPro Power State: The UniPro Power State is an abstracted representation within the PHY Adapter Layer
(L1.5) of the current power state of the underlying Physical Layer.
86 Preemption: Nesting of higher priority Frames into lower priority Data Frames.
87 Protocol Control Information (PCI): Information exchanged between Layer-(x) instances to coordinate
their joint-operation.
88 Protocol Data Unit (PDU): A unit of data consisting of Layer-(x) Protocol Control Information (PCI) and a
Layer-(x) Service Data Unit (SDU).
89 Quality of Service (QoS): The ability to guarantee certain properties of communication. QoS is used to
provide priority including dedicated bandwidth, controlled jitter and latency, and improved loss
characteristics.
90 Reserved Field: All the bits in such a field are set to the reserved value.
91 Routing: The determination of the path within a Network along which a Packet is sent.
92 Segment: The PDU of the Transport Layer (L4).
93 Segmentation: The function of splitting a Message or Fragment into Segments within the Transport Layer
transmitter.
94 Selector: An identifier of a range of Attributes associated with a given entity that can have multiple
occurrence (i.e., CPort).
95 Service Data Unit (SDU): Data provided by the User of a given Layer that is transferred without
interpretation or changes to a peer Layer.
96 Service Access Point (SAP): The point at which Layer-(x) services are provided by Layer-(x) to
Layer-(x+1).
97 Service Primitive: An abstract, and implementation independent, representation of an interaction between a
Layer(x)-service-user and a Layer-(x)-service-provider.
98 Service Provider: A layer that provides a SAP for use by another layer.
99 Service User: A layer that accesses a SAP provided by another layer.
100 Set command: A basic command used to change the value of an Attribute.
101 Short-header Packet: Packet that has a single-byte L3 header used for Connection-oriented data transfer.
102 Slave (entity): The Slave within a pair of peer entities is the passive entity that waits for a request from a
Master entity before taking action or responding. Note that for Notifications, however, the Slave sends the
Notification to the Master.
103 Switch: A switch routes Packets through the Network. It contains a UniPro-compliant L3 with routing
functionality. A switch definition is not part of this version of the specification and shall be made available in
a future version of the specification.
104 Switch Port: The physical interface of a Switch, needed to attach physically to a Network A switch
definition is not part of this version of the specification and shall be made available in a future version of the
specification.
105 Synchronization: A mechanism used by the PHY Adapter Layer (L1.5) to detect and compensate for timing
skew between multiple M-PHY Data Lanes.
106 Tester: A Device running the UniPro test suite and used for testing a remote UniPro Device-Under-Test
(DUT).
107 TstDst: A programmable analyzer of incoming Messages with the capability to check a stream of incoming
Messages against the expected values and lengths and report errors.
108 TstSrc: A programmable traffic generator that creates sequences of Messages containing well-defined byte
sequences of well-defined lengths.
109 Traffic Class: A priority equivalence class of Messages/Packets/Frames. Frames from a higher-priority
Traffic Class are allowed to preempt lower-priority Traffic Classes.
110 Transport Layer (L4): A protocol layer that can transfer Segments between Devices. The layer’s
functionality and concepts include Message Segmentation, Connections, End-to-End Flow Control and in-
order data delivery per Connection.
111 UniPort: Interface implementing the UniPro specification (L4 to L1.5) and a physical layer (L1)
specification. The UniPort definition excludes the UniPro User or any Application Layer specifications.
112 UniPort-D: a UniPort that uses D-PHY [MIPI01] for the Physical Layer (L1).
113 UniPort-M: a UniPort that uses M-PHY [MIPI05] for the Physical Layer (L1).
114 UniPro: Unified Protocol.
115 UniPro User: An Application that resides above UniPro and uses it via the DME SAP and the Transport
Layer SAP.
2.3 Abbreviations
125 etc. And so forth (Latin: et cetera)
126 e.g. For example (Latin: exempli gratia)
127 i.e. That is (Latin: id est)
2.4 Acronyms
128 ACK Acknowledgment
129 AFC Acknowledgment and Flow Control
130 A_PDU Application Protocol Data Unit
131 CCITT Comité Consultatif International Téléphonique et Télégraphique
132 CO Connection Oriented
133 COF Continuation of preempted Frame
134 CRC Cyclical Redundancy Checking
135 CReq Credit Transmit Request
3 References
212 [ITUT01] ITU-T Recommendation X.200, Information technology – Open Systems Interconnection –
Basic Reference Model: The basic model, <http://www.itu.int/rec/T-REC-X/en>,
International Telecommunication Union, July 1994
213 [ITUT02] ITU-T Recommendation X.210, Information technology – Open systems interconnection –
Basic Reference Model: Conventions for the definition of OSI services,
<http://www.itu.int/rec/T-REC-X/en>, International Telecommunication Union,
November 1993
214 [ITUT03] ITU-T Recommendation X.25 (1996), Interface between Data Terminal Equipment (DTE)
and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet
mode and connected to public data networks by dedicated circuit,
<http://www.itu.int/rec/T-REC-X/en>, International Telecommunication Union, October
1996
215 [ITUT04] ITU-T Recommendation Z.100 (2002), Specification and Description Language (SDL),
<http://www.itu.int/rec/T-REC-Z/en>, International Telecommunication Union, August
2002
216 [MIPI01] MIPI Alliance Specification for D-PHY, version 1.00.00, MIPI Alliance, Inc., 14 May 2009
217 [MIPI02] MIPI Alliance Specification for UniProSM: SDL State Machines, version 1.40.00, MIPI
Alliance, Inc., 31 January 2011
218 [MIPI03] MIPI Alliance Specification for UniProSM: Test Procedure, version 0.80.00, MIPI
Alliance, Inc., In Press
219 [MIPI04] MIPI Alliance Specification for Device Descriptor Block (DDB), version 0.82.01, MIPI
Alliance, Inc., 30 October 2008
220 [MIPI05] MIPI Alliance Specification for M-PHY, version 1.00.00, MIPI Alliance, Inc., 8 February
2011
221 [TAN01] Tanenbaum, Andrew, Computer Networks, 4th Ed.,
<http://authors.phptr.com/tanenbaumcn4/>, Prentice Hall, 9 August 2002
Transport (L4), Network (L3), Data Link (L2), PHY Adapter for M-PHY (L1.5) Layers and Device
Management Entity (DME) is available. The SDL model is meant to capture the minimal conformant
implementation of the specification. It does not preclude other possible conformant implementations
230 In SDL, a system is modeled as a number of concurrently executing Extended Finite State Machines (EFSM)
that communicate by exchanging atomic PDUs. In any given state, a state machine accepts one or more
incoming PDU types. On receipt of any of these PDU types, the state machine transitions to another state.
State transitions can cause the extended finite state machine to do some processing, e.g. updating internal
counters, or may trigger the transmission of other PDUs.
231 The SAPs described in this document match those found in the SDL model. The SDL model has more
internal interfaces than just the SAPs between protocol layers because complex layers are decomposed into
multiple interconnected EFSMs. Such internal design details within the SDL model do not impose limitations
on allowed implementations other than by defining the resulting normative behavior on external interfaces.
232 The formality of the UniPro SDL model is useful for resolving any text ambiguities or for getting an
impression of how the described functionality might be partitioned into more manageable functional entities.
In case of any discrepancies between the specification text and the SDL model, the SDL model has
precedence. The reader can nevertheless find many details of the UniPro specification without consulting the
SDL description.
233 Note that, again, the structure of the SDL model does not constrain possible implementations: any
implementation which provides identical behavior on its external interfaces to the SDL model is allowed.
These external interfaces are the physical medium (wires) attached to the physical layer and more abstract
“ports”, which connect the Transport Layer to Applications.
Application (L7)
Application-specific Protocols
Presentation (L6)
(LA)
Session (L5)
(DME)
Specification
Medium Medium
Figure 3. SAPs at the top of the UniPro stack have special significance for users because they constitute the
only external interfaces to services provided by the UniPro stack. Currently, two external interfaces for
Application use are defined, CPorts (T_SAP) and DME_SAP. Additional interfaces for specialized purposes,
such as security protocols, might be added in future versions of this specification.
Device A Device B
DME DME
SAP
T_SAP T_SAP SAP
T_LM
T_LM
SAP
SAP
N_SAP N_SAP
N_LM
N_LM
SAP
(DME)
(DME)
DL_SAP DL_SAP
DL_LM
DL_LM
SAP
PA_SAP PA_SAP
PA_LM
PA_LM
SAP
PHY_SAP PHY_SAP
Medium
243 If the Application at Device A needs to send data to the Application at Device B, the data will pass via the
T_SAP to the Transport Layer (L4), which passes the data via the N_SAP to the Network Layer (L3), which
passes the data via the DL_SAP to the Data Link Layer (L2), which passes the data via the PA_SAP to the
PHY Adapter Layer (L1.5), which passes the data via an interface belonging to the PHY to the PHY Layer
(L1). The PHY communicates to the other PHY via the wiring (“medium”). At Device B, the data passes up
the corresponding stack layers in reverse order.
244 Note that the D-PHY specification defines the informative PPI as a signal-level interface corresponding to the
more abstract PHY_SAP in Figure 3. The M-PHY specification defines an optional normative signal-level
interface in its Annex A that also corresponds to the PHY_SAP in Figure 3. D-PHY and M-PHY are,
however, quite different technologies, and thus have different PHY_SAP interfaces. This variation is
accommodated by providing two alternative PHY Adapter Layers (L1.5), one version for D-PHY and one
version for M-PHY.
the L4 level these units of data exchange are known as L4 Protocol Data Units (or T_PDUs). So, part of the
L4 specification maps T_SAP primitives to the exchange of T_PDU units between peer Devices.
254 Note that although the structure and behavior of T_PDUs (“Segments”) are a normative element of the
specification of L4 behavior, L4 PDUs are abstract in the sense that they cannot be sent directly over the
media or cannot be observed directly by monitoring the media. This is because transmission over the media
involves using the services of lower protocol layers. Lower protocol layers may add additional header or
trailer information or transform the data in other ways, e.g. symbol encoding in lower layers.
255 Thus, the UniPro specification defines how L4 PDUs (“Segments”) are mapped using the L3 SAP to L3
PDUs (“Packets”), how Packets are mapped via the L2 SAP to L2 PDUs (“Frames”), and how Frames are
mapped via the L1.5 SAP to L1.5 PDUs (“Symbols”). For D-PHY or M-PHY, the specification provides one
more mapping within L1.5 from UniPro's 17-bit PHY-independent Symbols to the symbols passed to and
from the PHY. Note that both PHY technologies provide some form of line encoding and thus internally
performs a final mapping.
256 On the one hand, the UniPro specification thus makes extensive use of this OSI-based style for defining
layered protocol specifications which stresses rigorously decoupling of the behavior of individual layers. On
the other hand, a special characteristic of the UniPro protocol stack is that the transformations between PDUs
of the various protocol layers are relatively simple: L4, L3 and L2 merely add a few bytes of header and in
one case trailer data. This is because all layers were designed together, and were thus optimized to minimize
total stack complexity. Nevertheless, the specification is still strictly described as independent layers coupled
by SAPs in order to simplify its readability and its maintenance.
280 D-PHY high-speed data rates can be increased by providing up to four Data Lanes per direction. Using four
Data Lanes gives a bandwidth increase of 4x and behaves like a 4x faster Physical Layer technology. D-PHY
uses only a single Data Lane when in Low Power mode.
294 Note:
295 The HIBERNATE_STATE receives special treatment within the UniPro stack compared to all the other
Power States. The reasons why are mentioned in Section 4.9.
296 Note:
297 UniPro does not allow an Application to put any of the directions of a Link into SLEEP_STATE.
SLEEP_STATE is supported by allowing a UniPro stack to autonomously toggle M-PHY between
SLEEP_STATE and either FAST_STATE or SLOW_STATE. Thus, if one direction of the Link happens
to be in SLEEP_STATE, and some data needs to be sent, the UniPro stack has the capability to go
to FAST or SLOW state, thus enabling bidirectional communication. This approach also explains why
UniPro can hide the distinction between M-PHY's STALL and SLEEP states from Applications.
298 Controlling Power State transitions on M-PHY is quite complicated. Sometimes only a simple form of line-
state signaling is enough. This could, for instance, involve asserting the lines to a negative differential state
(DIF-N) for a longer period of time than can occur during normal operation. In such a case, the transmitter
can signal a Power State transition and the attached receiver automatically recognizes the transition. Due to
the limited options provided by line state signaling, various other transitions involve higher protocol layers.
299 Rather than expose this complexity to the Application that controls the UniPro Link, the UniPro stack
abstracts many PHY related details.
4.7.7 L1 Idles
300 One of the tasks of the PHY Layer is to transmit special L1 Idle symbols on the line when the Link is in high-
speed mode and there is no data to send. These Idle symbols are thus inserted in the gaps between Packets and
are removed by the corresponding L1 receiver's decoder.In the case of D-PHY, Idle symbols are special 9-bit
symbols defined in Annex C of [MIPI01] for this purpose. These Idle symbols are needed in high speed mode
because the transmit clock needs to be left running.
301 In the case of M-PHY, Idle symbols map to pairs of special 10-bit M-PHY-defined FILLER control symbols.
The use of pairs of PHY Idle symbols, when used with a UniPro stack, is convenient because it ensures that
upper protocol layers can maintain 16-bit alignment on headers, trailers and payload.
that a contiguous series of Lanes is “connected”, starting at Physical Lane #0. It can also opt to use fewer than
the number of connected Lanes by configuring the number of “active” lanes (again starting at Lane #0).
307 For D-PHY, no mechanism is provided to assess the number of connected lanes. And it is assumed that
connected lanes start at Physical Lane #0 and that the wiring attaches corresponding Physical Lane numbers.
308 Note that details about how many Data Lanes are available for use are not critical: after reset, only a single
Data Lane is used. Furthermore, with the D-PHY in SLOW_STATE, only Physical Data Lane #0 is used.
320 So the difference between Power States and Power Modes are as follows:
321 • an Application can set only a Power Mode, but cannot set a Power State
322 • an Application can read out a Power Mode and read out a Power State
323 • the readable value of a Power Mode simply reflects the value that was set
324 • the readable value of a Power State may change spontaneously when in FastAuto_Mode or
SlowAuto_Mode
change request has been completed. This approach was taken because certain Power Modes transitions might
take a relatively long time to execute, e.g. to start up and train Phase Locked Loop (PLL) circuitry.
339 Also note that the Application needs to modify only Lane, Gear and Series Attributes if a change is needed.
However, analogous to the M-PHY specification itself, any modifications to these Attributes are only
effectuated on a write to PA_PWRMode, using the PA_LM_SET.req primitive.
340 It is worth noting that, because the process of changing Power Modes is a bit tricky, setting PA_PWRMode
using the PA_LM_SET.req primitive can, in principle, return an error code, and thus require a retry by the
Application.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 L1.5 payload
0 L1.5 payload
342 Each 17-bit symbol (the PA_PDU) can hold two bytes of data plus an associated control-or-data flag (Bit 16).
This flag allows a UniPro stack to distinguish between special symbols used by the protocol and payload
data. Note the color convention whereby Bit 16 is shown in red to correspond to the color convention used for
L1.5 (see Figure 2). In subsequent figures, color coding is used to indicate which field belongs to which layer
in the UniPro protocol. Gray means “don't care”.
343 Note that the use of 17-bit symbols at the PA_SAP interface is an abstract representation of the data going
over the line. The 17-bit L1.5 symbols are thus translated within L1.5 to the symbols, or “code words”
supported by the PHY. When Bit 16 equals zero, the two Bytes in the Symbol's L1.5 payload translate to two
normal 9-bit (D-PHY) or 10-bit (M-PHY) data codes. When Bit 16 equals one, bits [15:8] are used to identify
a special control data code, while bits [7:0] directly map to one of the 256 normal data codes.
16 15 14 13 12 11 10 9 8 6 7
5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId
0 Parameters
0 ...
0 CRC-16
347 The first 17-bit symbol contains a constant. Because Bit 16 is set to one, this symbol, at the PHY level, results
in a PHY-level control symbol that is used only to signal the start of a PACP Frame. The second Symbol
indicates the type of PACP Frame, and tells the receiving L1.5 how to interpret the remaining fields. Note that
all fields are shown in “L1.5 red” because the data is defined, generated and absorbed by L1.5 in the UniPro
stack.
348 PACP Frames have very specialized usage (changes in L1.5 Power Modes and their confirmation, automatic
exchange of capability information, forcing a form of low-level reset, remote Get/Set and M-PHY testing)
and thus are sent infrequently.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 L2 payload
0 L2 payload
0 L2 payload
1 ESC_DL EOF_EVEN Frame Seq. Number
0 CCITT CRC-16
357 Payloads with an odd number of bytes are extended with an extra padding byte at the end of the L2 payload
area. The presence of the padding byte is flagged in the Frame’s trailer. See Figure 7.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 L2 payload
0 L2 payload
0 L2 payload Padding Byte = 0x00
1 ESC_DL EOF_ODD Frame Seq. Number
0 CCITT CRC-16
16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL AFC TC CReq Reserved
0 Frame Seq. Number Reserved Credit Value
0 CCITT CRC-16
359 AFC Frames are generally encountered as a result of Data Frame transmission: as Data Frames are sent, the
receiver of the Data Frames will send AFC Frames back to the peer transmitter to acknowledge correct
receipt (the Frame Sequence Number field) and to inform the transmitter about available L2 buffer space (the
Credit Value field).
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL NAC Reserved RReq
0 CCITT CRC-16
360 NAC Frames are sent back to the transmitter after certain L2 error conditions are detected by the receiver. In
contrast, a stream of AFC Frames generally indicates that things are going well.
4.10.1 L3 Packets
371 The Network Layer introduces a new PDU known as a Packet. When a Packet is passed down to L2, the
Packet is encapsulated between an L2 header and an L2 trailer to form a single L2 Frame (see Figure 10).
There are two types of Packets, Long Header Packets, which will be defined in a future UniPro specification,
and Short Header Packets.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 L3s=1 DestDeviceID_Enc L3 payload
0 L3 payload L3 payload
0 L3 payload L3 payload
1 ESC_DL EOF_EVEN Frame Seq. Number
0 CCITT CRC-16
4.11.1 L4 Connections
377 The Transport Layer supports multiple bidirectional Connections (T_CO_SAP) between endpoint Devices.
Connections can span a single hop or multiple hops using switches. A pair of endpoint Devices can
communicate via multiple Connections and, on a Network, an endpoint can have multiple simultaneous
Connections to multiple Devices. Connections can be regarded as virtual private wires between Devices on
the shared Network.
378 UniPro guarantees that data sent over a single Connection arrives in the order in which it was sent. All data
sent over a single Connection has the same Traffic Class (TC0 or TC1). The latter is needed to ensure in-order
delivery within a Connection.
4.11.2 L4 Segments
379 The PDUs of the Transport Layer are called Segments. When a Segment is passed down to L3, the Segment is
simply prefixed by an L3 header to form a single L3 Packet which is then encapsulated between an L2 header
and an L2 trailer to form a single L2 Frame (see Figure 11).
380 Segments belonging to one Connection are guaranteed to arrive in order; the exact order of Segments
received over multiple Connections is undefined. In addition, Segments transmitted over a Connection need
to adhere to the same Application-level protocol.
381 For example, a UniPro-based display protocol may transmit its pixel stream and its command stream using
two different Connections, each using a different Application-level protocol and potentially using a different
Traffic Class. Segments belonging to both Connections can be distinguished at the destination (the display in
this example) based on the DestCPortID_Enc field (see Section 4.11.3).
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 L3s=1 DestDeviceID_Enc L4s=1 DestCPortID_Enc FCT EOM
0 L4 Payload L4 Payload
0 L4 Payload L4 Payload
1 ESC_DL EOF_EVEN Frame Seq. Number
0 CCITT CRC-16
contains a matching data analyzer that checks the correctness of the incoming data stream against the
expected data traffic.
397 The built-in Test Features are mainly intended to allow a UniPro stack within a Device to be checked for
design- and conformance problems in a well-defined and readily automated way [MIPI03].
398 The Test Features can also be useful for checking the operation of a prototype or production system as they
provide a built-in functional self-test of the UniPro stack, the PHY Layers and associated wiring.
4.12 DME
399 The Device Management Entity (see Figure 3) controls the layers in the UniPro stack. It provides access to
various control parameters in all layers, manages the power mode transitions of the Link, and handles boot-
up, hibernate and reset of the entire UniPro stack.
Display
Module #1
UniPro Display
Bidirectional Module #2
Link
UniPro
Bidirectional
Link
Cellular
RF PHY MODEM
(Device B)
Non-UniPro
Bidirectional
Link
412 Figure 13 shows the Switch as a logically separate component for clarity. Although Switches can be
implemented as discrete components on separate integrated circuits, they may alternatively be integrated
onto the same die as Devices to avoid increasing the component count. Since the PHY Layer is designed for
off-chip communication, the connection between a Switch and a Device on the same die might likely avoid
using a high-speed serial PHY Layer, and might instead use, for example, a parallel CMOS interface.
UniPro
Bidirectional
Link
Display
Module #1
(Device E)
Display
Switch
Host Processor Non-UniPro
Processor Unidirectional
(Device A)
(Device C) Link
Cellular
RF PHY MODEM Camera
(Device B) Sensor
(Device D)
Non-UniPro
Bidirectional
Link
Device
Management
PA_SAP
Entity
(DME) Management Plane Data Plane
PA_LM
SAP
415 The PHY Adapter ensures that the UniPro protocol is independent of the PHY technology. To do so, it hides
internal implementation details of the PHY from the Data Link Layer. PHY Adapter Layers for D-PHY and
M-PHY are called PA D-PHY and PA M-PHY, respectively.
416 For off-chip communication, a UniPro implementation shall use a physical layer compliant with [MIPI01] or
[MIPI05]. Future versions of the UniPro specification may support and allow alternative physical layers for
off-chip usage. Note that an on-chip implementation of UniPro is not restricted to any specific set of physical
layer technologies.
423 These services are offered independently from the PHY technology. Just a basic set of features is required
from the PHY, as described in Section 5.2.
5.3 PA_SAP
432 The PA_SAP offers three groups of Service Primitives: Data Transfer primitives, Control primitives and
Status primitives.
433 The Data Transfer primitives enable data transmission and reception, while the Control primitives are needed
for (re-)initialization of the Link. Status primitives are used to indicate PA Layer status information, such as
identified errors, to the Data Link Layer.
434 The primitives on this SAP are used by the Data Link (DL) Layer.
436 The parameters used for these primitives are defined in Table 2.
5.3.1.1 PA_DATA.req
437 This primitive requests the transmission of payload data.
438 The semantics of this primitive are:
439 PA_DATA.req( Data )
5.3.1.2 PA_DATA.cnf_L
447 This primitive informs the PA Service User that the Service Provider, L1.5 in this case, is ready to accept a
new PA_DATA.req or PA_ESCDATA.req primitive.
448 The semantics of this primitive are:
449 PA_DATA.cnf_L( )
5.3.1.3 PA_DATA.ind
457 This primitive reports the reception of a DL data symbol over the Link.
458 The semantics of this primitive are:
459 PA_DATA.ind( Data )
5.3.1.4 PA_DATA.rsp_L
467 This primitive informs the Service Provider that the PA Service User, L2 in this case, is ready to accept a new
PA_DATA.ind or PA_ESCDATA.ind primitive.
468 The semantics of this primitive are:
469 PA_DATA.rsp_L( )
5.3.1.5 PA_ESCDATA.req
476 This primitive requests the transmission of escaped payload data.
477 The semantics of this primitive are:
478 PA_ESCDATA.req( EscType, EscParam )
5.3.1.6 PA_ESCDATA.cnf_L
486 This primitive informs the PA Service User that the Service Provider, L1.5 in this case, is ready to accept a
new PA_DATA.req or PA_ESCDATA.req primitive.
487 The semantics of this primitive are:
488 PA_ESCDATA.cnf_L( )
5.3.1.7 PA_ESCDATA.ind
496 This primitive reports the reception of a DL Control symbol.
497 The semantics of this primitive are:
498 PA_ESCDATA.ind( EscType, EscParam )
5.3.1.8 PA_ESCDATA.rsp_L
506 This primitive informs the Service Provider that the PA Service User, L2 in this case, is ready to accept a new
PA_DATA.ind or PA_ESCDATA.ind primitive.
507 The semantics of this primitive are:
508 PA_ESCDATA.rsp_L( )
517 The parameters used for these primitives are defined in Table 4.
5.3.2.1 PA_INIT.req
518 This primitive requests to (re-)initialize the PA Layer and underlying PHY. For D-PHY, this request (re-
)initializes only the transmit path. For M-PHY, both transmit and receive paths are (re-)initialized. For a
description of the (re-)initialization process on D-PHY and M-PHY see Section 5.7.9 and Section 5.8.10,
respectively.
519 The semantics of this primitive are:
520 PA_INIT.req( )
5.3.2.2 PA_INIT.cnf_L
528 This primitive reports the completion of the (re-)initialization procedure.
529 The semantics of this primitive are:
530 PA_INIT.cnf_L( PAResult )
5.3.2.3 PA_DL_PAUSE.ind
537 This primitive informs the PA Service User, the DL Layer in this case, that the PA Layer was requested to
execute a operation that requires the usage of the Link, e.g. power mode change or PACP frame transmission.
This primitive is one in the group of primitives defining the handshake procedure used between PA Layer and
DL Layer to coordinate the Link usage. After generating this primitive, the PA Layer shall wait for the
reception of the PA_DL_PAUSE.rsp_L before taking any further action.
5.3.2.4 PA_DL_PAUSE.rsp_L
546 This primitive informs the Service Provider that the PA Service User, the DL Layer in this case, has reached a
state where the Link may be used by the PA Layer.
547 The semantics of this primitive are:
548 PA_DL_PAUSE.rsp_L( )
5.3.2.5 PA_DL_RESUME.ind
555 This primitive informs the PA Service User, the DL Layer in this case, that the PA Layer has completed its
operation and the DL Layer may continue to use the Link.
556 The semantics of this primitive are:
557 PA_DL_RESUME.ind( PAResult )
5.3.2.6 PA_LANE_ALIGN.req
564 The DL Layer generates this request to force the PA Layer to execute a Lane Synchronization, which results
in the PA Layer sending a deskew pattern as described in Section 5.8.11.
565 The semantics of this primitive are:
566 PA_LANE_ALIGN.req( )
5.3.2.7 PA_LANE_ALIGN.cnf_L
574 This primitive informs the PA Service User, the DL Layer in this case, that the Service Provider, the PA Layer
in this case, has completed the Lane Synchronization previously requested by the primitive
PA_LANE_ALIGN.req.
575 The semantics of this primitive are:
576 PA_LANE_ALIGN.cnf_L( )
PA_ERROR 5.4.3.2 D, M
5.3.3.1 PA_ERROR.ind
586 This primitive reports errors identified by the PA Layer to the Data Link Layer.
587 The semantics of this primitive are:
588 PA_ERROR.ind( PAErrorCode )
602 The PA_ERROR.ind primitive is sent when a PA symbol (formed out of two M-PHY symbols) has an error
that the PA Layer can detect. Note that two consecutive M-PHY symbol errors might cause one or two
PA_ERROR.ind primitives, depending on their position relative to the PA symbol.
5.4 PA_LM_SAP
607 The PHY Adapter Layer Management (PA_LM) SAP offers three groups of Service Primitives:
Configuration primitives, Control primitives and Status primitives. The primitives on the PA_LM_SAP are
used by the Device Management Entity (DME) to configure and control the layer and receive layer status
information.
608 The Configuration primitives enable access to configuration information specific to the PA Layer. This
information is represented as a PHY Adapter Layer-specific Management Information Base (PA_MIB). The
PA_MIB is regarded as “contained” within the PA_LM entity. Multiple accesses to the PA_MIB via the
Configuration primitives shall not occur concurrently. The available configuration Attributes are defined in
Section 5.9.
609 The Control primitives provide direct control of the PA Layer. Control primitives are generated by the DME
and can occur concurrently.
610 The Status primitives indicate status information of the PA Layer. Status primitives are generated by the PA
Layer and can occur concurrently.
613 The parameters used for these primitives are defined in Table 8.
5.4.1.1 PA_LM_GET.req
614 This primitive requests information about a given PA_MIB Attribute or PHY Attribute identified by
MIBattribute, and, if relevant, the SelectorIndex. The SelectorIndex shall be interpreted as a PHY Data Lane
index if relevant for the targeted Attribute. For Attributes not associated with the SelectorIndex, the
SelectorIndex shall be ignored.
615 The semantics of this primitive are:
616 PA_LM_GET.req( MIBattribute, SelectorIndex )
5.4.1.2 PA_LM_GET.cnf_L
624 This primitive reports the result of an information request about a given PA_MIB Attribute or a PHY
Attribute.
625 The semantics of this primitive are:
626 PA_LM_GET.cnf_L( ConfigResultCode, MIBvalue )
5.4.1.3 PA_LM_SET.req
634 This primitive attempts to set to the MIBvalue value the PA_MIB Attribute or a PHY Attribute indicated by
MIBattribute, and, if relevant, the SelectorIndex. The SelectorIndex shall be interpreted as a data PHY Lane
index if relevant for the targeted Attribute. For Attributes not associated with the SelectorIndex, the
SelectorIndex shall be ignored.
635 The semantics of this primitive are:
636 PA_LM_SET.req( AttrSetType, MIBattribute, MIBvalue, SelectorIndex )
5.4.1.4 PA_LM_SET.cnf_L
644 This primitive reports the results of an attempt to set the value of an Attribute in the PA_MIB or in the
underlying PHYs.
645 The semantics of this primitive are:
646 PA_LM_SET.cnf_L( ConfigResultCode )
5.4.1.5 PA_LM_PWR_MODE.ind
654 This primitive passes the PAPowerModeUserData that was received from the peer Device during the Link
Configuration procedure.
655 The semantics of this primitive are:
656 PA_LM_PWR_MODE.ind( PAResult, PAPowerModeUserData )
657 The first parameter is set to TRUE, when the power mode change request was created by the local DME,
otherwise it is set to FALSE.
658 The second parameter is a 24-byte long data payload containing private data from the peer DME.
5.4.1.6 PA_LM_PWR_MODE.rsp_L
665 This primitive acknowledges PA_LM_PWR_MODE.ind. The PAPowerModeUserData is to be sent to the
peer Device if the power mode change request was created by the remote DME.
666 The semantics of this primitive are:
667 PA_LM_PWR_MODE.rsp_L( PAPowerModeUserData )
5.4.1.7 PA_LM_PWR_MODE_CHANGED.ind
676 This primitive reports the results of the Link Configuration procedure.
677 The semantics of this primitive are:
678 PA_LM_PWR_MODE_CHANGED.ind( PowerChangeResultCode )
5.4.1.8 PA_LM_PEER_GET.ind
686 This primitive indicates the value of the Attribute identified by GenMIBattribute, and, if relevant, the
GenSelectorIndex. The GenSelectorIndex shall be interpreted either as a data PHY Lane index, CPort index
or Test Feature index, depending on the particular Attribute. For Attributes not associated with
GenSelectorIndex, the GenSelectorIndex parameter shall be ignored.
687 The semantics of this primitive are:
688 PA_LM_PEER_GET.ind( GenMIBattribute, GenSelectorIndex )
5.4.1.9 PA_LM_PEER_GET.rsp
696 This primitive reports the results of an information request about the Attribute given in the received
PA_LM_PEER_GET.ind.
697 The semantics of this primitive are:
698 PA_LM_PEER_GET.rsp( ConfigResultCode, MIBvalue )
5.4.1.10 PA_LM_PEER_SET.ind
706 This primitive attempts to set the MIBvalue value to an Attribute of the local UniPro stack identified by
GenMIBattribute, and, if relevant, the GenSelectorIndex. The GenSelectorIndex shall be interpreted either as
a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. For Attributes not
associated with the GenSelectorIndex, the GenSelectorIndex shall be ignored.
707 The semantics of this primitive are:
708 PA_LM_PEER_SET.ind( AttrSetType, GenMIBattribute, MIBvalue, GenSelectorIndex )
5.4.1.11 PA_LM_PEER_SET.rsp
716 This primitive reports the results of an attempt to set the value of an Attribute in the UniPro stack or PHYs.
717 The semantics of this primitive are:
718 PA_LM_PEER_SET.rsp( ConfigResultCode )
5.4.1.12 PA_LM_PEER_GET.req
726 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
727 This primitive requests information about a given Attribute of the peer Device, this Attribute being identified
by GenMIBattribute, and, if relevant, the GenSelectorIndex. The GenSelectorIndex shall be interpreted either
as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. For Attributes not
associated with the GenSelectorIndex, the GenSelectorIndex shall be ignored.
728 The semantics of this primitive are:
729 PA_LM_PEER_GET.req( GenMIBattribute, GenSelectorIndex )
5.4.1.13 PA_LM_PEER_GET.cnf
737 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
738 This primitive reports the results of an information request about an Attribute of the peer Device.
5.4.1.14 PA_LM_PEER_SET.req
748 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
749 This primitive attempts to set the Attribute of the peer Device indicated by GenMIBattribute and, if relevant,
the GenSelectorIndex, to the MIBvalue value. The GenSelectorIndex shall be interpreted either as a data
PHY Lane index or CPort index or Test Feature index depending of the Attribute. For Attributes not
associated with the GenSelectorIndex, the GenSelectorIndex shall be ignored.
750 The semantics of this primitive are:
751 PA_LM_PEER_SET.req( AttrSetType, GenMIBattribute, MIBvalue, GenSelectorIndex )
5.4.1.15 PA_LM_PEER_SET.cnf
759 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
760 This primitive reports the results of an attempt to set the value of an Attribute of the peer Device.
761 The semantics of this primitive are:
762 PA_LM_PEER_SET.cnf( ConfigResultCode )
775 The parameters used for these primitives are defined in Table 11.
5.4.2.1 PA_LM_AUTOSELECT.req
776 This primitive requests the PA_LM to switch to the selected power state when the PA Layer is in
FastAuto_Mode or SlowAuto_Mode (see Section 5.6.1.1). When the PA Layer is in a different mode, this
primitive shall have no effect.
777 The semantics of this primitive are:
778 PA_LM_AUTOSELECT.req( AutoState )
5.4.2.2 PA_LM_AUTOSELECT.cnf_L
783 This primitive indicates to the DME that the requested power state has been reached.
784 The semantics of this primitive are:
785 PA_LM_AUTOSELECT.cnf_L( PAAutoSelectResultCode )
5.4.2.3 PA_LM_RESET.req
793 This primitive requests the PA_LM to reset the PA Layer and PHY Layer. See Section 9 for a description of
reset.
794 The semantics of this primitive are:
795 PA_LM_RESET.req( ResetLevel )
5.4.2.4 PA_LM_RESET.cnf_L
805 This primitive is used during the UniPro reset procedure (see Section 9.11.1).
806 The semantics of this primitive are:
807 PA_LM_RESET.cnf_L( )
5.4.2.5 PA_LM_ENABLE_LAYER.req
814 This primitive enables the PA Layer.
815 The semantics of this primitive are:
816 PA_LM_ENABLE_LAYER.req( )
5.4.2.6 PA_LM_ENABLE_LAYER.cnf_L
823 This primitive reports that PA Layer has been enabled.
824 The semantics of this primitive are:
825 PA_LM_ENABLE_LAYER.cnf_L( )
5.4.2.7 PA_LM_LINKSTARTUP.req
832 This primitive attempts to establish a Link to the peer Device by starting the Link Startup sequence (L1.5
initialization protocol). See Section 5.6.3
833 The semantics of this primitive are:
834 PA_LM_LINKSTARTUP.req( )
5.4.2.8 PA_LM_LINKSTARTUP.cnf_L
843 This primitive is used during the UniPro boot procedure (see Section 9.11.2) to indicate to the DME that the
PA Layer completed the Link Startup sequence and the PA Layer is ready to be used by the Data Link Layer.
844 The semantics of this primitive are:
845 PA_LM_LINKSTARTUP.cnf_L( GenericErrorCode )
5.4.2.9 PA_LM_LINKSTARTUP.ind
852 This primitive indicates the reception of the first phase of the Link Startup sequence.
853 The semantics of this primitive are:
854 PA_LM_LINKSTARTUP.ind( )
5.4.2.10 PA_LM_ENDPOINTRESET.req
862 This primitive is used to transmit the EndPointReset trigger (‘TRG_EPR’) over the Link to the peer PA Layer.
See Section 9.3.3 for details.
863 The semantics of this primitive are:
864 PA_LM_ENDPOINTRESET.req( )
5.4.2.11 PA_LM_ENDPOINTRESET.cnf_L
871 This primitive reports the completion of a request to send a EndPointReset trigger (‘TRG_EPR’).
872 The semantics of this primitive are:
873 PA_LM_ENDPOINTRESET.cnf_L( )
5.4.2.12 PA_LM_ENDPOINTRESET.ind
880 This primitive indicates the reception of an EndPointReset trigger (‘TRG_EPR’) over the Link.
881 The semantics of this primitive are:
882 PA_LM_ENDPOINTRESET.ind( )
5.4.2.13 PA_LM_HIBERNATE_ENTER.req
889 This primitive attempts to put the PA Layer and the Link to Hibernate Mode.
890 The semantics of this primitive are:
891 PA_LM_HIBERNATE_ENTER.req( )
5.4.2.14 PA_LM_HIBERNATE_ENTER.cnf_L
898 This primitive reports the result of a hibernate request.
899 The semantics of this primitive are:
900 PA_LM_HIBERNATE_ENTER.cnf_L( GenericErrorCode )
5.4.2.15 PA_LM_HIBERNATE_ENTER.ind
907 This primitive reports the completion of a hibernate request.
908 The semantics of this primitive are:
909 PA_LM_HIBERNATE_ENTER.ind( PowerChangeResultCode )
5.4.2.16 PA_LM_HIBERNATE_EXIT.req
917 This primitive attempts to put the PA Layer and the Link into Active Mode.
918 The semantics of this primitive are:
919 PA_LM_HIBERNATE_EXIT.req( )
5.4.2.17 PA_LM_HIBERNATE_EXIT.cnf_L
926 This primitive reports the results of a hibernate exit request.
927 The semantics of this primitive are:
928 PA_LM_HIBERNATE_EXIT.cnf_L( GenericErrorCode )
5.4.2.18 PA_LM_HIBERNATE_EXIT.ind
935 This primitive reports the completion of a hibernate exit request.
936 The semantics of this primitive are:
937 PA_LM_HIBERNATE_EXIT.ind( PowerChangeResultCode )
5.4.2.19 PA_LM_TEST_MODE.ind
947 This primitive reports the reception of a request to put the PA Layer in a given test mode.
948 The semantics of this primitive are:
949 PA_LM_TEST_MODE.ind( )
5.4.2.20 PA_LM_TEST_MODE.req
956 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
957 This primitive attempts to put the PA Layer of the peer Device to the test mode.
958 The semantics of this primitive are:
959 PA_LM_TEST_MODE.req( )
5.4.2.21 PA_LM_TEST_MODE.cnf_L
967 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
968 This primitive reports the completion of a test mode request.
969 The semantics of this primitive are:
970 PA_LM_TEST_MODE.cnf_L( )
5.4.2.22 PA_LM_PHY_RESET.ind
977 This primitive reports that the PHY was reset due to a received or generated LINE-RESET.
PA_LM_RXPWRSTATE 5.4.3.1 D
PA_LM_ERROR 5.4.3.2 D
987 The parameters of these primitives are defined in Table 13 and Table 14.
5.4.3.1 PA_LM_RXPWRSTATE.ind
988 This primitive reports the change of the power mode on the receive path (Reverse Link) of the UniPro stack.
5.4.3.2 PA_LM_ERROR.ind
995 This primitive reports the occurrence of an error in the receive path.
996 The semantics of this primitive are:
997 PA_LM_ERROR.ind( PhyErrorCode )
998 The primitive parameter is defined in Table 13. Section 5.7.7 defines the mapping of PHY errors to
PhyErrorCode values.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 Data
1007 The header bit (bit 16) is fixed to ‘0’ in this PDU. The remaining 16-bits carry the DL Layer or PACP frame
data symbols in a way that bits [15:0] of the data symbol map directly to bits [15:0] of the Normal Data
PA_PDU.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 EscType EscParam
1010 In the Escaped Data PA_PDU, the header bit (bit 16) is set to ‘1’. The payload of the Escaped Data PA_PDU
is partitioned into the EscType field (bits [15:8]) and EscParam (bits [7:0]). The only valid values for
EscType are ESC_DL and ESC_PA, as described in Section 5.5.2.1 and Section 5.5.2.2, respectively.
1011 A transmitter shall not transmit an Escaped Data PA_PDU with EscType set to any value other than ESC_DL
or ESC_PA.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL EscParam_DL
1013 UniPro defines only one EscType for the higher protocol layers, namely the ESC_DL.
1014 For the PA_PDU composition, the ESC_DL is encoded as ‘0b00000001’. Therefore, an Escaped Data
PA_PDU that is initialized by the DL Layer with EscType=ESC_DL looks like in Figure 18. Note that the
ESC_DL encoding in the PA_PDU is different from the ESC_DL encoding for the physical layer, which is
described in Section 5.7.5 for D-PHY and in Section 5.8.3 for M-PHY.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 0 0 0 0 0 0 1 EscParam_DL
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA
1016 For PDU composition, the ESC_PA is encoded to ‘0b11111110’. Note that the ESC_PA encoding in the
PA_PDU is different from the ESC_PA encoding for the physical layer, which is described in Section 5.7.5
for D-PHY and in Section 5.8.3 for M-PHY.
1017 Receiving a PA Escaped Data PA_PDU shall be reported to L2 using the PA_ERROR.ind primitive with
PAErrorCode set to BAD_PA_PARAM (see Section 5.3.3.1) when any of the following conditions occur:
1018 • An ESC_PA symbol is received with an undefined value of EscParam_PA.
1019 • An ESC_PA symbol is received that represents TRG_UPR1 or TRG_UPR2, but Link Startup in high-
speed mode is not supported (D-PHY only).
1026 A UniPro power mode is assigned per Link direction, thus the power mode of the forward Link may be
different from the power mode of the reverse Link. Note that all active Lanes per direction shall have the
same power configuration. In D-PHY, a UniPro stack is able to set only the power mode of its forward Link,
while its reverse Link is set by the remote UniPro. This process is described in Section 5.7.1. In M-PHY, a
UniPro stack is able to set the power mode of its forward and reverse Links via the Link Configuration
Procedure described in Section 5.8.12.
Lane 0 PA_PDU 0 PA_PDU 1 PA_PDU 2 PA_PDU N-3 PA_PDU N-2 PA_PDU N-1
1030 Figure 21 defines the PHY Adapter Layer PDU ordering for two Data Lanes. The diagram shows that the
PDU #0 and PDU #1 are transferred simultaneously on the two Data Lanes.
Lane 0 PA_PDU 0 PA_PDU 2 PA_PDU 4 PA_PDU N-6 PA_PDU N-4 PA_PDU N-2
Lane 1 PA_PDU 1 PA_PDU 3 PA_PDU 5 PA_PDU N-5 PA_PDU N-3 PA_PDU N-1
1031 Figure 22 defines the PDU ordering for a three Data Lane configuration. Here, the PDU #0, PDU #1 and PDU
#2 are transferred simultaneously on the three Data Lanes.
Lane 0 PA_PDU 0 PA_PDU 3 PA_PDU 6 PA_PDU N-9 PA_PDU N-6 PA_PDU N-3
Lane 1 PA_PDU 1 PA_PDU 4 PA_PDU 7 PA_PDU N-8 PA_PDU N-5 PA_PDU N-2
Lane 2 PA_PDU 2 PA_PDU 5 PA_PDU 8 PA_PDU N-7 PA_PDU N-4 PA_PDU N-1
1032 The PDU ordering for a four Data Lane configuration is depicted in Figure 23. Here, the PDU #0, PDU #1,
PDU #2 and PDU #3 are transferred simultaneously on the four Data Lanes.
Lane 0 PA_PDU 0 PA_PDU 4 PA_PDU 8 PA_PDU N-12 PA_PDU N-8 PA_PDU N-4
Lane 1 PA_PDU 1 PA_PDU 5 PA_PDU 9 PA_PDU N-11 PA_PDU N-7 PA_PDU N-3
Lane 2 PA_PDU 2 PA_PDU 6 PA_PDU 10 PA_PDU N-10 PA_PDU N-6 PA_PDU N-2
Lane 3 PA_PDU 3 PA_PDU 7 PA_PDU 11 PA_PDU N-9 PA_PDU N-5 PA_PDU N-1
1033 The described Lane distribution scheme is independent of the actual PHY type. The mapping of PHY
Adapter PDUs to PHY bits is defined in Section 5.7.5 for D-PHY and in Section 5.8.3 for M-PHY.
FAST
PA_LM_AUTOSELECT.req PA_LM_AUTOSELECT.cnf_L
(FAST_STATE)
PA_LM_AUTOSELECT.req
(SLEEP_STATE)
PWRMode = FastAuto_Mode FAST/SLEEP
PA_LM_SET.cnf_L PA_LM_AUTOSELECT.req
(FAST_STATE)
PA_LM_AUTOSELECT.req
(SLEEP_STATE)
SLEEP
PA_LM_AUTOSELECT.cnf_L
SLOW
PA_LM_AUTOSELECT.req PA_LM_AUTOSELECT.cnf_L
(SLOW_STATE)
PA_LM_AUTOSELECT.req
(SLEEP_STATE)
PWRMode = SlowAuto_Mode SLOW/SLEEP
PA_LM_SET.cnf_L PA_LM_AUTOSELECT.req
PA_LM_RESET.req (SLOW_STATE)
PA_LM_AUTOSELECT.req
(SLEEP_STATE)
SLEEP
PA_LM_AUTOSELECT.cnf_L
1049 In the case of a Link with multiple Data Lanes, the following rules shall apply:
1050 • In the FAST_STATE of the Fast_Mode or FastAuto_Mode, a Device may use multiple Data Lanes to
transmit data as defined by PA_ActiveTxDataLanes. When a transmitter enters and exits the
FAST_STATE, all active Data Lanes shall enter and exit the HS state in the same bit-clock cycle at a
PA_PDU symbol boundary.
1051 • In the SLOW_STATE of the Slow_Mode or SlowAuto_Mode, a UniPro Device shall use Data Lane 0.
Data Lane 1 up to Data Lane (PA_ActiveTXDataLanes-1) shall be in SLEEP_STATE.
1052 • When a transmitter enters and exits HIBERNATE_STATE, all active and inactive Data Lanes shall enter
and exit the ULPS state in the same bit-clock cycle at a PA_PDU symbol boundary.
1053 • When a transmitter enters the OFF_STATE, all active and inactive Data Lanes shall be shutdown in the
same bit-clock cycle at a PA_PDU symbol boundary.
1054 • An inactive Data Lane may be placed in any mode, including Hibernate_Mode and Off_Mode.
1066 The number of additional PHY byte clock cycles depends on the implementation, e.g. number of pipeline
stages, of the receiving Device.
Node A Node B
PA_LM_RESET.req
PA_LM_RESET.cnf_L
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.cnf_L
PA_LM_LINKSTARTUP.req
TRG_UPR1
PA_LM_LINKSTARTUP.ind
PA_LM_RESET.req
PA_LM_RESET.cnf_L
PA_LM_ENABLE_LAYER.req
TRG_UPR1
1 PA_LM_ENABLE_LAYER.cnf_L
PA_LM_LINKSTARTUP.req
TRG_UPR1
1
TRG_UPR1
2
TRG_UPR1 TRG_UPR1
2
TRG_UPR1 TRG_UPR2
TRG_UPR2
3 3
TRG_UPR2
4
TRG_UPR2 TRG_UPR2
4
PA_LM_LINKSTARTUP.cnf_L
5 TRG_UPR2
PA_LM_LINKSTARTUP.cnf_L
5
Figure 25 Link Startup Sequence Example with One Node Initiating the Sequence (D-PHY
only)
1076 In the second scenario, shown in Figure 26, both ends of the Link (nodes) start the Link Startup sequence
simultaneously. In this scenario, both nodes receive the PA_LM_LINKSTARTUP.req primitive from their
respective DMEs at approximately the same time and enter Phase 1. Both nodes start sending TRG_UPR1
events while waiting to receive TRG_UPR1 events from the other node. All other data is ignored by both
nodes. After receiving a TRG_UPR1 event, each node enters Phase 2 of the Link Startup sequence and sends
two additional TRG_UPR1 events before moving to Phase 3.
1077 Both nodes continue through the Link Startup sequence.
Node A Node B
PA_LM_RESET.req
PA_LM_RESET.req
PA_LM_RESET.cnf_L
PA_LM_RESET.cnf_L
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.cnf_L
PA_LM_ENABLE_LAYER.cnf_L
PA_LM_LINKSTARTUP.req
PA_LM_LINKSTARTUP.req
TRG_UPR1
TRG_UPR1
1
1
TRG_UPR1
TRG_UPR1 2
2
TRG_UPR1 TRG_UPR1
TRG_UPR2 TRG_UPR2
3
3
TRG_UPR2
4 TRG_UPR2
TRG_UPR2 4
TRG_UPR2
PA_LM_LINKSTARTUP.cnf_L
5
PA_LM_LINKSTARTUP.cnf_L
5
Figure 26 Link Startup Sequence Example with Both Nodes Initiating the Sequence
(D-PHY only)
PA-PDU
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
B1 X1 Y1 Y2 B2 B3 Y3 Y4 X2 B1 X1 Y1 Y2 B2 B3 Y3 Y4 X2
1082 The content of the PA_PDU [16:8] bits shall be mapped to the first symbol (High Symbol); the content of the
PA_PDU [7:0] bits shall be mapped to the second symbol (Low Symbol). The High Symbol is transmitted
first over the Link. Within each symbol, the B1 bit shall be transmitted first and the X2 bit shall be transmitted
last.
1083 The mapping of PA_PDU content to the Encoded D-PHY Low symbol is defined in Table 16. The
PA_PDU[7:0] bits shall map linearly to the input of the Encoded D-PHY encoder, with PA_PDU[7] as most
significant bit and PA_PDU[0] as least significant bit.
1084 The mapping of PA_PDU content to the Encoded D-PHY High symbol is defined in Table 17. When
PA_PDU [16] is ‘0’, the PA_PDU [15:8] bits shall map linearly to the input of the Encoded D-PHY encoder,
with PA_PDU bit 15 as the most significant bit and PA_PDU bit 8 as the least significant bit. When PA_PDU
bit 16 is ‘1’, the mapping is controlled by the value of PA_LegacyDPHYEscDL and the resulting Encoded D
PHY High symbol shall be the Type A comma code for protocol usage or a regular exception code, as defined
in Table 17.
1085 Table 18 shows examples for the symbol mapping of various PA_PDU types when PA_LegacyDPHYEscDL
is FALSE. The first example represents normal DL data symbol, and the second a DL escaped data symbol
(‘SOF TC1’).
1086 The 8b9b coding enables the detection of invalid 9-bit D-PHY symbols and valid 9-bit D-PHY symbols that
are undefined at the receiver.
1087 An Encoded D-PHY 9-bit symbol that is not a valid data or escape code is called an invalid symbol. An
Encoded D-PHY 9-bit symbol that is a valid 9-bit code, but not one of D000-D255, C400, C417 or C600, is
called an undefined symbol.
1088 When received, a C417 or a C600 9-bit symbol for PA_PDU[15:8] shall be mapped to ESC_DL.
1089 If an invalid or undefined symbol is received, it shall be flagged to the DL Layer using the PA_ERROR.ind
primitive, with PAErrorCode set to BAD_PHY_SYMBOL or UNMAPPED_PHY_ESC_SYMBOL,
respectively. A PA_PDU containing invalid or undefined 9-bit symbols shall be discarded by the PA Layer
and shall not be passed to the DL Layer.
1090 Receiving a C400, C417 or C600 9-bit symbol for PA_PDU[7:0] shall be flagged to the DL Layer as an error
using the PA_ERROR.ind primitive with PAErrorCode set to UNEXPECTED_PHY_ESC_SYMBOL. A
PA_PDU containing a C400, C417 or C600 9-bit symbol for PA_PDU[7:0] shall be discarded by the PA
Layer and shall not be passed to the DL Layer.
1092 These definitions apply to D-PHY Data Lanes. The status of the Clock Lane depends on PA_TxForceClock
(see Table 36). When PA_TxForceClock equals TRUE, the transmit Clock Lane shall run in the HS mode,
independent of the actual UniPro power mode. When PA_TxForceClock equals FALSE, the transmit Clock
Lane shall run in the actual UniPro power mode. In both cases, the definitions of Section 5.6.1 and those of
[MIPI01] shall remain the same.
1093 In the UniPro FAST_STATE, the D-PHY shall perform high speed data transmission (HS) on all activated
PHY Data Lanes. As UniPro requires an encoded D-PHY, the D-PHY HS state has an interruptible data
transmission. When a UniPro stack stops data transmission when D-PHY is in the HS state, the D-PHY
inserts PHY IDLE symbols. As a result, for D-PHY, data transmission is interruptible in the FAST_STATE.
1094 In the UniPro SLOW_STATE, the D-PHY shall perform low power data transmission (LPDT) on PHY Data
Lane 0 only. In this state, no additional PHY Data Lanes shall be used for data transmission. For D-PHY, data
transmission is interruptible in the SLOW_STATE.
1096 All D-PHY error events should be indicated to the DME with the PA_LM_ERROR.ind primitive. The error
events are identified by their PhyErrorCode value.
1101 A low-speed UniPro trigger is mapped to a single D-PHY trigger event preceded by the STOP state for a
specific duration. For the TRG_UPR2 and TRG_EPR events, this duration should be as short as the PHY
implementation allows while complying with [MIPI01].
1102 For the TRG_UPR1 event, the duration of the preceding STOP state shall be TINIT, MASTER as defined in
Table 23. This is to ensure the minimum STOP state duration seen by the attached receiver, as defined in
[MIPI01].
1105 Note that EndPointReset is not supported when high-speed triggers are used.
5.7.9 (Re-)Initialization
1106 The PA_INIT.req primitive shall cause the D-PHY transmit Data Lanes to transition from their current
original state to the STOP state and back to the original state. If the original state is interruptible, the PA Layer
ensures that at least PA_TxTrailingClocks clocks where driven since the last data transmission prior to the
transition to the STOP state as defined in Section 5.6.2. The time spent in the STOP state should be as short as
practical. When the original state is reached again, this shall be indicated by the PA Layer to the DL Layer
with the PA_INIT.cnf_L primitive.
1108 The PHY shall initialize as defined in the “Initialization” section of the D-PHY specification [MIPI01]. The
respective TINIT,MASTER and TINIT,SLAVE timings are defined in Table 23.
1109 After PHY initialization, its transmitter shall be either in the STOP or LPDT mode which is according to the
UniPro SlowAuto_Mode.
1150 • TX_HSGEAR
1151 • TX_HSRATE_Series
1152 • TX_HIBERN8_Control
1153 • TX_LCC_Sequencer
1154 • TX_HS_Unterminated_LINE_Drive_Enable
1155 • MC_HS_Unterminated_LINE_Drive_Enable
1156 • MC_HS_Unterminated_Enable
1157 • TX_LS_Terminated_LINE_Drive_Enable
1158 • MC_LS_Terminated_LINE_Drive_Enable
1159 • MC_LS_Terminated_Enable
1160 • RX_MODE
1161 • RX_PWMGEAR
1162 • RX_HSGEAR
1163 • RX_HSRATE_Series
1164 • RX_Enter_HIBERN8
1165 • RX_HS_Unterminated_Enable
1166 • RX_LS_Terminated_Enable
1167 Trying to set these Attributes shall be rejected with a READ_ONLY_MIB_ATTRIBUTE error. An access to
an Attribute of an unavailable Lane shall be rejected with a BAD_INDEX error.
5.8.2.1 LINE-RESET
1168 The PA Layer issues a LINE-RESET to PHY in three cases: 1) at the beginning of the Link Startup sequence,
2) at the recovery step in the power mode change operation, 3) on a request from the DL with a PA_INIT.req
primitive. The LINE-RESET shall be issued on all available Lanes.
1169 The PA Layer shall indicate to the DME via a PA_LM_PHY_RESET.ind primitive if the PHY has been reset
due to a received LINE-RESET or due to a transmitted LINE-RESET. Since LINE-RESET causes PHY to
reset all its Attributes to their default values, the Application needs to SET the optimized values after each
reset.
1177 A UniPro Link may use any number of Lanes in SLOW_STATE and FAST_STATE.
1178 When ending a burst, PA Layer TX shall perform the following steps on all active Lanes (see Figure 28 for an
example):
1179 1. Transmit a MK2 symbol, i.e. an M-PHY End-of-Burst marker
1180 2. Transmit FILLER symbols (FLR) for the period of PA_TxTrailingClocks
1181 3. Issue a M-LANE-BurstEnd.req
Lane 0 PA_PDU 0 PA_PDU N-3 PA_PDU N-1 MK2 FLR FLR FLR
Lane 1 PA_PDU 1 PA_PDU N-2 FLR FLR MK2 FLR FLR FLR
Tail of Burst is
padded with
FILLER symbols to
align MK2s
1182 After the end of the burst, PA Layer TX guarantees a minimum re-configuration time for the M-PHY before
beginning a new burst. The minimum time values are obtained in Link Startup sequence (see Section 5.8.8.5)
and cover both the local M-TX and the peer M-RX. The time is counted from the reception of a M-LANE-
SaveState.ind primitive. The following three cases shall be detected:
1183 1. HS burst ending with no configuration applied: wait for PA_StallNoConfigTime
1184 2. PWM burst ending with no configuration applied: wait for PA_SleepNoConfigTime
1185 3. HS or PWM burst ending with a new configuration applied: wait for PA_SaveConfigTime
1186 When waking-up a Lane from HIBERNATE_STATE, the PA Layer shall keep the M-TX in SLEEP_STATE
for the period set in PA_TActivate. The value of PA_TActivate takes into account the peer M-RX’s
TACTIVATE, as defined in [MIPI05], and possibly other system-specific timing issues.
1192 UniPro trigger TRG_UPR1 has a 4-bit parameter containing information regarding connected Lanes in a
bitmap format. The bit n of the parameter shall be set if a TRG_UPR0 has been received on Physical Lane n.
TRG_UPR1 is mapped to an escaped PA_PDU with EscParam parameter set to 0x80 + C, where C is the 4-bit
parameter of TRG_UPR1. Minimum and maximum values for C are 1 and 15, respectively. Table 26 shows
examples for TRG_UPR1 mappings. The trigger is transmitted on all available Lanes with the same value of
C.
1193 UniPro trigger TRG_UPR2 is mapped to an escaped PA_PDU with EscParam set to 0xC0. This translates to
<MK1, 0xC0>. The trigger is transmitted on all available Lanes.
1194 UniPro trigger TRG_EPR is mapped to PACP_EPR_ind (see Section 5.8.7.4). The trigger is transmitted as
any PACP frame, i.e. following the normal Lane distribution rules.
16 15 14 13 12 11 10 9 8 76 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId
0 Parameters
0 ...
0 CRC-16
1198 The receiving PA Layer detects the beginning of a PACP frame from the unique start symbol, an escaped
PA_PDU with EscParam set to PACP_BEGIN, which is equal to 0x01. The 16-bit field PACP_FunctionId
identifies the function and also determines how many 16-bit parameters, if any, follow. The PACP frame ends
with a CRC-16 field. The CRC-16 checksum shall be calculated over the whole PACP frame using the same
algorithm as in the DL Layer (see Section 6.6.12). The receiving PA Layer shall silently ignore all PACP
frames that fail the checksum check or contain invalid values. The reception of a new PACP start symbol
shall cause the PA Layer to discard any PACP frame that has not been received completely.
1199 The valid function IDs are defined in Table 27 and described in detail in other sections.
1200 The PA Layer has two counters for counting received PACP frames, PA_PACPFrameCount and
PA_PACPErrorCount. PA_PACPFrameCount shall be incremented by one if the received frame has a valid
FunctionID and passes the checksum verification. PA_PACPErrorCount shall be incremented by one for each
PACP start symbol that is not part of a PACP frame that incremented PA_PACPFrameCount. The counters
shall automatically roll-over to zero on an overflow. A PA_LM_SET request to PA_PACPFrameCount or
PA_PACPErrorCount shall set the counter to zero.
5.8.7.1 PACP_PWR_req
1201 A PACP_PWR_req frame is used when changing a Link’s power configuration (see Section 5.8.12.2). A
complete frame is shown in Figure 30.
1202 The frame parameters contain the requested power configuration for both directions and a data payload
(PAPowerModeUserData) for DME. Note that in this Frame “TX” and “RX” refer to the outbound and
inbound directions of the requestor, respectively.
1203 The fields shall be as follows (related PA Layer Attribute given in parenthesis):
1204 • DevID: Local Device ID, set to 0x80 when N_DeviceID_valid is FALSE, otherwise set to the value of
N_DeviceID
1205 • Flags
1206 • Flags[4]: UserDataValid, set to ‘1’ if the frame contains valid PAPowerModeUserData
1207 • Flags[3]: HS Series, set to ‘0’ for Series A and to ‘1’ for Series B (PA_HSSeries)
1208 • Flags[2]: Line-reset request
1209 • Flags[1]: TX-direction termination enable (PA_TxTermination)
1210 • Flags[0]: RX-direction termination enable (PA_RxTermination)
1211 • TxMode: UniPro Power mode for TX-direction (PA_PWRMode[b2:b0]). Set to 0x3 when entering
hibernate.
1212 • TxLane: Active Lane count for TX-direction (PA_ActiveTxDataLanes)
1213 • set to ‘0’ when PA_ActiveTxDataLanes=4, else set to PA_ActiveTxDataLanes
1214 • TxGear: PWM or HS gear for TX-direction (PA_TxGear)
1215 • RxMode: UniPro Power mode for RX-direction (PA_PWRMode[b6:b4]). Set to value 0x3 when
entering hibernate.
1216 • RxLane: Active Lane count for RX-direction, set to ‘0’ when count = 4 (PA_ActiveRxDataLanes)
1217 • set to ‘0’ when PA_ActiveRxDataLanes=4, else set to PA_ActiveRxDataLanes
1218 • RxGear: PWM or HS gear for RX-direction (PA_RxGear)
1219 • PAPowerModeUserData: user-data for peer DME (PA_PWRModeUserData)
1220 The direction-specific parameters shall be ignored if the direction’s Mode is set to UNCHANGED. If the
Line-Reset flag is asserted, the receiving PA Layer shall issue a LINE-RESET before processing the received
frame.
1221 If the UserDataValid flag is set, the receiving PA Layer shall give the data received in the PAPowerModeUser
field to the DME via the PA_LM_PWR_MODE.ind (see Section 5.8.12.4).
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_PWR_req
0 DevID Reserved Flags
0 TxMode TxLane TxGear RxMode RxLane RxGear
0 PAPowerModeUserData[0]
0 PAPowerModeUserData[1]
0 PAPowerModeUserData[2]
0 PAPowerModeUserData[3]
0 PAPowerModeUserData[4]
0 PAPowerModeUserData[5]
0 PAPowerModeUserData[6]
0 PAPowerModeUserData[7]
0 PAPowerModeUserData[8]
0 PAPowerModeUserData[9]
0 PAPowerModeUserData[10]
0 PAPowerModeUserData[11]
0 CRC-16
Figure 30 PACP_PWR_req
5.8.7.2 PACP_PWR_cnf
1222 The PACP_PWR_cnf frame is a response to a PACP_PWR_req frame. The frame structure is shown in
Figure 31. The Status parameter shall contain the status of the requested power mode change. The
PA P o w e r M o d e U s e r D a t a p a r a m e t e r c a r r i e s t h e d a t a p a y l o a d d e l i v e r e d t o D M E v i a a
PA_LM_PWR_MODE.ind primitive. The possible values of the Status field are listed in Table 28.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_PWR_cnf
0 Reserved Status
0 PAPowerModeUserData[0]
0 PAPowerModeUserData[1]
0 PAPowerModeUserData[2]
0 PAPowerModeUserData[3]
0 PAPowerModeUserData[4]
0 PAPowerModeUserData[5]
0 PAPowerModeUserData[6]
0 PAPowerModeUserData[7]
0 PAPowerModeUserData[8]
0 PAPowerModeUserData[9]
0 PAPowerModeUserData[10]
0 PAPowerModeUserData[11]
0 CRC-16
Figure 31 PACP_PWR_cnf
5.8.7.3 PACP_CAP_ind
1223 The PACP_CAP_ind frame is shown in Figure 32. It shall be used in the last state of the Link Startup
Sequence to notify the remote PA Layer of the local M-TX capabilities (see Section 5.8.8).
1224 The frame’s fields shall be set as follows (source of the information given in parenthesis):
1225 • Flags
1226 • Flags[1]: HS untermination capability (TX_HS_Unterminated_LINE_Drive_Capability)
1227 • Flags[0]: LS termination capability (TX_LS_Terminated_LINE_Drive_Capability)
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_CAP_ind
0 TSleepNoConfig Reserved Flags MaxHS MaxPWM
0 TStallNoConfig TSaveConfig
0 VersionInfo
0 Reserved
0 Reserved
0 Reserved
0 CRC-16
Figure 32 PACP_CAP_ind
5.8.7.4 PACP_EPR_ind
1234 The PACP_EPR_ind frame is shown in Figure 33. It does not have any parameters.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_EPR_ind
0 CRC-16
Figure 33 PACP_EPR_ind
5.8.7.5 PACP_TEST_MODE_req
1235 The PACP_TEST_MODE_req frame is shown in Figure 34. It is used to set the peer Device in PHY testing
mode. The frame does not have any parameters.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_TEST_MODE_req
0 CRC-16
Figure 34 PACP_TEST_MODE_req
5.8.7.6 PACP_GET_req
1236 The PACP_GET_req frame is shown in Figure 35. This PACP frame shall be sent when a
PA_LM_PEER_GET.req primitive is generated by the DME or when the PHY Test Feature requests it.
1237 The frame’s fields shall be set as follows:
1238 • MIBattribute: defines the Attribute to be accessed in the peer Device
1239 • GenSelectorIndex: the index required for certain Attributes
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_GET_req
0 MIBattribute
0 GenSelectorIndex
0 CRC-16
Figure 35 PACP_GET_req
5.8.7.7 PACP_GET_cnf
1240 The PACP_GET_cnf frame is shown in Figure 36. When the DME generate the PA_LM_PEER_GET.rsp
primitive or when the PHY Test Feature requests it, the PA Layer shall send the PACP_GET_cnf frame.
1241 The frame’s fields shall be set as follows:
1242 • ConfigResultCode: returns the result of the operation. The values taken by this field are defined in the
context of the PA_LM_PEER_GET.rsp primitive in Table 8
1243 • MIBvalue: holds the value of the Attribute
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_GET_cnf
0 ConfigResultCode Reserved
0 MIBvalue (high word)
0 MIBvalue (low word)
0 CRC-16
Figure 36 PACP_GET_cnf
5.8.7.8 PACP_SET_req
1244 The PACP_SET_req frame is shown in Figure 37. This PACP frame shall be sent when a
PA_LM_PEER_SET.req primitive is generated by the DME or when the PHY Test Feature requests it.
1245 The frame fields shall be set as follows:
1246 • Cnf: defines the behavior of the receiving PA Layer
1247 • 0: no PACP_SET_cnf frame shall be sent
1248 • 1: a PACP_SET_cnf frame shall be sent to acknowledge the reception of the PACP_SET_req frame
and to return the result of the operation
1249 • T: defines the target Attribute type (AttrSetTypeType)
1250 • 0: Normal
1251 • 1: Static
1252 • MIBattribute: defines the Attribute to be accessed in the peer Device
1253 • GenSelectorIndex: the index required for certain Attributes
1254 • MIBvalue: holds the value which the Attribute shall take
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_SET_req
0 Cnf T Reserved
0 MIBattribute
0 GenSelectorIndex
0 MIBvalue (high word)
0 MIBvalue (low word)
0 CRC-16
Figure 37 PACP_SET_req
5.8.7.9 PACP_SET_cnf
1255 The PACP_SET_cnf frame is shown in Figure 38. When the DME generates the PA_LM_PEER_SET.rsp
primitive, the PA Layer shall send the PACP_SET_cnf frame.
1256 The frame’s fields shall be set as follows:
1257 • ConfigResultCode: returns the result of the operation. The values taken by this field are defined in the
context of the PA_LM_PEER_SET.rsp primitive in Table 8
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_SET_cnf
0 ConfigResultCode Reserved
0 CRC-16
Figure 38 PACP_SET_cnf
5.8.7.10 PACP_TEST_DATA
1258 The PACP_TEST_DATA frame is shown in Figure 39. There are four variations of the basic
PACP_TEST_DATA frame, each having a different FunctionID and different payload length. The frame is
used in PHY testing as explained in Section 5.8.15.
1259 The TestPattern field carries the PHY test pattern. The transmitted patterns are defined in Section 5.8.15. The
received patterns are undefined since the receiver shall only check the header, the length, and the checksum
while ignoring the content of TestPattern.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_PA EscParam_PA = PACP_BEGIN
0 PACP_FunctionId = PACP_TEST_DATA
0 TestPattern[0] TestPattern[1]
0 TestPattern[2] TestPattern[3]
0 ... ...
0 TestPattern[n-2] TestPattern[n-1]
0 CRC-16
Figure 39 PACP_TEST_DATA
1265 In the first phase, both Devices shall repeatedly send TRG_UPR0 triggers on all available Data Lanes. The
TRG_UPR0 trigger data structure is defined in Section 5.8.6, but the data structure contains a field that shall
be set by every transmitting Data Lane to hold that Data Lane's fixed, internal “Physical Data Lane number”
(PL# in Figure 40).
1266 The peer Device shall update its local PeerTxConnectedLanesMask register to reflect the Data Lanes on
which triggers have been received. This information is used in subsequent phases of this sequence.
1267 A Device shall continue transmitting TRG_UPR0 Messages until it receives a TRG_UPR0 Message from the
peer Device, after which it shall send two extra TRG_UPR0 Messages before proceed to the next phase.
1268 The following steps describe Phase 0 and Phase 0b operation in detail:
1269 1. Wait for a period of PA_TActivate to wake-up M-RXs from HIBERN8 (see [MIPI05]).
1270 2. Begin burst (includes the transmission of the deskew pattern) on all available TX Lanes.
1271 3. Send a TRG_UPR0 on all available TX Lanes.
1272 4. End burst on all available TX Lanes.
1273 5. If a TRG_UPR0 has been received then continue from Step 7.
1274 6. Continue from Step 1.
1275 7. Wait for a period of PA_TActivate to wake-up M-RXs from HIBERN8 (see [MIPI05]).
1276 8. Begin burst (includes the transmission of the deskew pattern) on all available TX Lanes.
1277 9. Send two additional TRG_UPR0s on all available TX Lanes.
1278 10. Exit to Phase 1.
Node A Node B
LocalTxConnectedLanesMask Tx TRG_UPR0 (TxLaneNumber = 11) Rx PeerTxConnectedLanesMask
PL#3 X
X TRG_UPR0 (TxLaneNumber = 10) 1
PL#2 X
X 1
X TRG_UPR0 (TxLaneNumber = 01) 0
PL#1 X
X 0
TRG_UPR0 (TxLaneNumber = 00)
PL#0 X
Node A Node B
LocalTxConnectedLanesMask Tx TRG_UPR1 (PeerTxConnectedLanesMask = 0100) Rx PeerTxConnectedLanesMask
PL#3 LL#1
1 TRG_UPR1 (PeerTxConnectedLanesMask = 0100) 1
PL#2 LL#0
1 1
0 TRG_UPR1 (PeerTxConnectedLanesMask = 0100) 0
PL#1 X
0 0
TRG_UPR1 (PeerTxConnectedLanesMask = 0100)
PL#0 X
1290 Note:
1291 Because the discovery process is handled autonomously, and considered to be highly robust, infor-
mation about which physical Data Lanes are connected and the interconnect topology are not made
available to the Application in a normative way. In fact, both Physical and Logical Data Lane numbers
as described in this Link Startup Sequence are invisible to higher protocol layers and to the Applica-
tion.
1292 In these phases, TRG_UPR2 Messages (with no special payload) shall be repeatedly transmitted over all
connected Data Lanes until a TRG_UPR2 Message is received by the peer Device, after which the Device
shall send two more TRG_UPR2 Messages over all connected Data Lanes. These phases essentially serve to
terminate previous phases in a robust and orderly manner.
1293 The following steps describe Phase 3 and Phase 4 operation in detail:
1294 1. Send a TRG_UPR2 on all available TX Lanes
1295 2. If a TRG_UPR2 has been received then continue from Step 4
1296 3. Continue from Step 1
1297 4. Send two additional TRG_UPR2s on all available TX Lanes
1298 5. Close the burst (which activates the new power mode settings)
1299 6. Update PA_LogicalLaneMap, and begin using the logical Lane numbering
1300 7. M-TXs and M-RXs on unconnected Lanes shall be configured to the UNPOWERED state
1301 8. Exit to Capability Phase
Node A Node B
LocalTxConnectedLanesMask Tx TRG_UPR2 Rx PeerTxConnectedLanesMask
LL#1 LL#1
1 TRG_UPR2 1
LL#0 LL#0
1 1
0 0
X X
0 0
X X
X X
0 TRG_UPR2 0
1 LL#0 LL#0
1
0 0
0 X X
0
X X
PeerTxConnectedLanesMask Rx Tx LocalTxConnectedLanesMask
closing the burst. When the PA Layer receives a PACP_CAP_ind Frame, and a M-CTRL-LCCReadStatus.ind
primitive from the M-RX on Logical Lane 0, it shall perform capability downgrading as described in
Section 5.8.9. The manufacturing information from the OMC is not used by the PA Layer but is stored for
Application usage in the Attributes of the M-RX on Logical Lane 0. The peer Device’s version information
received in PACP_CAP_ind is stored in PA_RemoteVerInfo. This finishes the Link Startup Sequence. The
M-PHY Link is now in the default power mode, i.e. PWM-G1, 1-Lane.
5.8.10 (Re-)Initialization
1315 The PA Layer offers two mechanisms to reinitialize the Link. The less severe mechanism, deskew pattern
injection, inserts additional deskew patterns to all active Lanes in order to fix any M-PHY symbol or PA
Symbol synchronization issues. The insertion adds a one symbol delay to the transmission and may be
requested at any point. The request is ignored in SLEEP_STATE since there is no active burst on-going. The
mechanism may be triggered by the DL Layer via the PA_LANE_ALIGN primitive (see Section 5.3.2.6).
1316 The more severe mechanism involves reinitializing the power configuration of both inbound and outbound
Links. The DL Layer can request this mechanism via a PA_INIT primitive (see Section 5.3.2.1). The
procedure is as follows:
1317 1. Issue LINE-RESET to reset outbound M-TX, M-RX, and possible OMC to PWM-G1
1318 2. Begin burst on logical Lane 0
1319 3. Request the peer Device issue LINE-RESET on the inbound Link via PACP_PWR_req. The request
also contains the current power mode configuration. No PowerModeUserData is exchanged and thus
the UserDataValid flag is unset.
1320 4. PACP_REQUEST_TIMER is set to PA_PACPReqTimeout + TLINERESET and started
1321 5. Wait for a PACP_PWR_cnf frame from the peer Device, or for PACP_REQUEST_TIMER to timeout
1322 6. Configure M-TX and M-RX
1323 7. End burst to activate the new PHY configuration
1324 8. Reply to the DL Layer via a PA_INIT.cnf_L primitive
1325 If there is a timeout at Step 5, the Link is considered unusable and the reinitialization is aborted. The PA Layer
replies to the DL Layer with a PA_INIT.cnf_L primitive, even though the reinitialization failed. The PA
Layer shall be ready for a possible retry by the DL Layer.
1326 If the reinitialization succeeds, the power mode is reinitialized using the active settings, and a misconfigured
M-RX or OMC receives correct settings.
1347 1. A local request shall be rejected when the PA Layer is processing a local request or a remote request
from the peer Device. In this case, the conflict is detected when the DME issues a PA_LM_SET.req
primitive to PA_PWRMode. The DME is notified with a PA_LM_SET.cnf_L primitive having a
parameter BUSY.
1348 2. A remote request shall be rejected when the PA Layer is processing a local request, and the DevID field
of the remote request is larger than or equal to X, where X is N_DeviceID if N_DeviceID_valid is
TRUE, otherwise X is 0x80.
1349 Note, the second rule causes concurrent requests from both Devices to be rejected when both local and
remote DeviceIDs have not yet been assigned. If at least one of the DeviceIDs have been set, then the
equation guarantees that one of two on-going requests is accepted.
DME. Then the remote PA Layer shall begin a burst on its outbound Link. Before sending the
PACP_PWR_cnf frame to the local PA Layer, the M-PHY shall be configured with the parameters of the
request.
1358 When the local PA Layer receives a valid PACP_PWR_cnf frame, it shall first check the status of the
confirmation. If the status is positive, the received PAPowerModeUserData is given to the local DME and the
local M-PHY shall be configured with the requested parameters. The local PA Layer shall close the burst on
the outbound Link. The remote PA Layer shall close the burst on the other Link when detecting the end of
burst on its inbound Link. Consequently, both directions of the Link have now the new configuration
activated. Both sides shall notify their respective DL Layers about the completion of the procedure. The local
and remote PA Layer notify their respective DMEs with a PA_LM_PWR_MODE_CHANGED.ind signal
with the parameter PWR_LOCAL and PWR_REMOTE, respectively. This concludes the power mode
change and both PAs are ready for subsequent operations.
1400 The local PA Layer shall have a timer, PACP_REQUEST_TIMER, to detect a missing PACP_PWR_cnf
Message and also to detect missing end of burst of the inbound Link. The initial timer value shall be set
through PA_PACPReqTimeout and PA_PACPReqEoBTimeout, respectively.
1401 The following list includes the steps related to error recovery. Only the local PA Layer shall take recovery
actions while the remote PA Layer only follows them:
1402 1. The first PACP_PWR_req is transmitted. PACP_REQUEST_TIMER shall be set to
PA_PACPReqTimeout.
1403 2. If a valid PACP_PWR_cnf Message is not received before the timer expires, the PACP_PWR_req is
sent again. The timer is reset to PA_PACPReqTimeout.
1404 3. If a valid PACP_PWR_cnf Message is not received before PACP_REQUEST_TIMER expires, the PA
Layer shall first issue a LINE-RESET and then send the PACP_PWR_req again but this time asserting
the reset flag of the Message. The reset flag instructs the remote PA Layer to do a LINE-RESET on the
opposite direction. PACP_REQUEST_TIMER shall be reset to PA_PACPReqTimeout + TLINERESET to
take into account the time consumed at the remote LINE-RESET.
1405 4. If a valid PACP_PWR_cnf Message is not received before PACP_REQUEST_TIMER expires, the PA
Layer shall abort the power mode request and notify the DME via a PA_LM_PWR_MODE.ind
primitive with the parameter PWR_FATAL_ERROR.
1406 When a PACP_PWR_cnf Message is received successfully, the local PA Layer closes the burst and shall set
PACP_REQUEST_TIMER to PA_PACPReqEoBTimeout. If the remote PA Layer does not close the burst
within this period, the local PA Layer shall abort the power mode request and notify the DME via a
PA_LM_PWR_MODE_CHANGED.ind primitive with the parameter PWR_FATAL_ERROR.
1407 Transmissions after LINE-RESET use the PWM-G1 1-Lane configuration, in all other cases the PA Layer
uses the current mode.
Idle Idle
PA_LM_SET.req (PA_PwrMode, x)
Check Capability
PA_LM_SET.cnf_L (SUCCESS)
PA_DL_PAUSE
Burst TX
PACP_REQUEST_TIMER
PACP_PWR_req
WaitCnf
Check Capability
PA_LM_PWR_MODE.ind
PA_LM_PWR_MODE.rsp_L
PA_DL_PAUSE
Burst TX
Configure MODULEs
PACP_PWR_cnf
WaitEoB
PACP_REQUEST_TIMER
Check cnf
PA_LM_PWR_MODE.ind
PA_LM_PWR_MODE.rsp_L
Configure MODULEs
End TX Burst
PACP_REQUEST_TIMER
WaitEoB
End TX Burst
PACP_REQUEST_TIMER
PA_DL_RESUME.ind PA_DL_RESUME.ind
PA_LM_PWR_MODE_CHANGED.ind PA_LM_PWR_MODE_CHANGED.ind
(PWR_LOCAL) (PWR_REMOTE)
Idle Idle
5.8.13 PA Hibernate
1408 Hibernate is separated from the normal power mode change operation. The hibernate enter and hibernate exit
procedures are described in this section. When entering hibernation, the current power mode configuration,
including M-PHY settings and Lane count information, are stored. They are automatically restored when
exiting hibernate.
1409 The time in hibernation shall be greater than, or equal to, the minimum hibernate time, THIBERN8, defined in
[MIPI05]. The implementation can use a timer to guarantee this condition.
Idle
Idle
PA_LM_HIBERNATE_ENTER.req
PA_LM_HIBERNATE_ENTER.cnf_L
PA_DL_PAUSE
Burst TX
PACP_REQUEST_TIMER
PACP_PWR_req
WaitCnf
PA_DL_PAUSE
Burst TX
Configure MODULEs
PACP_PWR_cnf
PACP_REQUEST_TIMER
WaitEoB
Configure MODULEs
End TX Burst
PACP_REQUEST_TIMER
WaitEob
End TX Burst
PACP_REQUEST_TIMER
PA_DL_RESUME.ind PA_DL_RESUME.ind
PA_LM_HIBERNATE_ENTER.ind PA_LM_HIBERNATE_ENTER.ind
(PWR_LOCAL) (PWR_REMOTE)
LinkHibernate LinkHibernate
LinkHibernate
LinkHibernate
PA_LM_HIBERNATE_EXIT.req
PA_LM_HIBERNATE_EXIT.cnf_L
PA_TActivate
WaitTActive
Timer
WaitRxWake
(DIF-N) Configure MODULEs
PA_TActivate
Timer
WaitTActive
PA_LM_HIBERNATE_EXIT.ind PA_LM_HIBERNATE_EXIT.ind
(PWR_LOCAL) (PWR_REMOTE)
Idle Idle
primitive. When the PA Layer receives the primitive, it shall transmit a PACP_GET_cnf frame containing the
results given in the primitive.
1457 Note, the replay mechanism of PACP_GET and SET_req is identical to the one specified in Section 5.8.12.5
for PACP_PWR_req, with the exception that the LINE-RESET phase is not used here. Therefore, an
implementation may share the replay functionality (including the timer) between these two features.
1 to
PA_ActiveTxDataLanes 0x1560 Active TX Data Lanes Integer Lane 1 1
PA_AvailTxDataLanes
1 to
PA_ActiveRxDataLanes 0x1580 Active RX Data Lanes Integer Lane 1 1
PA_AvailRxDataLanes
136
FAST_STATE = 1,
PA_TxPWRStatus 0x1567 TX power state status Enumeration SLOW_STATE = 2,
HIBERNATE_STATE = 3,
SLEEP_STATE = 4
OFF_STATE = 0,
FALSE=0,
PA_TxForceClock 0x1562 the Clock Lane shall be Boolean FALSE FALSE
TRUE=1
always on, independent of the
UniPro stack power mode.
Off=0
MIPI Alliance Member Confidential
Fast_Mode=1,
Slow_Mode=2,
PA_TxPWRMode 0x1563 TX power mode Enumeration SlowAuto_Mode
Hibernate=3,
FastAuto_Mode=4,
SlowAuto_Mode=5
138
PA_TxSpeedFast 0x1565 Actual TX Data Lane speed (FAST_STATE) Mbps, per Lane Implementation-specific
PA_TxSpeedSlow 0x1566 Actual TX Data Lane speed (SLOW_STATE) Mbps, per Lane Implementation-specific
PWM_G4 =4
PWM_G5 =5
PA_TxGear 0x1568 TX Gear in PWM or HS Mode Enumeration PWM_G1 PWM_G1
PWM_G6 =6
PWM_G7 =7
MIPI Alliance Member Confidential
HS_G1=1
HS_G2=2
HS_G3=3
FALSE=0, FALSE,
PA_TxTermination 0x1569 TX Termination Boolean FALSE
TRUE=1 TRUE
140
PWM_G5 =5
PA_RxGear 0x1583 RX Gear in PWM or HS Mode Enumeration PWM_G1 PWM_G1
PWM_G6 =6
PWM_G7 =7
HS_G1=1
HS_G2=2
MIPI Alliance Member Confidential
HS_G3=3
FALSE=0, FALSE,
PA_RxTermination 0x1584 RX Termination Boolean FALSE
TRUE=1 TRUE
PWM_G1 =1
141
PWM_G2 =2
PWM_G1 to
PWM_G3 =3
Maximun RX Low Speed Gears RX_PWMG
PA_MaxRxPWMGear 0x1586 Integer PWM_G4 =4 PWM_G1
(PWM) EAR_Capab
PWM_G5 =5
ility
PWM_G6 =6
PWM_G7 =7
PACP_REQUEST_TIMER when
the PA Layer is waiting for the end
PA_PACPReqEoBTimeout 0x1591 of burst (see Section 5.8.12.5). Integer ms 0 to 15 15
The actual duration of the timeout
period shall be the value set in the
Attribute ±10%
142
PA_ConnectedTxDataLane 0 to
Number of TX Data Lanes
143
PA_ConnectedRxDataLan 0 to
Number of RX Data Lanes
0x1581 Integer 0 to PA_MaxDataLanes PA_AvailRx 0
es2 connected
DataLanes
TX Lanes:
Bits [1:0]: Physical Lane of Logical
Lane 0.
Bits [3:2]: Physical Lane of Logical
MIPI Alliance Member Confidential
Lane 1.
Bits [5:4]: Physical Lane of Logical
Lane 2.
PA_LogicalLaneMap2 0x15A1
Bits [7:6]: Physical Lane of Logical
16-bit word Implementation-specific Any
Lane 3.
144
RX Lanes:
Bits [9:8]: Physical Lane of Logical
Lane 0.
Bits [11:10]: Physical Lane of
Logical Lane 1.
Device
Management DL_TC0 DL_TC1
Entity SAP SAP
(DME) Management Plane Data Plane
DL_LM
SAP
6.3 DL_TCx_SAP
1532 Services to a DL Service User are provided via the DL_TCx_SAP. Each Traffic Class uses a dedicated
Service Access Point (SAP) for transferring data. The two defined SAPs are DL_TC0_SAP and
DL_TC1_SAP. The Traffic Class identification is performed based on the used SAP.
1533 At the sending side, data is passed via the DL_TCx_SAP in DL_SDUs to the DL Layer to transfer it to a peer
DL Layer. At the recipient side, the DL Layer delivers received data in DL_SDUs to the upper layer.
1535 Table 42 lists the parameters that appear in the DL_TCx_SAP primitives.
6.3.1.1 DL_DATA.req
1536 This primitive is used to send a DL_SDU over a dedicated TC of the DL Layer. The TC is given by the SAP
used. The user may transmit any integral number of bytes greater than zero up to the DL_MTU.
6.3.1.2 DL_DATA.cnf_L
1545 This primitive informs the DL Service User that the Service Provider, L2 in this case, is ready to accept a new
DL_DATA.req primitive.
1546 The semantics of this primitive are:
1547 DL_DATA.cnf_L( L2ResultCode )
6.3.1.3 DL_DATA.ind
1557 At the local RX the DL Layer Service Provider shall pass the received DL_SDU to the DL Layer Service
User using this primitive via the SAP of appropriate Traffic Class. The DL_SDU may consist of any integral
number of bytes greater than zero up to DL_MTU.
6.3.1.4 DL_DATA.rsp_L
1566 This primitive informs the Service Provider that the DL Service User, L3 in this case, is ready to accept a new
DL_DATA.ind or DL_ESCAPED_DATA.ind primitive.
1567 The semantics of this primitive are:
1568 DL_DATA.rsp_L( )
6.4 DL_LM_SAP
1575 The Data Link Layer Management (DL_LM) SAP offers three groups of Service Primitives: Configuration
primitives, Control primitives and Status primitives. The primitives on the DL_LM_SAP are used by the
Device Management Entity (DME) to configure and control the layer and receive layer status information.
1576 The Configuration primitives enable access to configuration information specific to the DL Layer. This
information is represented as a DL Layer-specific Management Information Base (DL_MIB). The DL_MIB
is regarded as “contained” within the DL_LM entity. Multiple accesses to the DL_MIB via the Configuration
primitives shall not occur concurrently. The available Data Link Layer Attributes are defined in Section 6.8.
1577 The Control primitives provide direct control of the DL Layer. Control primitives are generated by the DME
and can occur concurrently.
1578 The Status primitives indicate status information of the DL Layer. Status primitives are generated by the DL
Layer and can occur concurrently.
1581 The parameters used for these primitives are defined in the next table.
READ_ONLY_MIB_ATTRIBUTE 3
NORMAL 0 Select whether the
actual value (NOR-
AttrSetType Enumeration MAL) or the reset
STATIC 1 value (STATIC) of
the Attribute is set
6.4.1.1 DL_LM_GET.req
1582 This primitive requests information about a given DL_MIB Attribute identified by MIBattribute.
1583 The semantics of this primitive are:
1584 DL_LM_GET.req( MIBattribute )
6.4.1.2 DL_LM_GET.cnf_L
1592 This primitive reports the results of an information request about the DL_MIB.
1593 The semantics of this primitive are:
1594 DL_LM_GET.cnf_L( ConfigResultCode, MIBvalue )
6.4.1.3 DL_LM_SET.req
1603 This primitive attempts to set the indicated DL_MIB Attribute indicated by MIBattribute to the MIBvalue
value.
6.4.1.4 DL_LM_SET.cnf_L
1613 This primitive reports the results of an attempt to set the value of an Attribute in the DL_MIB.
1614 The semantics of this primitive are:
1615 DL_LM_SET.cnf_L( ConfigResultCode )
1626 Table 48 lists the parameters that appear in the DL_LM_SAP control primitives.
6.4.2.1 DL_LM_RESET.req
1627 This primitive requests to reset the Data Link Layer.
1628 The semantics of this primitive are:
1629 DL_LM_RESET.req( ResetLevel )
1634 The ResetLevel COLD resets the complete DL Layer including the statistics. The ResetLevel WARM resets
the DL Layer without the statistics, if they exist.
6.4.2.2 DL_LM_RESET.cnf_L
1637 The DL_LM_RESET.cnf_L primitive is used during the UniPro reset procedure (see Section 9.11.1).
1638 The semantics of this primitive are:
1639 DL_LM_RESET.cnf_L( )
6.4.2.3 DL_LM_ENABLE_LAYER.req
1646 The DL_LM_ENABLE_LAYER.req primitive starts the L2 initialization protocol (see Section 6.7) as
required by the UniPro boot procedure.
1647 The semantics of this primitive are:
1648 DL_LM_ENABLE_LAYER.req( )
6.4.2.4 DL_LM_ENABLE_LAYER.cnf_L
1656 The DL_LM_ENABLE_LAYER.cnf_L primitive is used during the UniPro boot procedure (see
Section 9.11.2) to indicate to the DME that the DL is ready for the L2 initialization protocol.
1657 The semantics of this primitive are:
1658 DL_LM_ENABLE_LAYER.cnf_L( )
6.4.2.5 DL_LM_LINKSTARTUP.req
1665 This primitive attempts to establish a Link to the peer Device by starting the Data Link Layer Initialization.
See Section 6.7
1666 The semantics of this primitive are:
1667 DL_LM_LINKSTARTUP.req( )
6.4.2.6 DL_LM_LINKSTARTUP.cnf_L
1673 This primitive is used during the UniPro boot procedure (see Section 9.11.2) to indicate to the DME that the
Data Link Layer completed the Initialization and the Data Link Layer is ready to be used by the Network
Layer.
1674 The semantics of this primitive are:
1675 DL_LM_LINKSTARTUP.cnf_L( )
6.4.2.7 DL_LM_HIBERNATE_ENTER.req
1680 This primitive requests the Data Link Layer to go to Hibernate.
1681 The semantics of this primitive are:
1682 DL_LM_HIBERNATE_ENTER.req( )
6.4.2.8 DL_LM_HIBERNATE_ENTER.cnf_L
1700 This primitive is used to indicate that the Data Link Layer is about to hibernate.
1701 The semantics of this primitive are:
1702 DL_LM_HIBERNATE_ENTER.cnf_L( )
6.4.2.9 DL_LM_HIBERNATE_EXIT.req
1707 This primitive is used to request the Data Link Layer to stop hibernating and return to normal operation.
1708 The semantics of this primitive are:
1709 DL_LM_HIBERNATE_EXIT.req( )
6.4.2.10 DL_LM_HIBERNATE_EXIT.cnf_L
1714 This primitive is used to indicate to the DME that the Data Link Layer has returned to normal operation after
hibernating.
1715 The semantics of this primitive are:
1716 DL_LM_HIBERNATE_EXIT.cnf_L( )
1723 Table 50 lists the parameters that appear in the DL_LM_SAP status primitives.
6.4.3.1 DL_LM_ERROR.ind
1724 The Service Primitive indicates to the DME an error event in the Data Link Layer.
1725 The semantics of this primitive are:
1726 DL_LM_ERROR.ind( DLErrorCode )
6.4.3.2 DL_LM_CTRL_NOFRAME.ind
1754 The Service Primitive indicates to the DME that there are no Control Frames queued in the Data Link Layer
transmitter.
1755 The semantics of this primitive are:
1756 DL_LM_CTRL_NOFRAME.ind( )
6.4.3.3 DL_LM_TC1_NOFRAME.ind
1763 The Service Primitive indicates to the DME that there are no new or unacknowledged Data Frames in the
Data Link Layer transmitter for Traffic Class 1.
1764 The semantics of this primitive are:
1765 DL_LM_TC1_NOFRAME.ind( )
6.4.3.4 DL_LM_TC0_NOFRAME.ind
1772 The Service Primitive indicates to the DME that there are no new or unacknowledged Data Frames in the
Data Link Layer transmitter for Traffic Class 0.
1773 The semantics of this primitive are:
1774 DL_LM_TC0_NOFRAME.ind( )
6.4.3.5 DL_LM_CTRL_FRAME.ind
1781 The Service Primitive indicates to the DME that the DL Layer has to transmit a Control Frame (AFC0, AFC1
or NAC Frame).
1782 The semantics of this primitive are:
1783 DL_LM_CTRL_FRAME.ind( )
6.4.3.6 DL_LM_TC1_FRAME.ind
1790 The Service Primitive indicates to the DME that there is at least one new or unacknowledged Data Frame in
the Data Link Layer transmitter for Traffic Class 1.
1791 The semantics of this primitive are:
1792 DL_LM_TC1_FRAME.ind( )
6.4.3.7 DL_LM_TC0_FRAME.ind
1799 The Service Primitive indicates to the DME that there is at least one new or unacknowledged Data Frame in
the Data Link Layer transmitter for Traffic Class 0.
1800 The semantics of this primitive are:
1801 DL_LM_TC0_FRAME.ind( )
Data Frames
Control Frames
(TCx)
Acknowledgement Negative
Traffic Class 0 Traffic Class 1
and Flow Control Acknowledgement
Data Frames (TC0) Data Frames (TC1) Control (NAC) Frames
(AFCx) Frames
1813 The DL Layer shall support Data Frames of at least one Traffic Class. If both TCs are supported, the DL
Layer shall support Data Frames of two Traffic Classes with different priorities. These Frames always have a
Start of Frame (SOF) symbol, one or more data bytes, possibly a padding byte, an End of Frame (EOF_EVEN
or EOF_ODD) and an error protection symbol. The Frame length is flexible for each Traffic Class (see
Section 6.8), but the maximum Frame length is limited to DL_SYMBOL_MTU symbols (excluding SOF
symbol, EOF_EVEN or EOF_ODD symbol, COF and CRC symbols).
1814 Additionally, each Traffic Class possesses a separate AFC Frame and, for all Traffic Classes, a common NAC
Frame. These Control Frames are different from the Data Frames as they do not have SOF and EOF_EVEN
or EOF_ODD symbols. ESC_DL together with Control Symbol Type acts as start of a Frame for respective
Control Frame. Each Control Frame is of fixed length, which depends on its type. These Control Frames may
be transmitted during Data Frames, i.e. they can preempt Data Frames, depending on the priority rule (see
Section 6.6.4).
1815 Transmission gaps within Data Link Layer Frames resulting in the PHY inserting PHY Idle symbols while in
HS mode should be avoided.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 Data
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL Ctrl Symbol Type Parameter
1821 Note that data and control symbols can be translated to an encoding scheme suitable for the PHY by the PA
Layer. If the underlying PHY supports character coding the control symbol identifier (MS byte of a control
symbol) can be translated to a special PHY character. The number of such special PHY characters is limited,
and, therefore, Data Link Layer minimizes the number of control symbol identifiers.
1822 Table 51 shows the currently defined MS byte of control symbol. The undefined values are reserved for
future use. The DL Layer shall not use the reserved values. If received they shall be discarded.
1823 Table 52 shows all DL Layer control symbols with the corresponding Control Symbol Type and a short
description.
1824 The remaining values are reserved for future use. The transmitter shall not use reserved Control Symbol Type
values. A control symbol received with a reserved Control Symbol Type shall be dropped.
1825 Table 53 shows definition of the parameter fields of the DL Layer control symbols.
1826 The DL Layer transmitter shall set the reserved bits to one. The DL Layer receiver shall ignore the reserved
bits.
1827 The bit 4 and bit 3 are used for identification of Traffic Class for SOF, COF and AFC control symbols. The
usage is defined in Table 54.
1828 The DL Layer transmitter shall not use reserved Traffic Class values. A SOF, COF or AFC control symbol
received with a reserved TC value shall be dropped.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 DL_SDU – Byte 0 DL_SDU – Byte 1
0
. .
. .
. .
0
0 DL_SDU – Byte n-2 (n <= DL_MTU) DL_SDU – Byte n-1 (n <= DL_MTU)
1 ESC_DL EOF_EVEN Frame Seq. Number
0 CCITT CRC-16
1834 The padding is always placed in the least significant byte of the last data symbol before the EOF_ODD
symbol of a Data Frame. The transmitter shall set the padding byte to zero and at the receiver this padding
byte shall be discarded after it has been fed through the CRC checker. The padding byte shall not be passed to
the upper layer.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 DL_SDU – Byte 0 DL_SDU – Byte 1
0
. .
. .
. .
0
0 DL_SDU – Byte n-1 (n <= DL_MTU) Padding Byte = 0x00
1 ESC_DL EOF_ODD Frame Seq. Number
0 CCITT CRC-16
1835 Figure 52 shows a Data Link Layer Data Frame with an even number of DL_SDU bytes that is preempted by
a NAC Control Frame. The continuation of the preempted Frame is marked by the COF control symbol.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL SOF TC Reserved
0 DL_SDU – Byte 0 DL_SDU – Byte 1
0
. .
. .
. .
0
0 DL_SDU – Byte x-2 DL_SDU – Byte x-1
1 ESC_DL NAC Reserved RReq
0 CCITT CRC-16
1 ESC_DL COF TC Reserved
0 DL_SDU – Byte (x) DL_SDU – Byte (x+1)
0
. .
. .
. .
0
0 DL_SDU – Byte n-2 (n <= DL_MTU) DL_SDU – Byte n-1 (n <= DL_MTU)
1 ESC_DL EOF_EVEN Frame Seq. Number
0 CCITT CRC-16
16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1 0
1 ESC_DL AFC TC CReq Reserved
0 Frame Seq. Number Reserved Credit Value
0 CCITT CRC-16
1842 The AFC Frame is used to exchange credit information and acknowledgments with the remote end. The
CReq bit in the AFCx symbol is used for requesting flow control information for the corresponding Traffic
Class from the remote end. The rules for requesting AFC Frame transmission are defined in Section 6.6.10.
1843 The Frame Sequence Number is defined with 5-bits that allows acknowledgments either individually or in a
group (an acknowledgment to more than one Data Frame, but limited to sixteen, i.e. grouped
acknowledgment) by the receiver per Traffic Class. See Section 6.6.8.1
1844 The credit unit size in bytes is defined by DL_CreditUnitSize and the Credit Value field in AFC Frame is
defined by DL_CreditValSizeBits. See Table 60. Therefore, an AFC Frame can convey credit information for
a receiver buffer size up to maximum of 4 KB due to the required roll over functionality of the credit
accumulator. The flow control credit does represent the total number of credits available since boot time and
does not represent a relative number. During the Data Link Layer initialization phase the free space in buffer
is communicated via the AFC Frames. More details are listed in Section 6.7.
1845 The reserved bits shall be set to one when transmitting and shall be ignored at the receiver.
16 15 14 13 12 11 10 9 8 67 5 4 3 2 1 0
1 ESC_DL NAC Reserved RReq
0 CCITT CRC-16
1847 The reserved bits shall be set to ‘1’ when transmitting and shall be ignored at the receiver.
1850 The DL Layer sender adds a SOF control symbol as header for each upper layer PDU and an EOF_EVEN or
EOF_ODD control symbol and the CRC symbol as trailer. The composition is shown in Figure 55 for an even
DL_SDU length.
6.6.1.1 Preemption
1851 In order to reduce delays in the transmission of high priority Frames and to improve QoS in conjunction with
upper layers, the DL Layer can insert high priority Frames within a low-priority Data Frame if the latter one
is already in transmission. This functionality is known as preemption of a Frame. Support of preemption
functionality is optional for the transmitter, whereas the receiver shall always be able to receive preempted
and non-preempted Frames.
1852 DL_TxPreemptionCap defines if the transmit side of the Data Link Layer has preemption capability. If
TRUE, the transmit side shall support preemption. If FALSE, the transmit side shall not support any case of
preemption. Data Frames shall not be preempted by AFC Frames or NAC Frames; Data Frames of lower
priorities shall not be preempted by Data Frames of higher priorities.
1853 The transmission of a preempted Frame shall be continued with a COF symbol followed by a data symbol or
an EOF_EVEN or EOF_ODD symbol for that Traffic Class. Figure 56 shows the case, where preemption is
carried out in the middle of the low priority Data Frame for the quick transmission by the high-priority
Frame. Both Frames have even DL_SDU lengths.
Upper Layer PDU – TC X (Part 1) Upper Layer PDU – Traffic Class Y Upper Layer PDU – TC X (Part 2)
SOF DL_SDU – Traffic Class X (Part 1) SOF DL_SDU – Traffic Class Y EOF CRC COF DL_SDU – Traffic Class X (Part 2) EOF CRC
DL Layer Frame – Traffic Class X (Part 1) DL Layer Frame – Traffic Class Y DL Layer Frame – Traffic Class X (Part 2)
1854 When implemented, the preemption allows a faster delivery of the high-priority Frames and prevents the
Frames from being blocked by a low priority Frame. In contrast to that a system without preemption causes a
higher latency to the high-priority Frame. Section B.2 highlights the effects of preemption in more detail.
1855 The priority list for preemption is given in Section 6.6.4.
1856 The following rules shall be considered during preemption:
1857 • The preemption shall not occur:
1858 • between EOF_EVEN or EOF_ODD and CRC symbols
1859 • within AFC and NAC Frames (including the CRC symbol(s))
1860 • The preemption may happen at any symbol boundary except where the above rule is valid
1862 In case of preemption also COF control symbols are removed before passing the Frame to the Network Layer.
The correct and complete payload (without COF symbol) of a Frame is passed to the upper layer if the above
mentioned rules for correctness are fulfilled. Figure 58 shows the decomposition with preemption.
DL Layer Frame – Traffic Class X (Part 1) DL Layer Frame – Traffic Class Y DL Layer Frame – Traffic Class X (Part 2)
SOF DL_SDU – Traffic Class X (Part 1) SOF DL_SDU – Traffic Class Y EOF CRC COF DL_SDU – Traffic Class X (Part 2) EOF CRC
TC0 TC1
SOF
SOF PA_DL_PAUSE.ind is
received: no new frame is
TC1
sent
#0
The TC1 Frame is sent and
EOF the TC0 Frame resumes
CRC
COF
TC0
#0 PA_DL_PAUSE.rsp_L is
generated at the latest at this
EOF
CRC point
1871 Figure 59 exemplifies the behavior previously described in the case where the PA_DL_PAUSE.ind is
received when a TC1 Frame preempting a TC0 Frame is transmitted. No new Frames are transmitted and the
current TC1 Frame is transmitted to completion. The completion times of TC0 and TC1 are shown in the
figure. PA_DL_PAUSE.rsp_L can be transmitted any time between the start of the PA_DL_PAUSE.ind
primitive and completion of the TC0 Frame timer.
1872 The transmission of the currently preempted TC0 Frame is completed and finally this marks the latest point in
time where the PA_DL_PAUSE.rsp_L primitive is generated, if it was not already generated.
1873 If the Frozen state is entered during the transmission of a Frame, when exiting the Frozen state and resuming
normal operation that Frame shall be continued from the point of interruption.
1874 The PHY Adapter Layer indicates the operation has completed with a PA_DL_RESUME.ind primitive sent
to the Data Link Layer. Upon reception of the primitive PA_DL_RESUME.ind, the Data Link Layer shall
leave the Frozen state, shall resume normal operation and shall send any pending Frames according to the
arbitration scheme. The DL Layer shall re-enable Frame transmission, reset and restart all timers.
transmitting SOF, EOF_EVEN, EOF_ODD, COF and CRC symbols, and Control Frames. As the credit
values are updated during the original transmission of a Data Frame, they shall not be updated again during
retransmission of that Data Frame.
1882 The credit flow control scheme used in DL Layer requires that the DL transmitter shall keep track of the
space available in the remote RX logical buffer per Traffic Class (logical buffer to store Frames). The system
is based on registers that represent the total number of credits that have been available since boot up/reset.
This amount of credits is then compared to the total amount of credit used since power-up or reset to
determine if a Frame shall or shall not be transmitted. Note that the number of credits received is often
pessimistic. It is delayed in time and often does not reflect the actual amount of credit available at the
receiver, but a slightly older version of this number. This creates a conservative view of the space available.
This ‘error’ may actually impact system performance, as data may be held in the transmitter when space
exists in the receiver. However, it will always be robust, as this error only understates the space available and
never overstates it. Credits are self-healing. That is, if a credit Frame is dropped due to either CRC checksum
failure of AFC Frame or AFC Frame is not detected, it will be corrected by the transmission of a next/new
more up to date AFC Frame. This works because the credits represent the total number of credits since boot
time.
1883 During the boot procedure, each side exchanges, for each Traffic Class, AFC Frames with CReq set and a
Credit Value field equal to the size of their receiving logical buffer in credit units (see Section 6.7).
1884 Each node must maintain, for each TC, the following register values:
1885 • R; Stores the number of credits received
1886 • U; Stores the total number of credits used
1887 • S; Stores the total number of credits sent
1888 • A; Stores the total number of credits available
1889 • Part_U; Stores the number of partial credits of U
1890 • Part_A; Stores the number of partial credits of A
1891 The transmitter part of a node handles the registers R and U, whereas the receiver block of a node handles the
registers S and A. The initial values of R, U, and S are 0. A is initialized to the size of the receiving logical
buffer in credit units (DL_CreditUnitSize). If the logical buffer size is not an integer multiple of the credit
unit size then the available logical buffer space to be specified shall be rounded down to the nearest integer
multiple of credit unit size, e.g., if the logical buffer size is 1000 bytes, then A shall be set to 31. The size of
credit registers R, S, U and A shall be the same as the credit value size of an AFC Frame (see Figure 53),
which is 8-bits, whereas the granularity of their representation is one credit unit size. Note that the 8-bit R, U,
S, A registers actually contain the number of total credits received, used, sent or available, respectively,
modulo 256. Overflow of the 8-bit registers shall be ignored.
1892 When a node receives an error-free AFC Frame for a Traffic Class, the value received in credit value field of
the AFC Frame shall replace the value of R.
1893 When an L2 transmitter sends payload or padding bytes to the L1.5 layer, the node shall increment U by the
number of whole credit units sent, i.e. the integer quotient of the number of bytes sent divided by
DL_CreditUnitSize. The node shall internally track the number of partial credits sent, i.e. data sent to the
other end which is less than DL_CreditUnitSize bytes, in Part_U. One partial credit represents one byte.
Whenever the sum of partial credits sent in Part_U exceeds DL_CreditUnitSize bytes, U shall be incremented
by one and Part_U shall be decremented by DL_CreditUnitSize, i.e. the Part_U value is replaced by the
number of partial credits sent modulo DL_CreditUnitSize. The partial credit sum shall be less than one credit
unit size at any time.
1894 The payload bytes fetched by the upper layer from the DL Layer and the padding bytes discarded by the DL
Layer represent the logical buffer empty space created in the DL Layer receiver's logical buffer. The DL
Layer shall increment A by the integer quotient of the newly created logical buffer empty space in bytes
divided by DL_CreditUnitSize. The remainder of the division shall be accumulated in bytes as partial credits
in Part_A. Whenever the sum of partial credits in Part_A exceeds DL_CreditUnitSize bytes, A shall be
incremented by one and Part_A shall be decremented by DL_CreditUnitSize.
1895 The AFC sending node shall set the AFC credit value field with the contents of A when an AFC Frame is
sent. At the same time, the value of S shall be replaced by the value of A.
1896 At any time a node is allowed to send at most:
DL_CreditValSizeBits DL_CreditValSizeBits
1897 [((R + 2 – U ) mod 2 ) × DL_CreditUnitSize – Part_U ] bytes
1904 where,
1905 x represents the Traffic Class number, 0 or 1,
1906 A and S belong to the same Traffic Class as DL_AFCxCreditThreshold.
1907 If DL transmitter has a Data Frame to send and fewer credits than DL_TCxTXFCThreshold, it shall send an
AFCx Frame with CReq bit set after expiration of FCx_PROTECTION_TIMER to request the remote node
to send flow control information. The following formula is used to compare the number of credits available to
DL_TCxTXFCThreshold:
DL_CreditValSizeBits DL_CreditValSizeBits DL_CreditValSizeBits
1908 [((R + 2 – U ) mod 2 )×2 – Part_U ]
< DL_TCxTXFCThreshold × DL_CreditUnitSize
1909 The FCx_PROTECTION_TIMER is used for protecting against loss of credits due to the loss of the AFCx
Frame. The timeout value of FCx_PROTECTION_TIMER is denoted as DL_FCxProtectionTimeOutVal and
the calculation details are provided in Section 6.6.9.
1910 FCx_PROTECTION_TIMER shall be reset when at least one of the following conditions is valid:
1911 • With the expiration of FCx_PROTECTION_TIMER
1912 • With the reception of an error-free AFCx Frame
1913 FCx_PROTECTION_TIMER shall run when at least one of the following conditions is valid:
1914 • The TCx of the peer node is present (see Section 6.7), TX of a TCx has less credits than
DL_TCxTXFCThreshold and data to send
1915 • The Data Link Layer is in the initialization phase, and no AFCx Frame was received for TCx
1916 The FCx_PROTECTION_TIMER shall be stopped when all of the above run conditions are not satisfied or if
the DL Layer is waiting for PA_INIT.cnf_L as a result of a request for PHY (re-)initialization (PA_INIT.req).
1917 After sending an AFCx Frame with CReq bit set and the FCx_PROTECTION_TIMER expires without
receiving the AFCx Frame, then PA_INIT.req shall be triggered. After receiving PA_INIT.cnf_L, a NAC
Frame with the RReq bit set shall be transmitted before the transmission of an AFCx Frame with CReq bit set.
1918 Note:
1919 The priority of the AFCx Frame is raised when responding to an AFCx Frame with CReq bit set. See
Section 6.6.4.
1920 More details are given in Section 6.6.8.2. All AFC Frame transmission rules are explained in Section 6.6.10.
1921 Table 56 provides an example of the changes in the various credit-tracking registers after boot up. In the
example, the receiver’s initial credit value, e.g. for TC0 it is given by DL_TC0RxInitCreditVal, is assumed to
be sixteen and the DL_AFCxCreditThreshold is set to fifteen. Local node transmits AFC0 Frames to remote
node and remote node transmits Data Frames of TC0 to local node. Figure 60 illustrates the same example as
Table 56 using a Message Sequence Chart. Figure 61 depicts difference between R and U credits at remote
node TX. The graph shows the variation of (R – U) credits during data transmission and AFC Frame
reception.
of A of U of A of U
T0 Init 16 0 0 0 0 0 16 0 0 0 0 0
Local node sends an AFC Frame
T1 16 0 16 0 0 0 16 0 0 0 0 0
with a value of 16
MIPI Alliance Member Confidential
AFC
TC0
AFC
0#31
CV16 TC0
0#31 A=16 PA=0 S=16
CRC
CV16
CRC
R=16 U=0 PU=0
SOF
TC0
SOF
#0
256 TC0
R=16 U=8 PU=0 #0
EOF
CRC 256 Local upper layer reads 256
EOF bytes (8 credits) from buffer
CRC
SOF
A=24 PA=0 S=16
TC0
SOF
#1
218 TC0
R=16 U=14 PU=26 #1
EOF
CRC 218 Local upper layer reads 212 bytes
EOF (6 credits + 20 bytes) from buffer
CRC
SOF
A=30 PA=20 S=16
TC0
SOF
#2
32 TC0
R=16 U=15 PU=26 #2
EOF
CRC 32 Local upper layer reads 38 bytes
EOF (1 credit + 6 bytes) from buffer
CRC
A=31 PA=26 S=16
AFC
TC0
AFC
0#2
CV31 TC0
0#2 A=31 PA=26 S=31
CRC
CV31
CRC
R=31 U=15 PU=26
SOF
TC0
SOF
#3
6 TC0
R=31 U=16 PU=0 #3
EOF
CRC 6 Local upper layer reads 6 bytes
EOF from buffer
CRC
A=32 PA=0 S=31
Figure 60 Message Sequence Chart for Flow Control Register Changes after Boot Up
Example
14
12
10
Credits consumption
consumption during
Credits
data transmission
Variation of
8 during data
transmission credits
4
Reset state;
2 no credits
available
0
T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16
Time
1922 Padding byte, if it is used in a Data Frame at transmitter side, shall consume a partial credit (partial credits of
U).
1923 At the receiver the padding byte shall be discarded and available partial credits (partial credits of A)
incremented by one.
1924 During retransmission the credit used by register U shall not be incremented because the credits have already
been consumed during the original transmission.
depend on it to make any decision (to identify if it is a TC0 or TC1, Data Frame or a Control Frame). There is
a dedicated AFC Frame for each Traffic Class (AFC0 for TC0 and AFC1 for TC1).
1926 The following sections provide information on Frame Sequence Number and acknowledgment timeout
operation.
1939 • Local TX triggers retransmission due to timeout (last acknowledged Frame was TC0Frame#3)
1940 • Local TX triggers PA_INIT.req
1941 • After confirmation by PA_INIT.cnf_L Service Primitive the local TX starts transmission of a NAC
Frame with the RReq bit set and then sends an AFC Frame (current information on flow control and
acknowledgment status) for TC1.
1942 • As there are no outstanding TC1 Data Frames, the local TX do not send any TC1 Data Frames
1943 • Local TX sends AFC (current information on flow control and acknowledgment status) for TC0
1944 • Local TX starts replaying Frame from TC0Frame#4 to TC0Frame#7
1945 • During TC0Frame #4 replay, local RX receives AFC0#7 Frame
1946 • The local RX accepts flow control information but discards acknowledgment information from AFC0#7
Frame and continue with the replay (TC0Frame#4, TC0Frame#5, TC0Frame#6, and TC0Frame#7)
1947 If the TCx_REPLAY_TIMER expires for a given TCx Data Frame without receiving an acknowledgment,
i.e., the Frame is assumed not successfully transmitted, then the DL Layer shall trigger PA_INIT.req Service
Primitive. After the completion of PHY initialization (indicated by the PA_INIT.cnf_L Service Primitive) the
DL Layer shall transmit a NAC Frame with the RReq bit set, then an AFC Frame (current information on
flow control and acknowledgment status) for TC1, then all unacknowledged Data Frames, if any, of TC1,
then an AFC Frame (with current flow control and acknowledgment status) for TC0 and then all
unacknowledged Data Frames, if any, of TC0.
1948 If a NAC Frame is detected during the transmission of any Data Frame then the transmitter shall stop current
Data Frame transmission if the EOF_EVEN or EOF_ODD symbol was not sent yet. If the EOF_EVEN or
EOF_ODD symbol is sent this Frame shall not be stopped. If a NAC Frame is detected during the
transmission of any Control Frame then the transmitter shall not stop the Control Frame under transmission.
1949 The receiver of a NAC Frame shall perform the following sequence: The DL Layer may trigger PA_INIT.req
Service Primitive of the PHY Adapter Layer if the RReq bit in the NAC Frame is not set. The receiver shall
trigger PA_INIT.req of the PHY Adapter Layer if the RReq bit in the NAC Frame is set. If PA_INIT.req is
t r ig g e r e d, t he n th e T X s h a l l w a i t f o r PA_ I N I T.c n f _ L . I f PA _ I N I T.r e q is n ot t r i g ge r e d , a
PA _ L A N E _ A L I G N . r e q s h a l l b e t r i g g e r e d , a n d o n l y a f t e r t h e r e c e p t i o n o f t h e p r i m i t i v e
PA_LANE_ALIGN.cnf_L the procedure will continue. After that, AFC Frames and all unacknowledged
Data Frames, if any, for all TCs shall be transmitted according to the priority scheme. Retransmitted lower
priority Frames can be preempted by higher-priority non-replayed Frames.
1950 The retransmission of a Frame shall be detected in the receiver by comparing the received Frame Sequence
Number with the expected Frame Sequence Number. If the received Frame Sequence Number is not an
expected one, then it shall be compared with last sixteen Frame Sequence Numbers prior to the expected
Frame Sequence Number. If any one of that is matching to the correctly received Frame Sequence Number,
then the received Frame shall be identified as a retransmitted Frame and shall be discarded. In any case,
whether the Frame is identified as a retransmitted Frame or not, an acknowledgment shall be scheduled either
individually or in a group for each correctly received Data Frame.
1951 The replay timer (TCx_REPLAY_TIMER, where x = 0 or 1) guards against losing AFC or NAC Frame
detection. The Frame acknowledge timer (AFCx_REQUEST_TIMER) shall guarantee that the remote
transmitter schedules an AFC Frame before the transmitter TCx_REPLAY_TIMER expires. The
DL_TCxReplayTimeOutVal and the DL_AFCxReqTimeOutVal for a TC shall be programmed such that this
is the case. Examples of formulas to calculate timeout values are given in Section 6.6.9. An illustration of the
Frame acknowledge timer and replay timer for TC0 is given in Figure 62. Initially both timers are in a reset
state, they are stopped. The local TX sends TC0 Frame#0 to remote RX and starts TC0_REPLAY_TIMER.
The remote RX starts AFC0_REQUEST_TIMER after reception of TC0 Frame#0. After some time, the
remote TX sends AFC0#0 acknowledging TC0 Frame#0, resets and stops AFC0_REQUEST_TIMER. The
timer operations for TC1 are similar to TC0.
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
EOF
CRC
AFC
TC0 AFC
#0
TC0
CRC #0
CRC
TC0_REPLAY_TIMER AFC0_REQUEST_TIMER
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
Figure 62 Definition of Frame Acknowledgment Timer and Replay Timer for TC0
1952 TCx_REPLAY_TIMER shall be reset when at least one of the following conditions is valid:
1953 • with the transmission of the last symbol of a TCx Data Frame (CRC symbol)
1954 • with the reception of a correct AFCx Frame which acknowledges at least one unacknowledged Data
Frame
1955 • with the reception of a correct NAC Frame
1956 • with the expiration of TCx_REPLAY_TIMER
1957 TCx_REPLAY_TIMER shall run when all of the following conditions are valid:
1958 • there exists at least one unacknowledged transmitted TCx Data Frame
1959 • the DL Layer is not waiting for PA_INIT.cnf_L as a result of a request for PHY (re-)initialization
(PA_INIT.req)
1960 The TCx_REPLAY_TIMER should be stopped when any of the above TCx_REPLAY_TIMER run rules is
not satisfied.
1961 AFCx_REQUEST_TIMER shall be reset when at least one of the following conditions is valid:
1962 • with the reception of a correct TCx Data Frame
1963 • with the reception of a correct NAC Frame
1964 • with the transmission of an AFCx Frame
1965 • with the expiration of AFCx_REQUEST_TIMER
1966 This AFCx_REQUEST_TIMER shall run when the following condition is valid:
1967 • there are unacknowledged received TCx Data Frames and the DL Layer is not waiting for
PA_INIT.cnf_L as a result of a request for PHY (re-)initialization (PA_INIT.req)
1968 The AFCx_REQUEST_TIMER should be stopped when the above AFCx_REQUEST_TIMER run rules are
not satisfied.
1969 NOTE: With the expiration of the AFCx_REQUEST_TIMER the priority of the AFCx Frame is raised. See
Section 6.6.4.
1991 The MaxFrameTransferTime depends on the DL_SYMBOL_MTU, DL Layer overhead and the Link speed.
This value is computed from following expression:
DL_AFCxReqTimeOutVal ≥ ForwardLinkPhyProces
1999 sin g- + MaxFrameTransferTime
--------------------------------------------------------------------------
ForwardLinkDataRate
+ MaxFrameGap + ForwardLinkDLLProces sin g
2000 where,
2001 MaxFrameGap is the maximum gap in µs between two consecutive Data Frames measured
on the wire between the CRC of the first Data Frame and the SOF of the second, which is
used to capture limitations that some implementation might have and that impact the
timeout values,
2002 DL_AFCxReqTimeOutVal is the expiration value of the AFCx_REQUEST_TIMER as
defined in Table 59,
2003 ForwardLinkDLLProcessing is the total time taken by the DLL to process a symbol at both
TX and RX sides of the Link used to transfer the Frame.
2004 If preemption is supported at the transmitter side then:
2005 the DL_TCxReplayTimeOutVal is given by the following equation:
ReverseLinkPhyProces sin g
2006 DL_TCxReplayTimeOutVal ≥ DL_AFCxReqTimeOutVal + --------------------------------------------------------------------------
ReverseLinkDataRate
+ ReverseLinkDLLProces sin g + PhyWakeUpTime
2007 the DL_FCxProtectionTimeOutVal is given by the following equation:
+ (--------------------------------------------------------------------------------------------------------------------------------------------------------
DL_SYMBOL_MTU + DLLOverhead ) × DLLSymbolSize-
ReverseLinkDataRate
Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved.
MIPI Alliance Member Confidential
185
Version 1.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro
2014 where,
2015 DL_TCxReplayTimeOutVal is the expiration value of the TCx_REPLAY_TIMER,
2016 DL_FCxProtectionTimeOutVal is the expiration value of the
FCx_PROTECTION_TIMER as defined in Table 59,
2017 ReverseLinkDataRate is the bit rate of the incoming Link as seen from the local TX,
2018 ReverseLinkDLLProcessing is the total time taken to process a symbol at both TX and RX
sides of the incoming Link as seen from local TX,
2019 PhyWakeUpTime is the time required by the PHY Adapter to bring the Link into active
mode.
2020 The Table 57 is informative that illustrates calculation of timeout values for above said timers if preemption
is supported at transmitter side. Due to reset rules, the timeout values are same even for grouped
acknowledgment. Further, it is assumed that TX and RX are located at different nodes.
2021 The values for D-PHY are taken from [MIPI01]. The calculation example is based on a D-PHY with 8b9b
line coding and with EoT (End of High Speed Transmission) processing handled by the RX PHY. To simplify
the calculations, the maximum data rate is assumed to be 1 Gbps, which might deviate from the actual
specification.
2022 The values for M-PHY MODULEs are taken from [MIPI05]. In Table 58, the calculation example is based on
single Lane M-PHY Link with 8b10b line coding for the forward and reverse direction. Since the PHY Wake-
up time can be configured by value stored in some M-PHY Attributes, a given reference configuration was
used to compute the PHY Wake-up time for M-PHY MODULEs and is as follow:
2023 • HS_PREPARE_length=7, defined by the M-PHY Attribute TX_HS_PREPARE_LENGTH
2024 • LS_PREPARE_length=7, defined by the M-PHY Attribute TX_LS_PREPARE_LENGTH
2025 • SYNC_length=7, defined by a field of the M-PHY Attribute TX_HS_SYNC_LENGTH
2026 • SYNC_range=0, defined by a field of the M-PHY Attribute TX_HS_SYNC_LENGTH
2027 The parameters PhyTxPipelineFlush, PhyRxPipelineFlush, PhyAdapterLatency, PhyWakeUpTime,
ForwardLinkDLLProcessing and ReverseLinkDLLProcessing (for TX and RX) are physical layer
implementation-specific.
2035 • When the difference between the available credits (the A credit accumulator) and the sent credits (the S
credit register) exceeds the DL_AFCxCreditThreshold threshold:
DL_CreditValSizeBits DL_CreditValSizeBits
2036 [(2 + A – S ) mod 2 ] > DL_AFCxCreditThreshold
2062 A NAC Frame with the RReq bit set shall be transmitted when at least one of the following conditions occurs:
2063 • The FCx_PROTECTION_TIMER expires while waiting to receive an AFCx Frame in response to a
previously sent AFCx Frame with CReq bit set.
2064 • The TCx_REPLAY_TIMER expires.
2065 In this context, an incorrect Frame Sequence Number in a received Data Frame for any TC means a Sequence
Number that appears to be from a future frame. If the expected Frame Sequence Number is ExpSeq and the
received Frame Sequence Number is RcvSeq, RcvSeq is incorrect if the following equation is satisfied:
2067 A Data Frame is considered preempted when at least one Frame has preempted it and no COF symbol for the
same Traffic Class has been received yet to resume that Frame. Examples of symbol sequences when this
NAC generation condition holds are (SOF symbol with TC=0, DATA, SOF symbol with TC=0), when no
preemption has occurred for the started Frame, or (SOF symbol with TC=0, DATA, AFC symbol, DATA,
DATA, COF symbol with TC=0, DATA, SOF symbol with TC=0), when an earlier preemption has completed
and the ongoing TC0 Data Frame is no longer preempted.
2068 A SOF symbol during an ongoing Frame of the same TC is permitted when a replay starts, but only when the
Frame is preempted, as a replay always generates an AFC Frame before any replayed Data Frame. For
example, the symbol sequence (SOF symbol with TC=0, DATA, AFC symbol, DATA, DATA, SOF symbol
with TC=0) is valid and does not generate a NAC Frame, since the second SOF symbol with TC=0 represents
the beginning of a replayed Data Frame.
CRC Coverage
2072 To calculate the CRC-16 at the transmitter, the CRC-16 value shall be initialized to 0b1111 1111 1111 1111
(D[15], D[14],… D[1], D[0]). In addition, the first bit of the CRC-16 calculation shall be the most significant
bit (bit 16) of the DL symbol. Finally, the calculation bit sequence shall be complemented to obtain the CRC-
16 checksum.
2073 A DL Layer data symbol (bit 16 = 0) shall carry the 16-bit CRC value with X15 through X0 of the CRC-16
value corresponding to bit 15 through bit 0 of the symbol, as shown in Figure 64.
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
15 8 7
0 X ... X X ... X0
2074 At the receiver, the initial value of the CRC-16 calculation shall be 0b1111 1111 1111 1111 (D[15], D[14],…
D[1], D[0]). If a Frame payload (including DL Layer control symbols and DL Layer data symbols) are sent to
the CRC-16 calculator at the receiver, it shall result, in the absence of transmission errors, in the same
checksum that has been received.
2075 An example illustration of CRC calculation is given in Section B.3.
received AFCx Frame, DL_PeerTCxPresent shall be set to TRUE. All other values of flow control credits
received during the initial AFC exchange are not supported and results in a undefined behavior.
2088 When one AFCx Frame is received for each Traffic Class, the initial credit exchange and thus DL Layer
initialization are considered complete and L2 shall be reported to the DME as operational by sending the
DL_LM_LINKSTARTUP.cnf_L primitive.
2089 The number of credits received in the first AFC Frame for TCx shall be stored in
DL_PeerTCxRxInitCreditVal. This value minus one shall define the upper bound of the valid value of
DL_TCxTXFCThreshold as shown in Table 59.
2090 Note that starting with this specification, a UniPro implementation supporting only one Traffic Class shall
implement TC0. But since, UniPro v1.10.00 allowed an implementation to support only TC1, the detection of
presence of the TCs of a peer Device is kept unchanged.
2091 Figure 65 illustrates the initial credit exchange procedure for TC0 and TC1 for the case of a receiver logical
b u ff e r s i z e o f s i x t e e n c r e d i t s a n d a v a l u e o f n i n e i n b o t h D L _ T C 0 T X F C T h r e s h o l d a n d
DL_TC1TXFCThreshold.
NAC
RReq
CRC
AFC
CReq Sending an AFC1 with the Sending an AFC1 with the
TC1 CReq bit set starts the CReq bit set starts the
#31
CRC FC1_PROTECTION_TIMER FC1_PROTECTION_TIMER
AFC AFC
CReq Sending an AFC0 with the CReq
TC0 CReq bit set starts the Remote end TC1 AFC
#31 #31 CReq
FC0_PROTECTION_TIMER not ready to
CRC CRC TC1
receive data AFC #31
CReq CRC
TC0 AFC
#31 CReq
CRC TC0 Receiving credits >=
#31 DL_TC1TXFCThreshold
CRC stops the timer.
AFC Sending an AFC0 with the
CReq bit set starts the Receiving credits >=
TC1 Receiving credits >= DL_TC0TXFCThreshold
After receiving an AFC1 AFC FC0_PROTECTION_TIMER
#31 DL_TC1TXFCThreshold stops the timer.
with the CReq bit set, a
TC1 stops the timer. L2 initialization complete.
normal AFC1 is sent CRC #31
AFC
CRC
After receiving an AFC0 TC0
#31 AFC
with the CReq bit set, a
TC0
normal AFC0 is sent CRC #31
SOF
CRC
TC0
#0 SOF
TC0 Receiving credits >=
EOF #0
CRC DL_TC0TXFCThreshold
EOF stops the timer.
CRC L2 initialization complete.
Local Remote
FC0_PROTECTION_TIMER FC0_PROTECTION_TIMER
FC1_PROTECTION_TIMER FC1_PROTECTION_TIMER
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
hibernate.
Number of outstanding
acknowledgments for TC0
(number of TC0 Data Frames
DL_TC0OutAckThreshold 0x2045 received before an AFC0 Integer Frame 0 to 15 0 to 15 0
MIPI Alliance Member Confidential
Frame is sent).
This Attribute is retained during
hibernate.
TC1 Parameters
195
DL_CreditValSizeBits Number of bits used to represent Credit Value field in an AFC Frame Integer Bit 8
DL_CreditUnitSize Size of one credit unit Integer Byte 32
MIPI Alliance Member Confidential
TRUE = 1,
DL_PeerTC1Present 0x2066 Peer Device supports TC1 Bool
FALSE = 0
Peer TC1 Receiver Initial Credit Value (initial register
DL_PeerTC1RxInitCreditVal1 0x2067 Integer DL_CreditUnitSize 0, 10 to 128
A value)
MIPI Alliance Member Confidential
Device
Management N_TC0 N_TC1
Entity SAP SAP
(DME) Management Plane Data Plane
SAP
N_TRAP1
N_LM
SAP
SAP
N_MIB
N_TRAP0
Network Layer (L3)
2108 In general a Network address, defined as DeviceID, identifies one Network Layer SAP group (N_TCx_SAP)
(refer to Figure 67). By means of the used entity, namely TC0 or TC1, and addressed by the Network Service
User, e.g. Transport Layer – L4, the DeviceID identifies uniquely any individual Network Layer SAP, i.e.
N_TC0_SAP or N_TC1_SAP. The uniqueness of DeviceIDs within a UniPro Network shall be ensured.
2109 The DeviceID, uniquely identifying a specific Device, is a 7-bit value, ranging from 0 to N_MaxDeviceID
(see Table 80), which is the highest possible DeviceID supported in the current version of UniPro.
Device 1 Device 2
TC0 Entity TC1 Entity Service Provider TC0 Entity TC1 Entity
N_TC0 N_TC1
SAP SAP
Network Layer (L3)
DL_TC0 DL_TC1
SAP SAP
2119 In order to support the given characteristics and to keep them independent, the Network Layer model consists
of two identical TCx entities.
2120 Note, although there are two separate entities TC0 and TC1 drawn, this does not imply any implementation
choice.
7.6 N_TCx_SAP
2123 The N_TCx_SAP provides the services for basic data transmission.
2124 At the sending side, data is passed via the N_TCx_SAP in N_SDUs to the Network Layer to transfer it to the
peer Network Layer. At the recipient side, the Network Layer delivers received data in N_SDUs to the upper
layer. The Traffic Class identification is done based on the used SAP.
2125 The N_TCx_SAP shall support the transmission of user-supplied data between users, which shall not be
modified and shall not be re-ordered by the provider. The user may transmit any integral number of bytes
greater than zero up to the N_MTU.
2127 Table 63 lists the parameters that appear in the N_TCx_SAP primitives.
7.6.1.1 N_DATA_SHDR.req
2128 This primitive requests the transfer of user payload to a peer Network Layer by means of a DT SH N_PDU
(Refer to Section 7.8.1.1), i.e. no source DeviceID or other L3-specific information will be transferred.
2129 The provided DestPeerDeviceID shall identify the recipient of the payload. The DeviceIDOffset parameter
shall be in the range [0, N_MaxDeviceIDOffset], which is derived from Transport Layer protocol constants,
and is defined in Table 80.
2130 The user may transmit any integral number of bytes that shall be greater than zero up to the
N_TCxTxMaxSDUSize. The value of N_TCxTxMaxSDUSize depends on the value of
DL_TCxTxMaxSDUSize and the value of N_MaxHdrSize.
2131 The semantics of this primitive are:
2132 N_DATA_SHDR.req( DestPeerDeviceID, DeviceIDOffset, Payload )
7.6.1.2 N_DATA_SHDR.cnf_L
2139 This primitive informs the Service User that the Service Provider, so L3 in this case, is ready to accept a new
N_DATA_SHDR.req primitive.
2140 The semantics of this primitive are:
2141 N_DATA_SHDR.cnf_L( L3ResultCode )
7.6.1.3 N_DATA_SHDR.ind
2152 This primitive shall report the reception of user payload, carried by a DT SH N_PDU; no sender is identified.
The DeviceIDOffset shall be provided to the Service User for Transport Layer decoding purposes (see
Section 8.11.2). The payload may consist of any integral number of bytes greater than zero up to the N_MTU.
2153 The semantics of this primitive are:
2154 N_DATA_SHDR.ind( DeviceIDOffset, Payload )
7.6.1.4 N_DATA_SHDR.rsp_L
2161 This primitive informs the Network Layer that the Transport Layer is ready to accept a new
N_DATA_SHDR.ind primitive.
2162 The semantics of this primitive are:
2163 N_DATA_SHDR.rsp_L( )
7.6.1.5 N_DATA_LHDR_TRAP.req
2171 The N_DATA_LHDR_TRAP.req primitive is used to provide a Long Header Packet for transmission to the
Data Link Layer.
7.6.1.6 N_DATA_LHDR_TRAP.cnf_L
2180 This primitive informs the Network Layer extension that Network Layer is ready to accept a new
N_DATA_LHDR_TRAP.req primitive.
2181 The semantics of this primitive are:
2182 N_DATA_LHDR_TRAP.cnf_L( L3ResultCode )
7.6.1.7 N_DATA_LHDR_TRAP.ind
2191 This N_DATA_LHDR_TRAP.ind primitive reports the reception of user-data to the Network Layer
extension.
7.6.1.8 N_DATA_LHDR_TRAP.rsp_L
2201 The N_DATA_LHDR_TRAP.rsp_L primitive indicates that the Network Layer extension is ready to accept a
new N_DATA_LHDR_TRAP.ind primitive.
2202 The semantics of this primitive are:
2203 N_DATA_LHDR_TRAP.rsp_L( )
7.7 N_LM_SAP
2210 The Network Layer Management (N_LM_SAP) offers three groups of Service Primitives: Configuration
primitives, Control primitives and Status primitives. The primitives on the N_LM_SAP are used by the
Device Management Entity (DME) to configure and control the layer and receive layer status information.
2211 The Configuration primitives enable access to Network Layer Attributes. This information is represented as a
Network Layer-specific Management Information Base (N_MIB). The N_MIB is regarded as “contained”
within the N_LM entity. Multiple accesses to the N_MIB via the Configuration primitives shall not occur
concurrently. The available Network Layer Attributes are defined in Section 7.14.
2212 The Control primitives provide direct control of the Network Layer. Control primitives are generated by the
DME and can occur concurrently.
2213 The Status primitives indicate status information of the Network Layer. Status primitives are generated by the
Network Layer and can occur concurrently.
2216 The parameters used for these primitives are defined in the next table.
7.7.1.1 N_LM_GET.req
2217 This primitive requests the value of the Attribute identified by MIBattribute.
2218 The semantics of this primitive are:
2219 N_LM_GET.req( MIBattribute )
7.7.1.2 N_LM_GET.cnf_L
2226 This primitive indicates the success or failure of N_LM_GET.req, and, is successful, returns the Attribute
value.
2227 The semantics of this primitive are:
2228 N_LM_GET.cnf_L( ConfigResultCode, MIBvalue )
7.7.1.3 N_LM_SET.req
2237 This primitive attempts to set the value (SetType = NORMAL) or the reset value (SetType = STATIC) of the
Attribute indicated by MIBattribute to the MIBvalue.
2238 The semantics of this primitive are:
2239 N_LM_SET.req( SetType, MIBattribute, MIBvalue )
7.7.1.4 N_LM_SET.cnf_L
2248 This primitive reports the results of an attempt to set the value of an Attribute or its reset value.
2249 The semantics of this primitive are:
2250 N_LM_SET.cnf_L( ConfigResultCode )
2261 Table 69 lists the parameters that appear in the N_LM_SAP control primitives.
7.7.2.1 N_LM_RESET.req
2262 This primitive requests reset of the Network Layer.
2263 The semantics of this primitive are:
2264 N_LM_RESET.req( ResetLevel )
7.7.2.2 N_LM_RESET.cnf_L
2272 The N_LM_RESET.cnf_L primitive is used during the UniPro reset procedure (see Section 9.11.1).
2273 The semantics of this primitive are:
2274 N_LM_RESET.cnf_L( )
7.7.2.3 N_LM_ENABLE_LAYER.req
2281 The N_LM_ENABLE_LAYER.req primitive is used during the UniPro boot procedure (see Section 9.11.2).
2282 The semantics of this primitive are:
2283 N_LM_ENABLE_LAYER.req( )
7.7.2.4 N_LM_ENABLE_LAYER.cnf_L
2290 The N_LM_ENABLE_LAYER.cnf_L primitive is used during the UniPro boot procedure (see
Section 9.11.2) to indicate to the DME that the Network Layer is enabled.
2291 The semantics of this primitive are:
2292 N_LM_ENABLE_LAYER.cnf_L( )
7.7.2.5 N_LM_HIBERNATE_ENTER.req
2299 The N_LM_HIBERNATE_ENTER.req primitive requests the Network Layer enter hibernation.
2300 The semantics of this primitive are:
2301 N_LM_HIBERNATE_ENTER.req( )
7.7.2.6 N_LM_HIBERNATE_ENTER.cnf_L
2308 The N_LM_HIBERNATE_ENTER.cnf_L primitive is used to indicate that the Network Layer is about to
hibernate.
2309 The semantics of this primitive are:
2310 N_LM_HIBERNATE_ENTER.cnf_L( )
7.7.2.7 N_LM_HIBERNATE_EXIT.req
2317 The N_LM_HIBERNATE_EXIT.req primitive is used to request the Network Layer to exit hibernation and
return to normal operation.
2318 The semantics of this primitive are:
2319 N_LM_HIBERNATE_EXIT.req( )
7.7.2.8 N_LM_HIBERNATE_EXIT.cnf_L
2326 The N_LM_HIBERNATE_EXIT.cnf_L primitive is used to indicate to the DME that the Network Layer has
exited hibernation and is operating normally.
2327 The semantics of this primitive are:
2328 N_LM_HIBERNATE_EXIT.cnf_L( )
2337 Table 71 lists the parameters that appear in the N_LM_SAP status primitives.
7.7.3.1 N_LM_DISCARD.ind
2338 This primitive indicates that the discard N_PDU feature has been performed (refer to Section 7.9.4) and
reports the reason for triggering the operation.
2339 The semantics of this primitive are:
2340 N_LM_DISCARD.ind( L3DiscardReasonCode )
2341 When the N_LM_DISCARD.ind is generated the provided L3DiscardReasonCode shall be set according to
the cases described in Section 7.9.4.
7.8.1.1 DT SH N_PDU
2351 If the L3s bit is set to ‘1’, the N_PDU is known as DT SH N_PDU, or a Data N_PDU with a short L3 Header.
The DT SH N_PDU is used to transfer Network Service User-data (N_SDU) to a peer Network Layer.
7 6 5 4 3 2 1 0
L3s=1 DestDeviceID_Enc
Payload – Byte 0
.
.
.
Figure 70 Network Layer Data N_PDU with Short Header (DT SH N_PDU)
2352 The natural DT SH N_PDU granularity is bytes, i.e. any integral number of data bytes, i.e. N_SDU, in the
range from 1 to N_MTU can be transferred.
2358 Any integral number in the range from 0 to N_MaxDeviceID shall be supported.
2359 Table 75 shows the supported settings.
Composition Process
Decomposition Process
2365 The user-data is obtained from the N_SDU field. The user-data and parts of the PCI shall be provided to the
Network Service User by means of the appropriate Service Primitive indications.
2366 For the construction of the PCI, the Header Format Analysis feature is used.
2367 The state diagram describing the behavior of the N_PDU Decomposition Feature is shown in the L3_TC_rx
SDL process of [MIPI02].
2372 If N_DeviceID_valid is set to FALSE, the DeviceIDOffset parameter shall be set to ‘0’.
2373 The resulting value of DeviceIDOffset shall be provided to the Transport Layer via the N_DATA_SHDR.ind
primitive.
2391 The state diagram describing these behaviors is shown in the L3_TC_rx SDL process of [MIPI02].
N_DeviceID 0x3000 Section 7.9.3 and Section 7.9.4 for Integer 0 to N_MaxDeviceID 0
more details).
This Attribute is retained during
hibernation..
MIPI Alliance Member Confidential
more details).
This Attribute is retained during
hibernation..
T_CO T_CO
SAP a SAP b
Management Plane Data Plane
Device
Management
T_LM
SAP
T_CO T_CO T_CO T_CO T_CO T_CO T_CO T_CO T_CO T_CO
SAP[0] SAP[1] SAP[3] SAP[9] SAP[5] SAP[10] SAP[11] SAP[13] SAP[25] SAP[31]
T_Core Entity
2421 A Transport address identifies one Transport Layer Connection-oriented SAP (T_CO_SAP[x]) by means of a
unique address (refer to Figure 74) which is referred to as CPortID. The CPortID number (‘x’ in the SAP
notation) shall range from 0 to T_MaxCPortID (defined in Table 108).
2422 Note:
2423 CPortID values above 31 should only be used if necessary. This is because each destina-
tion Device’s use of CPortID values above 31 will reduce the number of Network Layer
Device addresses: if the highest CPortID value is greater or equal to 32 and less than x*32-
1 (with x = 1 to 64), the number of available Network Layer Device addresses is reduced
by x-1. For example, if a Device uses CPortID values up to 100 (implying x = 4), this will
reduce the maximum number of addressable Devices by three units. The corresponding
address translation process is described in Section 8.11.2.
Device 1 Device 2
interactions between Connections due to congestion caused by shared L2 resources, also known as Head of
Line blocking (HOL). The E2E FC can also prevent certain types of deadlock situations.
8.8 T_CO_SAP
2444 The T_CO_SAPs provide the services for basic data transmission.
2445 The data transfer Service Primitives shall be used to transfer user-data called Transport Service Data Units
(T_SDUs) or Messages, in either direction or in both directions simultaneously on a Connection. The
Transport Service shall preserve the content, the order and the boundaries of the T_SDUs passed through the
T_CO_SAP. The T_CO_SAP offers primitives to transfer Message Fragments. There is no guarantee that the
received Message Fragment boundaries are the same as the transmitted Message Fragment boundaries. The
user may transmit a zero size Message. The user shall not transmit a zero size Message Fragment if the EOM
is set to FALSE. The user may transmit a zero size Message Fragment if the EOM is set to TRUE. Note that
internally, the Transport Layer may transmit a T_PDU with zero length payload to transmit a FCT token or an
EOM. A receiver shall be able to correctly process zero length payload Segments.
2446 Even though the T_CO_SAP allows the transfer of Message Fragments, a CPort User may still communicate
using full messages by providing the whole Message to the T_CO_DATA.req and setting the EOM to TRUE.
2447 Data transmission is supported by flow-control services governing the exchange of Segments either locally or
in an end-to-end manner.
2448 Prior to any data-transmission between two users, a Connection needs to be opened as described in
Section 8.11.1.
2449 T_CO_SAP primitives shall not be called when the UniPro stack is in Hibernate. While the UniPro stack is in
Hibernate, T_CO_SAP primitives have undefined behavior.
2451 Note:
2452 The identifier “CO” in the primitives describes the Connection-oriented service type.
2453 Table 83 lists the parameters that appear in the T_CO_SAP primitives.
8.8.1.1 T_CO_DATA.req
2454 This primitive requests the transfer of a Message Fragment to a peer CPort via the associated Connection.
2455 The semantics of this primitive are:
2456 T_CO_DATA.req( MessageFragment, EOM)
8.8.1.2 T_CO_DATA.cnf_L
2463 This primitive reports the result of a Message Fragment transfer attempt to a specified recipient.
2464 The semantics of this primitive are:
2465 T_CO_DATA.cnf_L( L4CPortResultCode )
2469 If the peer Device does not implement the TCx Traffic Class, the value of the L4CPortResultCode shall be
NO_PEER_TC. The Transport Layer learns about the peer Device not implementing the TCx Traffic Class
when it receives N_DATA_SHDR.cnf_L or N_DATA_LHDR_TRAP.cnf_L with L3ResultCode set to
NO_PEER_TC.
8.8.1.3 T_CO_DATA.ind
2475 This primitive reports the reception of a complete or incomplete Message Fragment. No sender is identified
by the indication; instead this has to be determined by the associated Connection.
2476 The semantics of this primitive are:
2477 T_CO_DATA.ind( MessageFragment, EOM, SOM, FragmentStatus )
8.8.1.4 T_CO_DATA.rsp_L
2488 This primitive informs the CPort that the CPort User is ready to accept a new T_CO_DATA.ind primitive.
2489 The semantics of this primitive are:
2490 T_CO_DATA.rsp_L( )
8.8.1.5 T_CO_FLOWCONTROL.req
2497 This primitive is the service request primitive for the Connection flow control service. Refer to
Section 8.11.8.
2498 The semantics of this primitive are:
2499 T_CO_FLOWCONTROL.req( Credits )
2504 In case the end-to-end flow control feature is enabled for the particular Connection, i.e.
T_CPortFlags.E2EFC equals ‘1’, the T_CO_FLOWCONTROL.req primitive shall also transfer Flow
Control Tokens (FCTs) to the peer CPort using the associated Connection by means of a DT T_PDU (see
Section 8.10.1).
2505 One FCT corresponds to a specific number of Credits in bytes, which is defined per Connection and per
direction (T_TxTokenValue, T_RxTokenValue; see Table 107). T_TxTokenValue is used for calculating the
amount of FCTs to be sent to the connected peer CPort. T_RxTokenValue is used to calculate the equivalent
value of the received FCT in bytes to increment the T_PeerBufferSpace counter for the transmitting peer
CPort.
2506 Since the primitive can accept more Credits than one Token is worth, while only one FCT can be signaled to
the peer CPort at a time, the number of outstanding Credits to be sent (T_CreditsToSend, see Table 107) shall
be tracked. When E2E FC is enabled, the T_CreditsToSend counter shall be incremented by the value in the
parameter Credits, limited to the maximum number of E2E FC Credits (T_MaxE2EFCCredits, see
Table 108), and shall be decremented by T_TxTokenValue each time a FCT is sent.
2507 The request is locally completed with a T_CO_FLOWCONTROL.cnf_L primitive. This does not necessarily
mean that the transmission of FCT(s) to a peer CPort was successfully completed.
8.8.1.6 T_CO_FLOWCONTROL.cnf_L
2512 This primitive is the service confirm primitive for the Connection flow control service.
2513 The semantics of this primitive are:
2514 T_CO_FLOWCONTROL.cnf_L( CreditsAccepted, L4CPortResultCode )
8.9 T_LM_SAP
2522 The Transport Layer Management (T_LM) SAP offers three groups of Service Primitives: Configuration
primitives, Control primitives and Status primitives. The primitives on the T_LM_SAP are used by the
Device Management Entity (DME) to configure and control the layer and receive layer status information.
2523 The Configuration primitives enable access to the Transport Layer Attributes defined in Section 8.17.
2524 The Control primitives provide direct control of the Transport Layer. Control primitives are generated by the
DME and can occur concurrently.
2525 The Status primitives indicate status information of the Transport Layer. Status primitives are generated by
the Transport Layer and can occur concurrently.
2528 The parameters used for these primitives are defined in Table 85.
8.9.1.1 T_LM_GET.req
2529 This primitive requests the value of the Attribute identified by MIBattribute and, if relevant, the
SelectorIndex. The SelectorIndex shall be interpreted either as a CPort index or a Test Feature index based on
the Attribute ID. For Attributes not associated with the SelectorIndex, the SelectorIndex shall be ignored.
2530 The semantics of this primitive are:
2531 T_LM_GET.req( MIBattribute, SelectorIndex )
8.9.1.2 T_LM_GET.cnf_L
2539 This primitive indicates the success or failure of T_LM_GET.req, and, is successful, returns the Attribute
value.
8.9.1.3 T_LM_SET.req
2550 This primitive attempts to set the value (SetType = NORMAL) or the reset value (SetType = STATIC) of the
Attribute indicated by MIBattribute to the MIBvalue and, if relevant, the SelectorIndex. The SelectorIndex
shall be interpreted either as a CPort index or a Test Feature index based on the Attribute ID. For Attributes
not associated with the SelectorIndex, the SelectorIndex shall be ignored.
2551 The semantics of this primitive are:
2552 T_LM_SET.req( SetType, MIBattribute, MIBvalue, SelectorIndex )
8.9.1.4 T_LM_SET.cnf_L
2561 This primitive reports the results of an attempt to set the value of an Attribute or its reset value.
2562 The semantics of this primitive are:
2563 T_LM_SET.cnf_L( ConfigResultCode )
2574 Table 89 lists the parameters that appear in the T_LM_SAP control primitives.
8.9.2.1 T_LM_RESET.req
2575 This primitive requests the reset of the Transport Layer.
2576 The semantics of this primitive are:
2577 T_LM_RESET.req( ResetLevel )
8.9.2.2 T_LM_RESET.cnf_L
2585 The T_LM_RESET.cnf_L primitive is used during the UniPro reset procedure (see Section 9.11.1).
2586 The semantics of this primitive are:
2587 T_LM_RESET.cnf_L( )
8.9.2.3 T_LM_ENABLE_LAYER.req
2594 The T_LM_ENABLE_LAYER.req primitive is used during the UniPro boot procedure (see Section 9.11.2).
2595 The semantics of this primitive are:
2596 T_LM_ENABLE_LAYER.req( )
8.9.2.4 T_LM_ENABLE_LAYER.cnf_L
2603 The T_LM_ENABLE_LAYER.cnf_L primitive is used during the UniPro boot procedure (see
Section 9.11.2) to indicate to the DME that the Transport Layer is enabled.
2604 The semantics of this primitive are:
2605 T_LM_ENABLE_LAYER.cnf_L( )
8.9.2.5 T_LM_HIBERNATE_ENTER.req
2612 The T_LM_HIBERNATE_ENTER.req primitive is used to request the Transport Layer to enter hibernation.
2613 The semantics of this primitive are:
2614 T_LM_HIBERNATE_ENTER.req( )
8.9.2.6 T_LM_HIBERNATE_ENTER.cnf_L
2621 The T_LM_HIBERNATE_ENTER.cnf_L primitive is used to indicate to the DME that the Transport Layer
is about to hibernate.
2622 The semantics of this primitive are:
2623 T_LM_HIBERNATE_ENTER.cnf_L( )
8.9.2.7 T_LM_HIBERNATE_EXIT.req
2630 The T_LM_HIBERNATE_EXIT.req primitive is used to request the Transport Layer to exit hibernation and
return to normal operation.
2631 The semantics of this primitive are:
2632 T_LM_HIBERNATE_EXIT.req( )
8.9.2.8 T_LM_HIBERNATE_EXIT.cnf_L
2639 The T_LM_HIBERNATE_EXIT.cnf_L primitive is used to indicate to the DME that the Transport Layer has
exited hibernation and is operating normally.
2650 Table 91 lists the parameters that appear in the T_LM_SAP status primitives.
8.9.3.1 T_LM_DISCARD.ind
2651 This primitive indicates that the Discard T_PDU feature has been performed (refer to Section 8.11.11) and
reports the reason for triggering the operation.
2654 When the T_LM_DISCARD.ind is generated the provided L4DiscardReasonCode shall be set accordingly
the cases summarized in Table 92 and described in Section 8.11.11 in more detail.
8.10.1.1 DT SH T_PDU
2664 The current version of UniPro only defines a DT T_PDU with a short header, referred to as DT SH T_PDU
and identified by the L4s bit set to ‘1’. The DT SH T_PDU is used to transfer User data between peer CPorts.
DT SH T_PDUs are sent using the N_DATA_SHDR.req primitive.
7 6 5 4 3 2 1 0
L4s=1 DestCPortID_Enc FCT EOM
Payload – Byte 0
.
.
.
2665 The natural T_PDU granularity is bytes, i.e. any integral number of data bytes in the range from 0 to T_MTU
can be transferred.
8.10.2.2 DestCPortID_Enc
2669 The DestCPortID_Enc field shall contain the five least significant bits of the CPortID of the targeted CPort.
The destination CPort value is a fixed property of a Connection and all T_PDUs sent within a Connection
shall have the same value for DestCPortID_Enc.
2670 In various cases a 5-bit CPortID may be enough. If a Device supports more than thirty-two CPorts, only the
least significant bits of the destination CPortID shall be encoded into the DestCPortID_Enc header field
according to the definitions in Section 8.11.2.
2671 Table 96 shows the supported settings.
2673 This bit is set to one (‘1’) by the sending CPort in case the end-to-end control feature is enabled and the CPort
has to signal a Flow Control Token to the receiving peer CPort. The conditions when a FCT is signaled are
specified in Section 8.11.8.1.
EOM 1-bit The last byte of the most recent received or transmitted
1 Fragment contains the last byte of the potentially
segmented Message
2675 As already introduced in Section 8.4, the segmentation process takes care of splitting Messages so that each
resulting Segment does not exceed the T_MTU size. The Transport Layer sender ensures that the reassembly
process on the receiving side merges the received Segments into exactly the same Message by asserting the
End of Message (EOM) flag to indicate the end of a Message. The order of the intermediate Segments is
preserved by means of the required Network properties, i.e. in-order delivery.
2676 Upon reception of a Segment with the EOM bit set, the Transport Layer shall notify the receiving application
after the last Segment has been processed by means of a T_CO_DATA.ind. The Transport Layer may also
notify the receiving application when parts of a Message are available, e.g., one or more Segments without
the EOM flag set have been received.
8.10.2.5 Payload
2677 The payload field carries the Message given by the CPort User and is potentially segmented by the CPort.
The payload may carry any value.
2696 The T_PeerDeviceID parameter shall be passed unchanged to the Network Layer:
2698 For the reception the targeted CPortID shall be determined as follows:
Segmentation Process
(a) (b)
2704 In Figure 77, the application hands over a Message (an A_PDU that then becomes a T_SDU) to the Transport
Layer. The Transport Layer performs the segmenting process and the Segment containing the last portion of a
Message shall be marked with EOM set to one (‘1’), which is visualized in the figure by a flag symbol. The
segmenting process is invoked on a given Message when the Message is larger than the payload a Segment
can carry, as exemplified in Figure 77a. In contrast, in Figure 77b the original structure is retained since the
T_SDU fits entirely into a single T_PDU and only the EOM is set. The segmenting state is maintained for
each Connection.
2705 The state diagram describing the behavior of the Segmentation Feature is shown in the L4_CPort_tx SDL
processes of [MIPI02].
2706 In exceptional cases, mainly encountered during error recovery, it might be necessary to signal an End of
Message even after the last valid portion of the Message has been sent and there is no more data left to
transmit. In this case, a Segment without any payload may be sent with the EOM set to one. The first payload
byte of any subsequent Segment shall be considered the first byte of a new Message.
2707 Note that the preceding description does not imply that an implementation of the Transport Layer performs
segmenting by buffering entire Messages so that they can be split into multiple Segments, it is merely a
conceptual model. An implementation of the Transport Layer may accept Message Fragments or any other
sized units of data from the Application Layer and thus avoid Message-sized buffers that are owned by the
Transport Layer. The Transport Layer is however responsible for ensuring that a Segment payload never
exceeds the T_MTU limit.
Reassembly Process
(a) (b)
2709 On reception of the first Segment that is determined either by reception of the very first Segment or by the
first Segment following a completed reassembling process, the reassembly process starts and is continued as
long as no further data T_PDUs with EOM set are received. Whenever an EOM is received, the reassembling
process ends and the receiving CPort User shall be notified by the CPort about that occurrence by setting the
EOM parameter to TRUE when calling the T_CO_DATA.ind Service Primitive. The T_CO_DATA.ind
Service Primitive offers the flexibility to provide either entire Messages or Message Fragments to the
application. As stated in Section 8.8.1.3, no relationship is specified between the received Message Fragment
size and the transmitted Message Fragment size or the received Segment size. If the Segment contains a
complete T_SDU the reassembly process is not required as shown in Figure 78b. The reassembling state shall
be maintained for each Connection.
2710 The state diagram describing the behavior of the Reassembly Feature is shown in the L4_CPort_rx SDL
processes of [MIPI02].
2711 Note that the above description does not imply that an implementation of the Transport Layer performs
reassembly by buffering multiple Segment payloads until an entire Message is available; it is merely a
conceptual model. An implementation of the Transport Layer may hand off Message Fragments or any other
sized units of data to the Application Layer and thus avoids Message-sized buffers that are owned by the
Transport Layer.
Composition Process
2713 In the Transport Layer, the composition process is performed on complete or portions of T_SDUs (expressed
by T_SDU[x/y] in Figure 79).
2714 The current segmenting state shall set the EOM parameter in the accordant data T_PDU.
Decomposition Process
2716 The user-data is obtained from the T_SDU field. The user-data and parts of the PCI shall be provided to the
Transport Service User by means of the appropriate Service Primitive indications.
2717 For the construction of the PCI the header format analysis feature is used.
2719 The T_PDU type is determined by the L4s field and identifies the T_PDU header structure.
2720 In the current version of UniPro the L4s field shall be set to ‘1’. In the case where a T_PDU is received with
the L4s bit set to '0', the T_PDU is discarded.
2721 Depending on the determined T_PDU structure, the header fields are extracted and the actual values are
provided either to the corresponding subsequent protocol features or to the Service User by means of Service
Primitive indications or confirmations. The fields to be extracted are specified in Section 8.10.2.
2722 The destination CPortID shall be determined by the Address translation protocol feature (Section 8.11.2).
First, it shall be checked whether the CPort exists. If not, the discard T_PDU feature (Section 8.11.11) shall
be performed. After that, it shall be checked whether a Connection exists for that CPort, i.e.
T_ConnectionState of the particular CPort must be CONNECTED. If not, the discard T_PDU feature shall be
performed.
2723 If T_ConnectionState is CONNECTED, the FCT shall be examined and if this parameter is set to one (‘1’)
this value shall be signaled to the E2E Flow Control protocol feature specified in Section 8.11.8.1. If
T_ConnectionState is not CONNECTED, FCT shall not be processed.
2724 If T_ConnectionState is CONNECTED, the EOM shall be extracted and the content shall be signaled to the
Reassembling protocol feature. If T_ConnectionState is not CONNECTED, EOM shall not be processed.
2732 See the L4_CPort_rx SDL process of [MIPI02] for reference algorithms defining the behavior of the
receiving CPort E2E FC, CSD and CSV features described in this section.
2741 Note:
2742 Step 1 to step 3 may be performed at any time in parallel to the execution of step 4.
2743 In Figure 81 the principal usage of E2E FC and a subsequent data transmission is outlined. Note the CPortID
parameters are omitted in the figure to enhance readability.
TS Provider A TS Provider B
CONNECTED, T_E2EFCEnabled=TRUE,T_[Rx/Tx]TokenValue=256
T_CO_FLOWCONTROL.req(Credits=600)
T_CO_FLOWCONTROL.cnf_L(600, SUCCESS)
T_PeerBufferSpace=0
T_CreditsToSend=600
DT SH T_PDU (EOM=0,FCT=1)
T_CreditsToSend=344
T_PeerBufferSpace=256
DT SH T_PDU (EOM=0,FCT=1)
T_CreditsToSend=88
T_PeerBufferSpace=512
T_CO_DATA.req(Message[400])
DT SH T_PDU (EOM=0,FCT=0,Message[0 to 271])
T_PeerBufferSpace=240
T_PeerBufferSpace=112
T_CO_DATA.ind(Message[400], FRAGMENT_CORRECT)
T_CO_DATA.cnf_L(SUCCESS)
2744 Figure 82 depicts a data transmission procedure where the sending side experiences a situation where the
remaining credits are not enough to continue with the transmission of the next scheduled Segment. The
sending Transport Layer interrupts the process for this particular CPort and Connection until new credits are
given from the receiving side. Note the CPortID parameters are omitted in the figure to enhance readability.
TS Provider A TS Provider B
T_CO_FLOWCONTROL.req(Credits=600)
T_CO_FLOWCONTROL.cnf_L(600, SUCCESS)
T_PeerBufferSpace=0
T_CreditsToSend=600
DT SH T_PDU (EOM=0,FCT=1)
T_CreditsToSend=344
T_PeerBufferSpace=256
DT SH T_PDU (EOM=0,FCT=1)
T_CreditsToSend=88
T_PeerBufferSpace=512
T_CO_DATA.req(Message[520])
DT SH T_PDU (EOM=0,FCT=0,Message[0 to 271])
T_CO_FLOWCONTROL.req(Credits=200)
Not enough
T_PeerBufferSpace to T_PeerBufferSpace=240 T_CO_FLOWCONTROL.cnf_L(200, SUCCESS)
transmit next
scheduled segment.
T_CreditsToSend=288
Wait for new credits.
DT SH T_PDU (EOM=0,FCT=1)
T_CreditsToSend=32
T_PeerBufferSpace=496
T_PeerBufferSpace=248
T_CO_DATA.ind(Message[520], FRAGMENT_CORRECT)
T_CO_DATA.cnf_L(SUCCESS)
2745 Note: the E2E FC procedure does not need to acknowledge FCT signals, and FCT signals do not contain
synchronization information, which is possible due to P2P reliability of the underlying Network.
parameter upon any invocation of the T_CO_FLOWCONTROL.req Service Primitive and decremented by
the amount of data received and forwarded to the receiving CPort User.
2750 If CSD is disabled, the CPort shall do no checks on the Segment payload size.
2751 If CSD is enabled, the CPort shall process and forward the received Segment payload only if the
T_LocalBufferSpace value is greater or equal than the size of the payload of the T_PDU currently indicated
by the underlying Network service. Otherwise, the received Segment payload shall be discarded after
ensuring that the T_PDU header is processed to be able to decode and indicate a potentially signaled EOM.
2752 The Reassembly process shall be informed in case a Segment payload was discarded to be able to determine
whether a Message could be delivered completely or incompletely.
2753 • The receiving User of a CSD-enabled CPort indicates that it can process new portion(s) of data by
invoking the T_CO_FLOWCONTROL.req Service Primitive with the appropriate parameter value set,
which causes incrementing the T_LocalBufferSpace counter with that value.
2754 • In case T_LocalBufferSpace is greater than zero, the receiving CSD-enabled CPort is entitled to receive
as much payload data as indicated by T_LocalBufferSpace, provided that it is ensured that any Segment
received can be completed in order to forward it to the receiving CPort User without running out of
credits. Otherwise, the payload of the current Segment is discarded. The amount of data received is
subtracted from T_LocalBufferSpace.
2755 The first step might be performed at any time in parallel to the second step.
2756 The MSC in Figure 83 shows the situation where the payload of all incoming Segments are discarded due to
a lack of Credits. Loss of Segment payload is marked with a black circle at the end of an arrow. CPortID
parameters are omitted in the figure to enhance readability.
TS Provider A TS Provider B
CONNECTED, T_E2EFCEnabled=FALSE
T_LocalBufferSpace=0
T_CO_DATA.req(Message[400])
DT SH T_PDU (EOM=0,FCT=0,Message[0 to 271]) Due to a lack of
LFC Credits the
incoming Message
DT SH T_PDU (EOM=1,FCT=0,Message[272 to 399])
T_CO_DATA.cnf_L(SUCCESS) Fragments are
dropped
The loss of
Messages can not
be determined on
the sending side
2757 Figure 84 illustrates the data transmission procedure using Controlled Segment Dropping to allow reception
of incoming Segment payload. CPortID parameters are omitted in the figure to enhance readability.
TS Provider A TS Provider B
CONNECTED, T_E2EFCEnabled=FALSE
T_LocalBufferSpace=0
T_CO_FLOWCONTROL.req(Credits=600)
T_LocalBufferSpace=600
T_CO_FLOWCONTROL.cnf_L(600, SUCCESS)
T_CO_DATA.req(Message[400])
DT SH T_PDU (EOM=0,FCT=0,Message[0 to 271])
T_LocalBufferSpace=328
T_LocalBufferSpace=200
T_CO_DATA.ind(Message[400], FRAGMENT_CORRECT)
2758 The MSC depicted in Figure 85 exemplifies a situation where, due to interim lack of credits, parts of the
overall Message are lost. According to the Service Primitive definitions and the reassembling feature this is
signaled to the receiving CPort User by tagging the delivered Message with FRAGMENT_CORRUPT. Loss
of Segment payload is marked with a black circle at the end of an arrow. CPortID parameters are omitted in
the figure to enhance readability.
TS Provider A TS Provider B
CONNECTED, T_E2EFCEnabled=FALSE
T_LocalBufferSpace=0
T_CO_FLOWCONTROL.req(Credits=300)
T_LocalBufferSpace=300
T_CO_FLOWCONTROL.cnf_L(300, SUCCESS)
T_CO_DATA.req(Message[0 to 599])
DT SH T_PDU (EOM=0,FCT=0,Message[0 to 271])
T_LocalBufferSpace=28
T_CO_FLOWCONTROL.req(Credits=200)
T_LocalBufferSpace=228
T_CO_FLOWCONTROL.cnf_L(200, SUCCESS)
DT SH T_PDU (EOM=1,FCT=0,Message[544 to 599])
T_LocalBufferSpace=172
2762 T_CPortFlags.CSV_n shall indicate whether CPort Safety Valve is enabled ('0') or not ('1').
2763 CSV works independently of E2E FC and CSD, and can be used in conjunction with both E2E FC and CSD,
or without any of them being turned on.
2781 • The received T_PDU shall be decomposed by means of the T_PDU decomposition feature
(Section 8.11.6) involving the header format analysis feature (Section 8.11.7) and in accordance to
Section 8.10.2
2782 • The type of the T_PDU shall be recovered
2783 • The present header fields shall be recovered and the resulting values shall be made available to the
corresponding protocol features
2784 • The user-data (or Segments of user-data) shall be obtained from the payload field
2785 • The T_SDU shall be reassembled according to the procedure defined in Section 8.11.4
2786 • The T_PDU should be received and processed in accordance to the Controlled Segment Dropping
procedure defined in Section 8.11.8.2 if the E2E FC is disabled for the particular Connection
2787 • If the receiving application cannot accept the data, the Segment is dropped according to the Safety Valve
procedure defined in Section 8.11.9.
2788 • The user-data shall be indicated to the Cport User by means of the corresponding Service Primitives
according to Section 8.8.1 and with accordingly set parameters after the T_SDU has been reassembled.
In case of interim Segment loss, this error shall be indicated to the receiving CPort User.
2789 Upon any exception listed in Section 8.11.11 the Discard T_PDU feature shall be performed.
Application
Application 1 Application 2 Application N
N+1
TF Dispatcher
T_LM
SAP
T_Core Entity
2795 The Test Feature is located below the LA and within the L4 as shown in Figure 86. A Device can contain
multiple Test Feature instances. The number of instances depends on the number of implemented CPorts in
the Device. If the Device contains one CPort, then the Device shall contain at least one instance of the Test
Feature. if the Device contains two or more CPorts, then the Device shall contain at least two instances of the
Test Feature. These requirements are summarized in Table 102. The previous conditions are needed to be able
to test arbitration at L4.
2796 The number of Test Feature instances in a Device shall be available through a static, gettable-only Attribute at
L4 DME called T_NumTestFeatures. The interconnection between the Test Feature instances and the CPorts
shall be implemented via two intermediate components, TF_Dispatcher and CP_Adapter.
2797 TF_Dispatcher specifies the actual interconnection between the CPorts and Test Feature instances. It is worth
noting that the TF_Dispatcher is not configurable and thus it is an implementation-specific block.
2798 CP_Adapter performs the multiplexing and demultiplexing of the SAP primitives directed to and received
from the CPort. The CP_Adapter shall be controlled via T_CPortMode, which sets the CPort either in the
application mode or test mode. T_CPortMode shall be maintained by every CPort regardless of whether or
not it can be tested by the Test Features.
2799 The assignment of a specific Test Feature instance to a given CPort is controlled via T_TstCPortID, which
shall be maintained by every Test Feature instance. T_TstCPortID specifies the CPort which shall be tested
by the Test Feature instance. If the Tester attempts to set T_TstCPortID to a CPort ID which cannot be
associated with the Test Feature instance for any reason, e.g. the CP_Adapter is not connected to the
TF_Dispatcher, then the Test Feature instance shall report this as an error to the requester.
2800 The CP_Adapter shall be locked, i.e. not settable, when the CPort is connected to the Test Feature instance.
Similarly, the Test Feature instance Attributes shall be locked if the TstSrc or TstDst are enabled.
2801 The Application Layer (LA) is expected to be configured into a safe state before closing the Connection and
establishing the Connection with the Test Feature instance.
8.15.3.1 Activation
2822 TstSrc shall be activated and start generating Messages via an Attribute called T_TstSrcOn, which shall take
two values only, either TRUE or FALSE. If T_TstSrcOn is FALSE, then TstSrc shall be deactivated and does
not generate any Messages. If T_TstSrcOn is TRUE, TstSrc is active and shall generate Messages. TstSrc
shall use T_CO_DATA.req with the EOM parameter set to TRUE for transmitting entire Messages. When a
Message is being transmitted, the TstSrc shall wait for the corresponding T_CO_DATA.cnf_L Service
Primitive.
2823 TstSrc shall be deactivated if any of the following conditions occurs:
2824 • T_TstSrcOn is set to FALSE.
2825 • TstSrc is configured to generate a finite number of Messages (see Section 8.15.3.2) and that number of
Messages has been generated.
MSC InterMessageGap_Example
5@$0@%"5"@5TUSFR
WaitCnf
T_CO_DATA.req
Ready
SrcOnWaitCnfL
T_CO_DATA.cnf_L
5@$0@%"5"@5TUDOG@-
CONNECTED
5@$0@%"5"@5TUDOG@-
SrcOn
t_MessageGapTimer(T_TstSrcInterMessageGap) Ready
SrcOn
5@$0@%"5"@5TUSFR
5@$0@%"5"@5TUSFR
WaitCnf T_CO_DATA.req
Ready
SrcOnWaitCnfL
5@$0@%"5"DOG@-
5@$0@%"5"@5TUDOG@-
5@$0@%"5"@5TUDOG@-
CONNECTED
SrcOn
t_MessageGapTimer(T_TstSrcInterMessageGap)
Ready
SrcOn
SrcOff
2833 TstSrc shall only insert the gap delay between two Messages. As a result, TstSrc does not precede the first
Message with a gap delay and does not succeed the last Message with a gap delay.
ID Value(s) Value
Value(s)
FALSE=0,
T_TstSrcOn 0x4081 Message generation state Boolean FALSE=0 FALSE
TRUE=1
T_TstSrcPattern 0x4082 Pattern used for Message generation Enum Sawtooth=0 Sawtooth
MIPI Alliance Member Confidential
T_TstSrcMessageCount 0x4085 finite Message stream, zero: infinite Message Integer Message 0 to 65535 256
stream).
If non-zero, the gap time between two
Messages.
T_TstSrcInterMessageGap 0x4086 Integer µs 0 to 65535 0
The actual duration of the timeout period shall
8.15.4.1 Activation
2836 TstDst shall be activated to start consuming the Messages from the associated CPort via an Attribute called
T_TstDstOn. If T_TstDstOn is set to FALSE, then TstDst shall be deactivated and does not consume any
Messages. If T_TstDstOn is TRUE, TstDst is active and shall consume Messages.
2837 TstDstOn shall automatically deactivate itself if any of the following conditions occur:
2838 • T_TstDstOn is set to FALSE.
2839 • A first error is discovered in the incoming Message stream.
MSC TstDst_E2EFC_Example
Off
TFmap ( T_TstCPortID )
Ready
T_CO_FLOW CONTROL_Tst.req
T_CO_FLOW CONTROL_Tst.req
(T_TstDstInitialFCCredits = 992,
T_TstCPortID = 1 )
(T_TstDstInitialFCCredits = 992, T_CO_FLOW CONTROL.req
WaitCnfL T_TstCPortID = 1 )
Ready (T_TstDstInitialFCCredits = 992 )
DstTFWaitCnfL
T_CO_FLOW CONTROL.cnf_L
Ready
OnNoFC
5@$0@%"5"@5TUJOE
( MessageSize = 1000 )
Ready
5@$0@%"5"@5TUSTQ@-
5@$0@%"5"@5TUSTQ@-
t_FCGapTimer(T_TstDstInterFCTokenGap)
Ready 5@$0@%"5"@5TUSTQ@-
OnFC
DstTF
CONNECTED
T_CO_FLOW CONTROL_Tst.req
DstTFWaitCnfL
T_CO_FLOW CONTROL.cnf_L
T_CO_FLOW CONTROL_Tst.cnf_L
( T_TstDstFCCredits = 512,
SUCCESS)
T_CO_FLOW CONTROL_Tst.cnf_L
( T_TstDstFCCredits = 512,
SUCCESS, CONNECTED
( T_TstDstFCCredits = 512, T_TstCPortID = 1 )
SUCCESS, DstTF
T_TstCPortID = 1 )
Ready
t_FCGapTimer(T_TstDstInterFCTokenGap)
OnFC
T_CO_FLOW CONTROL_Tst.req
T_CO_FLOW CONTROL_Tst.req
(T_TstDstFCCredits = 480,
T_TstCPortID = 1 ) T_CO_FLOW CONTROL.req
WaitCnfL (T_TstDstFCCredits = 480,
T_TstCPortID = 1 )
(T_TstDstFCCredits = 480 )
Ready
DstTFWaitCnfL
T_CO_FLOW CONTROL.cnf_L
2855 When the TstDst detects any of the errors shown in Table 105, it shall perform the following actions in the
given order:
NO_ERROR=0
Error code that generated the TstDst Enumera- FRAGMENT_CORRUPT=1
T_TstDstErrorCode 0x40AB NO_ERROR
disconnection tion INVALID_MSG_SIZE=2
UNEXPECTED_BYTE_VALUE=3
MIPI Alliance Member Confidential
272
T_CO_FLOWCONTROL.req(Credits=300)
Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved.
T_CO_FLOWCONTROL.cnf_L(300, SUCCESS)
N_DATA_SHDR.req(T_PDU[FCT=1])
DT SH N_PDU (N_SDU)
N_DATA_SHDR.ind(T_PDU[FCT=1])
FCT Received
MIPI Alliance Member Confidential
T_CO_DATA.req(Message)
N_DATA_SHDR.req(T_PDU[EOM=0])
DT SH N_PDU (N_SDU)
N_DATA_SHDR.ind(T_PDU[EOM=0])
N_DATA_SHDR.req(T_PDU[EOM=0])
DT SH N_PDU (N_SDU)
N_DATA_SHDR.ind(T_PDU[EOM=0])
N_DATA_SHDR.req(T_PDU[EOM=1])
T_CO_DATA.cnf_L(SUCCESS) DT SH N_PDU (N_SDU)
274
N_DATA_SHDR.ind(T_PDU[EOM=1])
T_CO_DATA.ind(Message, FRAGMENT_CORRECT)
Features
T_TC0TxMaxSDUSize2 0x4060 Maximum transmit payload (SDU) size per Segment for TC0 Integer Byte 1 to T_MTU
T_TC1TxMaxSDUSize3 0x4061 Maximum transmit payload (SDU) size per Segment for TC1 Integer Byte 1 to T_MTU
MIPI Alliance Member Confidential
DME SAP
T_LM
SAP
N_LM
SAP
2874 The functionality of the DME can be divided into two entities, Control and Configuration.
9.2.1 Attributes
2877 The DME Configuration uses Attributes to access configurable parameters in various UniPro protocol layers.
Figure 91 provides the format of the Attribute address. The Attribute address is a 16-bit AttributeID that has
two sub-fields, a 3-bit layer identifier (see Table 110) and a 12-bit layer-specific AttributeID. When Bit 15 of
the AttributeID is set to zero, the layer-specific AttributeID is defined in the relevant section of the
appropriate specification, either this document or [MIPI05]. When bit 15 is set to one, the layer-specific
AttributeID is implementation-specific.
Attribute ID
1 1 1 1
0
5 4 2 1
0 LayerID AtrributeID (layer)
2880 Cold Reset and Warm Reset affect the entire UniPro stack, Transport Layer (L4) through PHY Adapter Layer
(L1.5), and the respective Attributes, on the local side of a Link. The difference between Warm Reset and
Cold Reset is that Cold Reset clears statistics, while Warm Reset does not.
2881 EndPointReset is a method to trigger a reset of the remote Application over the Link. The effect of the
EndPointReset trigger on the Application, if any, is endpoint-specific and out of scope for this document.
2882 The different types of reset are summarized in Table 111.
2883 At the end of a UniPro Cold Reset or UniPro Warm Reset procedure, the UniPro Link is disabled and it can
either be instructed to enter the Off State (DME_POWEROFF.req), or a Boot process shall be initiated
(DME_ENABLE.req). For further information see Figure 98 and Section 9.11.2.
2884 The three types of reset are described in Section 9.3.1, Section 9.3.2 and Section 9.3.3. The assumed features
of other layers are defined in Section 9.7.
2890 The Warm Reset shall return all layers to their initial condition. All protocol state machines, timers, and
Attributes shall be reset to their reset states and all data buffers shall be cleared. The difference from Cold
Reset is that status fields including statistics, error counters and error flags shall not be cleared.
2891 The Warm Reset is not intended to reset the local Application.
9.3.3 EndPointReset
2892 The EndPointReset is a means for the local Application to request the remote Endpoint Application to reset
itself. It is essentially a remote trigger event (TRG_EPR) transferred across a UniPro Link. Sending this
trigger event may be requested by the local Endpoint Application using the DME_ENDPOINTRESET.req
primitive.
2893 The remote UniPort shall indicate the reception of this trigger event to its Endpoint Application. The
resulting action performed by the remote Endpoint Application is optional. It may reset itself or may refuse to
react to the trigger. If the Endpoint Application resets itself, it shall also apply a Warm Reset to its UniPort. If
this action is not performed, the EndPointReset has no further effect on the UniPro stack.
2894 The PA Layer shall send the ‘TRG_EPR’ over logical PHY Data Lane #0. The mapping of ‘TRG_EPR’ to the
PHY is defined in the PHY-specific sections, Section 5.7.8 and Section 5.8.6. ‘TRG_EPR’ shall be sent only
during SlowAuto_Mode. Therefore, an Endpoint Application that sends the EndPointReset trigger to the
remote side shall ensure the UniPro stack is in the SlowAuto_Mode before the trigger is sent.
Device A
(Local/Host)
Device B
(Remote)
2900 The following sections describe the hibernate entry and exit flow.
PACP_PWR to Hibernate
Hibernate L4
Hibernate L3
Hibernate L2
App (Local) DME UniPro (L1.5-L4) UniPro (L1.5-L4) DME App. (Remote)
DME_HIBERNATE_ENTER.req
PA_LM_HIBERNATE_ENTER.req
WaitCnf
PA_LM_HIBERNATE_ENTER.cnf_L
DME_HIBERNATE_ENTER.cnf_L
PACP_PWR to Hibernate
WaitInd
PA_LM_HIBERNATE_ENTER.ind PA_LM_HIBERNATE_ENTER.ind
T_LM_HIBERNATE_ENTER.req T_LM_HIBERNATE_ENTER.req
T_LM_HIBERNATE_ENTER.cnf_L T_LM_HIBERNATE_ENTER.cnf_L
N_LM_HIBERNATE_ENTER.req N_LM_HIBERNATE_ENTER.req
N_LM_HIBERNATE_ENTER.cnf_L N_LM_HIBERNATE_ENTER.cnf_L
DL_LM_HIBERNATE_ENTER.req DL_LM_HIBERNATE_ENTER.req
DL_LM_HIBERNATE_ENTER.cnf_L DL_LM_HIBERNATE_ENTER.cnf_L
DME_HIBERNATE_ENTER.ind DME_HIBERNATE_ENTER.ind
App (Local) DME UniPro (L1.5-L4) UniPro (L1.5-L4) DME App. (Remote)
DME_HIBERNATE_EXIT.req
PA_LM_HIBERNATE_EXIT.req
WaitCnf
PA_LM_HIBERNATE_EXIT.cnf_L
DME_HIBERNATE_EXIT.cnf_L
WaitInd
PA_LM_HIBERNATE_EXIT.ind PA_LM_HIBERNATE_EXIT.ind
T_LM_HIBERNATE_EXIT.req T_LM_HIBERNATE_EXIT.req
T_LM_HIBERNATE_EXIT.cnf_L T_LM_HIBERNATE_EXIT.cnf_L
N_LM_HIBERNATE_EXIT.req N_LM_HIBERNATE_EXIT.req
N_LM_HIBERNATE_EXIT.cnf_L N_LM_HIBERNATE_EXIT.cnf_L
DL_LM_HIBERNATE_EXIT.req DL_LM_HIBERNATE_EXIT.req
DL_LM_HIBERNATE_EXIT.cnf_L DL_LM_HIBERNATE_EXIT.cnf_L
DME_HIBERNATE_EXIT.ind DME_HIBERNATE_EXIT.ind
Write PA_PWRModeUserData 0 to 11
DME_POWERMODE.req
PA_LM_SET.req
Last cnf_L Primitive
PA_LM_SET.cnf_L
PA_LM_SET.req(PA_PWRMode)
PA_LM_PWR_MODE.ind
DL_LM_SET.req
DL_LM_SET.cnf_L
PA_LM_PWR_MODE.rsp_L
Last cnf_L Primitive
PA_LM_PWR_MODE_CHANGED.ind
DME_POWERMODE.ind
2913 The power mode change in the DME level may be split into the following three distinctive phases:
2914 • Issue a request to the local PA Layer
2915 • Update the local L2 timer values
2916 • Wait until the request (to the local PA Layer) has been completed
2917 Note:
2918 The first phase is skipped when the request is made by the peer DME. The second phase is missing
if the power mode change request fails.
2919 The local PA Layer provides a method to transmit data between two peer DME entities. The local data is sent
to the peer DME and the peer DME’s response is reported back. The payload is twenty-four bytes of data (see
Table 8) to fit all L2 timer values for all TCs.
9.6.3 Completion
2937 If the power mode change request was accepted, the DME shall wait until the local PA Layer returns with the
PA_LM_PWR_MODE_CHANGED.ind primitive. When the peer DME initiates the request, the local DME
shall receive the primitive even though it did not issue the power mode change request.
2938 The PA_LM_PWR_MODE_CHANGED.ind primitive has a parameter indicating the result of the power
mode change operation. Parameter values are defined in Table 9.
9.8 DME_SAP
2949 The primitives on this Service Access Point are intended to be used by an Application Layer, that is, a
component that is higher in the reset hierarchy than the UniPro stack.
2951 The DME shall have remote access to Attributes of the peer Device on the UniPro Link via the local PA
Layer.
2952 Even if the capability to request the access to remote Attributes is optional for a single Device, at least one
Device on each UniPro Link, usually the Host, needs this capability. Hence, a Host shall support the
DME_PEER_GET.xxx and the DME_PEER_SET.xxx primitives. These primitives are optional for a
Peripheral. Both Host and Peripheral shall support DME_GET.xxx and DME_SET.xxx. primitives.
2953 Table 114 provides further explanation to the various Return Codes.
2954 The DME shall use a request/confirmation handshake for the GET and SET primitives. The DME User shall
not issue a new request primitive before the previous one has terminated. Only the UniPro stack may delay a
primitive processing and cause a BUSY condition.
9.8.1.1 DME_GET.req
2955 This primitive shall be used to request information from a specific Attribute identified by MIBattribute and, if
relevant, the GenSelectorIndex. The GenSelectorIndex shall be interpreted either as a data PHY Lane index
or CPort index or Test Feature index depending on the Attribute. For Attributes not associated with a
GenSelectorIndex, the GenSelectorIndex shall be ignored.
2956 The semantics of this primitive are:
2957 DME_GET.req( MIBattribute, GenSelectorIndex )
9.8.1.2 DME_GET.cnf_L
2964 This primitive reports the results of a GET request.
2965 The semantics of this primitive are:
2966 DME_GET.cnf_L( ConfigResultCode, MIBvalue )
9.8.1.3 DME_SET.req
2974 This primitive shall be used to set the value of a specific Attribute identified by MIBattribute and, if relevant,
the GenSelectorIndex. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort
index or Test Feature index depending of the Attribute. For Attributes not associated with a
GenSelectorIndex, the GenSelectorIndex shall be ignored.
2975 The semantics of this primitive are:
2976 DME_SET.req( AttrSetType, MIBattribute, MIBvalue, GenSelectorIndex )
9.8.1.4 DME_SET.cnf_L
2983 This primitive shall be used to report the results of a SET request.
2984 The semantics of this primitive are:
2985 DME_SET.cnf_L( ConfigResultCode )
9.8.1.5 DME_PEER_GET.req
2993 This primitive shall be supported by a Host and is optional for a Peripheral. However, if an implementation
supports this primitive, it shall implement it as described in this section.
2994 This primitive shall be used to request information from a specific Attribute, in the peer Device, identified by
MIBattribute and, if relevant, the GenSelectorIndex. The GenSelectorIndex shall be interpreted either as a
data PHY Lane index or CPort index or Test Feature index depending of the Attribute. For Attributes not
associated with a GenSelectorIndex, the GenSelectorIndex shall be ignored.
2995 The semantics of this primitive are:
2996 DME_PEER_GET.req( MIBattribute, GenSelectorIndex )
9.8.1.6 DME_PEER_GET.cnf
3003 This primitive shall be supported by a Host and is optional for a Peripheral. If the DME_PEER_GET.req
primitive is supported by an implementation, it shall also support the DME_PEER_GET.cnf primitive as
described in this section.
3004 This primitive reports the results of a GET request.
3005 The semantics of this primitive are:
3006 DME_PEER_GET.cnf( ConfigResultCode, MIBvalue )
9.8.1.7 DME_PEER_SET.req
3013 This primitive shall be supported by a Host and is optional for a Peripheral. However, if an implementation
supports this primitive, it shall implement it as described in this section.
3014 This primitive shall be used to set the MIBvalue value of a specific Attribute, of the peer Device, identified by
MIBattribute and, if relevant, the GenSelectorIndex. The GenSelectorIndex shall be interpreted either as a
data PHY Lane index or CPort index or Test Feature index depending of the Attribute. For Attributes not
associated with a GenSelectorIndex, the GenSelectorIndex shall be ignored.
3015 The semantics of this primitive are:
3016 DME_PEER_SET.req( AttrSetType, MIBattribute, MIBvalue, GenSelectorIndex )
9.8.1.8 DME_PEER_SET.cnf
3023 This primitive shall be supported by a Host and is optional for a Peripheral. If the DME_PEER_SET.req
primitive is supported by an implementation, it shall also support the DME_PEER_SET.cnf primitive as
described in this section.
3024 This primitive shall be used to report the results of a SET request.
3025 The semantics of this primitive are:
3026 DME_PEER_SET.cnf( ConfigResultCode )
3035 Table 116 lists the parameters that appear in the DME_SAP control primitives.
Fast 1
Slow 2
TxPowerMode,
Enum FastAuto 4 Specifies the requested power mode
RxPowerMode
SlowAuto 5
Unchanged 7
3036 Table 117 defines the LocalL2TimerData and RemoteL2TimerData structure and order. Unused and reserved
bits should be set to one (‘1’).
1. 16-bit integer
3037 Table 118 provides further references to the specific definition of the LayerErrorCode (see Table 116) in each
layer.
9.8.2.1 DME_POWERON.req
3038 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
3039 The DME_POWERON.req primitive is used to power on the layers L1.5 through L4 connected to the DME.
3040 The semantics of this primitive are:
3041 DME_POWERON.req( )
9.8.2.2 DME_POWERON.cnf_L
3048 Support for this primitive is optional. If the DME_POWERON.req primitive is supported by an
implementation, it shall also support the DME_POWERON.cnf_L primitive as described in this section.
3049 The DME_POWERON.cnf_L primitive is used as a local confirm for the DME_POWERON.req primitive.
3050 The semantics of this primitive are:
3051 DME_POWERON.cnf_L( GenericErrorCode )
9.8.2.3 DME_POWEROFF.req
3058 Support for this primitive is optional. However, if an implementation supports this primitive, it shall
implement it as described in this section.
3059 The DME_POWEROFF.req primitive is used to power off the layers L1.5 through L4 connected to the DME.
3060 The semantics of this primitive are:
3061 DME_POWEROFF.req( )
9.8.2.4 DME_POWEROFF.cnf_L
3068 Support for this primitive is optional. If the DME_POWEROFF.req primitive is supported by an
implementation, it shall also support the DME_POWEROFF.cnf_L primitive as described in this section.
3069 The DME_POWEROFF.cnf_L primitive is used as a local confirm for the DME_POWEROFF.req primitive.
3070 The semantics of this primitive are:
3071 DME_POWEROFF.cnf_L( GenericErrorCode )
9.8.2.5 DME_ENABLE.req
3078 The DME User uses this primitive to enable the UniPro stack.
3079 The semantics of this primitive are:
3080 DME_ENABLE.req( )
9.8.2.6 DME_ENABLE.cnf_L
3087 This primitive is generated when the enable procedure has been completed.
3088 The semantics of this primitive are:
3089 DME_ENABLE.cnf_L( GenericErrorCode )
9.8.2.7 DME_RESET.req
3096 The DME_RESET.req primitive shall be used to reset the DME and the UniPro stack layers L1.5 through L4
connected to it.
3097 The semantics of this primitive are:
3098 DME_RESET.req( ResetLevel )
9.8.2.8 DME_RESET.cnf_L
3105 The DME_RESET.cnf_L primitive shall be used as a local confirm for the DME_RESET.req primitive.
3106 The semantics of this primitive are:
3107 DME_RESET.cnf_L( )
9.8.2.9 DME_ENDPOINTRESET.req
3114 The DME_ENDPOINTRESET.req primitive shall be used to send an EndPointReset request command to the
Link Endpoint.
3115 The semantics of this primitive are:
3116 DME_ENDPOINTRESET.req( )
9.8.2.10 DME_ENDPOINTRESET.cnf_L
3123 The DME_ENDPOINTRESET.cnf_L primitive shall be used as a local confirmation for the reception of the
DME_ENDPOINTRESET.req primitive by the DME.
3124 The semantics of this primitive are:
3125 DME_ENDPOINTRESET.cnf_L( GenericErrorCode )
9.8.2.11 DME_ENDPOINTRESET.ind
3132 The DME_ENDPOINTRESET.ind primitive shall be used to indicate that the EndPointReset request has
been received.
3133 The semantics of this primitive are:
3134 DME_ENDPOINTRESET.ind( )
9.8.2.12 DME_LINKSTARTUP.req
3141 The DME_LINKSTARTUP.req primitive shall be used to start the UniPro Link up.
3142 The semantics of this primitive are:
3143 DME_LINKSTARTUP.req( )
9.8.2.13 DME_LINKSTARTUP.cnf_L
3150 The DME_LINKSTARTUP.cnf_L primitive shall be used as a local confirm for the
DME_LINKSTARTUP.req primitive.
3151 The semantics of this primitive are:
3152 DME_LINKSTARTUP.cnf_L( GenericErrorCode )
9.8.2.14 DME_LINKSTARTUP.ind
3159 The DME_LINKSTARTUP.ind primitive shall be used as an indication that Link start-up process has been
initiated by the remote end of the Link.
3160 The semantics of this primitive are:
3161 DME_LINKSTARTUP.ind( )
9.8.2.15 DME_LINKLOST.ind
3168 The DME_LINKLOST.ind primitive shall be used as an indication that Link is lost.
3169 The semantics of this primitive are:
3170 DME_LINKLOST.ind( )
9.8.2.16 DME_HIBERNATE_ENTER.req
3177 The DME_HIBERNATE_ENTER.req primitive shall be used to put the Link and all the UniPro layers into
the Hibernate state to save power.
3178 The semantics of this primitive are:
3179 DME_HIBERNATE_ENTER.req( )
9.8.2.17 DME_HIBERNATE_ENTER.cnf_L
3186 The DME_HIBERNATE_ENTER.cnf_L primitive shall be used as a local confirmation for the
DME_HIBERNATE_ENTER.req primitive.
3187 The semantics of this primitive are:
3188 DME_HIBERNATE_ENTER.cnf_L( GenericErrorCode )
9.8.2.18 DME_HIBERNATE_ENTER.ind
3195 The DME_HIBERNATE_ENTER.ind primitive shall be used to indicate the completion of the Hibernate
Enter sequence. The PowerChangeResultCode parameter shall indicate if the procedure has succeeded or not.
The procedure has succeeded if the returned PowerChangeResultCode value is either PWR_LOCAL or
PWR_REMOTE. In this case, the Link is in the Hibernate state. Both ends of the Link receive this primitive.
3196 The semantics of this primitive are:
3197 DME_HIBERNATE_ENTER.ind( PowerChangeResultCode )
9.8.2.19 DME_HIBERNATE_EXIT.req
3204 The DME_HIBERNATE_EXIT.req primitive shall be used to get the Link out of the Hibernate state.
9.8.2.20 DME_HIBERNATE_EXIT.cnf_L
3213 The DME_HIBERNATE_EXIT.cnf_L primitive shall be used as a local confirmation for the
DME_HIBERNATE_EXIT.req primitive.
3214 The semantics of this primitive are:
3215 DME_HIBERNATE_EXIT.cnf_L( GenericErrorCode )
9.8.2.21 DME_HIBERNATE_EXIT.ind
3222 The DME_HIBERNATE_EXIT.ind primitive shall be used to indicate the completion of the Hibernate Exit
sequence. The PowerChangeResultCode parameter shall indicate if the procedure has succeeded or not. The
procedure has succeeded if the returned PowerChangeResultCode value is either PWR_LOCAL or
PWR_REMOTE. In this case the Link has left the Hibernate state. Both ends of the Link receive this
primitive.
3223 The semantics of this primitive are:
3224 DME_HIBERNATE_EXIT.ind( PowerChangeResultCode )
9.8.2.22 DME_POWERMODE.req
3231 This primitive shall be used to change the power mode of the Link (See Section 5 and Section 6 for more
information about power mode change). The requested UniPro power mode and all the Data Link Layer timer
required for the power mode change are provided as parameters. Attributes defining the PHY parameters for
the new power mode change shall be configured by the DME User before issuing the
DME_POWERMODE.req primitive.
3232 The semantics of this primitive are:
3233 DME_POWERMODE.req( TxPowerMode, RxPowerMode, LocalL2TimerData,
RemoteL2TimerData )
9.8.2.23 DME_POWERMODE.cnf_L
3240 The DME_POWERMODE.cnf_L primitive shall be used as a local confirmation for the
DME_POWERMODE.req primitive.
3241 The semantics of this primitive are:
3242 DME_POWERMODE.cnf_L( GenericErrorCode )
9.8.2.24 DME_POWERMODE.ind
3249 This indication shall be used to indicate that the DME, PA Layer, or DL Layer part of the power mode change
has been completed. Both ends receive this indication.
3250 The semantics of this primitive are:
3251 DME_POWERMODE.ind( PowerChangeResultCode )
9.8.2.25 DME_TEST_MODE.req
3258 This primitive shall be supported by a Host and is optional for a Peripheral. However, if an implementation
supports this primitive, it shall implement it as described in this section.
3259 This primitive is used to put the peer Device into test mode.
3260 The semantics of this primitive are:
3261 DME_TEST_MODE.req( )
9.8.2.26 DME_TEST_MODE.cnf_L
3268 This primitive shall be supported by a Host and is optional for a Peripheral. If the DME_TEST_MODE.req
primitive is supported by an implementation, it shall also support the DME_TEST_MODE.cnf_L primitive
as described in this section.
3269 This primitive inform the DME User that the sequence to set the peer Device to a given test mode was sent.
3270 The semantics of this primitive are:
3271 DME_TEST_MODE.cnf_L( GenericErrorCode )
9.8.2.27 DME_TEST_MODE.ind
3278 This primitive is used to indicate to the DME User, that the UniPro stack has been set to a certain test mode.
3279 The semantics of this primitive are:
3280 DME_TEST_MODE.ind( )
9.8.2.28 DME_ERROR.ind
3287 This primitive is used to indicate to the DME User, that a layer in the UniPro stack has encountered an error
condition. The information forwarded to the DME user differs by layer:
3288 • For the Transport layer (L4), the T_LM_DISCARD.ind information is forwarded to the DME User.
3289 • For the Network layer (L3), the N_LM_DISCARD.ind information is forwarded to the DME User.
3290 • For the Data Link layer (L2), the DL_LM_ERROR.ind information is forwarded to the DME User.
3291 • For the PA Layer (L1.5), the PA_LM_PHY_RESET.ind information is forwarded to the DME User.
3292 The semantics of this primitive are:
3293 DME_ERROR.ind( LayerNumber, LayerErrorCode )
9.8.2.29 DME_RXPWRSTATE.ind
3300 The DME_RXPWRSTATE.ind primitive is directly mapped to the PA_LM_RXPWRSTATE.ind primitive.
See Section 5.4.3.1 for a detailed description of this primitive.
DME_POWEROFF.req /
DME_POWEROFF.cnf_L
DME_POWERON.req /
DME_POWERON.cnf_L
DME_RESET.req / DME_HIBERNATE_ENTER.req /
DME_RESET.cnf_L DME_HIBERNATE_ENTER.cnf_L
DME_HIBERNATE_ENTER.req /
DME_HIBERNATE_ENTER.cnf_L
LinkLost
/Off(*) DME_ENABLE.req /
DME_ENABLE.cnf_L
DME_HIBERNATE_EXIT.req
[prev_state=LinkUp] /
DME_HIBERNATE_EXIT.cnf_L
DME_POWERMODE.req
PA_LM_LINKSTARTUP.ind] / [capability ok] /
DME_LINKSTARTUP.ind DME_POWERMODE.cnf_L
(SUCCESS)
LinkDown LinkUp LinkCfg
[pwrmode done]
DME_LINKSTARTUP.req DME_POWERMODE.ind(LOCAL)
DME_LINKSTARTUP.req
[peer detected] /
[no peer detected] /
PA_LM_LINKSTARTUP.cnf_L(SUCCESS)
DME_LINKSTARTUP.cnf_L(FAILURE)
3303 Based on the UniPro state diagram shown in Figure 98, some restrictions are enforced on all DME_xxx.req
primitives (see Section 9.8). These restrictions specify when a primitive is going to be executed or when it
shall be ignored by an implementation (see Table 120).
3304 If a DME_SAP control primitive is issued in a restricted power state, the DME shall set the
GenericErrorCode field in the local confirmation primitive to Failure.
3305 If a DME_SAP configuration primitive is issued in a restricted power state, the DME shall set the
ConfigResultCode field in the confirmation primitive to DME_FAILURE.
3320 • Figure 101 describes a special case where a peer Device-initiated sequence resulted in a Link reaching
LinkUp state, while receiving a DME_LINKLOST.ind primitive.
Disabled
DME_ENABLE.req
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.cnf_L
DL_LM_ENABLE_LAYER.req
DL_LM_ENABLE_LAYER.cnf_L
N_LM_ENABLE_LAYER.req
N_LM_ENABLE_LAYER.cnf_L
T_LM_ENABLE_LAYER.req
DME_ENABLE.cnf_L T_LM_ENABLE_LAYER.cnf_L
LinkDown
DME_LINKSTARTUP.req
PA_LM_LINKSTARTUP.req
PA_LM_LINKSTARTUP.cnf_L(Success)
DL_LM_LINKSTARTUP.req
DL_LM_LINKSTARTUP.cnf_L
DME_LINKSTARTUP.cnf_L(Success)
LinkUp
Disabled
DME_ENABLE.req
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.cnf_L
DL_LM_ENABLE_LAYER.req
DL_LM_ENABLE_LAYER.cnf_L
N_LM_ENABLE_LAYER.req
N_LM_ENABLE_LAYER.cnf_L
T_LM_ENABLE_LAYER.req
T_LM_ENABLE_LAYER.cnf_L
DME_ENABLE.cnf_L
LinkDown
DME_LINKSTARTUP.req
PA_LM_LINKSTARTUP.req
PA_LM_LINKSTARTUP.cnf_L(Failure)
DME_LINKSTARTUP.cnf_L(Failure)
LinkDown
PA_LM_LINKSTARTUP.ind
DME_LINKSTARTUP.ind
DME_LINKSTARTUP.req
PA_LM_LINKSTARTUP.req
PA_LM_LINKSTARTUP.cnf_L(Success)
DL_LM_LINKSTARTUP.req
DL_LM_LINKSTARTUP.cnf_L
DME_LINKSTARTUP.cnf_L(Success)
LinkUp
LinkUp
PA_LM_LINKSTARTUP.ind
DME_LINKLOST.ind
LinkLost
DME_RESET.req
PA_LM_RESET.req
PA_LM_RESET.cnf_L
... T_LM_RESET.req
T_LM_RESET.cnf_L
DME_RESET.cnf_L
Disabled
DME_ENABLE.req
PA_LM_ENABLE_LAYER.req
PA_LM_ENABLE_LAYER.cnf_L
... T_LM_ENABLE_LAYER.req
T_LM_ENABLE_LAYER.cnf_L
DME_ENABLE.cnf_L
LinkDown
DME_LINKSTARTUP.req
PA_LM_LINKSTARTUP.req
PA_LM_LINKSTARTUP.cnf_L(Success)
DL_LM_LINKSTARTUP.req
DL_LM_LINKSTARTUP.cnf_L
DME_LINKSTARTUP.cnf_L(Success)
LinkUp
1. Attributes 0x5000 to 0x5005 correspond to the DDB Level 1 fields and their offsets defined in [MIPI04].
3325 The DME Attributes listed in Table 121 should be retained during Hibernation. Those Attributes are simple
and do not cause any implicit action when set.
Cable
C C
T-PPI o o T-PPI
n n
FPGA with n n FPGA with
UniPro Stack e e UniPro Stack
(L4 to L1.5) c c (L4 to L1.5)
t t
T-PPI o o T-PPI
r r
PCB #1 PCB #2
3328 The T-PPI provides the signal list for interfacing UniPro stacks at the bottom of L1.5.
3329 The main requirement of T-PPI is to have a low signal count, because the number of connector pins is limited.
Moreover low T-PPI signal count would allow multiple Data Lanes fit on a low number of connectors. To
lower the T-PPI signal count, some of the mutually exclusive signals on the logical PPI are multiplexed. In
addition to this, PHY-specific signals, e.g. error signals, and signals not needed for UniPro, e.g. signals for
changing lane direction, etc, are not included in the T-PPI signal list. Both these sets of signals can be
included in the T-PPI if needed by extending T-PPI later.
3330 The T-PPI consists of three groups of signals, Control, Clock and Data, at both the Transmitter and the
Receiver.
3331 The control group signals, which are T-PPI-specific, qualify the clock group and data group signals. The
clock group signals consist of a sub-set of the Clock Lane signals specified in the D-PHY PPI signal list. The
data group signals consist of a sub-set of D-PHY PPI's Transmit and Receive signals. In addition to this, some
of the signals from the D-PHY PPI's Control signals category are multiplexed into the T-PPI data group to
minimize the number of signals.
3332 In the case multiple Data Lanes are emulated, each lane shall use a separate T-PPI data group. T-PPI's Clock
and Control groups shall be shared by all Data Lanes. Note that in the T-PPI's ESC mode; only Data Lane 0
shall be used. The signals on all the other Data Lanes shall be ignored.
Clock
TxByteClkHS 1 RxByteClkHS Clock
Group TxClkEsc 1 RxClkEsc Group
L=3 L=3
L=2 L=2
L=1 L=1
Data L=0 L=0 Data
Group TxData_L[7:0] 8*N RxData_L[7:0] Group
For multiple lane configuration, each data lane shall use a separate T-PPI data group of signals.
L is Data Lane, where L = {0,1,2,3}
N is Number of Lanes, where N = {1,2,3,4}
Figure 103 T-PPI Signal Groups with Their Respective Signals per Direction
3334 The T-PPI consists of thirteen signals per direction, one signal in the Control Group, two signals in the Clock
Group and ten signals in the Data Group, for a single lane configuration. For a multiple-lane configuration,
the total number of signals per direction is (1+2+10*N), where N is the number of lanes in that direction.
Note that when the TPPI is operating in ESC mode (Mode = ‘0’), only the signals belonging to the Data
Group corresponding to Lane 0 (L=0) are used by the transmitter and the signals belonging to Data Groups
corresponding to other Data Lanes (L=1, 2 and 3) shall be ignored at the receiver.
Table 122 T-PPI Control Group Transmitter and Receiver Signal List
Signal Name Direction Description
Transmit Mode (Transmitter)
TxMode indicates whether the Data Group signals belong to the High-
TxMode Output Speed mode or Escape mode, and which of the two Clock signals is used.
• TxMode='1' indicates the High-Speed (HS) mode.
• TxMode='0' indicates the Escape (ESC) mode.
Receive Mode (Receiver)
RxMode indicates whether the Data group signals belong to the High-
RxMode Input Speed mode or Escape mode, and which of the two Clock signals is used.
• RxMode='1' indicates the High-Speed (HS) mode.
• RxMode='0' indicates the Escape (ESC) mode.
Table 123 T-PPI Clock Group Transmitter and Receiver Signal List
Signal Name Direction Description
High-Speed mode transmit clock.
TxByteClkHS is used to synchronize the T-PPI data group signals when T-
PPI is in High-Speed mode (TxMode =’1’).
When the T-PPI is in ESC Mode (TxMode =’0’), TxByteClkHS may be
TxByteClkHS Output
driven ‘0’.
The T-PPI TxByteClkHS signal is equivalent to TxByteClkHS signal in the
logical PPI. Note that in T-PPI, TxByteClkHS is an output, as opposed to
the PPI TxByteClkHS, which is an input.
Escape mode transmit clock.
TxClkEsc is used to synchronize the T-PPI data group signals when T-PPI
is in escape mode (TxMode =’0’).
TxClkEsc Output
When the T-PPI is in high-speed mode (TxMode =’1’), TxClkEsc may be
driven ‘0’.
T-PPI TxClkEsc signal is equivalent to TxClkEsc signal in the logical PPI.
High-Speed mode receive clock.
RxByteClkHS is used to synchronize the T-PPI data group signals when T-
PPI is in High-speed mode (RxMode =’1’).
RxByteClkHS Input When the T-PPI is in ESC Mode (RxMode =’0’), RxByteClkHS shall be
ignored.
T-PPI RxByteClkHS signal is equivalent to RxByteClkHS signal in the
logical PPI.
Escape mode receive clock.
RxClkEsc is used to synchronize the T-PPI data group signals when T-PPI
is in escape mode (RxMode =’0’).
RxClkEsc Input
When the T-PPI is in high-speed mode (RxMode =’1’), RxClkEsc shall be
ignored.
T-PPI RxClkEsc signal is equivalent to RxClkEsc signal in the logical PPI.
Table 124 T-PPI Data Group Transmit and Receive Signal List
Signal Name Direction Description
Transmit data/miscellaneous signals for Data Lane L.
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
This 8-bit signal conveys the PPI Transmit data or PPI miscellaneous
TxData_L [7:0] Output (transmit /control) signals depending upon the value of the TxDataType_L
T-PPI signal. Also the T-PPI TxMode signal indicates whether these
signals correspond to high-speed mode or escape mode.
See Section A.2 on the T-PPI signal multiplexing to know the meaning of
each bit.
Type of Data on the TxData_L [7:0]
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
This signal indicates whether the TxData_L signals carry miscellaneous
signals (transmit and control signals in PPI) or data signals in PPI from the
transmitter.
TxDataType_L Output
• When '1', TxDataType_L indicates that the corresponding data group
signals TxData_L [7:0] carry miscellaneous signals (PPI transmit and
control signals).
• When '0', TxDataType_L indicates that the corresponding data group
signals TxData_L [7:0] carry PPI transmit data signals.
See Section A.2 on the T-PPI signal multiplexing for more details.
Transmit valid for Data Lane L.
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
• When '1' the TxData_L [7:0] and TxDataType_L shall carry valid (data or
TxValid_L Output miscellaneous) information.
• When '0' the corresponding TxData_L [7:0] and TxDataType_L shall
carry invalid information and shall be ignored at the receiver.
TxValid_L maps to TxValidHS or TxValidEsc in the PPI signal list
depending on the value of T-PPI TxMode signal.
Receive data/miscellaneous signals for Data Lane L.
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
This 8-bit signal conveys the PPI receive data or PPI miscellaneous
RxData_L
Input (receive /control) signals depending upon the value of the RxDataType_L
[7:0]
T-PPI signal. Also, the T-PPI RxMode signal indicates whether these
signals correspond to high-speed mode or escape mode.
See Section A.2 on the T-PPI signal multiplexing to know the meaning of
each bit.
Table 124 T-PPI Data Group Transmit and Receive Signal List (continued)
Signal Name Direction Description
Type of Data on the RxData_L [7:0].
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
This signal indicates whether the RxData_L signals carry miscellaneous
signals (receive and control signals in PPI) or data signals in PPI from the
RxDataType_ transmitter.
Input
L • When '1', RxDataType_L indicates that the corresponding data group
signals RxData_L [7:0] carry miscellaneous signals (PPI receive and
control signals).
• When '0', RxDataType_L indicates that the corresponding data group
signals RxData_L [7:0] carry PPI receive data signals.
See Section A.2 on the T-PPI signal multiplexing for more details.
Receive valid for Data Lane L.
L can take values 0, 1, 2 or 3 corresponding to Data Lane 0, Data Lane 1,
Data Lane 2 or Data Lane 3.
• When '1' the RxData_L [7:0] and RxDataType_L shall carry valid (data
RxValid_L Input or miscellaneous) information.
• When '0' the corresponding RxData_L [7:0] and RxDataType_L shall
carry invalid information and shall be ignored.
RxValid_L maps to RxValidHS or RxValidEsc in the PPI signal list
depending on the value of T-PPI RxMode.
‘0’ => ESC • When 11b indicates Data Link (DL) Layer Protocol Marker request/indication
TxData_0[7:6] related to C600 (Table 17).
‘1’ => Misc N/A1 • When 10b indicates Data Link (DL) Layer Protocol Marker request/indication
RxData_0[7:6]
related to C417 (Table 17).
• When 01b indicates PHY- Adapter (PA) Layer Protocol Marker request/indication
320
Note that in cases where there is no D-PHY interface to the UniPro Stack, there is no
need to assert this signal.
Stop State request/indication.
This active high signal is asserted to indicate that the protocol forced the Lane to a
MIPI Alliance Member Confidential
TxTriggerEsc[3:
When Data_0[3] is 1b it indicates a Escape mode Trigger-3. Data_0[7:4] and Data_0
TxData_0[3:0] 0]
[2:0] shall be 0x0.
RxData_0[3:0] RxTriggerEsc[3:
When Data_0[2] is 1b, it indicates an Escape mode Trigger-2. Data_0[7:3] and
0]
Data_0[1:0] shall be 0x0.
Protocol Marker. This single HS clock duration pulse is equivalent to the bits [16:8]
(control symbol indicator bit plus EscType field) in the Escaped Data PA_PDU
(Figure 16).
• When 11b indicates Data Link (DL) Layer Protocol Marker request/indication
MIPI Alliance Member Confidential
request/indication.
When Data_L [7:6] is 11b, 10b or 01b, Data_L [5:0] shall be 0x00.
TxData_L[5:0] Reserved.
N/A
RxData_L[5:0] Shall be set to 0x00.
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
EOF
CRC
AFC
No unacknowledged frames TC0 AFC
in the TC0 TX buffer so the #0
TC0_REPLAY_TIMER is TC0
stopped. CRC #0
CRC
TC0_REPLAY_TIMER
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
Figure 104 TC0 Replay Timer Operation for Simple ACK (no grouping ACK)
3345 The TC0_REPLAY_TIMER behavior for grouped acknowledgment is shown in Figure 105. Traffic Class 0
is used for illustration purposes though the same behavior is applicable to other Traffic Classes.
3346 • TC0_REPLAY_TIMER is reset and started after sending the last symbol of Frame#0.
3347 • While Frame #1 is being transmitted, TC0_REPLAY_TIMER is allowed to run.
3348 • TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of Frame#1.
3349 • While Frame #2 is being transmitted, TC0_REPLAY_TIMER is allowed to run.
3350 • TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of Frame#2.
3351 • Successful reception of AFC0#1 Frame (grouped acknowledgment for Frame#0 and Frame#1)
TC0_REPLAY_TIMER is reset and allowed to run since acknowledgment for Frame#2 is not yet
received.
3352 • Reception of AFC0#2 Frame by local RX resets and stops TC0_REPLAY_TIMER as there are no
unacknowledged Frames.
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
SOF EOF
CRC
TC0 SOF
#1
TC0
EOF #1
CRC
SOF EOF
CRC
TC0 SOF
#2
TC0
EOF #2
CRC AFC
EOF
CRC TC0 AFC
#1
TC0
CRC #1
CRC
CRC
No unacknowledged frames in
the TC0 TX buffer so the
TC0_REPLAY_TIMER is
stopped.
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
3353 Figure 106 shows TCx_REPLAY_TIMER behavior in case of preemption (TC0 is preempted by TC1).
3354 • TC0_REPLAY_TIMER is reset and started after sending the last symbol of TC0 Frame#0.
3355 • While TC0 Frame #1 is being transmitted, TC0_REPLAY_TIMER is allowed to run.
3356 • The local TX preempts TC0 Frame #1 with a higher priority Frame, TC1 Frame #0.
3357 • Since TC0 Frame #1 has not been acknowledged, TC0_REPLAY_TIMER continues to run.
3358 • TC1_REPLAY_TIMER is reset and allowed to run after sending the last symbol of TC1 Frame#0.
3359 • Since TC1 has no more Frames to send, TC0 resumes transmitting TC0 Frame#1 from its preempted
position.
3360 • TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of TC0 Frame#1.
3361 • After successful reception of AFC1#0 Frame by the local RX, TC1_REPLAY_TIMER is stopped as
there are no unacknowledged Frames for TC1.
3362 • After successful reception of AFC0#1 Frame by the local RX, TC0_REPLAY_TIMER is stopped as
there are no unacknowledged Frames for TC0.
Replay Timers
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
SOF EOF
CRC
TC0 SOF
#1
TC0
SOF #1
TC1 SOF
#0
TC1
EOF #0
CRC
COF EOF
CRC
TC0 COF
#1 AFC
TC0
EOF #1 TC1 AFC
CRC #0
EOF TC1
CRC CRC #0
No unacknowledged frames
in the TC1 TX buffer so the CRC
TC1_REPLAY_TIMER is
stopped.
AFC
TC0 AFC
#1
TC0
CRC #1
No unacknowledged frames
in the TC0 TX buffer so the CRC
TC0_REPLAY_TIMER is
stopped.
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
3369 • The local RX detects AFC0#1 Frame and stops the TC0_REPLAY_TIMER as there are no pending
acknowledgments.
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
SOF EOF
CRC
TC0 SOF
#1 Bit error, Frame #1 is
TC0
EOF #1 discarded
CRC
EOF
CRC
AFC
TC0 AFC
#0
TC0
CRC #0
CRC
NAC
NAC
CRC
CRC
AFC
AFC transmission for TC0_REPLAY_TIMER is
prior TC1 transmission TC1 AFC stopped on the receipt of
#31
TC1 the NAC frame.
CRC #31
AFC
AFC transmission for CRC
prior TC0 transmission TC0 AFC
#31
TC0
CRC #31
SOF
CRC
TC0 SOF
#1
TC0
EOF #1
CRC
EOF
CRC
AFC
TC0 AFC
No unacknowledged frames #1
in the TC0 TX buffer so the TC0
TC0_REPLAY_TIMER is CRC #1
stopped.
CRC
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
3370 Figure 108 shows a scenario with two Traffic Classes, and depicts the case when a NAC Frame is received by
the local RX due to bad Frame reception by the remote RX while the local TX is sending a Data Frame on the
forward Link.
3371 • The local TX sends TC0 Frame#0, Frame#1, Frame#2 and Frame#3. TC0_REPLAY_TIMER is reset
and started after finalization of each Frame
3372 • The remote RX receives Frame#0 in good condition, and Frame#1 with an error (detected during CRC
checking). It schedules the transmission of the AFC#1 Frame and a NAC Frame with the RReq bit not set
and discards all TC0 Data Frames until it receives TC0 Frame#1 error free.
3373 • The reception of NAC Frame by the local RX stops the TC0 Frame #3 transmission (without concluding
the current Frame).
3374 • Local TX transmits AFC Frames for TC1 and TC0 and starts retransmission of all unacknowledged Data
Frames in the priority order. In this illustration only TC0 traffic is depicted, hence it starts sending TC0
Frames from the oldest unacknowledged Frame (TC0 Frame#1) to the latest Frame (TC0 Frame#3)
available in buffer.
3375 • Remote RX receives the AFC1 Frame in good condition and activates the NAC Frame generation. See
Section 6.6.11 for more details.
3376 • Remote RX receives TC0 Frame#2 and TC0 Frame#3 in good condition and sends an acknowledgment
with AFC0#3 Frame.
3377 • The local RX detects the AFC0#3 Frame and stops the TC0_REPLAY_TIMER as there are no pending
acknowledgments.
SOF
TC0 SOF
#0
TC0
EOF #0
CRC
SOF EOF
CRC
TC0 SOF
#1 Bit error, Frame #1
TC0
EOF #1 is discarded
CRC
EOF
CRC
AFC
SOF
The Remote RX is TC0 AFC
TC0 SOF expecting Frame #1 #0
#2 to be retransmitted TC0
TC0 CRC #0
so Frame #2 is
EOF #2
CRC discarded. CRC
The current frame
EOF NAC
transmission is CRC
stopped. NAC
AFC for TC1 and TC0
is transmitted.
SOF Any unacknowledged CRC
frames are
retransmitted. SOF CRC
AFC
TC0 AFC
No unacknowledged frames #3
in the TC0 TX buffer so the TC0
TC0_REPLAY_TIMER is CRC #3
stopped.
CRC
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
Figure 108 Retransmission Triggered by NAC Frame while Stopping Current Frame
3378 Figure 109 depicts the case where retransmission is triggered by expiration of TC0_REPLAY_TIMER.
3379 • After sending TC0 Frame#16 the TC0_REPLAY_TIMER is reset and started waiting for an AFC0
Frame from remote TX by the local RX.
3380 • The remote RX could not detect an EOF_EVEN or EOF_ODD symbol and CRC symbol, so it did not
send an AFC0 Frame.
3381 • The local TX TC0_REPLAY_TIMER expires.
3382 • The local TX triggers PHY initialization (not shown in the figure).
3383 • The local TX transmits NAC Frame with the RReq bit set.
3384 • The local TX starts transmission first with the AFC Frames for TC1 and TC0 and then retransmits TC0
Frame#16 as there are no unacknowledged TC1 Data Frames.
3385 • The remote TX triggers PHY initialization (not shown in the figure) after receiving NAC Frame with the
RReq bit set.
3386 • The remote TX transmits AFC Frames for TC1 and TC0. It has no unacknowledged Data Frames for
TC1 and TC0 to send.
3387 • The remote RX receives Frame#16.
AFC
TC0 AFC
#15
TC0
CRC #15
CRC
SOF
TC0 SOF
#16
TC0
EOF #16 Frame end is
CRC not detected
XXX
CRC
NAC
NAC
RReq
RReq
CRC
AFC
AFC transmission for CRC
prior TC1 transmission TC1 AFC
#31
TC1 AFC
CRC #31 AFC transmission due
AFC to NAC reception TC1 AFC
AFC transmission for CRC #31
prior TC0 transmission TC0 AFC TC1
#31 CRC #31
TC0 AFC
CRC #31 AFC transmission due CRC
SOF to NAC reception TC0 AFC
CRC #15
Retransmission of all TC0 SOF TC0
frames that have not #16 CRC #15
been acknowledged TC0
EOF #16 CRC
CRC
EOF
CRC
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
3388 Figure 110 depicts the scenario where the retransmission is caused by a wrong Frame Sequence Number.
3389 • The local TX transmits TC0 Data Frames starting from Frame #16. An acknowledgment is received for
all Frames up to Frame#15 (sending of these Frames are not shown in the figure) that stops
TC0_REPLAY_TIMER before Frame#16 is transmitted.
3390 • The remote RX detects Frame#16 and Frame#18 but could not detect Frame#17. It recognizes the wrong
Frame Sequence Number when it received Frame#18 (while Frame#17 was expected).
3391 • The remote RX discards all TC0 Data Frames from Frame#18 until it receives TC0 Frame#17 and
remote TX sends an AFC0#16 Frame and a NAC Frame with the RReq bit not set.
3392 • The local RX receives the AFC0#16 and the NAC Frame, transmits AFC Frames for TC1 and TC0 then
starts retransmission of TC0 Frame#17 and the Frames that follow it (not shown in the figure).
AFC
TC0 AFC
#15
TC0
CRC #15
CRC
SOF
TC0 SOF
#16
TC0
EOF #16
CRC
SOF EOF SOF and/or EOF
CRC not detected
TC0 XXX
#17
TC0
Frame with
EOF #XX
CRC unexpected frame
SOF XXX number is received.
CRC
TC0 SOF This frame and all
#18 following frames are
TC0 discarded until a
EOF #18 frame with the
CRC expected frame
SOF EOF number is received.
CRC
TC0 SOF For indication to AFC
#19 Local a NAC frame
TC0 transmission is TC0 AFC
EOF #19 #16
triggered.
CRC TC0
EOF CRC #16
CRC NAC
CRC
NAC
CRC
CRC
AFC
TC1 AFC
#31
TC1
CRC #31
AFC
CRC
TC0 AFC
#31
TC0
CRC #31
SOF
CRC
TC0 SOF
#17
TC0
EOF #17
CRC
EOF
CRC
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
3393 Figure 111 depicts the scenario where NAC Frame transmission is triggered due to errors in AFC reception.
3394 • The local TX starts sending TC0 Frame#1. TC0 Frame#1 is preempted by TC1 Frame#0 while the
former was in transmission.
3395 • After transmitting TC1 Frame#0 completely, TC1_REPLAY_TIMER is reset and started and the local
TX continues with sending TC0 Frame#1 from its preempted position and then TC0 Frame#2.
3396 • Meanwhile, the remote RX receives TC1 Frame#0 and remote TX sends acknowledgment for it with the
AFC1#0 Frame.
3397 • The local RX detects this AFC1#0 Frame in error. Then the local TX sends a NAC Frame (RReq bit not
set). The NAC Frame preempts TC0 Frame#2. After the NAC Frame is sent, the transmission of TC0
Frame#2 is continued from its preempted position.
3398 • The remote RX detects the NAC Frame and remote TX transmits only the AFC1#0 and AFC0#1 Frames.
There is no Data Frame retransmission from remote TX because there are no outstanding Frames at the
remote TX.
3399 • With the reception of the AFC1#0 Frame, the TC1_REPLAY_TIMER is stopped as there are no
unacknowledged Frames in the buffer. The reception of the AFC0#3 Frame (acknowledgment for TC0
Frame#3) stops the TC0_REPLAY_TIMER. The illustration also shows resetting and running of
TC0_REPLAY_TIMER after sending each TC0 Frame.
Replay Timers
SOF
TC0 SOF
#1
TC0
SOF #1
TC1 SOF
#0
TC1
EOF #0
CRC
COF EOF
CRC
TC0 COF
#1
TC0 AFC
EOF #1
CRC TC1 AFC
SOF EOF #0 Bit error, AFC1
CRC Frame is discarded TC1
SOF CRC #0
TC0
CRC
TC0
NAC
NAC
CRC
COF
CRC
TC0 COF
#2 AFC
TC0
EOF #2 TC1 AFC
CRC #0
SOF EOF TC1
CRC CRC #0
TC0 SOF AFC
#3 CRC
TC0 TC0 AFC
EOF #3 #1
CRC TC0
EOF CRC #1
CRC
CRC
No unacknowledged frames
in the TC1 TX buffer so the
TC1_REPLAY_TIMER is
stopped.
AFC
TC0 AFC
#3
TC0
CRC #3
CRC
TC0_REPLAY_TIMER is
stopped on the receipt of
the AFC frame.
Timer Reset
Legend Timer Stopped Timer Running Timer Expired
and Running
10 Mbps Link
10 Mbps Link
10 Mbps Link
Figure 114 Forward Link Use Case with Preemption – Start of Preemption
10 Mbps Link
Figure 115 Forward Link Use Case with Preemption – End of Preemption
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission blocked
3405 The behavior of the use case is described here without preemption. Figure 117 shows that TC0 Frame is
started on reverse Link just before the completion of the TC1 data on forward Link. The received TC1 data is
consumed by the upper layer and the buffer is empty now. AFC1 Frame cannot be sent immediately as TC0
occupies the reverse Link. In Figure 117 the TC1 buffer at the receiver is empty and it is not yet
communicated to the sender side. The sender has new TC1 data to send. It cannot be sent due to the
undelivered AFC1 Frame from receiver side. This results in an IDLE state of the forward Link. After
completion of TC0, the AFC1 Frame is transmitted on the reverse Link (see Figure 118). After the reception
of the flow control the forward Link is able to transmit new TCx Data Frame on the forward Link.
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission blocked
Figure 117 Reverse Link Use Case without Preemption – AFC1 is Blocked
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission blocked
Figure 118 Reverse Link Use Case without Preemption – TC1 Data is Blocked
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission blocked
Figure 119 Reverse Link Use Case without Preemption – AFC1 Transmission
3406 With preemption the behavior is different. As the AFC1 is higher priority than the TC0, the AFC1 preempts
immediately the ongoing TC0 transmission (see Figure 120). The sender can serve TC1 Data Frame
transmission after the AFC1 is received (see Figure 121). The preempted Frame is continued after the AFC
Frame transmission is finalized. IDLE time of the forward Link is reduced to a minimum.
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission pre-empted
Figure 120 Reverse Link Use Case with Preemption – AFC1 Transmission
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission pre-empted
Figure 121 Reverse Link Use Case with Preemption – AFC1 Reception
1 Gbps Link
10 Mbps Link
TC0
TC1
Transmission pre-empted
Figure 122 Reverse Link Use Case with Preemption – End of Preemption
CRC
Register
(X15 .. X0)
Device A Device B
Layer n+1 Layer n Layer n Layer n+1
.req
.ind
.rsp
.cnf
Device A Device B
Layer n+1 Layer n Layer n Layer n+1
.req
.cnf .ind
.rsp
.rsp
.cnf
3416 The following additional Service Primitives are introduced to avoid this ambiguity:
3417 • The Local Confirm (.cnf_L) Service Primitive is issued following a Request Service Primitive directed
at the local Device. Typically, a new Request Service Primitive cannot be issued before reception of a
Local Confirm Service Primitive, thus regulating the rate of Messages sent between the Service User and
local Service Provider.
3418 • The Local Response (.rsp_L) Service Primitive is issued following an Indication Service Primitive that
was directed at the local Device. Typically, a new Indication Service Primitive cannot be issued before
reception of a Local Response Service Primitive, thus regulating the rate of Messages sent between the
Service User and local Service Provider.
3419 With the addition of these two new Service Primitives, the relationships between Service Primitives are
modified as shown in Figure 126. The Response (.rsp) and Confirm (.cnf) Service Primitives are now
reserved for Messages that result in a Message sent to a peer Device.
Device A Device B
Layer n+1 Layer n Layer n Layer n+1
.req
.cnf_L .ind
.rsp_L
.rsp
.cnf
t_tx_valid
t_tx_accept
t_tx_cportid
t_tx_data
T_CO_DATA.req
t_tx_byte_en
t_tx_eom
t_rx_valid
t_rx_accept
t_rx_cportid
T_CO_DATA.ind t_rx_data
t_rx_byte_en
t_rx_eom
t_rx_msg_status
t_fc_valid
t_fc_accept
t_fc_cportid
T_CO_FLOWCONTROL.req
t_fc_credits
t_fc_credits_accepted
t_txsa_cport_status
Tx Status/Arbitration t_txsa_fc_for_maxsegment
t_txsa_end_segment
3429 The CPort signal interface is a synchronous interface. All signals of the CPort signal interface are
synchronous to the rising edge of t_clk.
3430 The T_CO_DATA.req, T_CO_DATA.ind and T_CO_FLOWCONTROL.req reflect the UniPro T_CO_SAP.
3431 The CPort signal interface multiplexes the CPort data transfers to prevent a signal explosion, and because
data is serialized anyway by the UniPro stack. This multiplexing requires the UniPro stack to assist the
external TX CPort arbiter. These signals are grouped in the TX Status/Arbitration signal group. There is no
need for similar arbitration signals at the RX side, as the data is already serialized before being transferred
over the UniPro Link.
3432 All of the previous options are particular design choices, which lead to this particular CPort signal interface
design. Other choices are obviously possible. Moreover, signals can be added or removed as needed.
3433 A detailed description of all the CPort interface signals is shown in Table 126.
T_CO_DATA.req Group
Transmitter valid.
When '1', this signal indicates that t_tx_cportid, t_tx_data, t_tx_byte_en and t_tx_eom are valid and
t_tx_valid Application
will remain valid until they are accepted by the CPort by setting t_tx_accept to '1'. The data is
MIPI Alliance Member Confidential
This signal indicates the CPort ID to which the data is destined. This signal is sampled when
t_tx_valid is '1', and is driven with each data element. The signal width depends on the number of
t_tx_cportid[C:0] Application
CPorts in the UniPro stack, e.g., C=3 if 16 CPorts are implemented. Changing the t_tx_cportid value
creates a Message fragment boundary, and results in a new Packet being created by the UniPro
stack.
Receiver valid.
When '1', this signal indicates that t_rx_cportid, t_rx_data, t_rx_byte_en and t_rx_eom are valid and
t_rx_valid CPort
will remain valid until they are accepted by the Application by setting t_rx_accept to '1'. The data is
transferred when t_rx_valid and t_rx_accept are both '1'.
MIPI Alliance Member Confidential
Receiver accept.
t_rx_accept Application When '1', this signal indicates that the Application is ready to accept data. The Application is allowed
to set t_rx_accept to '1' before t_rx_valid is set to '1'.
Receiver CPort ID.
This signal indicates the CPort ID from which the data is sent. This signal is sampled when t_rx_valid
346
t_rx_cportid[C:0] CPort
is '1', and is driven with each data element. The signal width depends on the number of CPorts in the
UniPro stack, e.g., C=3 if 16 CPorts are implemented.
Receiver data.
t_rx_data[N-1:0] CPort This signal width is a multiple of 8, and is implementation-specific. The byte transmission order is
t_rx_data[N-1:N-8] (MSB), t_rx_data[N-9:N-16], … t_rx_data[7:0] (LSB).
T_CO_FLOWCONTROL.req Group
Flow-control valid.
When '1', this signal indicates that t_fc_cportid and t_fc_credits are valid and will remain valid until
t_fc_valid Application
they are accepted by the CPort by setting t_fc_accept to '1'. The data is transferred when t_fc_valid
MIPI Alliance Member Confidential
t_fc_cportid[C:0] Application This signal indicates the CPort ID to which the credits are destined. The signal width depends on the
number of CPorts in the UniPro stack, e.g., C=3 if 16 CPorts are implemented.
Flow-control credits.
This signal indicates the amount credits for a CPort. The credits represent the free buffer space in
bytes which became available from the last time t_fc_credits was last asserted for the same CPort.
t_fc_credits[F:0] Application
is not connected (NO_CONNECTION). A value of b'11' indicates that the CPort is connected to a
Traffic Class which is not present in the adjacent UniPro node (NO_PEER_TC). The b'10' value is
reserved.
Credits for maximum Segment.
MIPI Alliance Member Confidential
t_txsa_fc_for_maxsegment[(P-1):0] CPort If the t_txsa_fc_for_maxsegment[i] signal is '1', the i-th CPort has enough end-to-end credits to send
a maximum Segment, otherwise the i-th CPort has less credits (P is the total number of CPorts).
End of Segment.
t_txsa_end_segment[(P-1):0] CPort The t_txsa_end_segment[i] signal is set to '1' for a single cycle every time Layer 4 introduces an end
of Segment.
348
t_clk
t_tx_valid
t_tx_accept
t_tx_eom
cycle 1 cycle 2 cycle 3 cycle N-1 cycle N cycle N+1 cycle N+2
3438 In Figure 129, a second transmitter data transfer is shown. In this case, the UniPro stack uses t_tx_accept to
stop the data transfer in cycle 3. A transmitter transfer can be delayed in this way when e.g., the core inserts a
header symbol. The rest of the transfer is similar to that in Figure 128.
t_clk
t_tx_valid
t_tx_accept
t_tx_data[23:16] D1 D5 D5 D9 Dn-3 X D1
t_tx_data[31:24] D0 D4 D4 D8 Dn-4 Dn D0
t_tx_eom
3439 In Figure 130, a receiver data transfer is shown, first on CPort 0 (cycles 1 through N), then CPort 1 (cycle
N+1 onwards) as indicated by t_rx_cportid. The data is transferred when both t_tx_valid and t_tx_accept are
‘1’. Thus, data is transferred in all cycles except cycle 2. In cycle N, and end-of-message is indicated by
setting t_rx_eom to ‘1’. In cycle N, only the two most significant two bytes of t_rx_data are enabled, as
indicated by the t_rx_byte_en value of b’1100’. The t_rx_msg_status value of ‘0’ indicates that the Message
is correctly received.
t_clk
t_rx_valid
t_rx_accept
t_rx_data[23:16] D1 D5 D5 D9 Dn-4 Dn D1
t_rx_eom
t_rx_msg_status
3440 In Figure 131, a flow control credit transfer is shown. The first flow control credit C0 is made available by the
Application to CPort 0 on cycle 1 by setting t_fc_valid to ‘1’. The credit is accepted in cycle 2 by setting
t_fc_accept to ‘1’. As a result, in the following cycle, the UniPro stack indicates that the credits have been
correctly processed by setting the t_fc_credits_accepted to the same credit value C0 as the value of
transferred credits.
3441 In cycles 3 and 4, the t_fc_valid is ‘0’, which means the t_fc_credits do not contain meaningful values. As
shown in cycle 4, the UniPro stack can set the t_fc_accept to ‘1’ indicating it can accept a new credit value
even if no credit is available.
3442 In cycles 5 and 6, new credit values C1 and C2 are transferred for CPorts 1 and 2, respectively. The credits are
acknowledged by t_fc_credits _accepted on cycle after the credit transfer, in cycles 6 and 7, respectively. It is
allowed to transfer credits on t_fc_credits, while acknowledging credits from the previous cycle on
t_fc_credits_accepted, as shown in cycle 6.
t_clk
t_fc_valid
t_fc_accept
t_fc_credits[F:0] C0 C0 X X C1 C2 X
t_fc_credits_accepted[F:0] X X C0 X X C1 C2
Test Test
CTRL - RX Features Features CTRL - RX
3451 Figure 133 gives an example of a external M-PHY configuration using the T-MPI interface. The UniPro stack
and the T-MPI interface are implemented onto the FPGA of the UniPro stack PCB. The PHY PCB has an M-
PHY device and an FPGA. The FPGA of the PHY PCB implements the T-MPI interface to the UniPro stack
PCB and a proprietary interface to the M-PHY.
Proprietary I/F
DATA - RX T-MPI
UniPro SERDES SERDES
Stack M-PHY
L1.5 to L4 CTRL - TX
FPGA FPGA
UniPro Stack PCB PHY PCB
3452 Such a configuration enables usage of M-PHY from several sources with different proprietary interfaces. In
this configuration the M-PHY DATA SAPs are mapped to the T-MPI interface, while the M-PHY CTRL
SAPs are mapped to the serial interface.
3453 T-MPI should use one SERDES Transceivers pair per supported M-PHY data Lane and a single serial
interface for the control of the M-PHY regardless of the number of supported data lanes.
Lane0 DATA-TX
Lane0 DATA-RX
1 Lane T-MPI
TTXP0
Lane0 Control LaneX DATA-TX TTXN0
TRXP0
LaneX DATA-RX TRXN0
Lane1 DATA-TX
TTXP1
TTXN1
Lane1 DATA-RX
Shadow ERROR Control
TRXP1
Lane1 Control TRXN1
Protocol Physical Effective Power Mode SerDes
lane re- TTXP2
Transceivers
numbering DM Register bank TTXN2
Lane2 DATA-TX
LaneX Control
OMC Emulation TRXP2
Capability
Lane2 DATA-RX TRXN2
Status TTXP3
Lane2 Control FSM Emulation
TTXN3
TRXP3
Lane3 DATA-TX TRXN3
T-MPI Control
Lane3 DATA-RX
3470 Four instance of the T-MPI lane shall be used regardless on the number of supported data lanes by the
protocol. Each data lane of the protocol shall be connected to the T-MPI lane through a physical lane
renumbering module. The physical lane renumbering module just multiplexes logical lanes on protocol side
to physical lanes on T-MPI side. The control for the lane multiplexing is provided by T-MPI control
Attributes.
3471 M-TX-DATA SAP and M-RX-DATA SAP are transferred directly to and from the SERDES transceivers
respectively. Depending on the status of various test features additional control and status information are
sent and received by the SERDES.
3472 The DM Register bank refers to Dummy M-PHY Register bank. It contains all M-PHY related capability,
control and status Attributes including effective and shadow registers. This is necessary for the verification of
correct usage of the M-TX-CTRL and M-RX-CTRL SAPs.
3473 Since the SERDES operates at a fixed data rate, a Power Mode test feature is introduced in the T-MPI. The
Power Mode test feature is used to insert M-PHY power mode parameters at the beginning of each burst on
SERDES-TX according to the status of the effective configuration registers of the M-TX. On the SERDES-
RX side, the Power Mode parameters are extracted and checked against the expected power mode setting of
the effective configuration registers of the M-RX. In case of mismatch between the received power mode
parameters and the power mode setting of the M-RX an error is reported to the ERROR control module. This
is necessary for the verification of the PACP protocol in the PA Layer.
3474 The OMC Emulation test feature is used for checking proper handling of OMC capability checking and OMC
configuration during the power mode change procedure of the PA Layer. The OMC emulation module
controls sending of LCC commands over the SERDES-TX side and detects LCC commands on the SERDES-
RX side.
3475 FSM Emulation test feature is optional. It may be used to track the Dummy M-TX and M-RX state machines.
3476 The T-MPI control block contains all T-MPI related Attributes and controls the SERDES operations.
Lane0 DATA-TX
Lane2 Control
3478 For each supported data lane, the Dummy M-PHY shall have one instance of a T-MPI lane. A T-MPI lane
should have a single SERDES transceivers instance. The M-TX-DATA and M-RX-DATA SAPs are directly
mapped to the SERDES transceivers. The M-TX-CTRL and M-RX-CTRL SAPs should be mapped to a
single instance of a Serial interface.
3479 The T-MPI control block contains all necessary T-MPI-related Attributes and controls the SERDES
operations.
3481 When using the T-MPI in case of protocol testing only, four T-MPI data lanes shall be supported and the T-
MPI Serial interface shall be left unconnected.
3482 When using the T-MPI in case of the borrow M-PHY the number of T-MPI lanes is implementation
dependent and the T-MPI serial interface should be supported.
does not check for undefined control symbols. The list of T-MPI control symbols given in Table 128 may be
extended.
3503 Table 130 gives the bit field description for the PwrMode data symbol. The PwrMode data symbol gives the
power mode setting of the transmitter side.
Hibernate_Contr EXIT 0
ol ENTER 1
Reserved 1 Fixed to 1
3505 The LCC-Cmd given in Table 131 shall be supported for protocol testing use-case. Those data symbols are
always followed by four payload data symbols.
DATA Byte H G F E D C B A
8B/10B
j h g f i e d c b a
RESET
TX_LCC_Sequencer != 0 M-CTRL-LINE-RESET.req
OMC IDLE LINE-RESET
M-LANE-PREPARE.req
BURST
RESET
LCFG LRST
OMC IDLE LINE-RESET
EoB
HoB
BURST
DATA
NFLR
ERR
BURST State
3520 The BURST state is entered from the IDLE state. Each T-MPI BURST sequence corresponds to a single M-
PHY BURST. A BURST sequence shall start with the HoB control symbol. In case of protocol testing the
HoB control symbol is followed by the PwrMode data symbol. The PwrMode data symbol is followed by a
sequence of M-PHY payload symbols. Each M-PHY payload symbols may contain data or control symbols
as defined by the M-PHY specification. The EoB control symbol is used to detect end of BURST sequence.
3521 The S-TX shall transmit a HoB control symbol upon reception of an M-LANE-PREPARE.req primitive. In
the case of protocol testing the HoB control symbol shall be followed by a PwrMode data symbol. For the
external M-PHY use case, the HoB control symbol shall be followed by either symbols coming from the
protocol or by NFLR control symbols.
3522 The S-TX shall transmit a data or a control symbol for each occurrence of the M-LANE-SYMBOL.req
primitive. If within a BURST the PA Layer has no M-PHY symbol to transmit, the S-TX shall insert an NFLR
control symbol. The S-TX shall transmit an ERR control symbol instead of the requested M-PHY symbol
under the control of the ERROR Control Test Feature block.
3523 The S-TX shall transmit an EoB control symbol upon detection of Burst completion (Falling edge of
TX_Burst signal) and return to the IDLE state.
3524 The S-RX shall generate an M-LANE-PREPARE.ind primitive upon reception of HoB control symbol. After
reception of the HoB control symbol the S-RX shall receive the PwrMode data symbol and pass it to the
Power Mode block for the purpose of verifying correctness of used power mode.
3525 The S-RX shall generate an M-LANE-SYMBOL.ind primitive upon reception of each symbol received
between the PwrMode data symbol and the EoB control symbol. The S-RX shall not generate M-LANE-
SYMBOL.ind primitive when receiving an NFLR control symbol. The S-RX shall report any detected
symbol errors using the M-LANE-SYMBOL.ind primitive with the RX_SymbolError signal set. Received
symbol errors are one of the following:
3526 • 3b4b sub-block coding error
3527 • 5b6b sub-block coding error
3528 • Reserved symbol error
DATA3
DATA2
DATA1
DATA0
OMC State
3536 The S-TX shall transit from the IDLE state to the OMC state when there is no M-LANE-PREAPRE.req
primitive set and when there is no M-CTRL-LINERESET.req primitive set and when TX_LCC_Enable is set
to TRUE and when any bit of TX_LCC_Sequencer is set.
3537 Once the S-TX has entered the OMC state it shall execute the following sequence:
3538 • Transmit a LCFG control symbol
3539 • Transmit an LCC-Cmd data symbol
3540 • Transmit an LCC payload of four data symbols (DATA3, DATA2, DATA1 and DATA0)
3541 • Clear the corresponding set bit in TX_LCC_Sequencer
3542 • Return to the IDLE state
3543 The S-TX shall assign the LCC-Cmd data symbol according to the status of the bits in TX_LCC_Sequencer
with the following priority:
3544 • If LCC-WRITE-ATTRIBUTE is set, then LCC-Cmd shall be LCC-WRITE-ATTRIBUTE
3545 • If LCC-READ-MFG-INFO is set, then LCC-Cmd shall be LCC-READ-MFG-INFO
3546 • If LCC-READ-VEND-INFO is set, then LCC-Cmd shall be LCC-READ-VEND-INFO
3547 • If LCC-READ-CAPABILITY is set, then LCC-Cmd shall be LCC-READ-CAPABILITY.
3548 The LCC payload data symbols to be sent by the S-TX are depending on the LCC-Cmd. Table 132 and
Table 133 specify how to set the DATA3, DATA2, DATA1 and DATA0 LCC payload data depending on the
current active LCC-Cmd.
3549 Note that “x” in Table 133 relates to the Lane number. For example, L1_OMC_READ_DATA3 is the
OMC_READ_DATA3 Attribute for Logical Lane 1.
3550 The S-RX shall transit from the IDLE state to the OMC state on detection of a LCFG control symbol. Once
the S-RX has entered the OMC state it shall execute the following sequence:
3551 • Reception of the LCFG control symbol
3552 • Reception of the LCC-Cmd data symbol
3553 • Reception of the LCC payload consisting of four data bytes (DATA3, DATA2, DATA1 and DATA0)
3554 • Store the received LCC payload into the appropriate OMC Status Attribute or to Lx_OMC_WO,
depending on the LCC-Cmd
3555 • Generate an LCCReadStatus.ind primitive after receiving LCC-READ-MFG-INFO, LCC-READ-
VEND-INFO and LCC-READ-CAPABILITY
3556 • Return to the IDLE state
3557 On a LCC-WRITE-ATTRIBUTE command, the DATA3 payload shall be stored in Lx_OMC_WO and
DATA2, DATA1 and DATA0 values may be ignored. Table 134 specifies the assignment of LCC Payload
data to the T-MPI Attributes.
3558 When the LCC-Cmd is LCC-READ-MFG-INFO or LCC-READ-VEND-INFO the LCC Payload data shall
be stored in the OMC Status Attributes as defined in Table 135.
3559 When the LCC-Cmd is LCC-READ-CAPABILITY the LCC Payload data shall be stored in the OMC Status
Attributes as defined in Table 136.
T1 T2 T3 T4 T5 T6 T7
Data
M-PHY
PREPARE SYNC MK0 MK1 B3 7F A5 5A A9 82 MK2 FLR EoB
TXDP/TXDN
TX_SymbolClk
TX_ProtDORDY[1:0] 11 00
TX_DataNCtrl[1:0] 00 11 00 00
TX_Symbol[15:8] 02 7F 5A 82 80 00
TX_Symbol[7:0] 01 B3 A5 A9 04 00
TX_PhyDIRDY
TX_Burst
T-MPI
NFLR HoB PwrM MK0 MK1 B3 7F A5 5A A9 82 MK2 FLR EoB NFLR NFLR
TXDP/TXDN
3562 In this example, the PA Layer interface to the M-PHY is two M-PHY symbols wide. Therefore on each
TX_SymbolClk two M-PHY symbols are transmitted.
3563 At T1 the PA Layer asserts the TX_Burst signal to indicate beginning of a TX burst. This corresponds to the
M-LANE-PREAPRE.req primitive. At the same time the MK0 and MK1 control symbols are put on the
TX_Symbol bus and the TX_DataNCtrl signal is set to 0b00 to indicates that the symbols are control
symbols.
3564 At T2 an M-PHY would transit to the PREPARE state.
3565 At T3 an M-PHY would transit to the SYNC state. At T3 the S-TX transit into the BURST state and start to
transmit the HoB control symbol followed by the PwrMode data symbol. At the same time the
TX_PhyDIRDY signal is asserted to indicate that the S-TX has accepted the MK0, MK1 control symbols.
The assertion of TX_PhyDIRDY corresponds to the M-LANE-SYMBOL.cnf_L primitive.
3566 At T4 the S-TX starts to transmit exactly the same symbol sequence as would the M-PHY transmit in a
BURST. The T-MPI just passes the symbols provided by the PA Layer without interpreting them.
3567 At T5 the PA Layer requests the transmission of a MK2 symbol followed by a FLR symbol to indicate end of
burst. Then at T6 the PA Layer de-asserts the TX_Burst signal to indicate end of burst. The T-MPI does not
check the MK2 symbol to detecting end of burst, but is rather checking the status of the TX_Burst signal.
3568 At T7 the TX_Burst signal is sampled as inactive, therefore the T-MPI issue an EoB control symbol to
terminate the S-TX BURST state. The EoB control symbol is followed by an NFLR control symbol, which
indicates that the S-TX is in the IDLE state.
T1 T2 T3 T4 T5 T6 T7
Data D.E.
T-MPI
NFLR HoB PwrM MK0 MK1 B3 7F C4 FLR A9 82 E4 MK2 EoB NFLR NFLR
RXDP/RXDN
RX_SymbolClk
RX_PhyDORDY[1:0] 00 11 11 11 11 11 00
RX_DataNCtrl[1:0] 00 11 00 10 00 10 00
RX_Symbol[15:8] 00 02 7F 80 82 04 00
RX_Symbol[7:0] 00 01 B3 C4 A9 E4 00
RX_SymbolErr[1:0] 00 00 00 00 10 00 00
RX_Burst
3570 Also in this example the interface between the PA Layer and the PHY is two PHY symbols wide. Therefore at
each RX_SymbolClk two PHY symbols are received.
3571 At T1 the S-RX FSM is still in the IDLE state receiving NFLR control symbols.
3572 At T2 the S-RX has detected the reception of the HoB control symbol followed by a PwrMode data symbol.
The detection of the HoB control symbol causes the transition to the BURST state and the T-MPI asserts the
RX_Burst signal. The assertion of the RX_Burst signal corresponds to the M-LANE-PREPARE.ind
primitive.
3573 From T3 to T6 the S-RX just passes the received symbols to the PA Layer using the RX_Symbol bus and the
RX_DataNCtrl signal to qualify if the symbol is a data or control symbol.
3574 At T5 the S-RX detects a running disparity error for symbol 0x82, therefore the corresponding
RX_SymbolErr is set.
3575 At T7 the S-RX has detected the EoB control symbol and is therefore de-asserting the RX_Burst signal to
indicate a M-LANE-BurstEnd.ind primitive.
E.7.1 Transceivers
3577 Recommended transceivers from Xilinx are GTX transceivers. Those transceivers are also called CML
transceivers.
3578 Recommended transceivers from Altera are GX transceivers. Those transceivers are also called PCML
transceivers.
50 50
ohm ohm
50 ohm
+ +
- -
50 ohm
~100 nF 7 pF
Differential input
termination
configure the Capability Attributes of the M-PHY is essential for testing downgrading features of the PA
Layer.
3615 Table 137 gives the list of the M-TX Capability Attributes and defines for each Attribute:
3616 • Attribute ID: Attribute Address used in Get and Set commands.
3617 • Attribute Name: Symbolic Attribute name (as defined in [MIPI05]).
3618 • Access: access method to the Attribute. R: Read Only; RW: Read/Write; W: Write Only.
3619 • Default Value: value of the Attribute at reset.
3620 • Mandatory: Y: This Attribute shall be implemented in the Dummy M-PHY MODULE; N: support for
this Attribute is optional.
3621 • Control: Specifies the T-MPI Attribute that is used to control this M-PHY Attribute.
3622 • Shadow Required: Y: Requires a shadow register; N: Does not require a shadow register
3623 Table 138 gives the list of the M-RX Attributes and defines for each Attribute if it is implemented in the
Dummy M-PHY MODULE or if support for such an Attribute is optional.
3624 When the M-CTRL-CFGGET.req(MIBvalue) primitive is issued, the Capability Attribute value with the
MIBvalue=Attribute ID shall be returned by the Dummy M-PHY MODULE using the M-CTRL-
CFGGET.cnf_L primitive.
3630 Table 139 gives the list of the M-TX Configuration Attributes and defines for each Attribute if it shall be
implemented in the Dummy M-PHY MODULE or if it is optional. Furthermore, it specifies for each
Attribute if it shall support a shadow register. The Control column gives an indication of which feature of the
M-PHY MODULE is used to control the Attribute, or is controlled by the Attribute.
3631 Table 140 gives the list of the M-RX Configuration Attributes and defines for each Attribute if it shall be
implemented in the Dummy M-PHY or if it is optional. Furthermore, it specifies for each Attribute if it shall
support a shadow register. The Control column gives indication about which feature of the M-PHY is used to
control the Attribute or is controlled by the Attribute.
3637 Table 142 gives the list of write-only OMC Attributes supported by the Dummy M-PHY MODULE. The
Control column entry specifies the Attribute that is used for reading the write-only OMC Attribute.
3642 Table 144 gives the T-MPI Attributes list for Lane 1.
3643 Table 145 gives the T-MPI Attributes list for Lane 2.
3644 Table 146 gives the T-MPI Attributes list for Lane 3.
3645 Table 147 gives the list of T-MPI Attributes used to control the Serial Interface used for communication with
the external M-PHY as in the External M-PHY use case. In case of protocol testing those Attributes are not
mandatory.
3646 Table 149 gives the list of the T-MPI Power Mode Error Control and Status Attributes.
Table 149 T-MPI Power Mode Error Control and Status Attributes
Attribute Default
Attribute Name Access Mandatory Control
ID Value
0x0180 PWRMODE_MODE_ERR R 0x00 Y
0x0181 PWRMODE_SERIE_ERR R 0x00 Y
0x0182 PWRMODE_GEAR_ERR R 0x00 Y
PWRMODE_HIBERNATE_ Power Mode Test Feature
0x0183 R 0x00 Y
ERR
PWRMODE_TERMINATIO
0x0184 R 0x00 Y
N_ERR
0x0185 PWRMODE_CTRL W 0x00 Y
3649 Table 151 gives the detailed description of TX_OptCapability1 mapping to M-PHY Attributes.
3650 Table 152 gives the detailed description of TX_OptCapability2 mapping to M-PHY Attributes.
3651 Table 153 gives the detailed description of TX_OptCapability3 mapping to M-PHY Attributes.
3652 Table 154 gives the detailed description of OMC_WO mapping to M-PHY Attributes.
3654 Table 156 gives the detailed description of RX_OptCapability1 mapping to M-PHY Attributes.
3655 Table 157 gives the detailed description of RX_OptCapability2 mapping to M-PHY Attributes.
3656 Table 158 gives the detailed description of RX_OptCapability3 mapping to M-PHY Attributes
3657 Table 159 gives the detailed description of RX_OptCapability4 mapping to M-PHY Attributes.
3658 Table 160 gives the detailed description of RX_OptCapability5 mapping to M-PHY Attributes.
3668 The receiver shall compare the value of the GEAR field in the PwrMode data symbol to the RX_HSGEAR or
the RX_PWMGEAR Attributes when the MODE field is set to HS_MODE or to LS_MODE respectively. In
case of mismatch the PWRMODE_GEAR_ERR counter shall be incremented.
3669 The receiver shall compare the value of the Termination field in the PwrMode data symbol to
RX_HS_Unterminated_Enable or RX_LS_Terminated_Enable when the MODE field is set to HS_MODE or
to LS_MODE, respectively. In case of mismatch, the PWRMODE_TERMINATION_ERR counter shall be
incremented.
3670 The receiver shall compare the value of the Hibernate_Control field in the PwrMode Data symbol to
RX_Enter_HIBERN8. In case of mismatch, the PWRMODE_HIBERNATE_ERR counter shall be
incremented.
3685 Table 162 gives the setting of RX_FSM_State depending on the SERDES RX FSM State and the M-RX
RX_MODE and RX_Enter_HIBERN8 Attributes.
3688 Lane re-numbering is controlled by the MAP_x Attributes of the T-MPI as described in Table 163. This
description applies to MAP_RX_LANE0, MAP_RX_LANE1, MAP_RX_LANE2, MAP_RX_LANE3,
MAP_TX_LANE0, MAP_TX_LANE_LANE1, MAP_TX_LANE2 and MAP_TX_LANE3.
3707 Note that TC1 is intended for low-latency, low-bandwidth traffic. This could be restricted and enforced by
Switches to use, at maximum, a certain percentage of a UniPro Link. The percentage could be a system level
configurable parameter. Therefore, to ensure compatibility with future networks, Applications needing high
bandwidth for certain traffic are advised to use TC0 for such traffic.
Participants
The following list includes those persons who participated in the Working Group that developed this
specification and who consented to appear on this list.