3-Jun-2011

MIPI® Alliance Specification for Unified Protocol (UniProSM) Version 1.40.00 – 31 January 2011
MIPI Board Approved 28-Apr-2011

* 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/mipiadopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v00-80-00.pdf. Intel's licensing objection is available at https://members.mipi.org/mipiadopters/file/Specifications/Board%20Approved/MIPI%20UniPro%20Specification_v00-8000_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/mipiadopters/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

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential

Version 1.40.00 3-Jun-2011

MIPI Alliance Specification for UniPro

obligation for any subsequently adopted Specifications, Intel's prior License Objection stands and applies to this latest Draft. The “latest Draft” referred to in the advice of Intel is UniPro v1.00.00, originally drafted by the UniPro Working Group as UniPro v0.90.00 and later renumbered to UniPro v1.00.00 during subsequent approval by the MIPI Board as a MIPI Specification. MIPI has no view as to the accuracy or validity of the statement made by Intel. ALL MIPI MEMBERS AND ANY OTHER INTERESTED PARTIES ARE ADVISED THAT MIPI TAKES NO POSITION WITH REFERENCE TO, AND DISCLAIMS ANY OBLIGATION TO INVESTIGATE OR INQUIRE INTO, THE SCOPE OR VALIDITY OF ANY LICENSE OBJECTION OR CL AIM OR ASSERTION OF NECESSARY CLAIMS (AS DEFINED IN THE MIPI MEMBERSHIP AGREEMENT) WITH RESPECT TO UNIPRO V0.90.00 AND THE APPLICABILITY OF THE LICENSE OBJECTION OF INTEL TO UNIPRO V0.90.00.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 2

3-Jun-2011

MIPI® Alliance Specification for Unified Protocol (UniProSM) Version 1.40.00 – 31 January 2011
MIPI Board Approved 28-Apr-2011

* 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

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential

Version 1.40.00 3-Jun-2011

MIPI Alliance Specification for UniPro

working group member company feedback. This release adds support for the option of disabling the CSV feature of the Transport Layer (L4).

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 2

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

MIPI® Alliance Specification for Unified Protocol (UniProSM)

Version 1.40.00 – 31 January 2011
MIPI Board Approved 28-Apr-2011

Further technical changes to this document are expected as work continues in the UniPro Working Group

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential ii

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Release History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2

Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 2.2 2.3 2.4

3 4

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Architecture Overview (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.6 4.7 4.7.1 4.7.2 4.7.3 4.7.4 4.7.5 4.7.6 4.7.7 4.8 4.8.1 4.8.2 4.8.3 4.8.4 4.8.5 UniPro Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 The UniPro SDL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Comparison of UniPro to the OSI/RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Service Access Points (SAP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 SAP Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Data Flow through the Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Signal Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 CPort Signal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Interface to the Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 T-PPI Interface for Testing (D-PHY oriented). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 T-MPI Interface for Testing (M-PHY oriented). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Protocol Data Units (PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Physical Layer (L1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 D-PHY and M-PHY Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 L1 Symbol Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 D-PHY Data Rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 M-PHY Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 D-PHY Power States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 M-PHY Power States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 L1 Idles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 PHY Adapter Layer (L1.5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 L1.5 Multi-lane Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 L1.5 Power States and Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 L1.5 and Symbol Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 PACP Frames as Used with M-PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 L1.5 Automatic Capability Discovery (M-PHY only) . . . . . . . . . . . . . . . . . . . . . . . 45
Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential iii

. . . . . . . . . . . . . . . . .7 Test Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4. . . . . . . . . . . . . . . 56 Control Primitives . . . . . . .1 5. . . . . . . .6 CSD/CSV Mechanisms within a CPort . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . . . . . . . . . .4 The L4 SAP and Messages . . . . . . . . . . . . .7. .3 5. . 87 UniPro Link Management . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . .5.4 5. . . .1 5. . .2 UniPro Networks . . . . . . 90 PHY Adapter to D-PHY Interaction . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . .12. . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 5. . . . . . . . . . . . . . . . . . . . . . . .2 5. . . . 53 5 PHY Adapter Layer (L1. . . . . . . . . . . . . . . . . . . 51 4. . . . . . . . . .6. . . . .11. 56 PA_SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . 51 4. . . . 56 Data Transfer Primitives . . . . . . . . . . . . . . . 47 4. . . . . . . 48 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . . . . . . . . . . . . . . . . . 49 4. . . . . . . . . . . . . . . . . . . . . . . .2 5. . . . . . . . . . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4. . . . .3 Communicating between L4 CPorts . . . . . . . . . . . . . . . . . . . .3 L2 Retransmission on Errors . . . . . . . . . . . . . . . . . 49 4. . . . . . . . . . . . . . . . . . 87 Lane Distribution and Merging . . . . . . . . . . . . . . . .7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro 4. . . . . . . . . 74 Status Primitives (PA D-PHY only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . .13 Supported Topologies . . . . . . . . . . . . . . . . . . . . .10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 L3 Packets . 46 4. . . . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Transport Layer (L4) . . . . . . . . . . . . 50 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . . . . . .5 End-to-End Flow Control in L4. . . . . 91 Power Mode Change Procedure . . . . . . . . . . . . . . . 89 Link Startup Sequence . . . . . . . . . . . . . . . . . . . . . . 94 Link Startup Sequence . . . . . . . . . . . . . . . 95 Symbol Mapping . . . 99 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . .1 L2 Data Frames . . . .4. . . . . . . . . . . . . . . . . . . . .3. . . . . 46 4. . . . . . . . . . . . . . . . .1 Point-to-Point Links. . . . . . . . . . .2 5. . . . . . 51 4. . . . . . . . . . . . 52 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Structure and Encoding of Protocol Data Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13. . . . . . . . . . . . . . . 45 4.2 5. .4. . . . . . . . . . . . . . .12. . . . . . . . .5 L2 Traffic Classes and Priorities . . . . . . 52 4. . . . . . . . . . . .2 5. . . .5 5.1 Control Attributes . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Configuration Primitives . . . . . .1 5. . . . . . . . . . . . . . . . . .13. . . . . .2 Control Interfaces . . . . . . . 63 PA_LM_SAP. . . . .2 L2 Control Frames. . . . . . . . . .6 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4. . . . . . . . . . . . . . . . . . . . . . . . . . . .10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 5. . . . . 55 5.5) . . . . . . . . . .11. . . . . . . . . . . . . . . . . 51 4. . . . . . . . . . . . . . . . . . 49 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Data Link Layer (L2) . . . . . . . . . . . . . . . . . . . . . . . 50 4. . . . . . . . . . . . . . . . 94 PHY States with Data Transmission . 86 Protocol Features. . . . . . . . 48 4. . .4 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 L2 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . .5 PHY Adapter Layer Service Functionality and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential iv . . . . . . . . . . . .2 L4 Segments . . . . . . . . . . . . . . . . . . .1 5. . . . . .11. . . . . . . . . . . . . .9. . . . . . . . . . . . 55 Features Assumed from the PHY Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Escaped Data PA_PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Data PA_PDU . . . . . . . .1 5. . . . . . . . . . . . . . . . . . . . . . . . . . .11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4. .11. . . . . . . . . 92 Lane Number Change Procedure.2 L3 Devices and DeviceIDs . . . . . . . 65 Control Primitives . . . . . . . . . .1 L4 Connections . . . . . . . .3 5. . . . . . . . . . . . . .7. . . . . . . . . . . . . . . .10 Network Layer (L3). . . . . . . . . . . . . . . . . . . . . . .1 5. . . . . . . . . .12 DME . . . . . . . . . . . . . . . . . . . . . . . .3 5. . .11. . .9. . . . . . . . .11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Status Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . .3 5. .

. . . . . . . . . . . . . . . . . 163 Control Symbol . . . . . . .6 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . .8. . . . . . . . . . . . . . 107 5. . . . . . . . . . . . . . 106 5. . . . . . . . . . . . . . . . . . . . . .7 PA Control Protocol (PACP) . . . . . . .2 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . 121 5. 116 5. . . . . . . . . . . . . . . . . . . . . .9 (Re-)Initialization . . . . . . . . . .6 Power State Mapping.1 6. . . . . . . . . . . . . 108 5. . . . . . . . . . . . 101 5. . . 163 Data Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . .3 Symbol Mapping . . . . . . . . . . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 6. . . . . . . . . .13 PA Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Link Configuration Procedure . . . 171 Arbitration Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 5. . . . . . . . . .15 PHY Testing. . . 147 Data Transfer Primitives . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . .40. . . . . .8. . . . . . . . . . . . . 149 Configuration Primitives . . .8.2 PHY Control and Attributes . . . 102 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Data Link Layer Service Functionality and Features . . . . . . .8. . . . . . . . . . . . . . . . . . . 100 5. 146 6. . .4. . . . . . . . . . 139 6 Data Link Layer (L2). . . . . . .8 Link Startup Sequence . 171 Change of Certain Link Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . 135 5. . . . . . . . . . . . . . .1 6. . . . .7. .14 Remote Attribute GET and SET . .9 Capability Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5. . . . . . . . . . . . . . . . .7. . . . . . . . . . 147 DL_TCx_SAP . . . . .6 Trigger Mapping . . . . . . . . . . . . 168 PDU Decomposition Feature. . . . . . . . . 105 5. 105 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.8. . . . . . . . . . . . .7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5. 147 DL_LM_SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . .8. .5. . . . . .3 6.11 Lane Synchronization . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Services Assumed from PHY Adapter Layer . . . . . . . . . . . . . . . . . . . . . . . . . . .10 (Re-)Initialization . . . . . . . . . . . . . . 103 5.3 6. . . .5. . . . . . . .1 6. . . .16 Physical Layer Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Error Mapping . . . . . . . 165 Control Frames . . . . .6. . . . . . . . . 172 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 5.8. . . . . . . . . . .7.1 Data Transmission . . . . . .9 Management Information Base and Protocol Constants . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . .2 6. 150 Control Primitives . . . . . . . .11 Physical Layer Requirements . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . 127 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6.7. . . . . . . . . . . . . . . . . . . . . .Version 1.8. . Inc. . . .3. . . . . . . . . . . . . . . . . . . . . . . .8 PHY Adapter to M-PHY Interaction. . . . . . . . . . . . . . 131 5. . . . . .8. . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . .8. . . . . . . . . . .10 Actions Performed during Reset . . . 162 Data Symbol . . . . . . . . . .3 PHY Adapter M-PHY-specific Attributes . . 168 PDU Composition Feature. .8 Trigger Event Mapping . . . . . . .1 6. . . .4 Power State Mapping. . . . . . . . . . .8. . . . . . . . . . . . . . . .2 6. . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . 170 Buffering Mechanism . . . . . . . . . . . . . . . 157 Structure and Encoding of Protocol Data Units . . . . . . . . . . . . . . . . . . . . .5 6. . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5. . . . . . . . . .7. . . . . . . 120 5. . . . . .3 6. . . . . . . . .3 6. . 153 Status Primitives . . . . . . . . . . . . . . . .1 PHY Adapter Common Attributes. . . . . . . . . . . 120 5. . . . . . . . . . . . .4 6. . . . . . . . . . . . . . . . . . . . . . . .2 PHY Adapter D-PHY-specific Attributes . . . . . . . . . . . . . . . . . . . . . .6. 167 Protocol Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5. . . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 6. . . . . . . . . . . . .7 Error Mapping . . . . MIPI Alliance Member Confidential v . . . . . . . . . . . 132 5. . . . . . . . . . . . . . . . . . . . . .2 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5. . . . . . . .

. . . . 199 7. . . . . . . . . . . .7 Data Link Layer Initialization . . .9 7. . . . . . . . 216 N_PDU Fields . . . . . . . . .7. . . . . . . . . 202 N_TCx_SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . 199 Data Communication between Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 N_PDU Decomposition Feature . . . . . . . . . . . . . 202 N_LM_SAP. . . 201 Limitations and Compatibility Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 6. . . . . . . . . . . . . . . . . . . . . .1 7. . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . 190 6. . . . . . . . . . . . .7 8. . . . . . . . . . . . . . . . . .4 7. 199 Network Layer Addressing . . . . . . .2 7.6 TCx Data Frame Transmission . . . . . . . . . . . . . . . . . . . . . . . . . .1 8. . . .6. . . . . . . . . . . . . . . . . . . . .13 7. . . . 191 6. . . 226 Segmentation and Reassembly . . . . . . . . . . . . 218 Protocol Features. . . . . . . . . . . . . . . . . . . . . . . . . . . .3 7. . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Limitations and Compatibility Issues . . . . .3 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 6. . 188 6. . . . . . . . . . . . . . . . . . . . . . . . 216 Data N_PDUs . . .6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 7. . . . . . . . . . . 215 Structure and Encoding of Network Protocol Data Units . . . . . . . . . . . . . . . .9. . . . . . . . . . . .1 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Network Layer Service Functionality and Features . . . . . . . . . . . . . .3 7.40. . . . . . .10 7. . .8 Acknowledgment Operation . . . . . . . . . . . .Version 1. . . . . . . . . . . . . 228 T_CO_SAP . . . . . . . . . . . . . .5 7. . . MIPI Alliance Member Confidential vi 8 Transport Layer (L4). . . . .7 7. . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Configuration Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Connection-oriented (CO) Data Communication . . . . . . . . . . . . . . . . . . . . . . . . . 208 Control Primitives . 222 Network Layer and Data Link Layer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . . . . . . . . . 191 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . .7. . . . . .4 7. . . .8. . . . . . . . . 234 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . .1 8. . .2 8. . . . 221 Packet Reception . . . . . . . . . . . . . . . . . . . . . 228 T_LM_SAP . .2 7. . . . . . . . . . . . . . . . .9. . . . . . . . . . 220 Packet Transmission . . . . . . . . . . . . .12 Error Detection Mechanism. . . . . . . . . . . . . . . . . . . . . . . 202 Data Transfer Primitives . . . . 200 Services Assumed from the Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Flow Control . . . . . . . . . . . . . . . 184 6. . . . . .1 7. . . . 219 Header Format Analysis Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Data Transfer Primitives . . . . . . .1 7. . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 NAC Frame Transmission .2 7. . . . . . . 211 Status Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 . . . . . . . . . . . . . . . 227 Services Assumed from the Network Layer . . . . . . . . . . . . . . . . . . .9. . . .5 8. . . . . . . . .8 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Transport Layer Service Functionality and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Transport Layer Addressing . . . . . . . . . . . . . . . . . 227 End-to-End Flow Control (E2E FC) . . . .6. . . . . . . . . . . . . . . 217 Relationship of N_PDU Type Selection and Service Primitive Usage . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . . . . .3 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 8. . . . . . . . . . . . . . . . . . . . . . . . . . .8 Management Information Base and Protocol Constants . . . . 221 Long Header Trap . . . . . . . . . 219 N_PDU Composition Feature . 193 7 Network Layer (L3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 7. . . . . . . 180 6. . . . . . 222 Management Information Base and Protocol Constants . . . . . . . . . . . . .6. . . . . . . . . . . . . . . . . .3 7. . . . . . . . . . . . . . . . . . . . . .9 Timeout Values Calculation (informative) . . . . . . . . . . 173 6. .10 AFCx Frame Transmission . . . . . . . . . . . . .6. . . . . .6. .13 PHY Initialization Condition. . . . . . . . . . . . . . . .4 8. . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . . . 220 Discard N_PDU Feature . . . . . . . . . . . . .

. . . . 259 8. . . . . . . . . . . . . . . . .1 9. . . . . . . . . . . . . . . . . . . 282 Entering Hibernate. . . . . . . . . 242 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Address Translation Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential vii . . . . .6. . .17 Management Information Base and Protocol Constants . . . . . . . . . . . . 244 8. . . . .3 Segmentation Feature . . . . . . . .6. . . . . . . . .11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15. . . . . . . .10 Structure and Encoding of Transport Protocol Data Units . . . . . . . . . . . . . . . . . 280 Attributes . . .15. . . . . . . . . . . . . . . . . . . . . .10 Error Reporting for CSD and CSV .11. . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . .3. . . . . . . . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 8. . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . .2 9.9. . . . . . . . . . . . . . . . . . . . . . . . 286 DME Power Mode Change .9. . . . . . .9 CPort Safety Valve. . . . . . . . . . 260 8. . . . . . . . . . . . . . . . . . . . . . . . .2 9. . . . . . . . . . . . . .11. .5. . . . . . . . . . . . . . .3 Status Primitives . . . . . .2 9. 286 Issuing the Request . . . . . . . . 247 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 T_PDU Composition Feature . . . . . . . . . . . . .2. . . . . . . . . . . . . .11. .11 Protocol Features. . . . . . . . . . . . . .1 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Configuration Primitives . . . . 280 Attribute Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 9. . . . .15. .3 9. . . . . . . . . . . . . . . . . . . . . . . 281 EndPointReset . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . 280 DME Service Functionality and Features . . . . . . . 250 8. . . . . . . . . . . . . . . . .11. . . . . . . . . . . . . . . . . . . . .7 Header Format Analysis Feature . . . . . . 288 Copyright © 2007-2011 MIPI Alliance.11. . . 247 8. . . . . . . . . . 250 8. .3. . . . . . . . . . . . . . . . . . . . 244 8. . . . . . . . . . . . . .3 9. . . . .3 Traffic Generator (TstSrc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Initializing UniPro Attributes after Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 DME Configuration. .8 Explicit Flow Control Features . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Segment Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 8. . . . . . . . . . . . . . . . .14 CPort Arbitration. . . . . . . . . . . . . . . 250 8. . . . .2. . . . . . .1 9. . . . .1 Algorithm for Discovering the Test Feature Instances in a DUT (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 8. . . . . . . . . . .2 Control Primitives . 247 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Reassembly Feature . . .10. . .2 Configuration Primitives . . . . .3 9. . 285 Failing to Enter or Exit Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Updating L2 Timer Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 8. . . . . .6 T_PDU Decomposition Feature . . . . . . 243 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . 260 8. . . . . 262 8. . . .15 UniPro Test Feature. . . . . . .6 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 9. . . .11. . . . . . . . . . . . . . . .15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11. .3 9. . 259 8. . . . . . . . . . . 238 8. . . . . . . . .13 Segment Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 9 Device Management Entity (DME) . . . . . . . . . . .5 9. . . . . . . . . . . . . . . . . . . . 280 UniPro Cold Reset . . . . . . . . . . . . . .4 9. . . . . . . . . .2 9. . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro 8. . . .3. . . . . . . .2 T_PDU Fields . . . . . . . . . .1 Connection Management Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 Discard T_PDU Feature . . . . . . . . 259 8. . . . .2 9. . . . . . . . . . . . . . . . . . . . . . .4 Traffic Analyzer (TstDst). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 Exiting Hibernate (Un-hibernate) . . . . . . . . . . . . . .11. . . . . . . .11. 288 Completion . . . . . . . . . Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 Features Assumed from Other Layers.7 DME Control. . . . . . . . . . . . . . . . . . . . . . . . .1 Data T_PDUs. . . . . .1 9. . . . . . . . . . . . . . . 262 8. 248 8. . . 282 Hibernate (M-PHY only). . . . . . . . . . . . . . . . . . . . . . 259 8. . . . . . . . . . 267 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10. . . . . . . . . . . . . .11. . . . . 281 UniPro Warm Reset . . . . . . . . . . . . . . . . 258 8. . . . . . . . . . . . . . . . . .16 Transport Layer and Network Layer Interaction. . . . . . . . . . . . . . . . . . . . . . . . 273 8. . . . . . . . . . . . . . . .

. . . . . . . . .4 SERDES Data Format . . .1 UniPro Protocol Stack Testing . . . . . . . . . . . . . 315 A. . . . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . .9 UniPro Versioning.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9. . . . . . . . . . . . . . . 343 Timing Diagrams. . . . . . . 358 E. . . . . . . . . . . . . 352 E. . . . . . . . . . . . . . . . . . . . . . . . . . 368 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . .8.1 Forward Link . . . . 360 E. . . . . . . . . . . . . . .40. . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 B. . . . . . . . . . .4. . . . . . . . . . .1 Configuration Primitives .11. . . . . . . . . . . . . . . . . . . . . . . . . . 356 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . .1. . . . . . . . . . . . . . . . . . . . . . . 339 Annex C SAP Primitive Formalism (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 SERDES State Machines. . . . . . . . . . . . . .3 T-MPI Signal List . . . . . . . . 352 E. . . .4. . . . . . . . . . . . MIPI Alliance Member Confidential viii . . . . 335 B. . . . . . . . . . .1 T-PPI Signal List . . . . . . . . . . 295 9. . . .2. . . . . . . 353 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . . . . . . . . 343 Annex E Test M-PHY Protocol Interface (T-MPI) (informative) . . . . . . . . . . . . .2. . . . . . . . . . . . . . . . . . 308 9. . . . . . . . . . . . . . . . . . 334 B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 FSM State Descriptions . . . . . . . . . . . .2.3 CCITT CRC-16 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . 340 C. . . . . . . .10 UniPro States. . . .1 Timeout Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 T-MPI TX Burst Diagram . . . . . . . . . . . . . . . . . . .1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11.2 Retransmission Mechanism . . . . . . .2 Additional SAP Primitives . . . . . . . . . . . 310 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 9. . . . . . . . . . . .1. . . . . . . . .1 D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Clock Group. . . . . . . . . . . . . . . . .3 Bit Ordering and Binary Value . . . . . . . . . . . . . . . . 361 E. . . . . . . . . . . 356 E. . . . . .6 Timing Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Boot Procedure Example (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . 310 9. . . . . . . . . . . . . . 360 E. . . . . . . . . . . . .2 Functional Block Diagram (External M-PHY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 T-MPI Features . . . .2 Preemption Scenarios . 310 9. . 310 9. . . . . . .2 Control Primitives . . . . . . . . . . . . 315 A. . . . . . . . 349 Annex D CPort Signal Interface (informative) . . . . . . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Reset Procedure . . . . . . . . . . . . . . . . . . .1 T-MPI Control Symbols . . . . .1 Reliability Scenarios . . . . . . . . . 354 E. . . . . . . . . . . . . .1. . . . . . . . . . . . . . . . . . . . . . .11. . . 316 A. . . . . . .1 D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . Inc. . . .1. . . . . . . . . . . . . . . . . . . . . . . 334 B. . . . . . . . . . . . . . . . . . . . . . 352 E. .8. . . . . . . . . . . . . . . .1 Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 E. . . . . 289 9. . 325 B. . . . . . . 317 A. . . . . . . . . .1 Functional Block Diagram (Protocol Testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Data Group. . . .2 UniPort-M testing using an external third party M-PHY .2 Boot Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 T-MPI Data Symbols. . . . . . . . . . . . . . . . . . . . 313 Annex A Test PHY Protocol Interface (T-PPI) . . .12 DME DDB L1 . . . . . . . . . . . . . . . 368 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . .2 Reverse Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 DME_SAP. . . . . . . .2 T-PPI Signal Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . 355 E. . . . . . . . . . . . . . . . . . . 319 Annex B Data Link Layer (informative) . . . . . . . . . . . . . . . . . . . . . .11 Reset and Boot Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 E. . . . . . . . . . . . . . . . . . . . . . . 323 B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Signal Definition . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .1. . . . . . . . . . 389 F. . . . . . . . 386 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 T-MPI RX Burst Diagram . . . 385 E.2 Data Link Layer (L2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Access to T-MPI Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Network Layer (L3). . . . . . . . . . . . . .1 Transceivers. . . . . . . . 391 F. . . . . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . . .1. 370 E.4 Symbol Encoding. . . . . . . . . . . . . . . 384 E. . . . . . . . . . .6. . . . . . . . . . . . .2 IP Point of View . . . . . . . . . . . . . . 388 F. . 391 Annex G Recommended Pre-conditions for Hibernate Entry and Exit (informative) 392 Copyright © 2007-2011 MIPI Alliance. . . . .6 Static Configuration of a UniPro Device. . . . . . . . . . . . . . . . . . . . . . . . . . .1 Access to M-PHY Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 E. . . . . . . . . . . . . . . . . . . . . . . . . 389 F. . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . 390 F. . . . . . . . . . . . . . . . . .5 Device Management Entity . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7. . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5) . . . . . . . . .4 Error Control Test Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Power Mode Test Feature . . . . . . . . . .Version 1. . . . . . . . . 370 E. . . . . . .7 SERDES Configuration. . . . . . . . . . . . . 385 E. . . . . 370 E. . . . .5 OMC Emulation Test Feature .7 Physical Lanes Renumbering Test Feature . . . . . . . . . . . . . . . .8. . . . . . .7. . . .8. . . . .1. . . . . . . .8. . . . . . . .7. . .1. . . . . . . . . . . .8. .1 Specification Point of View . . . . . . . . . . . . . . .2 Driver Configuration . . . . . . . . . .7. . . . . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388 F. . . . MIPI Alliance Member Confidential ix . . . . . . . .1. . . . . 388 F. . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 E. . . . . . . . . . .6 FSM Emulation Test Feature. . . . . . . . . . . . . . . . . . .9 Serial Control Interface . . . . . . . . . . . . .5 Transceivers Frequency . . . . . . . . . 386 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Receiver Configuration . . . . . . . . . . . . . . . . . . . . . .1 PHY Adapter Layer (L1. . .1. . . . . . . . . 388 F. . . . . . . . . . . . . . . . . . . . . .8. . . . . . . . . . . . 371 E. . . . . . . . . . 387 Annex F Options and Tunable Parameters (informative) . . . . . .7. 377 E. . . 370 E. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Testing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Transport Layer (L4) . 369 E. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Power Mode Change Procedure for D-PHY . . 54 PHY Adapter Layer SAP Model . . . 86 DL Escaped Data PA_PDU . . . . . . . . 49 Example of a Short Header Segment in a Short Header Packet in an L2 Frame . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Example Data Frame with an Even Number of Payload Bytes . . . . Inc. . . . . . . . . . . . 55 Data PA_PDU . . . . . . . . . . . . . . . . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Point-to-Point Configuration Example. . . . . . . . 22 Comparison of UniPro and OSI/RM Layers . and Odd Number of PA_PDUs (informative)107 PACP Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 PHY Adapter PDU Ordering in a Four Lane Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Figure 29 Scope of the UniPro Specification . . . . . . . . . 53 UniPro Network Configuration Example. . . . . . . . . 89 PHY Adapter PDU Ordering in a Dual Lane Configuration . . . . . . . . . . . . . . 87 PHY Adapter PDU Ordering in a Single Lane Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 NAC Control Frame Structure . . . . . . . PA_ActiveTxDataLanes = 2. . . . . . . . . . . . . . . . . 44 PACP Frame Structure . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential x . . . . . . . . 36 17-bit PHY Adapter Layer Symbol Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Example Data Frame with an Odd Number of Payload Bytes. . . . . . . . . . . . . . . . . . . . . . . 99 End of Burst Sequence with PA_TxTrailingClocks = 3. . . . . . . . . . . . . . . . . . . 109 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 PHY Adapter PDU Ordering in a Three Lane Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Example Short Header Packet Encapsulated within an L2 Data Frame . . . . . . . . . . . . . . . . . . . . . . . 86 DL Escaped Data PA_PDU with EscType=ESC_DL . . . . . . . . . 86 PA Escaped Data PA_PDU . . . . . . . . . . 85 Escaped Data PA_PDU . . . 93 Link Startup Sequence Example with One Node Initiating the Sequence (D-PHY only) 96 Link Startup Sequence Example with Both Nodes Initiating the Sequence (D-PHY only)98 Encoded D-PHY Symbol Mapping . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Simplified Model of a Single UniPro Link Connecting Two Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 AFC Frame Structure . . . . . . . . . . . . . . . . . . . . . . .

169 Composition with Preemption (Traffic Class Y > X) . . . . . . . . . . . . . . . . . . . 113 PACP_EPR_ind . . . . . . . . . . . . . . . . . . . . . 127 Entering Hibernate (after Link Startup) . . . . Inc. . . . . . . . . . . . . .40. . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Figure 39 Figure 40 Figure 41 Figure 42 Figure 43 Figure 44 Figure 45 Figure 46 Figure 47 Figure 48 Figure 49 Figure 50 Figure 51 Figure 52 Figure 53 Figure 54 Figure 55 Figure 56 Figure 57 Figure 58 Figure 59 Figure 60 Figure 61 PACP_PWR_req . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Data Frame with Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 PACP_TEST_DATA . . . . . . . . . . . . . . . . . . 171 Latest Point in Time when PA_DL_PAUSE. . . . . . . . . . 112 PACP_CAP_ind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential xi . 115 PACP_SET_cnf . . 129 Exiting Hibernate (after Link Startup) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . 168 Composition of PDU with Even Length DL_SDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .rsp_L is Generated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 M-PHY Lanes Discovery . . . . . . . . . . . . . . . . . . . . . 162 Data Link Layer Data Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Control Symbol Definition . 171 Decomposition with Preemption . . . . . . . . . . . . . . . . 111 PACP_PWR_cnf . 114 PACP_GET_cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Repeated Transmission of TRG_UPR1 Messages . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . 167 AFC Frame . . 173 Message Sequence Chart for Flow Control Register Changes after Boot Up Example 179 Variation of Credits during Data Transmission Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Repeated Transmission of TRG_UPR2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Control and Data Frames Taxonomy . . . 168 NAC Frame . . . . . . . . . . . . 131 Data Link Layer SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Decomposition with Even Length DL_SDU . . . . . . . . . . . . . . . . . . . . . . . . . 113 PACP_TEST_MODE_req . . . . . . . . . . . . . . . 166 Data Frame with Odd Number of DL_SDU Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 PACP_SET_req . . . . . . . . . . . . 119 Power Mode Change using PACP_PWR_req and PACP_PWR_cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 PACP_GET_req . . . . . 163 Data Frame with Even Number of DL_SDU Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . 284 Copyright © 2007-2011 MIPI Alliance. 191 Initial Credit Exchange Example . . . . . . . . . . . . . . . . 279 Attribute Address Format . . . . . . . . . . . . 261 Inter-message Gap Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Address and CPortID . 225 T_SAPs. . . . 258 Test Feature Location within the Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Transport Layer Segmentation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. 256 Successful Data Transmission with Controlled Segment Dropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Figure 62 Figure 63 Figure 64 Figure 65 Figure 66 Figure 67 Figure 68 Figure 69 Figure 70 Figure 71 Figure 72 Figure 73 Figure 74 Figure 75 Figure 76 Figure 77 Figure 78 Figure 79 Figure 80 Figure 81 Figure 82 Figure 83 Figure 84 Figure 85 Figure 86 Figure 87 Figure 88 Figure 89 Figure 90 Figure 91 Figure 92 Figure 93 Figure 94 Definition of Frame Acknowledgment Timer and Replay Timer for TC0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . 219 Network Layer Decomposition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential xii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Transport Layer Reassembly Process. . . . . . . 250 Transport Layer Decomposition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 Concept of a Transport-level Connection. . . . . . . . . . 193 Network Layer SAP Model . . . . . . . . . . . . . 274 Device Management Entity SAP Model . . . . . . . . . . 202 Network Layer Data N_PDU with Short Header (DT SH N_PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Interrupted Data Transmission using E2E FC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Address and DeviceID. . . 199 N_SAPs. . . . . . . . . . . . . . . . . . . . . . 257 Unsuccessful Data Transmission Due to Interim Lack of Credits . . . . . 190 Bit Allocation for CRC-16 Checksum in DL Layer Data Symbol. . . . . . . . . . . . . . . .40. . . . . . . . . . . . . . 200 Network Layer Data Transfer Using Different Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 MSC of Network Layer and Transport Layer Interaction . . . . . . . . . . . . . . . . Inc. . . . . . . . . . . . . . . . . . . . 183 CRC Coverage . . . . . . . . . . . . . . . . 201 Relationship of Network Service Characteristics and Underlying Services . . 227 Data T_PDU with Short Header (DT SH T_PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Discard of Segment Payload Due to Lack of Credits. . . . . . . . . . . . . . 280 Hibernating a Peer-to-Peer Link. . . . . . . . . . . . . . . . . . . . . . . . . 249 Transport Layer Composition Process . . . . . . . . 220 Transport Layer SAP Model . . . . . . . . . . . . . . . . . . . . . . . . . 217 Network Layer Composition Process. . . . . . . . 264 E2EFC Behavior in TstDst Example . . . . 250 Data Transmission using E2E FC. . . . . . . . . . . 283 Hibernate High Level Entry Flow . . . . . . . . . . . . . . 283 Hibernate Entry Flow Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Figure 120 Reverse Link Use Case with Preemption – AFC1 Transmission. . . . . 336 Figure 117 Reverse Link Use Case without Preemption – AFC1 is Blocked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Figure 123 CCITT CRC Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Figure 104 TC0 Replay Timer Operation for Simple ACK (no grouping ACK). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Figure 95 Figure 96 Figure 97 Figure 98 Figure 99 Hibernate Entry Flow Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Figure 110 Retransmission Due to Wrong Frame Sequence Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Figure 127 CPort Signal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Figure 116 Reverse Link Use Case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Figure 108 Retransmission Triggered by NAC Frame while Stopping Current Frame . . . 343 Copyright © 2007-2011 MIPI Alliance. 325 Figure 107 Retransmission Triggered by NAC Frame . 340 Figure 125 Ambiguous Usage of SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Figure 118 Reverse Link Use Case without Preemption – TC1 Data is Blocked . . . . . . . . . . . 334 Figure 113 Forward Link Use Case without Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Figure 112 Forward Link Use Case . . . . . . . . . . . . . . . . . . . . . 313 Figure 102 Simplified View of UniPro Interoperability Setup. . . 286 Power Mode Change (DME Perspective) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 Figure 106 TCx Replay Timer Behavior during Preemption . . . . . . . . 328 Figure 109 Retransmission Triggered by TC0_REPLAY_TIMER Expiration . All rights reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 Figure 114 Forward Link Use Case with Preemption – Start of Preemption . . . . . . . . . . 338 Figure 121 Reverse Link Use Case with Preemption – AFC1 Reception . . . . . . . . . . . . . 312 Figure 101 Link Lost Triggered Boot Procedure . . . 287 UniPro States . . . . . . . 339 Figure 124 Common Usage of SAP Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40. . . . . . . . 341 Figure 126 Usage of the Local SAP Primitives . . . . . . . 285 Hibernate Exit Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Default Boot Procedure . . . . . . . . . . . . . . . 311 Figure 100 Peer Initiated Boot Procedure. . Inc. . . . . . . . . . 331 Figure 111 No Retransmission Due to Error in AFC Reception . . . . . . . . . 337 Figure 119 Reverse Link Use Case without Preemption – AFC1 Transmission . . . . . . . 323 Figure 105 TC0 Replay Timer Operation for Grouped ACK. . . 338 Figure 122 Reverse Link Use Case with Preemption – End of Preemption. . . . . . . . . 315 Figure 103 T-PPI Signal Groups with Their Respective Signals per Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Figure 115 Forward Link Use Case with Preemption – End of Preemption . . . MIPI Alliance Member Confidential xiii . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . 354 Figure 135 T-MPI Block Diagram for External M-PHY Case. . . . . . . . 360 Figure 137 State Diagram for S-TX . . . . . . . . . . . . . . . . . . . . . . . 350 Figure 131 Flow Control Credit Transfer Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Figure 130 Receiver Data Transfer Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 Figure 133 External M-PHY Configuration . . . . . . . . . . . . . . 361 Figure 138 State Diagram for S-RX . . . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . . . . . . . . . . . . . 353 Figure 134 Protocol Testing Block Diagram . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Figure 128 Transmitter Data Transfer Example . . . . . . . . . . . 361 Figure 139 BURST Sub-FSM. . MIPI Alliance Member Confidential xiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Figure 143 Transceivers Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .40. . . . . . . . . . . . . . . 368 Figure 142 RX Burst Timing Diagram Example . . . . . . 370 Copyright © 2007-2011 MIPI Alliance. . . . 364 Figure 141 TX-Burst Timing Diagram Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Figure 140 OMC Sub-FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Figure 129 Delayed Transmitter Data Transfer Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Figure 136 Bit Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Figure 132 T-MPI Protocol Testing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Tables Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 Table 28 Table 29 Table 30 Table 31 Table 32 Table 33 Table 34 Table 35 PA_SAP Data Transfer Primitives . . . . . 66 PowerChangeResultCode Values. . . . . . . . . 108 PACP Functions . . . . . . . . . . . . . . . . . . . . 64 PA_LM Configuration Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40. . . 91 Encoded D-PHY Low Symbol Mapping . . . . 102 Global Operation Timing Parameters. . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential xv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 PA_LM Control Primitives . . . . . . . . . . . . . . . . . . . . . . . 56 PA_SAP Data Transfer Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . settable) Common Attributes. . . . . . . . . . . . . . . . . . . . . . . . . 60 PA_SAP Status Primitive . . 64 PA_SAP Status Primitive Parameters . . . . . . . . . . . . . . . . . . . 134 CJTPAT Test Patterns . . . . . . . . . . . . . . 135 PHY Adapter Protocol Constants. . . . . . . . . . . . . . . . . . . . . . . . . . 136 PHY Adapter (gettable. . . . . . . . . . . . . . . . . 136 PHY Adapter (gettable. . . 84 PA_LM_SAP Status Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 PA_SAP Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 UniPro Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Low-speed Trigger Event to D-PHY Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . 100 D-PHY to UniPro Error Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 PHY Test Pattern PACP Frames . . . . . dynamic) Common Attributes . . . . . 136 PHY Adapter (gettable. . . . . . . . . . . . . . . . . . . . . 100 Encoded D-PHY Symbol Mapping Example (informative) . . . . 88 Link Startup Sequence . . . . . . . . . . . . . . . . . . . . . . . 110 PACP_PWR_cnf Status Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 PA_LM_SAP Status Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . static) Common Attributes. . . . . . . 99 Encoded D-PHY High Symbol Mapping . . . . . . . . 100 UniPro Power State to D-PHY State Mapping. . . . . . . . . 107 TRG_UPR0 Mapping. . . . . . . . . . . . . . . . . . . . 108 TRG_UPR1 Mapping Examples (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 PA_LM Control Primitive Parameters . . . . . . . . . . . 103 UniPro Power State to M-PHY State Mapping . . . . . . . . 102 High-speed Trigger Event to D-PHY Mapping . . . Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 PA_SAP Control Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 CRPAT Test Pattern PA Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Configuration Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . 212 N_LM_SAP Status Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Control Symbol MS Byte Encoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . dynamic) M-PHY-specific Attributes . . . . . . . . . . . . . . . 177 Calculation of Timeout Values for D-PHY with TX Preemption Support (informative) 187 Calculation of Timeout Values for M-PHY with TX Preemption Support (informative) 187 Data Link Layer (gettable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential xvi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 DL_LM_SAP Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . static) D-PHY-specific Attributes . . . . . . . . . . . . . . 140 DL_TCx_SAP Data Transfer Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Copyright © 2007-2011 MIPI Alliance. . . . . . 139 PHY Adapter (gettable. . . . . . . . . . . 172 Example of Flow Control Register Changes after Boot Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Data Link Layer (gettable. . . . . . . . . . . . . . . settable) D-PHY-specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Control Symbols Parameter Field Definition . . . . . . . . . . . . . . .40. . 211 N_LM_SAP Control Primitive Parameters . . . . . . . . . . . . 203 N_TCx_SAP Primitive Parameters . . . . . . . . . . . . . . . . 208 N_LM_SAP Configuration Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 152 DL_LM_SAP Control Primitives. . . . 209 N_LM_SET. . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Supported Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 N_LM_SAP Control Primitives . . 147 DL_TCx_SAP Primitive Parameters . . . . 197 N_TCx_SAP Primitives . 164 Control Symbol Type Field Definition. . 151 DL_LM_SET. . . . . . . . . . 138 PHY Adapter (gettable. . Inc. . . . . . . . . . . . . . 138 PHY Adapter (gettable. . . . . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 36 Table 37 Table 38 Table 39 Table 40 Table 41 Table 42 Table 43 Table 44 Table 45 Table 46 Table 47 Table 48 Table 49 Table 50 Table 51 Table 52 Table 53 Table 54 Table 55 Table 56 Table 57 Table 58 Table 59 Table 60 Table 61 Table 62 Table 63 Table 64 Table 65 Table 66 Table 67 Table 68 Table 69 Table 70 PHY Adapter (gettable. . . 153 DL_LM_SAP Status Primitives . . . . . . . . . . . .cnf_L ConfigResultCode Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . settable) M-PHY-specific Attributes . . . . . . . . . . . . . 150 DL_LM Configuration Primitive Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .cnf_L ConfigResultCode Values . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 157 DL_LM_SAP Primitive Parameters. . . . . . . . . . . . . . . . . . . . 208 N_LM_GET. . . . . . . . . . . . . . . . . . . . . 164 Traffic Class Identification. . . . 150 DL_LM_GET. . . . . . . . . . . . . . . . settable) Attributes .cnf_L ConfigResultCode Values . . . static) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 N_LM_SAP Configuration Primitives . . . . . . . . . . . . . . . . . . . . . dynamic) D-PHY-specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 139 PHY Adapter (gettable. . . . . .cnf_L ConfigResultCode Values . . . . . . . . . . . . . . . . . . . . . . . . . . 147 DL_LM Configuration Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . 194 Data Link Layer Protocol Constants . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Settings of the L4s Field. . . . . . .cnf_L ConfigResultCode Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Table 103 TstSrc (settable. . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . 246 Settings of the Payload Field . . MIPI Alliance Member Confidential xvii .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 71 Table 72 Table 73 Table 74 Table 75 Table 76 Table 77 Table 78 Table 79 Table 80 Table 81 Table 82 Table 83 Table 84 Table 85 Table 86 Table 87 Table 88 Table 89 Table 90 Table 91 Table 92 Table 93 Table 94 Table 95 Table 96 Table 97 Table 98 Table 99 N_LM_SAP Status Primitive Parameters . . . . . . . . . static) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Table 106 TstDst (settable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Settings of the L3s Field. . . . . . . . . . . . . . . . . . . . . . gettable) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .cnf_L ConfigResultCode Values . . . . . . . . . . . . . . . . . . . . . . . 247 Table 100 E2E Flow Control Steps . . 245 Settings of the DestCPortID_Enc field. . 266 Table 105 Possible Errors at TstDst . . . . 218 Service Primitive to N_PDU Association Table . . . . . . . . 242 T_LM_DISCARD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Settings of the EOM field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ind Reason Codes . . . . . . . . 252 Table 101 Test Feature Overview . . gettable) Attributes . . . . . . . . . . . . . . . . . . . . . . settable) Attributes. . . . . . . . . . . . . . . . . . . . . . . . 234 T_LM_GET. . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 T_LM_SET. . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Table 107 Transport Layer (gettable. . . . . . . . . . . . 243 Transport Layer PDU Types . . . . . . . . . . . . 238 T_LM_SAP Status Primitives . . . . . . . . . . . . . . . . . . . 260 Table 102 Determining the Number of Test Feature Instances in a DUT. . . . . . . . . . . . . . . . . . . . . . 218 Settings of the DestDeviceID_Enc Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . 276 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . settable) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Network Layer (gettable. 224 T_CO_SAP Primitives . . . . . . . . . . . . . . . . . . . . . . 216 Network Layer N_PDU Header Fields. . . . . . . . . . . gettable) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 User-data Network Layer PDU Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40. . . . . . . . . 229 T_LM_SAP Configuration Primitives . . . . . . . . . . . . . . . . . 219 Discard N_PDU ReasonCode Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 T_LM_SAP Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Network Layer (gettable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Settings of the Payload Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Table 104 General Test Feature (settable. . . . . . . . . . . . . . . . . 245 Settings of the FCT Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Network Layer Protocol Constants . . . . . . . . . . . . . . . . . . . . . 237 T_LM_SAP Control Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 T_LM_SAP Status Primitive Parameters. . . . . . . . . . . . . . . . . . . 234 T_LM_SAP Configuration Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 T_PDU Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 T_CO_SAP Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

289 Table 113 DME_SAP Configuration Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Copyright © 2007-2011 MIPI Alliance. . . . . 289 Table 114 ConfigResultCode Values . . . . . . 377 Table 144 T-MPI Lane1 Attributes . . 297 Table 119 UniPro Version Information Mapping . M-RX and OMC Status Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . 277 Table 109 Transport Layer (gettable. . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Table 112 DME_SAP Configuration Primitives . 374 Table 140 M-RX Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Table 133 LCC Payload for LCC-READ-X in S-TX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Table 122 T-PPI Control Group Transmitter and Receiver Signal List . . . 308 Table 120 DME_SAP Restrictions . . . . . . . . . . 359 Table 132 LCC Payload for LCC-WRITE-ATTRIBUTE in S-TX . . . . . . 278 Table 110 DME Attributes Routing Rules . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Table 127 T-MPI Signals description . . . . . . . . . . . . . . . 290 Table 115 DME_SAP Control Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Table 141 M-TX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Table 142 OMC Write Only Attributes. . . . . . . . . . . . . 316 Table 123 T-PPI Clock Group Transmitter and Receiver Signal List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Table 126 CPort Interface Signal Definition. . . . . . . . . . . 358 Table 131 LCC-Cmd Data Symbol Encoding. . . . . . . . . . . . . . . . . . . . . MIPI Alliance Member Confidential xviii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Table 139 M-TX Configuration Attributes . 295 Table 117 L2 Timer Data Structure. . Inc. . . . . . . . . . . . . . . 280 Table 111 Reset Scope and Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Table 130 PwrMode Bit Field Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . static) Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296 Table 118 LayerCodeError Mapping . . . . . . . . . 295 Table 116 DME_SAP Control Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Table 137 M-TX Capability Attributes . . . . . . . . . . . . . . . . . . . . . . . . 372 Table 138 M-RX Capability Attributes . . . 366 Table 136 LCC Payload assignment for LCC-READ-CAPABILITY in S-RX . . . . . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 108 Transport Layer Protocol Constants. . . . . . . . . . . . . . 318 Table 125 T-PPI Signal Multiplexing on the Data [7:0] Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Table 128 T-MPI Control Symbols . . . . . . . . . . . . . . . . . . . 357 Table 129 Power Mode Symbol Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Table 124 T-PPI Data Group Transmit and Receive Signal List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Table 143 T-MPI Lane0 Attributes . . . . . . . 366 Table 134 LCC Payload for LCC-WRITE-ATTRIBUTE in S-RX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Table 121 DDB L1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . 366 Table 135 LCC Payload for LCC-READ-MFG-INFO and READ-VEND-INFO in S-RX . . . . . . . . . . . . . .

. . . . . . . . . . 382 Table 152 TX_OptCapability2 Attribute Description . . 379 Table 147 T-MPI Serial Interface Control Attributes . . . . . . . . . . . . 381 Table 150 TX_Capability Attribute Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 Copyright © 2007-2011 MIPI Alliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Table 161 TX_FSM_State Attribute Setting . . . . . . . . . . . . . .Version 1. . . . . . . . . . . . . . . . . . . 386 Table 163 MAP_x Attribute Description . . . . . . . . . . . . . . . . . 386 Table 162 RX_FSM_State Attribute Setting. . . . . . . . . . . . . . . . . . . . . . . . All rights reserved. . . . . . . . . . . . . . . . . . . . . . 380 Table 148 T-MPI Physical Lanes Renumbering Attributes . . . . . . . . 382 Table 155 RX_Capability Attribute Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Table 154 OMC WO Attribute Description . . . . . . . . . . . . . . . . . . . . . . 382 Table 153 TX_OptCapability3 Attribute Description . 380 Table 149 T-MPI Power Mode Error Control and Status Attributes . . . 384 Table 160 RX_OptCapability5 Attribute Description. . . . . . . . . . . . . MIPI Alliance Member Confidential xix . . . .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 145 T-MPI Lane2 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 Table 146 T-MPI Lane3 Attributes . . . . . 381 Table 151 TX_OptCapability1 Attribute Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Table 158 RX_OptCapability3 Attribute Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Table 157 RX_OptCapability2 Attribute Description. . . 383 Table 156 RX_OptCapability1 Attribute Description. . . . 383 Table 159 RX_OptCapability4 Attribute Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40.00 Board approved release.Version 1.40. MIPI Alliance Member Confidential xx . All rights reserved. Inc. Description Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro Release History Date 2011-04-28 Release 1.

handheld computers. In addition. and multimedia Devices. In addition. Copyright © 2007-2011 MIPI Alliance. with low pin counts and at low energy per transferred bit. Throughout this document. UniPro enables these Devices and components to utilize MIPI PHY layers in order to exchange data at high data rates. as well as in [MIPI02]. See Section 4. Data Link (L2). 3 To aid in understanding the concepts presented in this specification. Section 7 and Section 8. respectively. bulk data transfer. modems. etc.5). digital cameras.1 Scope 4 This document defines the protocol used to transfer data between Devices that implement the UniPro specification. error handling.3 for more information on the similarities and differences to the OSI/RM. 1. Data Link. other MIPI Alliance specifications are used for definition of physical layer and Application Layer protocols. All rights reserved. This includes definitions of data structures. physical layer timing and encoding.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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. UniPro is applicable to a wide range of component types such as Application processors. Inc. flow control. used to convey information across the Network. such as Packets and Frames. 2 This document refers to MIPI Alliance Specification for UniPro: SDL State Machines [MIPI02] for formal definition of PHY Adapter for M-PHY (L1. Network (L3). MIPI Alliance Member Confidential 21 . the UniPro description is loosely based on the ISO OSI Reference Model (OSI/RM).Version 1. Network and Transport layer protocols are described in Section 5. Transport (L4). Section 6. 6 The electrical interface. packetized streaming. layer references are to the UniPro layering scheme unless otherwise indicated. 5 The PHY Adapter. As such. Application-specific protocols and command sets are out of scope for this document. this specification can be thought of as a member of a family of specifications. power and state management. The DME (Section 9) is also described in [MIPI02]. 7 Figure 1 shows the scope of this document as it relates to the OSI/RM. layer protocols and Device Management Entity (DME).40. co-processors. and to different types of data traffic such as control messages. and connection services are also within the scope of this document.

In addition.00 31-Jan-2011 MIPI Alliance Specification for UniPro Application-specific Protocols Scope of UniPro Specificaton Device Management Entity (DME) Transport (L4) Network (L3) Data Link (L2) PHY Adapter (L1. implementing new features is simplified due to the extensible nature of the UniPro specification. All rights reserved. Inc.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.40. Copyright © 2007-2011 MIPI Alliance.5) PHY (L1) Medium Figure 1 Scope of the UniPro Specification 1. 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.Version 1. MIPI Alliance Member Confidential 22 .

Version 1.2) are shown in all capital letters. 12 13 14 15 16 17 All sections are normative. without mentioning or excluding others. The use of the word must is deprecated and shall not be used when stating mandatory requirements. physical. FAST_STATE. or that a certain course of action is preferred but not necessarily required. bitwise XOR is represented by ‘^’ and 1’s complement (negation) is represented by ‘~’. The word can is used for statements of possibility and capability. A prefix of 0x indicates a hexadecimal number. 22 Attribute: Atomic unit of information that can be read or written from an Application using DME_GET or DME_SET primitives. The word may is used to indicate a course of action permissible within the limits of the Specification (may equals is permitted). The PHY Adapter Layer abstracts from whether or not a Clock Lane is required.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. will is only used in statements of fact. “should”. whether material. Attributes can be used to configure the behavior of a UniPro stack. Some PHY technologies require this.40. All rights reserved. must is used only to describe unavoidable situations. Copyright © 2007-2011 MIPI Alliance. e. 23 Big-endian: This term describes the order in which a sequence of bytes are stored in computer memory.1 of the IEEE Specifications Style Manual. 24 Checksum: See Cyclic Redundancy Check (CRC). 2. or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that). or causal (can equals is able to). MIPI Alliance Member Confidential 23 . 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). which dictates use of the words “shall”. to determine the current state of the interface or to determine the availability of interface options and interface capabilities. and “can” in the development of documentation. while a prefix of 0b indicates a binary number. bitwise OR is represented by ‘|’. 25 Clock Lane: A unidirectional interconnect between two UniPorts which carries clock information needed for decoding the data on the Data Lanes. unless they are explicitly indicated to be informative. The use of the word will is deprecated and shall not be used when stating mandatory requirements. The word should is used to indicate that among several possibilities one is recommended as particularly suitable. 19 This document uses the C/Verilog representation for operators where bitwise AND is represented by ‘&’. 26 Component: A physical entity such as an integrated circuit containing at least one Device or switch. 20 Named constants. and DME_PEER_GET or DME_PEER_SET primitives.g. 18 Numbers are decimal unless otherwise indicated. Inc. Bigendian is an order in which the “big end” (most significant value in the sequence) is stored at the lowest memory address. “may”. and Service Primitive names (Section 2.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2 Terminology 10 The MIPI Alliance has adopted Section 13.

errors that may occur in the Physical Layer. The sending side may then transfer data up to the credit limit. Copyright © 2007-2011 MIPI Alliance. logical communication channel between two CPorts. A Device needs to comply with Network Layer and Transport Layer (L3 and L4) requirements as defined in the UniPro specification. and possibly trailer. 35 D-PHY: High-speed serial interconnect technology. 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. 41 (Data Link Layer) Frame: A Layer 2 PDU for point-to-point transmission across an individual Link. which is consumed by the Data Link Layer. 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. 34 Credit-based Flow Control: A method to control the speed of data transfer between two entities. and possibly trailer. information from the PDU of a lower layer to extract an upper layer PDU.5 and L2) requirements as defined in the UniPro specification. MIPI Alliance Member Confidential 24 . An off-chip Link also needs to comply with PHY Adapter Layer and Data Link Layer (L1.5 because they are set using the UniPro PA Control Protocol (PACP). 44 Device: An addressable node on the Network. 38 (Data Link Layer) Control Frame: A Layer 2 PDU.40. based on source synchronous signaling. The CRC is used to produce a checksum. for a larger block of data. the Data Link Layer maintains Flow Control between the L2 entities. 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. 2. and possibly corrects. 42 Data Link Layer Symbol: The DL Layer data stream is constructed of atomic 17-bit symbols. 36 Data Lane: A physical interconnect between two UniPorts which carries data. The receiving side notifies the sending side that space is available in the receiving side buffer by issuing credits. 28 Connection: A Connection is a bidirectional. The mechanism is intended to manage Network congestion and avoid certain types of system-level deadlocks. These symbols can be either control or data symbols. Data Link Layer Flow Control is also referred to as Link-Level Flow Control. which is typically a small number of bits. A Link can consist of 1. 40 Data Link Layer Flow Control: Flow Control implemented on Data Link Layer (L2) using credits. information to the PDU of an upper layer to build a lower layer PDU. Frames may be either Data Frames or Control Frames. In addition. 39 (Data Link Layer) Data Frame: A Layer 2 PDU whose SDU is passed on to upper layers.Version 1. It is a concept used for Connection-oriented data transmission. A Lane with embedded clocking information is also considered a Data Lane. 32 Critical (M-PHY) Attributes: A set of control Attributes for M-PHY MODULEs that get special treatment within UniPro L1. whereby two Devices need to be connected before data can be exchanged. 43 Decomposition: The process of removing header. such as a Packet. 3 or 4 Data Lanes per direction. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 27 Composition: The process of adding header. The Data Link Layer provides the functional and procedural means to transfer data between two adjacent L2 instances. and with a Physical Layer (L1) as defined in [MIPI01] or [MIPI05]. that is defined in MIPI Alliance Specification for D-PHY [MIPI01]. 33 Cyclic Redundancy Check (CRC): A coding scheme to detect errors in transferred data. 37 Data Link (DL) Layer (L2): A Protocol Layer. A Data Lane in UniPro is used unidirectionally. The Data Link Layer also detects. Inc.

49 Endpoint: Device that is a leaf of a Network. 54 Gear: A mechanism defined in [MIPI05] that provides control over the speed of the Link in steps of 2x. 60 Logical Lane Number (M-PHY): A number assigned by a Device to its outbound Data Lanes after the Link Startup Sequence. or received by. 56 Host: This is a Device that has computation and storage capabilities that allow it to control and manage other Devices on a network. 46 DeviceID: A number which uniquely identifies a Device on the Network.5 Lane mapping whereby only the usable Physical Lanes are assigned a Logical Lane Number. Note that for Notifications. based on clock embedding.5 handshake to establish initial Link communication between two directly attached UniPorts. MIPI Alliance Member Confidential 25 . a CPort. 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. the slave sends the Notification to the master. All rights reserved.Version 1. however. 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. 59 Link Startup Sequence: The Link Startup sequence is an L1. 61 Long Header Packet: Packet that has an extended L3 header. Received Fragments are not generally identical to transmitted Fragments. 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.00 31-Jan-2011 MIPI Alliance Specification for UniPro 45 DeviceClass: A property of a UniPro Device that indicates what the UniPro Device does and what Application-level protocols it supports. Copyright © 2007-2011 MIPI Alliance. Note that the DeviceClass concept defined here is intended to match that used in [MIPI04]. Long Header packets are handled by the using the Long Header Trap feature. 66 M-PHY: High-speed serial interconnect technology. 55 Get command: A command used to read the value of an Attribute. 47 Device Management Entity (DME): The Device Management Entity is a layer-independent entity interfacing with all UniPro Protocol Layers and the Application Layer. Inc. 65 Message: The PDU of the Application Layer (LA). 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. as defined in [MIPI05]. A host is associated sometimes with the main CPU. 51 Fragment: A portion of a Message that can be passed to.40. 48 Dual Simplex: Supporting independent communication in forward and reverse direction simultaneously. Higher values of HS Gear or PWM Gear imply higher frequencies and higher bandwidths. 58 Link: A bidirectional interconnection between two Devices or Switches. The DME may set or get layer Attributes and signal and control the resetting of individual layers. It is used for L1. 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. 57 Lane: Data or Clock Lane.

77 Peripheral: Any external Device that provides input or output services for the Host. The part of the communication protocol that manages the Network and routes Packets to their destinations.5) the freedom to autonomously switch between two pre-determined Power States. 86 Preemption: Nesting of higher priority Frames into lower priority Data Frames.5): A Protocol Layer. The PHY Adapter Layer presents a common interface to the Data Link Layer for the supported Physical Layer. 75 PACP (Control) Frame: A PDU used by PACP for power control purposes. Copyright © 2007-2011 MIPI Alliance. and M-PHY testing. 71 (OSI) Layer 3: See Network Layer. 73 (PA) Symbol: The PDU of the PHY Adapter Layer (L1. 72 (OSI) Layer 4: See Transport Layer. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 67 Network: Communication structure allowing two or more Devices to exchange data via a communication protocol. MIPI Alliance Member Confidential 26 . All rights reserved. Please see the relevant document for further details. The Physical Lane Number plays a role in the L1. 79 PHY Adapter Layer (L1. Various Power Modes have a one-to-one mapping to Power States while other Power Modes give the PHY Adapter Layer (L1. 82 Pin Count: Number of pins required to implement a physical port. 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. 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). 84 PHY Power State: The PHY power state is defined in [MIPI01] for D-PHY and in [MIPI05] for M-PHY.5) of the current power state of the underlying Physical Layer. 74 Packet: The PDU of the Network Layer (L3). 87 Protocol Control Information (PCI): Information exchanged between Layer-(x) instances to coordinate their joint-operation. peer Device Attribute setting and getting. 68 Network Layer (L3): A Protocol Layer. 83 Power Mode: The UniPro Power Mode is a configurable Attribute used to control the UniPro Power State. 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).40.5) used for setting power modes.5). power. Typically. and M-PHY testing handling. 85 UniPro Power State: The UniPro Power State is an abstracted representation within the PHY Adapter Layer (L1. 70 (OSI) Layer 2: See Data Link Layer.5 Lane remapping to compensate for wiring topology. and control pins.Version 1. peer Device Attribute setting and getting. Typically includes signal. 80 PHY-Protocol Interface (PPI): The Interface between the Physical Layer (PHY) and the PHY Adapter Layer. 69 Operating Modes: UniPort-specific operating modes for power consumption and performance. 78 PHY Adapter Control Protocol (PACP): A control protocol within the PHY Adapter Layer (L1. 81 Physical Lane Number (M-PHY): A static number assigned at the implementation phase of a Device to its outbound and inbound Data Lanes.

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 27

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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

Service Primitives

116 This document uses an OSI-conforming name convention for Service Primitives. Service Primitive names are structured as follows: 117 118 119 120 121 122 123 <service-primitive> ::= <name-of-service-primitive> ( {<parameter>, }* ) <parameter> ::= <service control information> | <Service User data> <name-of-service-primitive> ::= <layer-identifier>_<service-primitive-name>.<primitive> <layer-identifier> ::= T | N | DL | PA <service-primitive-name> ::= e.g. CONNECT | RELEASE | DATA | ACTIVITY_START | … <primitive> ::= req | ind | rsp | rsp_L | cnf | cnf_L T: Transport N: Network DL: Data Link PA: PHY Adapter

124 See Annex C for additional details.

2.3
125 etc. 126 e.g. 127 i.e.

Abbreviations
And so forth (Latin: et cetera) For example (Latin: exempli gratia) That is (Latin: id est)

2.4
128 ACK 129 AFC 130 A_PDU 131 CCITT 132 CO 133 COF 134 CRC 135 CReq

Acronyms
Acknowledgment Acknowledgment and Flow Control Application Protocol Data Unit Comité Consultatif International Téléphonique et Télégraphique Connection Oriented Continuation of preempted Frame Cyclical Redundancy Checking Credit Transmit Request Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 28

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

136 CSD 137 DL 138 DL_LM 139 DL_PDU 140 DL_SAP 141 DL_SDU 142 DME

Controlled Segment Dropping Data Link Data Link Layer Management Data Link Protocol Data Unit Data Link Service Access Point Data Link Service Data Unit Device Management Entity

143 DT SH N_PDUData N_PDU with Short L3 Header. See Section 7.8.1.1. 144 DT SH T_PDUData N_PDU with Short L4 Header. See Section 8.10.1.1. 145 DUT 146 E2E FC 147 EFSM 148 EMI Device-Under-Test End-to-End Flow Control Extended Finite State Machine Electromagnetic Interference

149 EOF_EVEN End of Frame for even L2 SDU 150 EOF_ODD End of Frame for odd L2 SDU 151 EOM 152 EoT 153 ESC_DL 154 FC 155 FCT 156 HOL 157 HS 158 ID 159 ISO 160 ISTO 161 LA 162 LPDT 163 LS 164 LSB 165 Mbps 166 MIB 167 MIPI 168 MS End of Message End of Transmission Data Link Layer Control Symbol Identifier Flow Control Flow Control Token Head of Line High Speed Identifier International Organization for Standardization Industry Standards and Technology Organization Application Layer Low Power Data Transmission Least Significant Least Significant Bit Megabit per second Management Information Base Mobile Industry Processor Interface Most Significant Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 29

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

169 MSB 170 MSC 171 MTU 172 NAC 173 N_LM 174 N_PDU 175 N_SAP 176 N_SDU 177 OSI 178 OSI/RM 179 PA 180 PA_LM 181 PA_PDU 182 PA_SAP 183 PA_SDU 184 PCI 185 PDU 186 PHY 187 POR 188 PPI 189 QoS 190 RReq 191 RX 192 SAP 193 SDL 194 SDM 195 SDU 196 SI 197 SOF 198 SOM 199 SoT 200 TC0 201 TC1

Most Significant Bit Message Sequence Chart Maximum Transfer Unit Negative Acknowledgment Control Network Layer Management Network Protocol Data Unit Network Service Access Point Network Service Data Unit Open Systems Interconnection Open Systems Interconnection Reference Model PHY Adapter PHY Adapter Layer Management PHY Adapter Protocol Data Unit PHY Adapter Service Access Point PHY Adapter Service Data Unit Protocol Control Information Protocol Data Unit Physical Layer Power-on Reset PHY-Protocol Interface Quality of Service Reset Link Request Receiver Service Access Point Specification and Description Language System Device Manager Service Data Unit Symbol Interval. A 10-bit period for the transmission of one symbol. Symbol Interval scales with data rate. The Symbol Interval is applicable when using M-PHY. See [MIPI05]. Start of Frame Start of Message Start of Transmission Traffic Class 0 Traffic Class 1 Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 30

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

202 TF 203 TL

Test Feature Transport Layer

204 T_CO_SAP Transport Layer Connection-oriented Service Access Point 205 T_LM 206 T_PDU 207 T_SAP 208 T_SDU 209 TX 210 UI 211 ULPS Transport Layer Management Transport Layer Protocol Data Unit Transport Layer Service Access Point Transport Layer Service Data Unit Transmitter Unit Interval. The duration of one bit when using D-PHY. See [MIPI01]. Ultra Low Power State

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 31

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

3
212 [ITUT01]

References
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 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 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 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 MIPI Alliance Specification for D-PHY, version 1.00.00, MIPI Alliance, Inc., 14 May 2009 MIPI Alliance Specification for UniProSM: SDL State Machines, version 1.40.00, MIPI Alliance, Inc., 31 January 2011 MIPI Alliance Specification for UniProSM: Test Procedure, version 0.80.00, MIPI Alliance, Inc., In Press MIPI Alliance Specification for Device Descriptor Block (DDB), version 0.82.01, MIPI Alliance, Inc., 30 October 2008 MIPI Alliance Specification for M-PHY, version 1.00.00, MIPI Alliance, Inc., 8 February 2011 Tanenbaum, Andrew, Computer Networks, 4th Ed., <http://authors.phptr.com/tanenbaumcn4/>, Prentice Hall, 9 August 2002

213 [ITUT02]

214 [ITUT03]

215 [ITUT04]

216 [MIPI01] 217 [MIPI02] 218 [MIPI03] 219 [MIPI04] 220 [MIPI05] 221 [TAN01]

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 32

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

4

Architecture Overview (informative)

222 UniPro is structured as a stack of protocol layers (see Figure 1) that roughly follow the OSI Reference Model (OSI/RM) for networking as published in ITU-T Recommendation X.200, Information technology – Open Systems Interconnection – Basic Reference Model: The basic model [ITUT01]. This means that any given protocol layer in the stack provides services that do not depend on higher layer protocols but do depend on the layers below it. 223 Each layer can be described conceptually as communicating with a peer layer at the other end of the Link (for lower protocol layers) or network (for higher protocol layers). Communication between higher peer layers tends to be at a high level of abstraction, e.g. exchange of Application-specific units called Messages, while communication between lower peer layers tends to be at a low level of abstraction, e.g. in terms of byte or even bit streams. A specification of a layer thus also defines how a layer’s abstract protocol behavior maps to the communication services provided by the layer directly below it (Computer Networks, [TAN01]).

4.1

UniPro Layering

224 One way to visualize a protocol stack is to see it as a processing pipeline. In order to transmit data, each layer in the stack converts PDUs from the layer above it into PDUs it can process before passing the PDUs to the layer below it. 225 For example, in UniPro, the Transport Layer (L4) converts Application Level PDUs (Messages) into less abstract PDUs before passing them down to the next layer (L3). Each layer in the stack converts the PDUs from the previous layer into less abstract PDUs until finally, at the bottom layer of the stack (L1), the PDUs are converted into the electrical signals and low-level timing used by the Interconnect. 226 Similarly, when data is received from the interconnect at the bottom of the stack (L1), the electrical signals and low-level timing are converted into more abstract PDUs before being passed up to the next layer in the stack (L1.5). Each layer converts the PDUs into more abstract PDUs before passing them up to the next layer. Finally, the Transport Layer (L4) converts the PDUs back into Messages. 227 The UniPro specification deliberately does not define which parts of the protocol should be implemented in hardware or in software or which processing should take place concurrently as opposed to sequentially. For maximum performance, all UniPro layers have been designed to run efficiently as a fully pipelined hardware implementation. Implementers may however choose to implement some parts of the stack in software, thereby potentially serializing and slowing down parts of the processing. It is the implementer’s responsibility to assess whether the implementation’s architecture meets the temporal requirements, e.g. bandwidth and timers, found in the UniPro and PHY specifications. 228 In this document, splitting the protocol stack into multiple layers provides a convenient and familiar structure to the protocol description without imposing one particular implementation. The interfaces between the protocol layers are defined at an abstract level known as Service Access Points (SAPs, ITU-T Recommendation X.210, Information technology – Open systems interconnection – Basic Reference Model: Conventions for the definition of OSI services [ITUT02]). These internal interfaces are only intended to structure the specification and are not intended to define interfaces that allow independently developed implementation modules to work together. A manufacturer may choose to merge two or more layers into a single layer, or subdivide layers, as long as the integral behavior of the defined protocol stack is unchanged.

4.2

The UniPro SDL Model

229 UniPro is specified by defining per layer how SAPs provided by each protocol layer map to requests to primitives of SAPs provided by the protocol layer directly below it. In this document, this is specified in text, figures and examples along with some explanation why this behavior is needed. In a companion document [MIPI02], the behavior of the UniPro protocol layers are formalized using the SDL language ( ITU-T Recommendation Z.100 (2002): Specification and Description Language [ITUT04]). The SDL model of Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 33

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

4.3

Comparison of UniPro to the OSI/RM

234 Figure 2 compares UniPro to the OSI/RM. Each layer in UniPro provides roughly the same functionality as the corresponding layer in the OSI/RM. 235 Note that the OSI PHY (Physical) layer has been split into two sub-layers. The upper sub-layer, the PHY Adapter Layer (L1.5), exposes a PHY-independent interface to L2 and is part of the UniPro specification. The lower PHY sub-layer (L1) is outside the scope of this document. UniPro supports two alternative Physical Layer technologies, MIPI Alliance Specification for D-PHY [MIPI01] and MIPI Alliance Specification for M-PHY [MIPI05]. Both PHY specifications are essentially included in this document by reference. 236 In addition, layers above the Transport Layer (L4) are outside the scope of this document. These Applicationspecific protocols may support Devices such as camera or display modules, high-speed modems, coprocessors, etc., and may be implemented entirely in hardware or as software running on a general-purpose processor or any other combination of hardware and software. 237 The Device Management Entity (DME) is not typically shown in OSI protocol stacks, but serves as a control plane to initialize and control the layers involved in the actual data transport. The DME is not involved in data communication. 238 All references to protocol layers, by name or number, in this document are references to the UniPro stack unless explicitly stated otherwise.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 34

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

Application (L7) Application-specific Protocols (LA)

Presentation (L6)

Session (L5) Device Management Entity (DME)

Transport (L4)

Transport (L4)

Network (L3)

Network (L3)

Scope of UniPro Specification

Data Link (L2)

Data Link (L2) PHY Adapter (L1.5)

Physical (L1) PHY* (L1) Medium OSI Reference Model Medium UniPro * D-PHY or M-PHY

Figure 2

Comparison of UniPro and OSI/RM Layers

4.4

Service Access Points (SAP)

239 Upper layers use the services of lower layers by communicating through a conceptual interface known as a Service Access Point (SAP). As shown in Figure 3, a SAP is named after the layer whose services it exposes. Thus, Applications access UniPro’s services via the T_SAP where the T is shorthand for “Transport Layer”.

4.4.1

Service Primitives

240 SAPs consist of multiple Service Primitives that resemble function calls in software. However, unlike function calls, Service Primitives abstract fully from the employed implementation choices, e.g. hardware versus software. Furthermore, Service Primitive are actually typed messages, with an optional parameter list, that are exchanged between state machines. Thus, unlike function calls, their invocation does not return a value or cause the transmitting state machine to block, waiting for a return value; instead of waiting, a Device might, or might not, get an asynchronous message back, depending on specification details. 241 This document uses particular conventions for naming Service Primitives that are intended to highlight the direction in which the message is sent (transmit or receive) and whether the message initiates a transaction or is the consequence of a transaction requested elsewhere. These naming conventions for Service Primitive suffixes are explained in detail in Annex C.

4.4.2

SAP Significance

242 SAPs defined in this document correspond directly to the interface SAPs used in the SDL volume of this specification [MIPI02]. They thus serve to modularize the specification in a well-defined manner as shown in Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 35

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

4.4.3

Data Flow through the Stack
Device A Device B

Application-specific Protocols (LA)

Messages (A_PDU)

Application-specific Protocols (LA)

DME SAP T_LM SAP

T_SAP

T_SAP
T_LM SAP

DME SAP

Device Management Entity (DME)

Transport (L4)
N_SAP

Segments (T_PDU)

Transport (L4)
N_SAP

Device Management Entity (DME)

N_LM SAP

N_LM SAP

Network (L3)
DL_SAP

Packets (N_PDU)

Network (L3)
DL_SAP

DL_LM SAP

DL_LM SAP

Data Link (L2)
PA_SAP

Frames (DL_PDU)

Data Link (L2)
PA_SAP

PA_LM SAP

PA_LM SAP

PHY Adapter (L1.5)
PHY_SAP

Symbols (PA_PDU)

PHY Adapter (L1.5)
PHY_SAP

PHY (L1)

PHY-encoded Symbols

PHY (L1)

Medium

Figure 3

Simplified Model of a Single UniPro Link Connecting Two Devices

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.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 36

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

4.5

Signal Interfaces

245 Although key interfaces are defined as SAPs, the external interfaces at the top and bottom of the UniPro stack are also provided as informative signal-level interfaces.

4.5.1

CPort Signal Interface

246 Annex D provides a description of an informative signal-level interface called the CPort Signal Interface. The interface provides one concrete approach to implementing the more abstract, normative T_SAP interface. The annex illustrates how the data sent and received by multiple CPorts can be multiplexed and how buffer overflow is prevented via a handshake. Applications defined on top of UniPro cannot generally assume that the informative CPort Signal Interface is available in actual UniPro implementations. Application-level specifications should instead reference the normative T_SAP interface.

4.5.2

Interface to the Physical Layer

247 As explained in the previous section, D-PHY and M-PHY specifications provide signal level-interfaces in annexes defining external interfaces of these Physical Layer technologies. In both cases, an actual implementation is not mandated to provide these interfaces. This leeway allows a combined implementation of a UniPro stack and a Physical Layer to regard the PHY interface as an internal interface that can be optimized without being constrained by the interface described in an annex.

4.5.3

T-PPI Interface for Testing (D-PHY oriented)

248 Annex A provides an optional signal-level interface called the Test PHY-Protocol Interface (T-PPI). The TPPI corresponds to the PHY_SAP interface shown in Figure 3, but was optimized for the required bandwidths and signals used to control a D-PHY Physical Layer. 249 T-PPI and the associated mapping to a test connector (see [MIPI03]) allow a UniPro implementation to be connected to UniPro protocol conformance testing equipment while bypassing the physical layer. A pair of UniPro interfaces can use T-PPI to test the interoperability of the interfaces without using the PHY implementations. 250 The T-PPI implements a subset of the PPI signals [MIPI01] and multiplexes certain signals to reduce the pin count of the test connectors [MIPI03]. The T-PPI is thus mainly relevant for FPGA-based testing of UniPro implementations.

4.5.4

T-MPI Interface for Testing (M-PHY oriented)

251 A new signal-level interface for test connectors adapted to the M-PHY technology, T-MPI, is presented in Annex E. The T-MPI interface is comparable to the T-PPI interface, but is adapted to M-PHY bandwidths and control interface. T-MPI avoids excessive pin-counts by utilizing high-speed SERDES technologies found in modern FPGAs.

4.6

Protocol Data Units (PDU)

252 A list of Service Primitives and a full explanation of their usage would not be enough to define protocol behavior because it only defines what services are provided by a layer. SAPs do not define how this functionality is achieved using lower-level “over-the-medium” behavior. The data units that travel over the media are called Protocol Data Units (PDUs) and are described at multiple levels of abstraction (x_PDU, where “x” designates one of UniPro’s layers). 253 The Transport Layer, for example, by definition provides the functionality exposed by the T_SAP interface. At a conceptual level, the L4 logic at both ends implements a protocol that provides the services defined by the corresponding T_SAP interface pair. This L4 protocol obviously needs some kind of data exchange. At Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 37

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

4.7

Physical Layer (L1)

257 Although both Physical Layer (PHY) options for off-chip usage are defined within separate MIPI specifications, [MIPI01] and [MIPI05], this is mainly for architectural reasons. The PHY is a technically critical element for the operation of UniPro and many basic properties of an off-chip UniPro implementation, such as bandwidth and power, are largely determined by the PHY.

4.7.1

D-PHY and M-PHY Technologies

258 In UniPro version 1.40.00, the use of either D-PHY [MIPI01] or M-PHY [MIPI05] is mandated for chip-tochip interconnections. A practical constraint is that the PHY technologies used at both ends of a Link needs to match: a D-PHY transmitter cannot interoperate with an M-PHY receiver or vice versa. In addition, both directions of the Link need to use the same PHY technology (a UniPro L1.5-imposed constraint). This means that individual chip-to-chip Links in a UniPro network are either based on the D-PHY or the M-PHY technology. 259 In the context of use with UniPro, both D-PHY and M-PHY are used in a dual-simplex, high bandwidth serial link that employs a low-swing, differential signaling technique for high speed communication. Unidirectional PHY Links are not supported because various higher protocol layers require return information, e.g. for flow control. 4.7.1.1 Supported D-PHY Capabilities

260 Data can be sent across a Link simultaneously in both directions, either at equal or unequal PHY bandwidths. In the case of D-PHY, this means that UniPro supports use-cases where forward and reverse directions of a Link can be configured as follows: 261 • 262 • 263 • both directions are in High Speed (HS) mode, both directions are in LPDT mode, or one direction is in HS mode while the reverse direction is in LPDT mode both directions have different clock frequencies both directions have the same nominal clock frequency, but are based on independent reference clocks Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 38

2.2 L1 Symbol Encoding 273 In order to support UniPro. 4. The actual frequencies are determined by the system integrator and can vary per Link and even Link direction: differences in Link length. every byte is converted to ten bits with a guaranteed maximum of five successive zero or one bits on the wire.3 D-PHY Data Rates 278 The D-PHY specification does not define fixed operating frequencies. 275 Despite being documented within the D-PHY specification. etc. 4. low-power data communication mode that is supported by UniPro. The raw throughput of D-PHY across printed circuit board traces is in the order of 800 Mbps per Data Lane..1 D-PHY and Symbol Encoding 274 The symbol encoding technique that UniPro uses for the D-PHY is defined in Annex C of [MIPI01]. every byte is converted to nine bits with a guaranteed maximum of seven successive zero or one bits on the wire.7. In this well-known 8b10b coding scheme. 279 D-PHY also provides a low-speed (maximum of 10 Mbps). to denote the start of a Packet.1. 4.2 M-PHY and Symbol Encoding 276 The symbol encoding technique that UniPro uses for M-PHY is defined in Section 4.7.00 31-Jan-2011 MIPI Alliance Specification for UniPro 264 • both directions have different numbers of Data Lanes Supported M-PHY Capabilities 4. EMI considerations. The 8b9b coding scheme is used for UniPro Links that utilize the D-PHY technology.7. all impact frequency choices.Version 1. available reference frequencies. This flexibility allows UniPro implementations to use implementations of the D-PHY without native 8b9b support. the encoding was designed to allow a clock signal to be extracted from the data lane. The following configurations for an M-PHY-based Link are supported by UniPro: 266 • 267 • 268 269 270 271 272 • • • • • both directions are assumed to have independent reference clocks (UniPro only supports Type-I M-PHY) both directions can be in HS-MODE.7. In this 8b9b coding scheme.2 265 M-PHY also supports different configurations for the forward and reverse directions of the Link.40. Inc. All rights reserved. 277 Although 8b10b might seem to have more “overhead” than the 8b9b scheme used with D-PHY. a receiver receives the clock frequency on a separate clock Lane. the 8b9b coding functionality may be implemented as an extra protocol layer between the D-PHY and the UniPro protocol layers. impedance tolerance control.g. both directions can be in PWM-MODE. or one direction is in HSMODE and one direction in PWM-MODE both directions can be used with different HS-GEAR settings both directions have to use the same HS RATE Series setting both directions can have a different number of Data Lanes both Basic and Advanced Optical Media Converters are supported as options M-PHY line termination and drive strength can be controlled 4. Copyright © 2007-2011 MIPI Alliance. thus avoiding the need for a dedicated clock Lane. the PHY protocol layer needs to provide symbol encoding for the byte stream. that can be distinguished from payload symbols.7. This symbol encoding feature is needed to allow higher protocol layers to use special symbols.5 of [MIPI05].2. MIPI Alliance Member Confidential 39 . e. UniPro provides a control mechanism that allows a transmitter to switch between High Speed and Low Power modes under Application control.

The M-PHY PWM-MODE can also run over multiple Lanes (unlike the D-PHY case). PWM-G1 support a range of raw bitrates between 3 and 9 Mbps. resulting in an effective bit-rate (due to 8b10 encoding) of 2.00 31-Jan-2011 MIPI Alliance Specification for UniPro 280 D-PHY high-speed data rates can be increased by providing up to four Data Lanes per direction. SLEEP (SLEEP_STATE). enables communication in the multi-Mbps range. but does mandate PWM-G1. 2.5 D-PHY Power States 285 D-PHY’s low power states are utilized by UniPro. UniPro does not support PWM-G0. the M-PHY specification also defines a series of Gears that give control of the trade-off between bandwidth and power. Copyright © 2007-2011 MIPI Alliance. The Link can become active again via in-band means. Expressed as a bandwidth that is actually available to the next-higher protocol layer.2 Mbps. assumes the peer Device's RX is not powered. This means that a TX may send at rates anywhere within this range. this respectively results in 1.6 M-PHY Power States 287 The two directions of an M-PHY Link have independent L1 power states. PWM-BURST (SLOW_STATE). HIBERN8 (HIBERNATE_STATE). The transmitter for either direction is responsible for establishing an L1 power mode and the receiver at the other end of the Link will automatically adopt the same mode using signaling methods provided by the PHY. UniPro gives the controlling Application the choice of which series to use per Link (same setting for both directions) and which Gear to use per Link direction. Using four Data Lanes gives a bandwidth increase of 4x and behaves like a 4x faster Physical Layer technology. enables communication in the Gbps speed range. 4. The Link cannot get out of this Power State on its own because the RX is unpowered.25 (HS-G1 or HS-GEAR1).4 to 7.0.4 M-PHY Data Rates 281 The M-PHY specification defines two RATE series (A and B) of pre-determined frequencies that are used for high-speed data exchange. HS-BURST (FAST_STATE). 286 Note that both directions of a D-PHY Link have independent L1 power states.7. 4. D-PHY uses only a single Data Lane when in Low Power mode.7. For successive gears (PWM-G2 to PWM-G7). Inc. STALL (SLEEP_STATE). but the bandwidth requirement is below 10 Mbps (the bandwidth of the D-PHY LPDT state). and are relatively complex compared to D-PHY transmitters and receivers.0 and 4. 2. D-PHY’s STOP state allows the Link to be put into lowpower state for sustained periods of inactivity. these speeds are multiplied by a factor of two for each higher Gear. 4. The RATE-A series provides three frequencies or Gears defined at 1. 282 For Low-Speed mode (LS-MODE) data exchange.Version 1. Thus. for periods of inactivity when operating in FAST_STATE. Using four Data Lanes behaves like a single PHY Lane with a 4x higher bandwidth. allows the Link to be put into low-power state for sustained periods of inactivity.40. The most relevant M-PHY states (and their mapping to Power State names used by UniPro) include the following: 288 • 289 • 290 291 292 293 • • • • Unpowered (OFF_STATE).50 (HS-G2) and 5.0 Gbps due to 8b10b encoding. Frequencies for the RATE-B series are about 17% higher than RATE-A series and are primarily provided for EMI/EMC reasons. for periods of inactivity when operating in SLOW_STATE. States supported by M-PHY transmitters and receivers can be found in [MIPI05].0 (HS-G3) Gbps. MIPI Alliance Member Confidential 40 . All rights reserved.7. 283 Note that for practical reasons. D PHY’s LPDT state allows a UniPro stack to operate in a low-power CMOS mode when there is data to send. 284 The M-PHY’s high-speed bandwidth can be increased by utilizing up to four lanes per direction.

40. the Application can decide to use fewer Data Lanes. Although the user can opt to use a subset of available Data Lanes. These Idle symbols are thus inserted in the gaps between Packets and are removed by the corresponding L1 receiver's decoder.1 L1. when used with a UniPro stack. 4. only Data Lane 0 is active. The use of pairs of PHY Idle symbols.5 Multi-lane Support 303 The PHY Adapter Layer provides bandwidth scalability by supporting up to four PHY Data Lanes per direction. 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.00 31-Jan-2011 MIPI Alliance Specification for UniPro 294 Note: 295 The HIBERNATE_STATE receives special treatment within the UniPro stack compared to all the other Power States. is convenient because it ensures that upper protocol layers can maintain 16-bit alignment on headers. MIPI Alliance Member Confidential 41 . Idle symbols map to pairs of special 10-bit M-PHY-defined FILLER control symbols. Thus.8. it is assumed Copyright © 2007-2011 MIPI Alliance.1. All rights reserved. For D-PHY. they are assumed to have identical capabilities. If this is the case.In the case of D-PHY. involve asserting the lines to a negative differential state (DIF-N) for a longer period of time than can occur during normal operation. 4. the UniPro stack has the capability to go to FAST or SLOW state. and L1.5) 302 The PHY Adapter Layer is responsible for abstracting the details of the PHY technology. The number of Data Lanes may differ between both directions. This could. for instance.8. 298 Controlling Power State transitions on M-PHY is quite complicated.Version 1. 304 When multiple Data Lanes are available. 4. active (used) Lanes are assumed to be in the same state.9.1 L1. Sometimes only a simple form of linestate signaling is enough.8 PHY Adapter Layer (L1. If multiple Data Lanes are available.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 highspeed mode and there is no data to send. 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. if one direction of the Link happens to be in SLEEP_STATE. and some data needs to be sent.7. Idle symbols are special 9-bit symbols defined in Annex C of [MIPI01] for this purpose.5 Multi-lane Features for the D-PHY 306 An Application can discover via a pair of read-only Attributes how many Data Lanes are available on both the local TX and local RX. the UniPro stack abstracts many PHY related details. 4. thus enabling bidirectional communication. 296 Note: 297 UniPro does not allow an Application to put any of the directions of a Link into SLEEP_STATE.5 handles all details of how the Lanes are used autonomously. thus providing a PHY-independent interface (PA_SAP) to higher protocol layers. SLEEP_STATE is supported by allowing a UniPro stack to autonomously toggle M-PHY between SLEEP_STATE and either FAST_STATE or SLOW_STATE. This approach also explains why UniPro can hide the distinction between M-PHY's STALL and SLEEP states from Applications. in SLOW_STATE. For M-PHY this also applies to the SLOW_STATE PHY bandwidth. In such a case. The reasons why are mentioned in Section 4. trailers and payload. 305 Higher protocol layers see multiple Data Lanes simply as an increase in PHY bandwidth. various other transitions involve higher protocol layers. for example because fewer Data Lanes are available at the peer Device. Inc. 299 Rather than expose this complexity to the Application that controls the UniPro Link.

315 The discovery process implies that unconnected Lanes.g. 318 Higher layer protocols can read the L1.1 L1. SLOW_STATE.1. the RX can detect and compensate for the amount of inter-Lane skew. Inc. Copyright © 2007-2011 MIPI Alliance. D-PHY’s LPDT and M-PHY’s PWM states are mapped to the UniPro power state “SLOW_STATE”.40.5 of the UniPro specification.5 introduces two new power modes called FastAuto_Mode and SlowAuto_Mode. Not only are the PHY-specific power states mapped to UniPro-defined power states. Slow_Mode. there is a one-to-one mapping of power modes to power states. starting at Physical Lane #0.5 Power Mode. only Physical Data Lane #0 is used.5 however. 4. 308 Note that details about how many Data Lanes are available for use are not critical: after reset. a series of data exchanges are executed that perform the following actions: 311 • 312 • 313 • determine which Data Lanes are connected to the peer Device determine how the Physical Data Lanes are connected assign Logical Data Lane numbering to the connected Lanes 314 These actions are automatically handled during the Link Startup Sequence. only a single Data Lane is used. FastAuto_Mode tells L1.5 Multi-lane Deskewing for the M-PHY 316 Streams of M-PHY symbols sent across multiple Data Lanes can have some degree of inter-Lane skew due to differences in trace length or design details.5 Multi-lane Features for the M-PHY 309 As for D-PHY. but can only impact it by setting the L1. but the detailed PHY power management state machines are also abstracted to a simpler model.1. respectively. 307 For D-PHY. 4. By sending the deskew pattern on each Data Lane whenever a burst starts. The amount of allowed inter-Lane skew is normatively bounded by L1. Hibernate_Mode and Off_Mode correspond to FAST_STATE. 4. with the D-PHY in SLOW_STATE.00 31-Jan-2011 MIPI Alliance Specification for UniPro that a contiguous series of Lanes is “connected”. Fast_Mode. 310 During initialization of L1. Higher protocol layers are agnostic as to which physical Lanes are being used or the topology of the wiring.5 that the Link should be in FAST_STATE to transport data. but sometimes data arrives a bit later because there is some latency involved in getting from SLEEP_STATE to FAST_STATE.2.5 protocol has a feature to transmit a special deskew pattern.5 power state. HIBERNATE_STATE and OFF_STATE. It also gives the circuit board designer the freedom to route any TX physical Lane to any available RX physical Lane on the peer Device. In FastAuto_Mode. the Link behaves more or less like it were in Fast_Mode. and thus to PHY-defined power states. And it is assumed that connected lanes start at Physical Lane #0 and that the wiring attaches corresponding Physical Lane numbers. In many cases. an Application can discover via Attributes how many M-PHY Data Lanes are available. All rights reserved.8. The L1. MIPI Alliance Member Confidential 42 .2 L1.2 L1. Furthermore.8. but that L1. and can decided to activate fewer than all the available Lanes. SlowAuto_Mode is the equivalent mechanism for SLOW_STATE.8.Version 1. 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).5 is allowed to put the Link into SLEEP_STATE when there is no data to send. no mechanism is provided to assess the number of connected lanes. or even Lanes with a hardware failure. 319 However. e. L1.5 Power States and Power Modes 317 The PHY Adapter Layer abstracts the power states provided by the PHY. are automatically accounted for.

All rights reserved. During this interaction. In general. results in two separate acknowledgements. The RX of the peer Device automatically follows the TX state change by monitoring associated line signaling. the L1.5-to-L1. for example. 328 Providing logic and even a low-level protocol in L1. takes place. the only observable Attribute is PA_RxPWRStatus because the Power Mode of the TX at the other end of the Link is not directly observable.5 Attributes at both ends of the Link are also automatically copied by L1. 326 Note that some controllable Attributes that impact Fast_Mode take effect when the Power Mode is enabled. using the PA_LM_SET. and thus to program the set of Critical Attributes there.00 31-Jan-2011 MIPI Alliance Specification for UniPro 320 So the difference between Power States and Power Modes are as follows: 321 322 323 324 • • • • an Application can set only a Power Mode. L1. using the PA_LM_SET. The main example is the number of active Data Lanes: these can be modified in Slow Mode. at either end of the Link.req primitive. PDUs (“PACP Frames”) generated by L1.2 L1. to the Device at the far end of the Link.5 Programming Model for Controlling M-PHY Power Modes 327 The control of Power Modes for M-PHY uses a more sophisticated model than its D-PHY counterpart.2.8. followed by programming PA_PWRMode using the PA_LM_SET. in a single PACP Frame. 337 A typical use-case is to set these Attributes to their desired values at the near end of the Link. The first acknowledgement is almost instantaneous and indicates whether or not the request has been accepted (it might return an error code if. 329 The programming model used by the UniPro specification to support M-PHY involves the following socalled Critical Attributes at the “near” end (end closest to the controlling Device) of the Link: 330 331 332 333 334 335 • • • • • • Number of active Data Lanes per direction PWM-Gear per direction HS-Gear used per direction HS RATE series (same value used for both directions) Line termination per direction and associated drive strength Power Modes per direction (combined into a single PA_PWRMode Attribute) 336 An identical set of Attributes at the “far” end of the Link is automatically synchronized with the “near” end set whenever PA_PWRMode is written. MIPI Alliance Member Confidential 43 . 4. which only uses a single Lane. The second acknowledgement is an asynchronous Notification that typically informs the originator that the Power Mode Copyright © 2007-2011 MIPI Alliance.2.40.req primitive. 338 Note that programming PA_PWRMode.5 for M-PHY automates a significant part of the required steps utilizing an L1. Inc. a range is exceeded).Version 1. and the actual power state change.5 Controlling Power for the D-PHY 4. if applicable. and take effect when Fast_Mode is enabled using PA_TxPWRMode.5 communication protocol known as PACP (PHY Adapter Control Protocol). Setting the Power Mode then automatically causes PACP to transport all Attribute values.5 into the actual PHY Attributes.5 are multiplexed with the symbol stream received from L2 and can be recognized by a unique header pattern.5 to control PHY state transitions reduces the risk of usage errors by exposing relatively simple interfaces. At the RX side.req primitive.8.1 325 An Application controls the Power Mode of the TX part of a D-PHY Link via a D-PHY-only Attribute called PA_TxPWRMode. but cannot set a Power State an Application can read out a Power Mode and read out a Power State the readable value of a Power Mode simply reflects the value that was set the readable value of a Power State may change spontaneously when in FastAuto_Mode or SlowAuto_Mode L1. This is largely because M-PHY is more complex than D-PHY.

5 Idle symbols whenever there was no data to send.10. any modifications to these Attributes are only effectuated on a write to PA_PWRMode.5 Idle symbols in order to provide backwards compatibility with UniPro v1.5).g. see Section 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro change request has been completed. In subsequent figures. MIPI Alliance Member Confidential 44 .Version 1. 345 In version 1.5 Idle symbols is not necessary because they are compliant with.00. using the PA_LM_SET. to start up and train Phase Locked Loop (PLL) circuitry. 16 1 0 15 14 13 12 11 10 9 8 7 6 L1.req primitive can. See Figure 4. 4. 4.10.00 and later specifications. because the process of changing Power Modes is a bit tricky. In M-PHY-based stacks. However.4 PACP Frames as Used with M-PHY 346 The PACP protocol allows the L1.req primitive.00 and do not utilize legacy L1.00 of the UniPro specification. UniPro v1. and thus require a retry by the Application. This requires the exchange of messages known as PACP Frames (see Figure 5).1 D-PHY Encoding and Backwards Compatibility 344 Note that to improve robustness.10.5 Idle symbols. Inc. 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.5 entity at one end of the Link to communicate with the L1.5 uses 17-bit symbols. A UniPro v1. while bits [7:0] directly map to one of the 256 normal data codes. e. however. This approach was taken because certain Power Modes transitions might take a relatively long time to execute.5 entity at the other end of the Link. 4. A UniPro v1. analogous to the M-PHY specification itself. L1. Gray means “don't care”.5 and Symbol Encoding 341 The PHY Adapter Layer also abstracts the symbol encoding technique provided by the PHY. still required to absorb legacy L1. UniPro v1. Compatibility with UniPro v1.00 Devices is achieved with a special mode (PA_LegacyDPHYEscDL.01 changed the L1. All rights reserved. At the PA_SAP interface. 340 It is worth noting that.3 L1.5 payload L1. at least.00. or “code words” supported by the PHY. When Bit 16 equals zero.40.5 payload 5 4 3 2 1 0 Figure 4 17-bit PHY Adapter Layer Symbol Example 342 Each 17-bit symbol (the PA_PDU) can hold two bytes of data plus an associated control-or-data flag (Bit 16).7. the two Bytes in the Symbol's L1. setting PA_PWRMode using the PA_LM_SET.8.5 symbols are thus translated within L1.00.00 or later receiver is. When Bit 16 equals one.8.00.8. color coding is used to indicate which field belongs to which layer in the UniPro protocol.5 payload translate to two normal 9-bit (D-PHY) or 10-bit (M-PHY) data codes.10. return an error code. The 17-bit L1.5 (see Figure 2). in principle.3. the available PHY bandwidth in high speed mode was padded with L1. 339 Also note that the Application needs to modify only Lane. Note the color convention whereby Bit 16 is shown in red to correspond to the color convention used for L1.40. Gear and Series Attributes if a change is needed. This practice was deprecated in UniPro v1.00 or later conformant transmitter is required to use L1 Idle symbols instead.5 to the symbols. Copyright © 2007-2011 MIPI Alliance. absorption of legacy L1.5 PDU ESC_PA (see Table 17) to a comma code. bits [15:8] are used to identify a special control data code. This flag allows a UniPro stack to distinguish between special symbols used by the protocol and payload data.

.5 at both ends of the Link setting two readable Attributes known as PA_MaxRxPWMGear and PA_MaxRxHSGear. Inc.5 L1.g. The resulting value of PA_MaxRxPWMGear also reflects any machine-readable capability limitations of Advanced Optical Media Convertors and can be optionally derated further by the Application.5 Automatic Capability Discovery (M-PHY only) 349 When an M-PHY based Link is initialized. state.5 how to interpret the remaining fields. The second Symbol indicates the type of PACP Frame. HS-GEAR=2. the TX can handle PWM-G1 and PWM-G2 and the RX can in itself handle PWM-G1.5.. this symbol. MIPI Alliance Member Confidential 45 . software. results in a PHY-level control symbol that is used only to signal the start of a PACP Frame. Copyright © 2007-2011 MIPI Alliance.5 in the UniPro stack. automatic exchange of capability information.5 red” because the data is defined. if it knows about other limitations such as Basic Optical Media Convertors.00 31-Jan-2011 MIPI Alliance Specification for UniPro 16 1 0 0 0 0 15 14 13 12 11 10 ESC_PA 6 5 4 3 2 1 0 EscParam_PA = PACP_BEGIN PACP_FunctionId Parameters . These capability Attributes reside only at the RX end of the Link (they are not duplicated like the previously discussed Critical Attributes) and accurately portray the highest Gear settings in which the Link can operate. e. and operable.8. PowerMode=PWM 354 the request is automatically checked and. if an attempt is made to put a Link in the following state: 352 353 TX: RATE Series A. L1.40. priorities. For example.5 Power Modes and their confirmation. This results. at the PHY level. if the request is impossible to execute. 4. L1. PWM-GEAR=3. assume that in one particular direction. PWM-GEAR=1. Lanes=2. 348 PACP Frames have very specialized usage (changes in L1. CRC-16 9 8 7 Figure 5 PACP Frame Structure 347 The first 17-bit symbol contains a constant. This fact is automatically discovered by L1. which then proceeds to degrade the value of PA_MaxRxPWMGear from an initial value of three (RX capability) down to two (TX capability. remote Get/Set and M-PHY testing) and thus are sent infrequently. 350 As an example. generated and absorbed by L1. the lower of the two values).5 returns an error code and leaves the Link in a well-defined.g. Lanes=1. Note that all fields are shown in “L1. for example. forcing a form of low-level reset. Because Bit 16 is set to one.Version 1. 351 Although this Attribute pair is only located in a receiver (thus a total of four Attributes spread over two Devices). in L1. PWM-G2 and PWM-G3. and tells the receiving L1.9 Data Link Layer (L2) 355 The main responsibilities of the Data Link Layer are to provide reliable Links between a transmitter and a directly attached receiver and to multiplex and arbitrate multiple types of data traffic.5 automatically explores the capabilities of both directions of the Link. A similar discovery process also sets PA_MaxRxHSGear. PowerMode=HS RX: RATE Series A. 4. HS-GEAR=1. All rights reserved. e. a request to put a Link in a specific state is checked for correctness.

9. a payload of up to 144 symbols and a 2-symbol trailer including a checksum (a 16-bit CRC). Number Figure 7 Example Data Frame with an Odd Number of Payload Bytes 4.2 L2 Control Frames 358 Several types of Control Frames are also used to allow L2 to talk to its peer L2. Inc. The presence of the padding byte is flagged in the Frame’s trailer. 16 1 0 0 0 1 0 15 14 13 12 11 10 ESC_DL 9 6 5 SOF L2 payload L2 payload L2 payload 8 7 4 TC 3 2 1 0 Reserved ESC_DL EOF_EVEN CCITT CRC-16 Frame Seq. 16 1 0 0 0 1 0 15 14 13 12 11 10 ESC_DL 9 6 5 SOF L2 payload L2 payload 8 7 4 TC 3 2 1 0 Reserved L2 payload ESC_DL Padding Byte = 0x00 EOF_ODD CCITT CRC-16 Frame Seq. Copyright © 2007-2011 MIPI Alliance. All rights reserved. to enable L2 flow control and to handle transmission errors.40.Version 1. See Figure 8 and Figure 9. Control Frames do not contain Application data. Unlike Data Frames.1 L2 Data Frames 356 The Data Link Layer clusters the 17-bit PA_PDU symbols into Data Frames. See Figure 7. MIPI Alliance Member Confidential 46 .9.00 31-Jan-2011 MIPI Alliance Specification for UniPro 4. Every Data Frame consists of a 1-symbol header. Number Figure 6 Example Data Frame with an Even Number of Payload Bytes 357 Payloads with an odd number of bytes are extended with an extra padding byte at the end of the L2 payload area. Note that although some of the 144 payload symbols are used by higher protocol layers (L3. a Data Frame should typically be able to hold 256-byte Application payloads. These Control Frames are known as AFC (for Acknowledgment and L2 Flow Control) and NAC (for signaling errors and triggering retransmission) Frames and can be identified using bits [7:5] in the first symbol of the L2 header. L4 and LA). See Figure 6.

363 If the transmitter sends Data Frames.g. but are not covered by an acknowledgement or retransmission request scheme themselves. 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). due to thermal noise. Correctly received Data Frames are acknowledged by sending Acknowledgment Control Frames or AFC (Acknowledgment and Flow Control) Frames. but receives neither an AFC nor a NAC Frame within a certain time interval. 16 1 0 15 14 13 12 11 10 9 8 7 6 NAC 5 4 3 2 1 0 RReq ESC_DL Reserved CCITT CRC-16 Figure 9 NAC Control Frame Structure 360 NAC Frames are sent back to the transmitter after certain L2 error conditions are detected by the receiver.40. A credit-based flow control mechanism is used whereby the receiver sends credit information (in the form of AFC Frames) to update credit information maintained at the transmitter. e. Copyright © 2007-2011 MIPI Alliance. AFC Frames inform the transmitter that all Data Frames up to a particular Frame Sequence Number have been properly received. the transmitter will automatically retransmit. 362 A transmitter is also notified by the receiver of CRC errors or certain other errors via Negative Acknowledgment Control (NAC) Frames.4 L2 Flow Control 364 One key L2 feature is the provision of link-level flow control. Such timeouts can occur because AFC and NAC Frames can be lost or corrupted themselves. Data Frames contain Frame Sequence Numbers that are incremented in each successive Frame. or burst errors. All rights reserved. This option is referred to as Group Acknowledgement. In contrast. This allows multiple Data Frames to be acknowledged by a single AFC Frame to improve bandwidth utilization.Version 1. 4.9.g. Inc. or “replay”. L2 flow control ensures that the transmitter knows how much buffer space is available at L2 of the receiving end of the Link – thus preventing L2 buffer overflow and thus avoiding data loss.3 L2 Retransmission on Errors 361 Occasional bit errors.00 31-Jan-2011 MIPI Alliance Specification for UniPro 16 1 0 0 15 12 11 10 9 8 7 6 5 4 3 2 1 0 CReq Reserved ESC_DL AFC TC Frame Seq. the unacknowledged Data Frames from a transmit-side buffer.9. Number Reserved Credit Value CCITT CRC-16 Figure 8 AFC Frame Structure 14 13 359 AFC Frames are generally encountered as a result of Data Frame transmission: as Data Frames are sent. a stream of AFC Frames generally indicates that things are going well. 4. occurring on the PHY are detected at the receiver. e. MIPI Alliance Member Confidential 47 . due to EMI.

10. UniPro currently supports two Traffic Classes called TC0 and TC1.40. When a Packet is passed down to L2.9. UniPro thus also supports Devices that support only TC0.1 L3 Packets 371 The Network Layer introduces a new PDU known as a Packet.5.7). 4.5 L2 Traffic Classes and Priorities 365 Another feature of the Data Link Layer is the multiplexing of Frames belonging to different Traffic Classes. the upper layers of the UniPro stack are described as if TC0 and TC1 are both present because this is the most general and likely the most common case. 4. An Application running on top of a UniPro stack is responsible for using the appropriate TC.1 Short Header Packets 372 Most Packets on a UniPro network are typically Short Header Packets. The presence of such a single-TC Device is automatically detected by its peer Device during Data Link Layer initialization (see Section 6. These Packets consist of a one byte Short Header followed by L3 payload bytes (see Figure 7). 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. 368 In this specification. 4.5.10 Network Layer (L3) 370 The purpose of the Network Layer is to allow data to be routed to the proper destination in a networked environment. The details of the network switches needed for this routing will be defined in a future version of the UniPro specification.Version 1. 4. All rights reserved.2 Single-TC Devices 367 Each Traffic Class requires a certain amount of L2 buffering at both the transmit side (for retransmission) and the receive side (for CRC checking).9. Data Frames sent as TC1 have higher priority than Data Frames sent as TC0.1. Long Header Packets. 369 A Single-TC Device only supports TC0. Copyright © 2007-2011 MIPI Alliance.10. Control Frames such as NAC have an even higher priority. which will be defined in a future UniPro specification. This header byte contains a 7-bit destination address to enable Packet routing.1 Frame Preemption 366 The L2 transmitter can choose to interrupt or “preempt” an ongoing Data Frame transmission in order to send a higher priority Data Frame or Control Frame as soon as possible. Inc. MIPI Alliance Member Confidential 48 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 4. Support for the missing TC in higher protocol layers can be optimized away in an implementation. and Short Header Packets.9. 4.

Because Device identifiers (DeviceIDs) need to be unique within a Network they are either assigned at design time or when the Network is initialized. but may be addressable as multiple Devices. Inc.40.11 Transport Layer (L4) 376 The Transport Layer is the highest UniPro protocol layer involved in the transportation of data. All data sent over a single Connection has the same Traffic Class (TC0 or TC1).00 specification to handle Packets with long headers via a software change only.2 L3 Devices and DeviceIDs 374 UniPro supports Networks of up to 128 Devices. This Long Header trap feature allows Packets where the L3s=0 to be passed to a software entity (not covered by the UniPro specification). 4. Copyright © 2007-2011 MIPI Alliance. The latter is needed to ensure in-order delivery within a Connection. an endpoint can have multiple simultaneous Connections to multiple Devices. Connections can span a single hop or multiple hops using switches. It thus provides the data service interface (T_SAP or “CPorts”) that is used by hardware or software using UniPro.00 31-Jan-2011 MIPI Alliance Specification for UniPro 16 1 0 0 0 1 0 15 L3s=1 14 13 12 11 10 9 8 7 6 SOF 5 4 TC 3 2 1 0 ESC_DL DestDeviceID_Enc L3 payload L3 payload ESC_DL Reserved L3 payload L3 payload L3 payload EOF_EVEN CCITT CRC-16 Frame Seq. This feature is intended to allow Devices that support the UniPro v1. on a Network.1 L4 Connections 377 The Transport Layer supports multiple bidirectional Connections (T_CO_SAP) between endpoint Devices. MIPI Alliance Member Confidential 49 .40. logical Packet streams or “Connections”. 4. A pair of endpoint Devices can communicate via multiple Connections and.10. All rights reserved. 378 UniPro guarantees that data sent over a single Connection arrives in the order in which it was sent. Layer 3 provides a Long Header trap to allow software extensions to support certain future UniPro mechanisms. These mechanisms allow a single physical Packet stream between two Devices to support multiple. This software entity is also known as the Network Layer extension.2 Example Short Header Packet Encapsulated within an L2 Data Frame Long Header Packets 373 A future UniPro specification will include support for Long Header Packets (L3s=0). Similarly a multi-die package may at the package level have a single off-chip UniPro Link. 375 Note that a Device is not necessarily a physical component: a single integrated circuit can contain multiple individually addressable Devices interconnected by a Network switch.11.Version 1. the Transport Layer tends to concentrate on relatively abstract mechanisms. It also allows software to provide the entire payload of the L2 Data Frame. Number Figure 10 4.1. Connections can be regarded as virtual private wires between Devices on the shared Network. Unlike lower protocol layers. 4. independent.10.

All rights reserved. are internal sub-addresses that distinguish between the different Connections and thus different data streams to the same Device. When a Segment is passed down to L3.1 Short Header Segments 382 A Short Header Segment (see Figure 11. A Short Header Segment is always shipped inside a Short Header Packet. A Short Header Segment is typically used to carry L4 payload after an L4 Connection has been established. CPorts within a Device are identified using integer values between 0 and 2047 (although values above 31 should be used sparingly because they reduce the number of addressable L3 Devices). 385 Every Connection connects exactly one CPort in one Device to a CPort in another Device.11. A Connection can therefore connect CPort 1 of Device 2 to CPort 3 of Device 7. 381 For example.11.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 4.11. 4. Inc. each using a different Application-level protocol and potentially using a different Traffic Class. In addition. 16 1 0 0 0 1 0 15 L3s=1 14 13 12 11 10 9 8 7 L4s=1 6 SOF 5 4 TC 3 2 1 0 ESC_DL DestDeviceID_Enc L4 Payload L4 Payload ESC_DL Reserved FCT EOM DestCPortID_Enc L4 Payload L4 Payload EOF_EVEN CCITT CRC-16 Frame Seq.3 Communicating between L4 CPorts 383 The interface between the Transport Layer and the Application Layer is structured as a collection of CPorts (Connection-oriented Ports). MIPI Alliance Member Confidential 50 . the exact order of Segments received over multiple Connections is undefined. a Device with four CPorts can support up to four simultaneous Connections. 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.2 L4 Segments 379 The PDUs of the Transport Layer are called Segments. 384 CPorts can be considered as sub-addresses within a Device: the Device is identified by an L3 DeviceID while its CPorts.g. e. CPorts are thus in principle a scarce resource within an endpoint because every CPort has an independent state which needs to be maintained. L4s=1) consists of a single-byte L4 header followed by up to 272 bytes of payload. CPort 0. 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). Each CPort corresponds to a single SAP. Segments transmitted over a Connection need to adhere to the same Application-level protocol.40. a UniPro-based display protocol may transmit its pixel stream and its command stream using two different Connections.2. Number Figure 11 Example of a Short Header Segment in a Short Header Packet in an L2 Frame 4. In other words. Most Segments are Short Header Segments. Every CPort can be associated with at most one Connection at any time. Copyright © 2007-2011 MIPI Alliance. 380 Segments belonging to one Connection are guaranteed to arrive in order.3). CPort 3 and CPort 4.11.

11. 389 The signaling of Message boundaries also provides options for resynchronizing the higher protocol layers if needed. These ensure that incoming data that cannot be absorbed immediately by the CPort is automatically discarded. 395 The CSV mechanism can be disabled if so desired. and thus risks overflow and. Inc. This loss of data occurs if the destination CPort does not have enough buffer space to store the incoming stream of Segments. data loss. e. therefore. This is possible because the End-of-Message flag always coincides with the end of a Segment.Version 1.6 CSD/CSV Mechanisms within a CPort 392 A CPort is required to immediately absorb any data Segments that it receives from the network. behave like simple Applications. MIPI Alliance Member Confidential 51 . 394 CSD and CSV avoid one source of congestion and improve overall system integrity at the cost of introducing data corruption within the misbehaving Connection. as also illustrated in Annex D. a Message can range from a command consisting of only a few bytes to an entire multi-MByte data stream transported over the Connection. the source CPort cannot know how much buffer space is free at the destination. the granularity at which Message (Fragments) are transmitted may have any arbitrary small granularity. or “dropped”. at the receiving endpoint. 388 Although the Application data unit is a Message. The Test Feature also Copyright © 2007-2011 MIPI Alliance. In an implementation.11. L4 also provides an end-to-end flow control (E2E FC) feature. These are located at the top of the UniPro stack and. This is undesirable for performance and system reliability reasons (deadlocks).40.5 End-to-End Flow Control in L4 390 In addition to providing the resources that are needed to support Connections and multiplex their traffic onto a shared Link.7 Test Features 396 UniPro implementations can be tested using so-called Test Features. the end of a Packet and the end of a Frame. Triggering of the CSD and CSV mechanisms typically indicates a Device malfunction such as a design error or a crashed software Application. or backpressure.11. when enabled. 391 Although E2E FC can be disabled. 4. 393 The solution is a pair of mechanisms within a CPort respectively known as Controlled Segment Dropping (CSD) and CPort Safety Valve (CSV). 4. leading to data corruption. L4 is responsible for splitting. Message-based resynchronization can be relevant in special cases such as when Segments are discarded. 387 UniPro thus does not impose a size limit on Messages.11. If E2E FC is turned off. With E2E FC disabled. This mechanism ensures that the transmitting CPort never sends more data over a Connection than can be absorbed by the destination CPort’s buffer. or “segmenting”. Failure to do so could lead to filling up of the L2 receive buffers for the associated Traffic Class which could in turn lead to blocking of Segments addressed to other CPorts or even (in a Network) to other Devices. the feature is enabled on reset and disabling it is not generally recommended if the Application protocol using this CPort does not implement a E2E FC mechanism. incoming Messages.00 31-Jan-2011 MIPI Alliance Specification for UniPro 4. All rights reserved. There is no guarantee that the received Message Fragments have the same size as the transmitted Message Fragments or L4 Segments. 4. This option can be useful when specifying Applications on top of a UniPro stack that need to interrupt the Message creation based on information from the UniPro stack. the T_SAP offers the option to also transfer Message Fragments.4 The L4 SAP and Messages 386 An Application can submit data for transmission to L4 in the form of arbitrary-length data units known as Messages. L4 may need to discard Segments.g. the Messages into Segments. A Test Feature consists of a traffic generator that produces a well-defined sequence of bytes (structured as Messages)..

397 The built-in Test Features are mainly intended to allow a UniPro stack within a Device to be checked for design. 0x4021. such as T_PeerDeviceID. 4. The symbolic name is referenced in the text and SDL when the Attribute impacts particular protocol behavior. this Attribute determines the remote Device which a given CPort is connected to and is copied into L3 Packet headers. 4. Copyright © 2007-2011 MIPI Alliance.40. e. a 16-bit identifier.g. to configure the number of active Data Lanes. Attributes have both a symbolic name. 3.g. and in many cases written (“set”) via the DME. Those values can be overwritten via the DME if desired using a specific form of the SET operation. 403 Attributes have both a symbolic name.00 31-Jan-2011 MIPI Alliance Specification for UniPro contains a matching data analyzer that checks the correctness of the incoming data stream against the expected data traffic. for example. eFuse. an additional index or “selector” is required to distinguish multiple CPorts or Test Features because each has its own set of Attributes. number of CPorts. manages the power mode transitions of the Link. e. 4. It provides access to various control parameters in all layers. Others are dynamic and reflect the current (read-only) UniPro stack status. In principle. e.2 Control Interfaces 404 Layers 1. L2. Others can be set to control parts of the protocol stack. any Device can take the initiative to start sending data to any other Device on the Network. e. There is thus no master/slave distinction at the UniPro stack level. Inc. configuration is currently done via a control SAP named T_LM_SAP (“Layer Management”).12 DME 399 The Device Management Entity (see Figure 3) controls the layers in the UniPro stack.5.12. and in some cases an extra index or “selector”. All rights reserved. for example. and handles bootup. The “selector” index is used to distinguish multiple CPorts as each CPort has its own state Attributes. hibernate and reset of the entire UniPro stack.5. and a 16 bit identifier.g. Thus. After a value is overwritten it becomes the new persistence value the specific Attribute. In some cases. 0x1560.12. 402 For the Transport Layer. such as PA_ActiveTxDataLanes. Thus. UniPro is designed to support networks of Devices. 401 Persistent Attributes may be stored and provisioned in a form of Non Volatile Memory. the PHY Layers and associated wiring.13 Supported Topologies 405 Although switches for routing in networks are not supported in this version of UniPro.and conformance problems in a well-defined and readily automated way [MIPI03]. 4. e. MIPI Alliance Member Confidential 52 . Some Attributes are static and are defined at design time and describe the capabilities of the UniPro interface. 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. and 4 are controlled from the DME by “Layer Management” SAPs. in the example of T_PeerDeviceID. available space in L4 buffers.1 Control Attributes 400 The layers of the UniPro stack (L1.Version 1. L3 and L4) contain registers or “Attributes” that can be read (“get”). etc. 406 UniPro Networks are symmetrical in that Endpoints are peer Devices during normal operation.g.g. the Transport Layer is configured via an SAP named T_LM_SAP (see Figure 3). 2.

and the intermediate Switch. a Device such as a host processor can use a UniPro Link to connect to multiple other Devices.1 Point-to-Point Links 407 At the physical level. The other Network consists of the Links connecting Devices A.13. C. A Device on one Network. in this example. One Network consists of the Link between Devices A and B. 410 In the example shown in Figure 13. because there is no provision in UniPro to route data from one Link to another. The Switch is not covered by this version of UniPro yet. Copyright © 2007-2011 MIPI Alliance. In the figure.40. As shown in Figure 12. E. 409 Networked topologies might be desirable to reduce the cabling in systems where the components are located in physically separate chambers such as in a mobile flip-phone. D.g. two independent Links connect Device A to other Devices in the system. However. may have the same DeviceID as a Device on the other Network.00 31-Jan-2011 MIPI Alliance Specification for UniPro 4.2 UniPro Networks 408 For more complex systems. While Device B can only communicate using UniPro protocols with Device A. e. a Switch can be added to route data between the Devices.13. UniPro only supports point-to-point Links between pairs of Devices as these support the required high data rates.g. this means that Device D cannot communicate with Device C using only UniPro protocols. e. All rights reserved. but is relevant to understand the overall architecture. Device B. 411 Note that Figure 13 essentially shows two independent Networks. Display Module #1 Camera Sensor (Device D) UniPro Bidirectional Link UniPro Bidirectional Link Host Processor (Device A) Display Processor (Device C) Non-UniPro Unidirectional Link Display Module #2 RF PHY Cellular MODEM (Device B) Non-UniPro Bidirectional Link Figure 12 Point-to-Point Configuration Example 4. Any communication between these two Networks is outside the scope of this document. Device D. particularly those requiring a true Network.Version 1. Device D can communicate directly with Device A. MIPI Alliance Member Confidential 53 . Device C and Device E. Inc. the UniPro Links are independent and do not work together to form a Network as.

UniPro Bidirectional Link Display Module #1 (Device E) Host Processor (Device A) Display Processor (Device C) Switch Non-UniPro Unidirectional Link UniPro Bidirectional Link UniPro Bidirectional Link Display Module #2 RF PHY Cellular MODEM (Device B) Non-UniPro Bidirectional Link Camera Sensor (Device D) Figure 13 UniPro Network Configuration Example Copyright © 2007-2011 MIPI Alliance. All rights reserved. a parallel CMOS interface. and might instead use. Although Switches can be implemented as discrete components on separate integrated circuits.40.Version 1. Since the PHY Layer is designed for off-chip communication. they may alternatively be integrated onto the same die as Devices to avoid increasing the component count.00 31-Jan-2011 MIPI Alliance Specification for UniPro 412 Figure 13 shows the Switch as a logically separate component for clarity. for example. Inc. the connection between a Switch and a Device on the same die might likely avoid using a high-speed serial PHY Layer. MIPI Alliance Member Confidential 54 .

5) PHY SAP PHY Lane 0 PHY SAP PHY Lane 1 PHY SAP Data Plane PHY Adapter Layer Entity PA_ MIB PHY SAP PHY Lane 3 PHY Lane 2 Optional Data Lanes Figure 14 PHY Adapter Layer SAP Model 415 The PHY Adapter ensures that the UniPro protocol is independent of the PHY technology.1 418 419 420 421 422 • • • • • PHY Adapter Layer Service Functionality and Features Transmission and reception of Data Link Layer control symbols and data symbols via underlying PHY Lane distribution and merging in multi-Lane ports Provision of UniPro power management operating modes (Re-)Initialization of the PHY TX path Access to all M-PHY Attributes of all available Lanes 417 The PA Layer service defined in this specification provides: Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5 PHY Adapter Layer (L1. MIPI Alliance Member Confidential 55 . Note that this figure only shows PHY Data Lanes. 414 Figure 14 shows the SAP model used by the PHY Adapter Layer.5) 413 The PHY Adapter (PA) Layer is an intermediate layer between L1 and L2 (see Figure 3). a UniPro implementation shall use a physical layer compliant with [MIPI01] or [MIPI05]. All rights reserved. Inc. respectively. The PA Layer service to the Data Link Layer is provided by means of the PHY Adapter Service Access Point (PA_SAP). 416 For off-chip communication. PHY Adapter Layers for D-PHY and M-PHY are called PA D-PHY and PA M-PHY. Note that an on-chip implementation of UniPro is not restricted to any specific set of physical layer technologies.40. To do so. The PA Layer in turn relies on the service provided by the PHY Service Access Points (PHY_SAPs).Version 1. 5. Future versions of the UniPro specification may support and allow alternative physical layers for off-chip usage. Data Link Layer (L2) Device Management Entity (DME) PA_LM SAP PA_SAP Management Plane PA_LM Entity PHY Adapter Layer (L1. it hides internal implementation details of the PHY from the Data Link Layer. The PHY Adapter Layer Management SAP (PA_LM_SAP) is provided to the Device Management Entity (DME) for configuration and control purposes. potential PHY Clock Lanes are not shown.

1. D = PA D-PHY supported. while the Control primitives are needed for (re-)initialization of the Link.3.3. MIPI Alliance Member Confidential 56 .3. Inc.6 Confirm PA1 D.3.8 Local Confirm 5. including access to PHY escape symbols Transmission of PHY IDLE symbols when no data is supplied.3.00 31-Jan-2011 MIPI Alliance Specification for UniPro 423 These services are offered independently from the PHY technology. as described in Section 5.1. Control primitives and Status primitives.7 Local Response Response 5. 5. The PHY_SAP is defined by the relevant MIPI PHY specification.3. Table 1 Name PA_DATA PA_ESCDATA Request 5.1 5.1.5 PA_SAP Data Transfer Primitives Indication 5.2 Features Assumed from the PHY Layer 424 A PA Layer is associated with each PHY entity via its PHY_SAP. All rights reserved.3 PA_SAP 432 The PA_SAP offers three groups of Service Primitives: Data Transfer primitives. 433 The Data Transfer primitives enable data transmission and reception.2 5.1.1. Indication that PHY IDLE symbols were received.40. 5.4 5.1 Data Transfer Primitives 435 The primitives covered in this section are listed in Table 1.1.3. A method to re-initialize the forward Link to overcome error situations Provision of different power modes and a method to signal them from transmitter to receiver 431 When a PHY provides these basic features. Status primitives are used to indicate PA Layer status information. the PHY Adapter will be able to implement the required PA Layer services for the Data Link Layer.1. M = PA M-PHY supported. such as identified errors.3 5. 5. M D. Just a basic set of features is required from the PHY. 434 The primitives on this SAP are used by the Data Link (DL) Layer. Escaped payload data Copyright © 2007-2011 MIPI Alliance. 425 The PA Layer requires the following features provided by the PHY: 426 427 428 429 430 • • • • • Transmission and reception of encoded PHY symbols.2.Version 1. to the Data Link Layer. Table 2 Name Data EscType EscParam Type Integer Enumeration Integer PA_SAP Data Transfer Primitive Parameters Valid Range 0 to 65535 ESC_DL 0 to 255 Description Normal payload data Escaped data type (See Table 51).1. M 1. 436 The parameters used for these primitives are defined in Table 2.3.3.

Version 1.3.req or PA_ESCDATA. 5.3 PA_DATA. Inc.req primitive.1.cnf_L( ) 450 When Generated 451 This primitive shall be generated by the PA Service Provider after the receipt of a PA_DATA. MIPI Alliance Member Confidential 57 . L1. respectively.1 PA_DATA. Copyright © 2007-2011 MIPI Alliance.req primitive.cnf_L or PA_ESCDATA.3.3.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.40. 452 Effect on Receipt 453 Following the emission of a PA_DATA.req primitive and prior to the reception of a PA_DATA.1.req or PA_ESCDATA.req primitive to transmit a DL Layer data symbol over the Link. 458 The semantics of this primitive are: 459 PA_DATA. is ready to accept a new PA_DATA.ind 457 This primitive reports the reception of a DL data symbol over the Link. the PA Service User shall not emit a new PA_DATA.1. 441 When Generated 442 The DL Layer shall generate a PA_DATA.cnf_L 447 This primitive informs the PA Service User that the Service Provider.5 in this case.2 PA_DATA.ind( Data ) 460 The primitive parameter is defined in Table 2. 438 The semantics of this primitive are: 439 PA_DATA.req primitive.req 437 This primitive requests the transmission of payload data.req or PA_ESCDATA. 443 Effect on Receipt 444 The PA Layer shall transfer the payload over the Link via the underlying PHY.req( Data ) 440 The primitive parameter is defined in Table 2.req primitive. 448 The semantics of this primitive are: 449 PA_DATA.req primitive immediately following a reset or after the reception of the PA_DATA.cnf_L primitive corresponding to a previously emitted PA_DATA.cnf_L primitive. when the PA Service Provider can accept a new request to transfer a new DL Layer symbol. All rights reserved. 454 The PA Service User may emit a new PA_DATA. 445 Behavioral Description 446 The state diagram describing the behavior of the primitive is shown in Figure 98 of [MIPI02]. 5. 455 Behavioral Description 456 The state diagram describing the behavior of the primitive is shown in Figure 98 of [MIPI02].

5. the PHY Adapter Layer shall not emit a new PA_DATA. Copyright © 2007-2011 MIPI Alliance. 482 Effect on Receipt 483 The PA Layer shall transfer the EscType and EscParam information over the Link via the underlying PHY.ind or PA_ESCDATA. 5.1. is ready to accept a new PA_DATA. EscParam ) 479 The primitive parameters are defined in Table 2.ind primitive.req primitive to transmit an escaped DL Layer data symbol over the Link.ind or PA_ESCDATA.40. it shall consume the Data PA_PDU. L2 in this case.ind primitive. 463 Effect on Receipt 464 When the DL Layer receives this primitive. 468 The semantics of this primitive are: 469 PA_DATA. MIPI Alliance Member Confidential 58 .5 PA_ESCDATA.1.ind or PA_ESCDATA. 480 When Generated 481 The DL Layer shall generate a PA_ESCDATA.req 476 This primitive requests the transmission of escaped payload data.ind primitive and prior to the reception of a PA_DATA. or after reception of the PA_DATA. 477 The semantics of this primitive are: 478 PA_ESCDATA. The reception of an Escaped Data PA_PDU shall not generate this primitive.rsp_L or PA_ESCDATA.ind primitive.ind primitive only just after reset. 474 Behavioral Description 475 The state diagram describing the behavior of the primitive is shown in Figure 35 of [MIPI02].rsp_L( ) 470 When Generated 471 This primitive shall be generated by the PA Service User after the receipt of a PA_DATA.rsp_L 467 This primitive informs the Service Provider that the PA Service User. Inc. The corresponding escaped payload data is given with the EscParam parameter.4 PA_DATA.ind or PA_ESCDATA. The EscType parameter defines the type of escaped data.rsp_L primitive. respectively.ind primitive.req( EscType. All rights reserved.ind primitive. The PHY Adapter Layer may emit a new PA_DATA.00 31-Jan-2011 MIPI Alliance Specification for UniPro 461 When Generated 462 This primitive shall be generated by the PA Layer when a Data PA_PDU is received over the Link.rsp_L primitive corresponding to a previously emitted PA_DATA. 465 Behavioral Description 466 The state diagram describing the behavior of the primitive is shown in Figure 35 of [MIPI02].Version 1. 472 Effect on Receipt 473 Following the emission of a PA_DATA.3. when the PA Service User can accept a new PA_DATA.3.

req primitive and prior to the reception of a PA_ESCDATA.req primitive.req primitive. L1.cnf_L primitive. it shall consume the EscType and EscParam information.req or PA_ESCDATA.1.req primitive. Copyright © 2007-2011 MIPI Alliance. 494 Behavioral Description 495 The state diagram describing the behavior of the primitive is shown in Figure 98 of [MIPI02]. 504 Behavioral Description 505 The state diagram describing the behavior of the primitive is shown in Figure 35 of [MIPI02]. respectively.6 PA_ESCDATA. 502 Effect on Receipt 503 When the DL Layer receives this primitive. EscParam ) 499 The primitive parameters are defined in Table 2.40.req or PA_ESCDATA.cnf_L or PA_ESCDATA. 500 When Generated 501 This primitive shall be generated by the PA Layer when an Escaped Data PA_PDU is received over the Link via the underlying PHY and the EscType field of the PA_PDU is equal to ESC_DL. 493 The PA Service User may emit a new PA_ESCDATA.00 31-Jan-2011 MIPI Alliance Specification for UniPro 484 Behavioral Description 485 The state diagram describing the behavior of the primitive is shown in Figure 98 of [MIPI02].3. The reception of Escaped Data PA_PDUs with EscType equal to ESC_PA shall not generate this primitive. 487 The semantics of this primitive are: 488 PA_ESCDATA.ind 496 This primitive reports the reception of a DL Control symbol. 491 Effect on Receipt 492 Following the emission of a PA_ESCDATA.7 PA_ESCDATA.5 in this case. when the PA Service Provider can accept a new request to transfer a new DL Layer symbol.3.cnf_L primitive corresponding to a previously emitted PA_DATA.Version 1. Inc.req primitive immediately following a reset or after the reception of the PA_DATA.ind( EscType. 5. is ready to accept a new PA_DATA. MIPI Alliance Member Confidential 59 .req primitive.1.req or PA_ESCDATA. the PA Service User shall not emit a new PA_DATA.cnf_L( ) 489 When Generated 490 This primitive shall be generated by the PA Service Provider after the receipt of a PA_ESCDATA. 5. 497 The semantics of this primitive are: 498 PA_ESCDATA. All rights reserved.cnf_L 486 This primitive informs the PA Service User that the Service Provider.

5 5.3 5.ind primitive.2.ind primitive. Inc.ind or PA_ESCDATA.2 5.3. Table 4 Name PAResult Type Boolean PA_SAP Control Primitive Parameters Valid Range FALSE TRUE 0 1 Description Result of the operation Copyright © 2007-2011 MIPI Alliance.ind.2.2. M 1. The PHY Adapter Layer may emit a new PA_DATA. 516 The INIT primitive is represented as request with associated confirmation.1. L2 in this case.8 PA_ESCDATA. 517 The parameters used for these primitives are defined in Table 4. 511 Effect on Receipt 512 Following the emission of a PA_ESCDATA. D = PA D-PHY supported. M M M D. This primitive is prefixed by “PA” for the PA_SAP.3.2. is ready to accept a new PA_DATA.1 PA_SAP Control Primitives Indication Local Response Response Local Confirm 5.rsp_L primitive. The primitive is summarized in Table 3.ind primitive only just after reset.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. Table 3 Name PA_INIT PA_DL_PAUSE PA_DL_RESUME PA_LANE_ALIGN 5.3.3. 5.7 5.ind or PA_ESCDATA.ind or PA_ESCDATA.3.3. the PHY Adapter Layer shall not emit a new PA_DATA. MIPI Alliance Member Confidential 60 .40.Version 1. 513 Behavioral Description 514 The state diagram describing the behavior of the primitive is shown in Figure 35 of [MIPI02].2.ind or PA_ESCDATA.6 Request 5. All rights reserved.rsp_L( ) 509 When Generated 510 This primitive shall be generated by the PA Service User after the receipt of a PA_ESCDATA.ind primitive. respectively.3.ind primitive. when the PA Service User can accept a new indication PA_DATA. M = PA M-PHY supported.2 Control Primitives 515 The Control primitives of the PA_SAP are used by the DL Layer to control the PHY Adapter Layer.rsp_L 506 This primitive informs the Service Provider that the PA Service User.ind primitive and prior to the reception of a PA_ESCDATA.4 Confirm PA1 D.3.2. or after reception of the PA_DATA.3.2.rsp_L or PA_ESCDATA.rsp_L primitive corresponding to a previously emitted PA_DATA. 507 The semantics of this primitive are: 508 PA_ESCDATA.

that the PA Layer was requested to execute a operation that requires the usage of the Link. the PA Layer and PHY receive paths are also (re)initialized.ind 537 This primitive informs the PA Service User.g.3.10.1 PA_INIT. MIPI Alliance Member Confidential 61 .2. Refer to Section 6 for details. this request (re)initializes only the transmit path.7.3.cnf_L primitive. All rights reserved.cnf_L( PAResult ) 531 When Generated 532 This primitive shall be generated by the PA Layer as response to a PA_INIT. For M-PHY. 523 Effect on Receipt 524 The PA Layer (re-)initializes its transmit path. For a description of the (re-)initialization process on D-PHY and M-PHY see Section 5. the DL Layer in this case. 5.2 PA_INIT. 525 Following the emission of a PA_INIT.req. e. 519 The semantics of this primitive are: 520 PA_INIT.3 PA_DL_PAUSE.req( ) 521 When Generated 522 The DL Layer generates this request to (re-)initialize the PA Layer and underlying PHY. otherwise the parameter is set to FALSE. it performs the necessary actions to (re-)initialize the underlying PHY transmit path. Copyright © 2007-2011 MIPI Alliance. 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. both transmit and receive paths are (re-)initialized.2. The parameter is set to TRUE if the operation completed successfully. 529 The semantics of this primitive are: 530 PA_INIT. the PA Layer shall wait for the reception of the PA_DL_PAUSE. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. 535 Behavioral Description 536 The state diagram describing the behavior of the primitive is shown in Figure 72 of [MIPI02].req 518 This primitive requests to (re-)initialize the PA Layer and underlying PHY.Version 1. and prior to the reception of a PA_INIT.cnf_L 528 This primitive reports the completion of the (re-)initialization procedure. the PA Service User shall not emit a new PA_INIT.req primitive.3.rsp_L before taking any further action. For D-PHY.40.9 and Section 5.8. power mode change or PACP frame transmission. After generating this primitive.2. 533 Effect on Receipt 534 The DL Layer is informed about the finalization of the (re-)initialization procedure. In the case of M-PHY. when it has performed the (re-)initialization procedure. 526 Behavioral Description 527 The state diagram describing the behavior of the primitive is shown in Figure 70 of [MIPI02]. 5.req primitive. Further. respectively.

3.ind( PAResult ) 558 When Generated 559 This primitive shall be generated by the PA Layer when it has completed its operation. 560 Effect on Receipt 561 When the DL Layer receives this primitive. Copyright © 2007-2011 MIPI Alliance.ind and only when the DL Layer has reached a state where the PA Layer can use the Link (see Section 6.6. the DL Layer in this case.6. 556 The semantics of this primitive are: 557 PA_DL_RESUME.6.3. 547 The semantics of this primitive are: 548 PA_DL_PAUSE. otherwise the parameter is set to FALSE.5). the DL Layer in this case. The parameter is set to TRUE if the operation completed successfully. 5.rsp_L 546 This primitive informs the Service Provider that the PA Service User. it shall continue the execution of the requested operation. 5. it shall resume normal operation knowing that the UniPro Link is once more in a state where Frames can be sent (see Section 6.5).rsp_L( ) 549 When Generated 550 This primitive shall be generated by the DL Layer after receipt of a PA_DL_PAUSE.2. All rights reserved. it shall take the necessary action to reach a state where the Link is temporarily not used (see Section 6. Inc.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 538 The semantics of this primitive are: 539 PA_DL_PAUSE.4 PA_DL_PAUSE.ind 555 This primitive informs the PA Service User.5 PA_DL_RESUME. 551 Effect on Receipt 552 When the PA Layer receives this primitive. 544 Behavioral Description 545 The state diagram describing the behavior of the primitive is shown in Figure 97 of [MIPI02].5).Version 1.2.ind( ) 540 When Generated 541 This primitive shall be generated by the PA Layer when an operation requiring PACP transmission is requested and shall precede any other actions necessary to execute the operation. 553 Behavioral Description 554 The state diagram describing the behavior of the primitive is shown in Figure 97 of [MIPI02]. that the PA Layer has completed its operation and the DL Layer may continue to use the Link. 542 Effect on Receipt 543 When the DL Layer receives this primitive. has reached a state where the Link may be used by the PA Layer. MIPI Alliance Member Confidential 62 .

2. Copyright © 2007-2011 MIPI Alliance.req( ) 567 When Generated 568 The DL Layer shall generate a PA_LANE_ALIGN.3 Status Primitives 583 The ERROR primitive is represented as an indication and is prefixed by “PA” for the PA_SAP. that the Service Provider.2. which results in the PA Layer sending a deskew pattern as described in Section 5. Inc. the PA Layer in this case.cnf_L primitive.cnf_L 574 This primitive informs the PA Service User. MIPI Alliance Member Confidential 63 .3. 5.req primitive to ensure that all Lanes are synchronized (deskewed) and shall not generate a PA_ESCDATA.cnf_L( ) 577 When Generated 578 This primitive shall be generated by the PA Service Provider after receipt of a PA_LANE_ALIGN.8. 569 Effect on Receipt 570 PA M-PHY shall execute Lane Synchronization as defined in Section 5. 584 The primitive is summarized in Table 5. 5.req primitive. after the Lane Synchronization has completed. 572 Behavioral Description 573 The state diagram describing the behavior of the primitive is shown in Figure 103 of [MIPI02].Version 1. has completed the Lane Synchronization previously requested by the primitive PA_LANE_ALIGN.req or PA_DATA.req or PA_DATA. 579 Effect on Receipt 580 The DL Layer shall be allowed again to generate a PA_ESCDATA. 571 PA D-PHY shall ignore this request and respond immediately with a PA_LANE_ALIGN.11. the DL Layer in this case.7 PA_LANE_ALIGN. 575 The semantics of this primitive are: 576 PA_LANE_ALIGN. 565 The semantics of this primitive are: 566 PA_LANE_ALIGN.req.3.3.6 PA_LANE_ALIGN.00 31-Jan-2011 MIPI Alliance Specification for UniPro 562 Behavioral Description 563 The state diagram describing the behavior of the primitive is shown in Figure 97 of [MIPI02]. 581 Behavioral Description 582 The state diagram describing the behavior of the primitive is shown in Figure 104 of [MIPI02].11. 5.req primitive before completion of the Lane Synchronization. All rights reserved.8.40.req primitive.req 564 The DL Layer generates this request to force the PA Layer to execute a Lane Synchronization.

7.8.5) BAD_PA_PARAM: ESC_PA with EscParam_PA other than PACP_START. Table 6 Name Type PA_SAP Status Primitive Parameters Valid Range BAD_PHY_SYMBOL Value 1 2 3 4 Description Error types as identified by the PA Layer and flagged to the L2.7.5. C417 or C600 is received for PA_PDU[7:0] (see Section 5.1 PA_ERROR.40. PAErrorCode identifies the detected error as follows: 593 • 594 • 595 • 596 • BAD_PHY_SYMBOL: an invalid 9b symbol is received (see Section 5.8. PAErrorCode identifies the detected error as follows: 598 • 599 • 600 • 601 • BAD_PHY_SYMBOL: a coding error is detected by the PHY (see Section 5.3. 592 With D-PHY.3.7. Inc.ind 586 This primitive reports errors identified by the PA Layer to the Data Link Layer.5) UNMAPPED_PHY_ESC_SYMBOL: a reserved symbol is detected by the PHY (see Section 5. 0b01101111. TRG_UPR1.5) BAD_PA_PARAM: ESC_PA with EscParam_PA other than 0b00000000. MIPI Alliance Member Confidential 64 .Version 1.4.2.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 5 Name PA_ERROR Request PA_SAP Status Primitive Local Response Response Local Confirm Confirm PA1 D.2 1. 587 The semantics of this primitive are: 588 PA_ERROR. M = PA M-PHY supported.5) UNMAPPED_PHY_ESC_SYMBOL: an undefined 9b symbol is received (see Section 5. All rights reserved. 585 The parameter used for this primitive is defined in Table 6. 590 When Generated 591 This primitive shall be generated by the PA Layer when an error is detected in the incoming stream of symbols.5) UNEXPECTED_PHY_ESC_SYMBOL: C400.ind( PAErrorCode ) 589 The primitive parameter is defined in Table 6. or 0b01110100 is received (see Section 5. M Indication 5.2) 597 With M-PHY. TRG_UPR2 (see Section 5. D = PA D-PHY supported.3. PAErrorCode Enumeration UNMAPPED_PHY_ESC_SYMBOL UNEXPECTED_PHY_ESC_SYMBOL BAD_PA_PARAM 5.5) Copyright © 2007-2011 MIPI Alliance. TRG_UPR0.8.5) UNEXPECTED_PHY_ESC_SYMBOL: a Marker or a FILLER is received for PA_PDU[7:0] (see Section 5.8.

respectively.4. D = PA D-PHY supported.1.4.M D. for the configuration Attributes in the PA_MIB.1. Status primitives are generated by the PA Layer and can occur concurrently.1. 610 The Status primitives indicate status information of the PA Layer. 608 The Configuration primitives enable access to configuration information specific to the PA Layer.4.4. depending on their position relative to the PA symbol.15 5.13 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro 602 The PA_ERROR. Control primitives and Status primitives.4 5. 5. Table 7 Name PA_LM_GET PA_LM_SET PA_LM_PWR_MODE PA_LM_PWR_MODE_CHA NGED PA_LM_PEER_GET PA_LM_PEER_SET 5. Inc.12 5.M M M M M 1.4.4. 612 The GET and SET primitives are represented as requests with associated confirm primitives.1. The PA_MIB is regarded as “contained” within the PA_LM entity.Version 1. M = PA M-PHY supported.4.3 PA_LM Configuration Primitives Indication Local Response Response Local Confirm 5.2 5.8 5.9 5. Copyright © 2007-2011 MIPI Alliance.ind primitives.4.1. The primitives are summarized in Table 7.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.1.11 5. GET and SET.14 Request 5.4.6 Confirm PA1 D.1. All rights reserved. Control primitives are generated by the DME and can occur concurrently.4. This information is represented as a PHY Adapter Layer-specific Management Information Base (PA_MIB).10 5. are used by the DME to retrieve and store values.4.4 PA_LM_SAP 607 The PHY Adapter Layer Management (PA_LM) SAP offers three groups of Service Primitives: Configuration primitives. Multiple accesses to the PA_MIB via the Configuration primitives shall not occur concurrently.4.5 5. 603 Effect on Receipt 604 Refer to the Data Link Layer definitions for details.1.1. 609 The Control primitives provide direct control of the PA Layer.4.1.40.1. 605 Behavioral Description 606 The state diagram describing the behavior of the primitive is shown in Figure 37 of [MIPI02].9.1 Configuration Primitives 611 The PA_LM configuration primitives.1. MIPI Alliance Member Confidential 65 .1.1.1.7 5.1 5.4.4. 5. 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. The available configuration Attributes are defined in Section 5. These primitives are prefixed by PA_LM.4.

Table 8 Name Type Configuration Primitive Parameters Valid Range Any MIB Attribute as defined in Section 5. for CPort 0 to T_NumTestFeatures – 1. or a PHY Attribute (range 0x00000x0FFF) Value Description The Attribute identifier of the MIB Attribute Indicates the targeted M-PHY lane when relevant The Attribute identifier of the MIB Attribute Indicates the targeted logical M-PHY data Lane or CPort Test Feature when relevant The value of the MIB Attribute 0 Select whether Attribute value is set directly (normal) or static value is set.40.Version 1. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 66 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 613 The parameters used for these primitives are defined in Table 8. for Test Feature MIBvalue AttrValueType As defined in Section 5.9 NORMAL AttrSetType Enumeration STATIC 1 SUCCESS INVALID_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE READ_ONLY_MIB_ATTRIBUTE ConfigResultCode Enumeration WRITE_ONLY_MIB_ATTRIBUTE BAD_INDEX LOCKED_MIB_ATTRIBUTE PEER_COMMUNICATION_FAILURE BUSY PAPowerModeUser Data Data 0 1 2 3 4 5 6 8 9 24-byte data payload. Inc.9 (range 0x1000 to 0x1FFF). for M-PHY 0 to T_NumCPorts – 1. PowerChangeResult Code Enumeration Table 9). Result code of a power mode change operation (see Indicates the result of the request. MIBattribute Integer SelectorIndex Integer 0 to 2*PA_MaxDataLanes-1 GenMIBattribute Integer Any MIB Attribute GenSelectorIndex Integer 0 to 2*PA_MaxDataLanes – 1. All rights reserved.

req( MIBattribute. For Attributes not associated with the SelectorIndex. 622 Behavioral Description 623 The state diagram describing the behavior of the primitive is shown in Figure 24 of [MIPI02]. 620 Effect on Receipt 621 The PA_LM entity attempts to retrieve the requested MIB Attribute value from PA_MIB or the underlying PHY and responds with PA_LM_GET. The remote request was successfully applied. All rights reserved.Version 1. the SelectorIndex shall be ignored.2 PA_LM_GET.4.cnf_L 624 This primitive reports the result of an information request about a given PA_MIB Attribute or a PHY Attribute. The request was aborted due to a communication problem. The local request was successfully applied.cnf_L( ConfigResultCode. The request was aborted due to concurrent requests.40. MIBvalue ) Copyright © 2007-2011 MIPI Alliance. 615 The semantics of this primitive are: 616 PA_LM_GET. if relevant.4. SelectorIndex ) 617 The primitive’s parameters are defined in Table 8. and. MIPI Alliance Member Confidential 67 .1 PA_LM_GET.1. Inc.req 614 This primitive requests information about a given PA_MIB Attribute or PHY Attribute identified by MIBattribute.cnf_L that gives the result. the SelectorIndex. 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 8 Name GenericErrorCode Configuration Primitive Parameters (continued) Valid Range Success Failure Value 0 1 Description Result of the operation Type Enumeration Table 9 PowerChangeResultCode PWR_OK PWR_LOCAL PWR_REMOTE PWR_BUSY PWR_ERROR_CAP PWR_FATAL_ERROR PowerChangeResultCode Values Value 0 1 2 3 4 5 Condition The request was accepted. The request was rejected because the requested configuration exceeded the Link’s capabilities. 625 The semantics of this primitive are: 626 PA_LM_GET. 618 When Generated 619 This primitive is generated by the DME to obtain information from the PA_MIB or the underlying PHY. 5. The SelectorIndex shall be interpreted as a PHY Data Lane index if relevant for the targeted Attribute. The Link may be inoperable.1.

cnf_L( ConfigResultCode ) 647 The primitive’s parameter is defined in Table 8.12).The PA_LM responds with PA_LM_SET. MIBvalue. MIBvalue is undefined.3 PA_LM_SET. All rights reserved. 630 Effect on Receipt 631 The DME is informed about the result of the operation.req( AttrSetType.40.Version 1. Inc. 642 Behavioral Description 643 The state diagram describing the behavior of the primitive is shown in Figure 23 of [MIPI02]. MIBvalue carries the MIB Attribute value. 640 Effect on Receipt 641 The PA_LM attempts to set the specified MIB Attribute in its database or in the PHY.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.8. and in case ConfigResultCode is SUCCESS. 635 The semantics of this primitive are: 636 PA_LM_SET. SelectorIndex ) 637 The primitive’s parameters are defined in Table 8. setting PA_PWRMode triggers the Link Configuration procedure (see Section 5.1. 5.4. and. 628 When Generated 629 The PA Layer shall generate the PA_LM_GET. MIBattribute. The SelectorIndex shall be interpreted as a data PHY Lane index if relevant for the targeted Attribute.req 634 This primitive attempts to set to the MIBvalue value the PA_MIB Attribute or a PHY Attribute indicated by MIBattribute. the SelectorIndex. For Attributes not associated with the SelectorIndex. 632 Behavioral Description 633 The state diagram describing the behavior of the primitive is shown in Figure 24 of [MIPI02]. the SelectorIndex shall be ignored. then this primitive requests that the action be performed. if relevant.00 31-Jan-2011 MIPI Alliance Specification for UniPro 627 The primitive’s parameters are defined in Table 8.1. For any other value of ConfigResultCode.4.4 PA_LM_SET. 638 When Generated 639 This primitive is generated by the DME to set the indicated PA_MIB Attribute. If the MIB Attribute implies a specific action. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 68 . 645 The semantics of this primitive are: 646 PA_LM_SET. For example. 5.req from the DME.cnf_L primitive in response to a PA_LM_GET.cnf_L that gives the result.

Inc.12. The PAPowerModeUserData is to be sent to the peer Device if the power mode change request was created by the remote DME. 661 Effect on Receipt 662 DME shall respond with the PA_LM_PWR_MODE. and should have no further effects at the DME.6 PA_LM_PWR_MODE.rsp_L 665 This primitive acknowledges PA_LM_PWR_MODE. 663 Behavioral Description 664 The state diagram describing the behavior of the primitive is shown in Figure 80 of [MIPI02].ind( PAResult.5 PA_LM_PWR_MODE. 655 The semantics of this primitive are: 656 PA_LM_PWR_MODE.1.Version 1.req from the DME. PAPowerModeUserData ) 657 The first parameter is set to TRUE. 658 The second parameter is a 24-byte long data payload containing private data from the peer DME.00 31-Jan-2011 MIPI Alliance Specification for UniPro 648 When Generated 649 The PA Layer shall generate the PA_LM_SET. 652 Behavioral Description 653 The state diagram describing the behavior of the primitive is shown in Figure 23 of [MIPI02]. otherwise it is set to FALSE. 659 When Generated 660 See Section 5. when the power mode change request was created by the local DME.ind from the PA Layer. 5. primitive in response to a Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 69 . 669 When Generated 670 The DME shall generate the PA_LM_PWR_MODE.rsp_L( PAPowerModeUserData ) 668 The parameter is defined in Table 8.rsp_L PA_LM_PWR_MODE. 666 The semantics of this primitive are: 667 PA_LM_PWR_MODE.ind 654 This primitive passes the PAPowerModeUserData that was received from the peer Device during the Link Configuration procedure. All rights reserved. 5.4. 650 Effect on Receipt 651 The PA_LM_SET.cnf_L confirms the success or failure of the PA_LM_SET.ind.cnf_L primitive in response to a PA_LM_SET.1. ConfigResultCode shall be set to INVALID_MIB_ATTRIBUTE if AttrSetType of the request was STATIC and the Attribute indicated by MIBattribute and SelectorIndex does not support setting its reset value.8.40.req at the PA Layer.rsp_L primitive.4.

GenSelectorIndex ) 689 The primitive’s parameter is defined in Table 8.ind( PowerChangeResultCode ) 679 The primitive’s parameter is defined in Table 9. 690 When Generated 691 This primitive is generated by the local PA Layer on the reception of a PACP_GET_req frame requesting to obtain local Attribute information. the GenSelectorIndex parameter shall be ignored. 677 The semantics of this primitive are: 678 PA_LM_PWR_MODE_CHANGED. 674 Behavioral Description 675 The state diagram describing the behavior of the primitive is shown in Figure 80 of [MIPI02].4.8. All rights reserved. then the contents of PAPowerModeUserData is to be transmitted to the peer Device via a PACP_PWR_cnf frame. the GenSelectorIndex. 684 Behavioral Description 685 The state diagram describing the behavior of the primitive is shown in Figure 25 of [MIPI02]. depending on the particular Attribute.4.1. Inc. if relevant.00 31-Jan-2011 MIPI Alliance Specification for UniPro 671 Effect on Receipt 672 The PA Layer continues the on-going power mode change request.12 for more information. 5. CPort index or Test Feature index. If the power mode change was requested by the peer Device.Version 1.7 PA_LM_PWR_MODE_CHANGED. then the PA Layer begins to finish the power mode change by closing down the burst. Copyright © 2007-2011 MIPI Alliance.rsp that gives the result. 687 The semantics of this primitive are: 688 PA_LM_PEER_GET.8. 692 Effect on Receipt 693 The PA Layer attempts to retrieve the requested Attribute value from the UniPro stack and the DME shall respond with PA_LM_PEER_GET.12.1. For Attributes not associated with GenSelectorIndex.8 PA_LM_PEER_GET. The GenSelectorIndex shall be interpreted either as a data PHY Lane index. and.ind 676 This primitive reports the results of the Link Configuration procedure. If not. 673 See Section 5. 682 Effect on Receipt 683 The DME is notified that the local request or a remote request has been completed with the status reported by the parameter.ind 686 This primitive indicates the value of the Attribute identified by GenMIBattribute. 5. 680 When Generated 681 See Section 5.ind( GenMIBattribute. MIPI Alliance Member Confidential 70 .40.

MIBvalue is undefined. if relevant. 704 Behavioral Description 705 The state diagram describing the behavior of the primitive is shown in Figure 86 of [MIPI02].ind 706 This primitive attempts to set the MIBvalue value to an Attribute of the local UniPro stack identified by GenMIBattribute. the GenSelectorIndex shall be ignored. For any other value of ConfigResultCode. 702 Effect on Receipt 703 The PA Layer is informed about the result of the operation.40. 710 When Generated 711 This primitive is generated by the local PA Layer on the reception of a PACP_SET_req frame requesting to set a local Attribute. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. 5. All rights reserved. GenSelectorIndex ) 709 The primitive’s parameters are defined in Table 8. Inc. For Attributes not associated with the GenSelectorIndex.Version 1.ind from the PA Layer. MIBvalue.10 PA_LM_PEER_SET.1.rsp primitive in response to a PA_LM_PEER_GET. MIBvalue ) 699 The primitive’s parameters are defined in Table 8. 700 When Generated 701 The DME shall generate the PA_LM_PEER_GET.ind( AttrSetType.4. MIPI Alliance Member Confidential 71 .rsp that gives the result. 707 The semantics of this primitive are: 708 PA_LM_PEER_SET.rsp( ConfigResultCode. the GenSelectorIndex. Copyright © 2007-2011 MIPI Alliance. MIBvalue carries the MIB Attribute value. 5.ind. GenMIBattribute. and. The PA Layer shall use PACP to forward the result of the operation to the peer Device. The DME responds with PA_LM_PEER_SET.1.9 PA_LM_PEER_GET. 697 The semantics of this primitive are: 698 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. 714 Behavioral Description 715 The state diagram describing the behavior of the primitive is shown in Figure 86 of [MIPI02].00 31-Jan-2011 MIPI Alliance Specification for UniPro 694 Behavioral Description 695 The state diagram describing the behavior of the primitive is shown in Figure 86 of [MIPI02]. and in case ConfigResultCode is SUCCESS. 712 Effect on Receipt 713 The DME attempts to set the specified Attribute.4.

Version 1.cnf 737 Support for this primitive is optional. GenSelectorIndex ) 730 The primitive’s parameter is defined in Table 8. it shall implement it as described in this section.req( GenMIBattribute.11 PA_LM_PEER_SET.12 PA_LM_PEER_GET. this Attribute being identified by GenMIBattribute.rsp 716 This primitive reports the results of an attempt to set the value of an Attribute in the UniPro stack or PHYs. All rights reserved. Copyright © 2007-2011 MIPI Alliance. 738 This primitive reports the results of an information request about an Attribute of the peer Device. MIPI Alliance Member Confidential 72 .rsp confirms the success or failure of the PA_LM_PEER_SET.40.4. 722 Effect on Receipt 723 The PA_LM_PEER_SET. 733 Effect on Receipt 734 The PA Layer entity attempts to retrieve the requested MIB Attribute value from the peer Device by using PACP protocol and responds with PA_LM_PEER_GET. Inc. it shall implement it as described in this section.ind at the DME. 731 When Generated 732 This primitive is generated by the DME to obtain information about an Attribute of the peer Device.1. if an implementation supports this primitive.rsp primitive in response to a PA_LM_PEER_SET.13 PA_LM_PEER_GET.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.4. For Attributes not associated with the GenSelectorIndex. 728 The semantics of this primitive are: 729 PA_LM_PEER_GET. However. if an implementation supports this primitive. and.cnf that gives the result.1. 5.req 726 Support for this primitive is optional. However. 720 When Generated 721 The DME shall generate the PA_LM_PEER_SET. and the PA Layer shall use the PACP protocol to forward the result to the peer Device.1. the GenSelectorIndex shall be ignored.4. the GenSelectorIndex.ind from the PA Layer. 735 Behavioral Description 736 The state diagram describing the behavior of the primitive is shown in Figure 84 of [MIPI02].rsp( ConfigResultCode ) 719 The primitive’s parameter is defined in Table 8. 717 The semantics of this primitive are: 718 PA_LM_PEER_SET. 724 Behavioral Description 725 The state diagram describing the behavior of the primitive is shown in Figure 86 of [MIPI02]. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. 5. 727 This primitive requests information about a given Attribute of the peer Device. if relevant.

5.cnf primitive in response to a PA_LM_PEER_GET. 753 When Generated 754 This primitive is generated by the DME to set the indicated Attribute of the peer Device. 749 This primitive attempts to set the Attribute of the peer Device indicated by GenMIBattribute and. if an implementation supports this primitive. 761 The semantics of this primitive are: 762 PA_LM_PEER_SET. However. GenMIBattribute.cnf that gives the result.req( AttrSetType. For any other value of ConfigResultCode. 755 Effect on Receipt 756 By using the PACP protocol. 5. 742 When Generated 743 The PA Layer shall generate the PA_LM_PEER_GET. 744 Effect on Receipt 745 The DME is informed about the result of the operation.00 31-Jan-2011 MIPI Alliance Specification for UniPro 739 The semantics of this primitive are: 740 PA_LM_PEER_GET. However. the GenSelectorIndex. All rights reserved. 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.1. Inc. 750 The semantics of this primitive are: 751 PA_LM_PEER_SET. if relevant.cnf 759 Support for this primitive is optional. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. MIBvalue is undefined.Version 1. MIBvalue. For Attributes not associated with the GenSelectorIndex.40. it shall implement it as described in this section. 746 Behavioral Description 747 The state diagram describing the behavior of the primitive is shown in Figure 84 of [MIPI02]. MIBvalue carries the MIB Attribute value. 757 Behavioral Description 758 The state diagram describing the behavior of the primitive is shown in Figure 84 of [MIPI02].4.cnf( ConfigResultCode ) Copyright © 2007-2011 MIPI Alliance. MIBvalue ) 741 The primitive’s parameters are defined in Table 8. MIPI Alliance Member Confidential 73 . GenSelectorIndex ) 752 The primitive’s parameters are defined in Table 8.4. the GenSelectorIndex shall be ignored. The PA Layer responds with PA_LM_PEER_SET.cnf( ConfigResultCode. to the MIBvalue value.req 748 Support for this primitive is optional. the PA Layer shall attempt to set the specified MIB Attribute of the peer Device.15 PA_LM_PEER_SET. if an implementation supports this primitive. and in case ConfigResultCode is SUCCESS.1.14 PA_LM_PEER_SET.req from the DME.

4.5 5.2. D = PA D-PHY supported. M D.2.2.2. 774 The primitives are summarized in Table 10.4.4 5.11 5.14 5.4. All rights reserved.2 Control Primitives 770 The following control primitives of the PA_LM_SAP are used for controlling the FastAuto_Mode and SlowAuto_Mode (see Table 14). 771 The AUTOSELECT.2. 5.2.4.40. and PHY_RESET primitives are used only with PA M-PHY.4.4.req at the PA Layer.2 5. 775 The parameters used for these primitives are defined in Table 11.2.2. 773 The HIBERNATE_ENTER. Inc.16 5.19 5.2. 766 Effect on Receipt 767 The PA_LM_PEER_SET.15 5.2.4. TEST_MODE.Version 1. HIBERNATE_EXIT. 768 Behavioral Description 769 The state diagram describing the behavior of the primitive is shown in Figure 84 of [MIPI02].4.4. ENABLE_LAYER.cnf primitive in response to a PA_LM_PEER_SET.2.cnf confirms the success or failure of the PA_LM_PEER_SET. M D.1 5.2. M M M M M Indication 1.2.3 5.req from the DME.12 5.4.4. M = PA M-PHY supported.6 5. Copyright © 2007-2011 MIPI Alliance.4. LINKSTARTUP and ENDPOINTRESET primitives are prefixed by PA_LM for the PA Layer management SAP.2.2. Table 10 Name PA_LM_AUTOSELECT PA_LM_RESET PA_LM_ENABLE_LAYER PA_LM_LINKSTARTUP PA_LM_ENDPOINTRESET PA_LM_HIBERNATE_ENT ER PA_LM_HIBERNATE_EXIT PA_LM_TEST_MODE PA_LM_PHY_RESET Request 5.4.2.21 Confirm PA1 D D.9 5.13 5. 764 When Generated 765 The PA Layer shall generate the PA_LM_PEER_SET.4.2.10 5. MIPI Alliance Member Confidential 74 .7 5.8 5.18 5.4.4.00 31-Jan-2011 MIPI Alliance Specification for UniPro 763 The primitive’s parameter is defined in Table 8. M D.4.2. RESET.2.22 5. and should have no further effects at the DME.17 5.20 PA_LM Control Primitives Local Response Response Local Confirm 5.2.2.4.4.4. 772 The AUTOSELECT primitives are used only with PA D-PHY. and for reset and boot purposes (see Section 9).4.2.4.4.

1 PA_LM_AUTOSELECT.4.cnf_L 783 This primitive indicates to the DME that the requested power state has been reached.req( AutoState ) 779 When Generated 780 When PA_TxPWRMode is set to FastAuto_Mode or SlowAuto_Mode.40. Possible values for the AutoState parameter are FAST_STATE.6.1). When the PA Layer is in a different mode. 784 The semantics of this primitive are: 785 PA_LM_AUTOSELECT. this primitive shall have no effect. MIPI Alliance Member Confidential 75 . 777 The semantics of this primitive are: 778 PA_LM_AUTOSELECT. Copyright © 2007-2011 MIPI Alliance.2.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. Inc. All rights reserved.1.4. 787 When Generated 788 This primitive shall be generated by the PA Layer in response to a PA_LM_AUTOSELECT. SLOW_STATE and SLEEP_STATE. 5.cnf_L( PAAutoSelectResultCode ) 786 The primitive parameter is defined in Table 11.req primitive from the DME.Version 1.2 PA_LM_AUTOSELECT.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 11 Name PA_LM Control Primitive Parameters Type Valid Range FAST_STATE Value 1 2 4 0 1 0 1 0 1 0 1 Description Defines the power state when the Device is in FastAuto_Mode or SlowAuto_Mode Defines the reset level Indicates the result of the request Indicates the result of the request Indicates the target of the reset. this primitive shall be generated by the DME in order to put the PA Layer in the power state specified by the AutoState parameter. AutoState Enumeration SLOW_STATE SLEEP_STATE ResetLevel Enumeration COLD WARM SUCCESS FAIL Success Failure TX RX PAAutoSelectResultCode Enumeration GenericErrorCode Enumeration PHYDirection Enumeration 5. 781 Effect on Receipt 782 The PA Layer shall enter the power state according to the AutoState parameter.2.

cnf_L primitive during the boot procedure to indicate to the DME that the PA Layer came out of reset.cnf_L 805 This primitive is used during the UniPro reset procedure (see Section 9. 806 The semantics of this primitive are: 807 PA_LM_RESET. 5. All rights reserved. if they exist. Inc. the PA Layer shall set PAAutoSelectResultCode to FAIL. shall take effect. 792 In all other cases.00 31-Jan-2011 MIPI Alliance Specification for UniPro 789 Effect on Receipt 790 If PA_TxPWRMode is set to FastAuto_Mode and the PA Layer successfully changes its power state to FAST_STATE or SLEEP_STATE.4 PA_LM_RESET. Copyright © 2007-2011 MIPI Alliance. 800 The PA Layer shall reset the PHY entities and shall put them into a state according to the SlowAuto_Mode power mode. In case of an error.1).9.req( ResetLevel ) 796 When Generated 797 This primitive shall be generated by the DME in order to reset the PA Layer and PHY Layer. as defined in Section 5. 801 The ResetLevel COLD resets the complete PA Layer including any statistics and all Attributes. the PA Layer shall set PAAutoSelectResultCode to SUCCESS. the PA Layer shall not forward any received data to the DL Layer.3 PA_LM_RESET.cnf_L( ) 808 When Generated 809 The PA Layer uses the PA_LM_RESET. the PA Layer shall set PAAutoSelectResultCode to SUCCESS. 802 Detailed effects on the physical layer are described in the PHY-specific sections later in this section. MIPI Alliance Member Confidential 76 .4.4. 794 The semantics of this primitive are: 795 PA_LM_RESET. During a RESET of the PA Layer or PHY. 810 Effect on Receipt 811 The DME is informed that the PA Layer came out of reset.req 793 This primitive requests the PA_LM to reset the PA Layer and PHY Layer.40.Version 1. See Section 9 for a description of reset.2. 798 Effect on Receipt 799 The PA Layer resets transmit and receive state machines to the reset power-on states and reset values. 5. A PAAutoSelectResultCode equal to FAIL indicates the occurrence of an error. the power state can be determined by getting PA_TxPWRStatus (see Table 35). 803 Behavioral Description 804 The state diagram describing the behavior of the primitive is shown in Figure 19 of [MIPI02]. 791 If PA_TxPWRMode is set to SlowAuto_Mode and the PA Layer successfully changes its power state to SLOW_STATE or SLEEP_STATE.11. The reset values of the PA Layer Attributes.2. The ResetLevel WARM resets the PA Layer without any statistics.

cnf_L 823 This primitive reports that PA Layer has been enabled. 5. Inc.req( ) Copyright © 2007-2011 MIPI Alliance. 5.Version 1.4.req primitive from the DME.2.cnf_L. See Section 5. 815 The semantics of this primitive are: 816 PA_LM_ENABLE_LAYER.req 814 This primitive enables the PA Layer. MIPI Alliance Member Confidential 77 .cnf_L( ) 826 When Generated 827 This primitive shall be generated by the PA Layer in response to a PA_LM_ENABLE_LAYER. 828 Effect on Receipt 829 The DME is informed that the PA Layer has been enabled and is actively monitoring the inbound Lanes for incoming Link Startup sequences. 830 Behavioral Description 831 The state diagram describing the behavior of the primitive is shown in Figure 20 of [MIPI02].40.req 832 This primitive attempts to establish a Link to the peer Device by starting the Link Startup sequence (L1.2.6 PA_LM_ENABLE_LAYER.2) and is generated by the DME after the PA Layer comes out of reset.5 initialization protocol).5 PA_LM_ENABLE_LAYER. 821 Behavioral Description 822 The state diagram describing the behavior of the primitive is shown in Figure 20 of [MIPI02].6.11.4. 5. All rights reserved.req primitive is part of the UniPro boot procedure (see Section 9. 824 The semantics of this primitive are: 825 PA_LM_ENABLE_LAYER.4.2.req( ) 817 When Generated 818 The PA_LM_ENABLE_LAYER. 819 Effect on Receipt 820 The PA Layer shall begin monitoring the inbound Lanes for incoming trigger events and respond with PA_LM_ENABLE_LAYER.7 PA_LM_LINKSTARTUP.3 833 The semantics of this primitive are: 834 PA_LM_LINKSTARTUP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 812 Behavioral Description 813 The state diagram describing the behavior of the primitive is shown in Figure 19 of [MIPI02].

2. the PA Layer shall not forward any received data to the DL Layer.8.2. PA_ LM_ LINKSTA RT UP.40.3 defines the order of triggers sent and received during this sequence. and to FALSE when the operation failed. This is indicated to the DME with the PA_LM_LINKSTARTUP.cnf_L( GenericErrorCode ) 846 When Generated 847 This primitive is generated by the PA Layer after the Link Startup sequence has completed.req and PA_LM_LINKSTARTUP. 848 Effect on Receipt 849 The DME is informed about the completion of the PA Layer’s Link Startup sequence. All rights reserved. 837 Effect on Receipt 838 The PA Layer enters the Link Startup sequence. Section 5. 839 During the Link Startup sequence. 840 Once the Link Startup sequence has finalized. due to timeout. Copyright © 2007-2011 MIPI Alliance.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.cnf_L 843 This primitive is used during the UniPro boot procedure (see Section 9. MIPI Alliance Member Confidential 78 . The Boolean parameter is set to TRUE when the operation has completed successfully.ind( ) 855 When Generated 856 This primitive shall be generated by the PA Layer when it receives a ‘TRG_UPR1’ trigger (D-PHY) or a ‘TRG_UPR0’ trigger (M-PHY) and the PA Layer is not executing the Link Startup sequence. 5. Section 5.4. the PA Layer shall not accept any data from the DL Layer for transmission.ind shall n ot be generat ed by the PA Layer in t he t im e bet ween PA_LM_LINKSTARTUP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 835 When Generated 836 The DME shall generate this when it wants to establish a Link to the peer Device.9 PA_LM_LINKSTARTUP.g.6. 850 Behavioral Description 851 The state diagram describing the behavior of the primitive is shown in Figure 20 of [MIPI02]. 841 Behavioral Description 842 The state diagram describing the behavior of the primitive is shown in Figure 20 of [MIPI02]. Also.Version 1. 844 The semantics of this primitive are: 845 PA_LM_LINKSTARTUP. 5.cnf_L primitive.8 (D-PHY) or Section 5.8 PA_LM_LINKSTARTUP. Thus. 857 The trigger is defined in the applicable PHY-specific.cnf_L.11.7. the PA Layer shall enter normal operation.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.6 (M-PHY). e. Inc.4.

cnf_L 871 This primitive reports the completion of a request to send a EndPointReset trigger (‘TRG_EPR’). Following the UniPro stack reset. 878 Behavioral Description 879 The state diagram describing the behavior of the primitive is shown in Figure 88 of [MIPI02]. 867 Effect on Receipt 868 Once the EndPointReset trigger is sent.req( ) 865 When Generated 866 The DME shall generate this primitive when it receives an DME_ENDPOINTRESET. 860 Behavioral Description 861 The state diagram describing the behavior of the primitive is shown in Figure 20 of [MIPI02].3.40. 872 The semantics of this primitive are: 873 PA_LM_ENDPOINTRESET.req primitives for each layer. All rights reserved.cnf_L( ) 874 When Generated 875 This primitive is generated by the PA Layer in response of the PA_LM_ENDPOINTRESET. 5.req 862 This primitive is used to transmit the EndPointReset trigger (‘TRG_EPR’) over the Link to the peer PA Layer.2. primitive after having sent the EndPointReset trigger (‘TRG_EPR’).3 for details.5 through L4) using the <layer-identifier>_LM_RESET.11 PA_LM_ENDPOINTRESET.3).Version 1.2. the PA Layer shall indicate it to the DME with the PA_LM_ENDPOINTRESET. See Section 9.req from the DME_SAP user (generally the Application Layer).11. the DME shall initiate the boot procedure starting from the PA Layer and ending with the Transport Layer as described in Section 9.4. the DME shall reset the UniPro stack (L1. Copyright © 2007-2011 MIPI Alliance. 876 Effect on Receipt 877 When the DME receives this primitive from the local PA Layer it forwards a confirmation (Endpoint Reset) to the DME User (generally the Application Layer). Inc.ind primitive to forward the Link Startup notification to the user of the DME_SAP (generally the Application Layer).00 31-Jan-2011 MIPI Alliance Specification for UniPro 858 Effect on Receipt 859 The DME shall issue the LINKSTARTUP. Additionally. 869 Behavioral Description 870 The state diagram describing the behavior of the primitive is shown in Figure 88 of [MIPI02].req. 863 The semantics of this primitive are: 864 PA_LM_ENDPOINTRESET.2. MIPI Alliance Member Confidential 79 .cnf_L primitive (see Section 9.3.10 PA_LM_ENDPOINTRESET. 5.4.

If GenericErrorCode is set to Success.cnf_L to indicate whether or not the request was accepted. 899 The semantics of this primitive are: 900 PA_LM_HIBERNATE_ENTER.ind( ) 883 When Generated 884 The PA Layer shall generate this primitive when it receives an EndPointReset trigger (‘TRG_EPR’).2.req( ) 892 When Generated 893 This primitive is generated by the DME to put the PA Layer and the Link into Hibernate.Version 1. 896 Behavioral Description 897 The state diagram describing the behavior of the primitive is shown in Figure 21 of [MIPI02]. then the PA Layer begins to hibernate the Link as specified in Section 5. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 80 . 881 The semantics of this primitive are: 882 PA_LM_ENDPOINTRESET. 5. Inc.8. 890 The semantics of this primitive are: 891 PA_LM_HIBERNATE_ENTER. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.4.4.cnf_L( GenericErrorCode ) 901 When Generated 902 The PA Layer shall generate this primitive in response to a PA_LM_HIBERNATE_ENTER.req.4.12 PA_LM_ENDPOINTRESET. 894 Effect on Receipt 895 The PA Layer responds with PA_LM_HIBERNATE_ENTER. possibly because the PA Layer is executing a power mode change or a Link Startup sequence.40. 885 Effect on Receipt 886 When the DME receives this primitive from the local PA Layer it forwards a notification (Endpoint Reset) to the DME User (generally the Application Layer). 5. 887 Behavioral Description 888 The state diagram describing the behavior of the primitive is shown in Figure 88 of [MIPI02].2.req 889 This primitive attempts to put the PA Layer and the Link to Hibernate Mode.14 PA_LM_HIBERNATE_ENTER.1.13.2.ind 880 This primitive indicates the reception of an EndPointReset trigger (‘TRG_EPR’) over the Link.13 PA_LM_HIBERNATE_ENTER. If GenericErrorCode is set to Failure.cnf_L 898 This primitive reports the result of a hibernate request. the PA Layer rejected the request.

911 When Generated 912 The PA Layer shall generate this primitive when the enter hibernate procedure has completed.req( ) 920 When Generated 921 This primitive is generated by the DME to request the PA Layer and the Link to exit hibernate.cnf_L 926 This primitive reports the results of a hibernate exit request.16 PA_LM_HIBERNATE_EXIT. 915 Behavioral Description 916 The state diagram describing the behavior of the primitive is shown in Figure 21 of [MIPI02]. 5.40. Inc.ind it receives 907 This primitive reports the completion of a hibernate request.2. 924 Behavioral Description 925 The state diagram describing the behavior of the primitive is shown in Figure 22 of [MIPI02].cnf_L( GenericErrorCode ) Copyright © 2007-2011 MIPI Alliance.4. the DME shall wait until PA_LM_HIBERNATE_ENTER.req 917 This primitive attempts to put the PA Layer and the Link into Active Mode.00 31-Jan-2011 MIPI Alliance Specification for UniPro 903 Effect on Receipt 904 If GenericErrorCode is set to Success. 922 Effect on Receipt 923 The PA Layer responds with PA_LM_HIBERNATE_EXIT. 913 Effect on Receipt 914 The DME is informed of the completion of the enter hibernate procedure and the final status of the operation. All rights reserved.15 PA_LM_HIBERNATE_ENTER.17 PA_LM_HIBERNATE_EXIT. 5. 5.ind to know when the operation has been completed. MIPI Alliance Member Confidential 81 .ind( PowerChangeResultCode ) 910 The primitive parameters are defined in Table 9. 927 The semantics of this primitive are: 928 PA_LM_HIBERNATE_EXIT.2.4.2. 908 The semantics of this primitive are: 909 PA_LM_HIBERNATE_ENTER.4.Version 1. The parameter carries the result of the operation. 918 The semantics of this primitive are: 919 PA_LM_HIBERNATE_EXIT. 905 Behavioral Description 906 The state diagram describing the behavior of the primitive is shown in Figure 21 of [MIPI02].cnf_L to indicate whether or not the request was accepted.

19 PA_LM_TEST_MODE. If GenericErrorCode is set to Failure. 952 Effect on Receipt 953 The DME is informed that the PA Layer has been set in the testing mode and shall inform the user of the DME with DME_TEST_MODE.00 31-Jan-2011 MIPI Alliance Specification for UniPro 929 When Generated 930 The PA Layer shall generate this primitive in response to a PA_LM_HIBERNATE_EXIT.3.4. 939 When Generated 940 The PA Layer shall generate this primitive when the exit hibernate procedure has completed.ind( PowerChangeResultCode ) 938 The primitive parameters are defined in Table 9. 941 Effect on Receipt 942 The DME is informed of the completion of the exit hibernate procedure.ind 947 This primitive reports the reception of a request to put the PA Layer in a given test mode.2.ind to know when the operation has been completed. 931 Effect on Receipt 932 The DME is informed of the result of the operation. the DME shall wait until it receives PA_LM_HIBERNATE_EXIT. 933 Behavioral Description 934 The state diagram describing the behavior of the primitive is shown in Figure 22 of [MIPI02]. 5.40. If GenericErrorCode is set to Success. MIPI Alliance Member Confidential 82 . At this point. Inc.req. All rights reserved.ind( ) 950 When Generated 951 The PA Layer shall generate this primitive when a PACP_TEST_MODE_req frame is received before the start of Link Startup sequence.8. then the PA Layer begins to exit hibernate as specified in Section 5.13. 936 The semantics of this primitive are: 937 PA_LM_HIBERNATE_EXIT.Version 1. the PA Layer and the Link are in the same state as before hibernation.2. Copyright © 2007-2011 MIPI Alliance. 948 The semantics of this primitive are: 949 PA_LM_TEST_MODE. 945 Behavioral Description 946 The state diagram describing the behavior of the primitive is shown in Figure 22 of [MIPI02].ind primitive. 5.ind 935 This primitive reports the completion of a hibernate exit request. If GenericErrorCode is set to Success.18 PA_LM_HIBERNATE_EXIT. the PA Layer rejected the request. 943 Note: 944 The exit hibernate procedure might have been requested by a peer Device as well as the DME.4.

if an implementation supports this primitive. 975 Behavioral Description 976 The state diagram describing the behavior of the primitive is shown in Figure 90 of [MIPI02].22 PA_LM_PHY_RESET.cnf_L to inform the completion of the request.req( ) 960 When Generated 961 This primitive is generated by the DME to request the PA Layer to set the PA Layer of the peer Device to a given test mode. 5.2.2.req 956 Support for this primitive is optional.40. 969 The semantics of this primitive are: 970 PA_LM_TEST_MODE.20 PA_LM_TEST_MODE. it shall implement it as described in this section. MIPI Alliance Member Confidential 83 . if an implementation supports this primitive. The primitive is only accepted before the start of Link Startup sequence.ind 977 This primitive reports that the PHY was reset due to a received or generated LINE-RESET. 965 Behavioral Description 966 The state diagram describing the behavior of the primitive is shown in Figure 90 of [MIPI02]. 5.2.4. it shall implement it as described in this section. Inc.Version 1. 973 Effect on Receipt 974 The DME is informed about the completion of the operation.21 PA_LM_TEST_MODE. 962 Effect on Receipt 963 The PA Layer shall send the PACP_TEST_MODE_req frame.00 31-Jan-2011 MIPI Alliance Specification for UniPro 954 Behavioral Description 955 The state diagram describing the behavior of the primitive is shown in Figure 90 of [MIPI02]. Copyright © 2007-2011 MIPI Alliance. 968 This primitive reports the completion of a test mode request.req from the DME.cnf_L( ) 971 When Generated 972 The PA Layer shall generate this in response to a PA_LM_TEST_MODE. However. All rights reserved. 957 This primitive attempts to put the PA Layer of the peer Device to the test mode. 5. However. after having sent the PACP_TEST_MODE_req frame. 964 The PA Layer responds with PA_LM_TEST_MODE. 958 The semantics of this primitive are: 959 PA_LM_TEST_MODE.4.cnf_L 967 Support for this primitive is optional.4.

4. 987 The parameters of these primitives are defined in Table 13 and Table 14.2 Local Response Response Local Confirm Confirm PA1 D D 1.4.4. The primitives are summarized in Table 12. D = PA D-PHY supported.8.ind 988 This primitive reports the change of the power mode on the receive path (Reverse Link) of the UniPro stack.2.4.Version 1. 982 Effect on Receipt 983 The DME is informed that the PHY has been reset and shall inform the user of the DME with DME_ERROR. MIPI Alliance Member Confidential 84 .3.3 Status Primitives (PA D-PHY only) 986 The RXPWRSTATE and ERROR primitives are represented as indications. Copyright © 2007-2011 MIPI Alliance. 984 Behavioral Description 985 The state diagram describing the behavior of the primitive is shown in Figure 42 of [MIPI02]. and to RX when the PA Layer receives the LINE-RESET (i.ind primitive (see Section 9. All rights reserved.e. M-TX is affected).40. PHYDirection shall be set to TX when the PA Layer generates the LINE-RESET (i. Table 12 Name PA_LM_RXPWRSTATE PA_LM_ERROR Request PA_LM_SAP Status Primitives Indication 5. Inc.3. The primitives are prefixed by “PA_LM” for the PA Layer management SAP. the user has to re-apply all custom settings.ind( PHYDirection ) 980 When Generated 981 The PA Layer shall generate this when it detects an incoming LINE-RESET or it drives an outgoing LINERESET.1 5. M-RX is affected).3.e. see Table 20) PWRState Enumeration SLOW_STATE HIBERNATE_STATE SLEEP_STATE 5.28). 5. Since the PHY reset clears all Attributes to their default values. M = PA M-PHY supported.1 PA_LM_RXPWRSTATE. Value Description PAErrorCode (for D-PHY. Table 13 Name PhyErrorCode Type Integer PA_LM_SAP Status Primitive Parameters Valid Range 0 to 255 OFF_STATE FAST_STATE 0 1 2 3 4 Available UniPro power states.00 31-Jan-2011 MIPI Alliance Specification for UniPro 978 The semantics of this primitive are: 979 PA_LM_PHY_RESET.

5. This information may be stored in statistics or may trigger user-defined events.Version 1. or autonomously by the PA Layer. MIPI Alliance Member Confidential 85 . 993 Effect on Receipt 994 The DME is informed to which power state the RX part of the PA Layer and PHY has changed. Inc. 1004 All PA_PDUs have a fixed length of 17-bits.5 Structure and Encoding of Protocol Data Units 1003 The PA Layer communicates with its peer PA Layer via PHY Adapter Protocol Data Units (PA_PDUs).7. These are defined in the following sections.40.2 PA_LM_ERROR. There are two types of PA_PDUs. 1001 Effect on Receipt 1002 The DME is informed that a certain error event has occurred.1 Data PA_PDU 1005 The Data PA_PDU carries DL Layer and PACP frame data symbols as payload. 5. All rights reserved. It can be initiated by a PA_DATA.5.7 defines the mapping of PHY errors to PhyErrorCode values. 999 When Generated 1000 This primitive shall be generated in the PA_LM to inform the DME of an error event in the RX part of the PA Layer and PHY. Section 5.4. one for normal data and one for escaped data. 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro 989 The semantics of this primitive are: 990 PA_LM_RXPWRSTATE. 1006 This PDU has the structure shown in Figure 15.ind 995 This primitive reports the occurrence of an error in the receive path.ind( PhyErrorCode ) 998 The primitive parameter is defined in Table 13. 16 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Data Figure 15 Data PA_PDU Copyright © 2007-2011 MIPI Alliance.req from the DL Layer. Definition of the response to this primitive is beyond the scope of this document.3.ind( PWRState ) 991 When Generated 992 This primitive shall be generated in the PA_LM to inform the DME of a power state change of the RX part of the PA Layer and PHY. 996 The semantics of this primitive are: 997 PA_LM_ERROR.

3 for M-PHY. the ESC_DL is encoded as ‘0b00000001’.req primitive to request the transmission of an Escaped Data PA_PDU.8.5. an Escaped Data PA_PDU that is initialized by the DL Layer with EscType=ESC_DL looks like in Figure 18.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1007 The header bit (bit 16) is fixed to ‘0’ in this PDU. 16 1 15 14 13 12 11 10 ESC_DL Figure 17 9 8 7 6 5 4 3 2 EscParam_DL 1 0 DL Escaped Data PA_PDU 1013 UniPro defines only one EscType for the higher protocol layers. All rights reserved. This information shall be passed to the peer DL Layer by a PA_ESCDATA. the PDU transports the primitive parameters EscType and EscParam over the Link. which is described in Section 5. MIPI Alliance Member Confidential 86 . Figure 17 shows the generic structure of a DL Escaped Data PA_PDU. 5. 16 1 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 EscType Figure 16 Escaped Data PA_PDU EscParam 1010 In the Escaped Data PA_PDU.2. 16 1 15 0 14 0 13 0 12 0 11 0 10 0 9 0 8 1 7 6 5 4 3 2 1 0 EscParam_DL Figure 18 DL Escaped Data PA_PDU with EscType=ESC_DL Copyright © 2007-2011 MIPI Alliance. respectively. Inc. Note that the ESC_DL encoding in the PA_PDU is different from the ESC_DL encoding for the physical layer. It can be initiated by the DL Layer or autonomously by the PA Layer. the header bit (bit 16) is set to ‘1’.5. 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.5. Therefore. 5.40. In this case.2.5 for D-PHY and in Section 5.2.7.1 DL Escaped Data PA_PDU 1012 The DL Layer uses the PA_ESCDATA.2 Escaped Data PA_PDU 1008 The Escaped Data PA_PDU carries escaped data as payload. namely the ESC_DL. 1009 Figure 16 shows the general structure of this PDU.5.2.Version 1.1 and Section 5. The only valid values for EscType are ESC_DL and ESC_PA. 1014 For the PA_PDU composition. as described in Section 5.ind. The payload of the Escaped Data PA_PDU is partitioned into the EscType field (bits [15:8]) and EscParam (bits [7:0]). 1011 A transmitter shall not transmit an Escaped Data PA_PDU with EscType set to any value other than ESC_DL or ESC_PA.

Inc. MIPI Alliance Member Confidential 87 . Copyright © 2007-2011 MIPI Alliance. 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. 1017 Receiving a PA Escaped Data PA_PDU shall be reported to L2 using the PA_ERROR. In this case it transports PA Layer control information to the peer PA Layer and the PDU is called ‘PA Escaped Data PA_PDU’. The remaining PHY-specific protocol features are described in Section 5. A Lane can be either connected or unconnected.7.ind. 1024 UniPro supports up to four PHY Data Lanes per direction in all modes.3.3. 5.1.Version 1.40.2.8. depending of the interconnection between the local PHY and the remote PHY.6. All rights reserved. 1023 Each of the UniPro power modes Fast_Mode.6. which can be switched autonomously.1 UniPro Link Management 1021 An available Lane is a Lane that is implemented in the PHY. An active Lane is used for data transfers while an inactive or unused Lane is not. their properties and their mapping to UniPro power states.1) when any of the following conditions occur: 1018 • 1019 • An ESC_PA symbol is received with an undefined value of EscParam_PA. 5. 16 1 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA Figure 19 EscParam_PA PA Escaped Data PA_PDU 1016 For PDU composition. Its information shall not be passed to the peer DL Layer with a PA_ESCDATA. Unused Lanes shall be kept in HIBERNATE_STATE.2 PA Escaped Data PA_PDU 1015 An Escaped Data PA_PDU can also be generated by the PA Layer autonomously without request from the DL Layer.6 Protocol Features 1020 This section defines the generic PHY Adapter Layer protocol features such as Lane distribution. The number of active Lanes is set by PA_ActiveTxDataLanes and PA_ActiveRxDataLanes. Hibernate_Mode and Off_Mode map to exactly one UniPro power state. the ESC_PA is encoded to ‘0b11111110’.8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.ind primitive with PAErrorCode set to BAD_PA_PARAM (see Section 5.7 and Section 5.5. 1025 Table 14 summarizes the different UniPro power modes. An ESC_PA symbol is received that represents TRG_UPR1 or TRG_UPR2. 5. Slow_Mode. Each of the UniPro power modes Fast_AutoMode and Slow_AutoMode map to two UniPro power states. The connection state is automatically discovered during the Link Startup Sequence. but Link Startup in highspeed mode is not supported (D-PHY only). Unconnected Lanes shall be kept in OFF_STATE.1 Power Modes 1022 UniPro defines six power modes that are abstracted from the power modes provided by the underlying PHY.5 for D-PHY and in Section 5.3 for M-PHY.

power. The actual data rate in the Slow_Mode is PHY-specific. a UniPro stack is able to set only the power mode of its forward Link. the SlowAuto_Mode might save power compared to the Slow_Mode. or equal to. The Link is always ready to send and receive data while providing a well-defined latency. thus the power mode of the forward Link may be different from the power mode of the reverse Link. the data rate in Fast_Mode and consume less. The Hibernate_Mode is a low power mode in which no data transmission is possible.12. In M-PHY.8. except Off_Mode. UniPro does not dictate a certain method for the autonomous switching. a PA Layer shall be able to transmit DL Layer data when in SlowAuto_Mode. 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. depending on whether or not the DL Layer has data to send. All rights reserved. In case a UniPro stack does not provide any method for autonomous switching.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 14 Power Mode UniPro Power Modes Power State Description The Fast_Mode is capable of the highest data transmission rate of all power modes. but at the cost of a possibly less well-defined latency. UniPro does not dictate a certain method for the autonomous switching.Version 1. There may be a long latency returning from this mode to one of the other modes. Copyright © 2007-2011 MIPI Alliance. Note that all active Lanes per direction shall have the same power configuration. In D-PHY. SLEEP_STATE SlowAuto_Mode SLOW_STATE. MIPI Alliance Member Confidential 88 . It should be less than. The Off_Mode prepares for the removal of power. By switching between states. The SlowAuto_Mode allows the UniPro stack to autonomously switch between the SLOW_STATE and the SLEEP_STATE. The Hibernate_Mode should consume less power than any of the other modes in this table. or equal.40. a PA Layer shall be able to transmit DL Layer data when in FastAuto_Mode. while its reverse Link is set by the remote UniPro. When a Device is ready to have its power removed it enters the OFF_STATE. depending whether or not the DL Layer has data to send. but at the cost of a possibly less well-defined latency. The actual data rate per Data Lane in the Fast_Mode is PHY-specific. Fast_Mode FAST_STATE Slow_Mode SLOW_STATE FastAuto_Mode FAST_STATE. The FastAuto_Mode allows the UniPro stack to autonomously switch between the FAST_STATE and the SLEEP_STATE. the FastAuto_Mode might save power compared to the Fast_Mode. The provided latency is well-defined but may be higher than in the Fast_Mode.7. The Slow_Mode is also capable of transmitting data. In any case.1. Inc. SLEEP_STATE Hibernate_Mode HIBERNATE_STATE Off_Mode OFF_STATE 1026 A UniPro power mode is assigned per Link direction. In any case. By switching between states. This process is described in Section 5. which is the lowest of any UniPro power modes. its SlowAuto_Mode shall be strictly mapped to the SLOW_STATE.

Version 1. 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 Figure 22 PHY Adapter PDU Ordering in a Three Lane Configuration 1032 The PDU ordering for a four Data Lane configuration is depicted in Figure 23. PDU #1. 1029 When multiple Lanes are used. When a single Lane is used. 1028 Figure 20 shows the single Data Lane case. Inc. Note that a L2 Frame may begin from any active Lane N given that Lanes 0 through Lane N-1 contain data and the Lane distribution order is followed.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. PA_PDU #0 is the earliest generated PDU.2 Lane Distribution and Merging 1027 UniPro allows transmitting data over multiple PHY Data Lanes. the PHY Adapter Protocol Data Units (PA_PDUs) are just sent in order over the only existing PHY Data Lane (PHY Data Lane 0). starting from Lane 0 through Lane (PA_ActiveTxDataLanes – 1). In terms of Lane distribution this is the trivial case.40. MIPI Alliance Member Confidential 89 . 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 Figure 21 PHY Adapter PDU Ordering in a Dual Lane Configuration 1031 Figure 22 defines the PDU ordering for a three Data Lane configuration. PDU #2 and PDU #3 are transferred simultaneously on the four Data Lanes. Similarly. Here. PA symbols shall be received in order starting from Lane 0 through Lane (PA_ActiveRxDataLanes – 1). Here. In the following figures. Lane 0 shall be used to transmit and receive PA symbols. the PDU #0. the PDU #0. Lane 0 PA_PDU 0 PA_PDU 1 PA_PDU 2 PA_PDU N-3 PA_PDU N-2 PA_PDU N-1 Figure 20 PHY Adapter PDU Ordering in a Single Lane Configuration 1030 Figure 21 defines the PHY Adapter Layer PDU ordering for two Data Lanes. All rights reserved. PA symbols shall be transmitted in order. when the bandwidth of a single Lane is not sufficient. The diagram shows that the PDU #0 and PDU #1 are transferred simultaneously on the two Data Lanes. Copyright © 2007-2011 MIPI Alliance. The PHY Adapter Layer distributes the transmitted data over multiple PHY Data Lanes on the sending side and merges the data again on the receiving side.6.

The Link Startup sequence may be initiated at the same time on both ends of the Link or at different times. t h e s e q u e n c e i s a b o r t e d a n d t h e D M E i s n o t i f i e d w i t h a PA_LM_LINKSTARTUP. If a Link Startup fails continuously it probably indicates that the peer Device is not present. All rights reserved.6. It uses robust PHY trigger events and transmits each trigger multiple times. 5.3 Link Startup Sequence 1034 The Link Startup sequence is a multiphase handshake.cnf_L primitive having the status parameter set to FALSE (failed). When the PA Layer receives the PA_LM_LINKSTARTUP. The mapping of PHY Adapter PDUs to PHY bits is defined in Section 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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 Figure 23 PHY Adapter PDU Ordering in a Four Lane Configuration 1033 The described Lane distribution scheme is independent of the actual PHY type.40. When the PA Layer finalizes the Link Startup sequence in phase 5. n o t p o w e r e d . A succesful startup is indicated with the status parameter set to TRUE (succeeded).5 for D-PHY and in Section 5.req primitive from the DME. o r h a s s o m e f a t a l e r r o r. 5. MIPI Alliance Member Confidential 90 . in both directions. 1038 Table 15 defines the five phases of the Link Startup sequence. 1035 Link Startup shall be initiated by the DME using the PA_LM_LINKSTARTUP.3. reset itself and then enter into Link Startup. Mapping of the UniPro trigger events to D-PHY and M-PHY trigger events is defined in Section 5.7. 1039 The Link Startup procedure is very robust. one end may start a Link Startup and the other end may detect this. which exchanges UniPro trigger events to establish initial Link communication. The UniPro stack shall not autonomously generate a Link Startup as part of DL Layer error recovery.cnf_L primitive with the parameter set to FALSE. respectively. respectively. Inc.1 Phases of the Link Startup Sequence 1037 Both ends of a Link may enter the Link Startup sequence at the same time. 1036 The Link Startup sequence is protected with a timeout mechanism.cnf_L primitive. This time is system dependant. it shall enter the sequence at phase 0 for M-PHY and phase 1 for D-PHY.s p e c i f i c ) . T h e f a i l u r e i s r e p o r t e d t o t h e D M E w i t h a PA_LM_LINKSTARTUP. between two directly attached UniPro Devices. Copyright © 2007-2011 MIPI Alliance.req primitive.6.Version 1.3 for M-PHY.8.8.6.8 and Section 5. Alternatively. 1040 Each endpoint or switch application shall incorporate a timeout to know when it is appropriate to abort the attempt to startup a Link.7. If the sequence is not completed within a s p e c i f i e d t i m e ( P H Y. it shall confirm this to the DME with the PA_LM_LINKSTARTUP.

8. Continue to send TRG_UPR2 on PHY TX Data Lane 0. All rights reserved.40. 0 Non supported 0b Non supported 1 Continue to send TRG_UPR1 on PHY TX Data Lane 0.cnf_L that the Link Startup sequence succeeded.2) Ignore all data. Send two additional TRG_UPR0 (all Lanes). 8b9b encoding is necessary to map a UniPro PA_PDU to a D-PHY symbol.6. Then proceed with Phase 5. Exit the Link Startup sequence and enter SlowAuto_Mode. Copyright © 2007-2011 MIPI Alliance. M-PHY: ignored) • TRG_UPR2 (Phase 4) 4 Ignore all data. Wait for TRG_UPR2 reception on PHY RX Data Lane 0. Continue to send TRG_UPR1 Wait for TRG_UPR1 reception on PHY RX Data Lane 0. MIPI Alliance Member Confidential 91 . 5 Report to the DME using PA_LM_LINKSTARTUP.8. Lane discovery (see Section 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 15 PA Transmitter Phase D-PHY Link Startup Sequence PA Receiver M-PHY Continue to send TRG_UPR0 (all Lanes). Then proceed with phase 3.8. D-PHY M-PHY Wait for TRG_UPR0 reception.8. 1045 This specification mandates 8b9b encoding as described in Annex C of [MIPI01] for implementations that use D-PHY. Send two additional TRG_UPR2 on PHY TX Data Lane 0. Re-align Lane numbering (Section 5. Then proceed with phase 3. • TRG_UPR1 (ignored) • Others (D-PHY: Phase 1.3.Version 1. 5. This specification also mandates D-PHY detect and flag non-existing 9b code words.3) 2 Send two additional TRG_UPR1 on PHY TX Data Lane 0. 3 Continue to send TRG_UPR2 on all Lanes Send two additional TRG_UPR2 on all Lanes. Ignore all data. Then proceed with Phase 5.7 PHY Adapter to D-PHY Interaction 1044 This section defines the interaction between the PHY Adapter and a D-PHY physical layer [MIPI01]. Send two additional TRG_UPR1.2 Terminating a Link Startup 1041 A UniPro Link Startup sequence shall be aborted by either of the following conditions: 1042 • 1043 • Application setting power mode to Hibernate_Mode or Off_Mode Assertion of UniPro Cold Reset or UniPro Warm Reset 5. • TRG_UPR1 (Phase 2) • Others (ignore) Wait for TRG_UPR1 reception on all Lanes. a D-PHY with 8b9b line coding is referred to as an ‘Encoded D-PHY’ in the following sections. For simplicity. Inc.

the receiving UniPro Device generates a PA_LM_RXPWRSTATE.Version 1. In addition. 1048 A UniPro power mode change shall be initiated by setting the mode value in PA_TxPWRMode of the PA_MIB via the PA_LM_SET. This might lead to a new power state. Inc.ind to its DME to indicate that a power state change has occurred. Copyright © 2007-2011 MIPI Alliance. For example. Finally. After requesting the new UniPro power mode. MIPI Alliance Member Confidential 92 .7.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. 1047 If there is a change in the power state. This procedure is depicted in Figure 24. changing from the Fast_Mode to the FastAuto_Mode might still keep the FAST_STATE on the Link. a PHYdependant process is performed to reach the mode. the PA Layer shall use the PA_LM_SET.cnf_L primitive to confirm that the mode has been reached.req primitive.1 Power Mode Change Procedure 1046 The power mode of a Link can be changed by assigning a new power mode to the transmitting Device. All rights reserved. the attached receiving UniPro Device will recognize it and adapt to it.

req (FAST_STATE) PA_LM_AUTOSELECT.req (SLEEP_STATE) PA_LM_AUTOSELECT.req (SLEEP_STATE) SLEEP PA_LM_AUTOSELECT. Inc.Version 1.cnf_L PWRMode = Hibernate_Mode HIBERNATE PA_LM_SET.req (SLOW_STATE) PWRMode = SlowAuto_Mode PA_LM_RESET.cnf_L PA_LM_AUTOSELECT.cnf_L PA_LM_AUTOSELECT. PWRMode) PWRMode = Fast_Mode FAST PA_LM_SET.req (FAST_STATE) PWRMode = FastAuto_Mode FAST/SLEEP PA_LM_SET.40.req SLOW/SLEEP PA_LM_SET.req (PA_TxPWRMode. MIPI Alliance Member Confidential 93 .00 31-Jan-2011 MIPI Alliance Specification for UniPro PA_LM_SET.req (SLEEP_STATE) SLEEP PA_LM_AUTOSELECT.cnf_L PWRMode = Off_Mode OFF PA_LM_SET.cnf_L SLOW PA_LM_AUTOSELECT.req (SLOW_STATE) PA_LM_AUTOSELECT.cnf_L PWRMode = Slow_Mode SLOW PA_LM_SET.cnf_L Figure 24 Power Mode Change Procedure for D-PHY Copyright © 2007-2011 MIPI Alliance. All rights reserved.cnf_L PA_LM_AUTOSELECT.cnf_L PA_LM_AUTOSELECT.req (SLEEP_STATE) PA_LM_AUTOSELECT.cnf_L FAST PA_LM_AUTOSELECT.

3 PHY States with Data Transmission 1064 A PHY is said to have a state with interruptible data transmission when the PHY allows data transmission to be temporarily stopped. Both UniPro data transmission states. In the SLOW_STATE of the Slow_Mode or SlowAuto_Mode. does not request valid data on each clock cycle. all active Data Lanes shall enter and exit the HS state in the same bit-clock cycle at a PA_PDU symbol boundary. Change the number of TX Data Lanes on the near end of the Link and the number of RX Data Lanes on the remote end of the Link to the same value. 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. In Slow_Mode or SlowAuto_Mode only PHY Data Lane 0 will be used.40. The PA Layer shall use the PA_LM_SET. Inc. a Device may use multiple Data Lanes to transmit data as defined by PA_ActiveTxDataLanes. When a transmitter enters and exits the FAST_STATE.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1049 In the case of a Link with multiple Data Lanes. Note that Clock Lanes are not included in the Data Lane count. Note that the current version of UniPro does not define a specific method to communicate the number of Data Lanes to the remote end.5 is not in Slow_Mode or SlowAuto_Mode. When a transmitter enters and exits HIBERNATE_STATE. An inactive Data Lane may be placed in any mode. including Hibernate_Mode and Off_Mode. The additional clock cycles are required to clean the data pipeline prior to pausing data transmission or changing the power state. shall return 1061 • 1062 Attempts to set PA_ActiveTxDataLanes. from the last data transmission. When a transmitter enters the OFF_STATE. Copyright © 2007-2011 MIPI Alliance. Enter UniPro Fast_Mode or FastAuto_Mode. the following rules shall apply: 1050 • In the FAST_STATE of the Fast_Mode or FastAuto_Mode. 1057 UniPro shall use Data Lane 0 up to Data Lane (PA_ActiveTxLanes-1) and Data Lane (PA_ActiveRxLanes-1) as active Lanes at the TX and RX sides.2 Lane Number Change Procedure 1055 A Device can use between one and four PHY Data Lanes (PHY Data Lane 0 to 3) per direction in the FAST_STATE. i. all active and inactive Data Lanes shall be shutdown in the same bit-clock cycle at a PA_PDU symbol boundary. 1051 • 1052 • 1053 • 1054 • 5.7. Data Lane 1 up to Data Lane (PA_ActiveTXDataLanes-1) shall be in SLEEP_STATE. 5. have an interruptible data transmission. All rights reserved. respectively. MIPI Alliance Member Confidential 94 .7. 1058 The following sequence shall be used to change the number of Data Lanes during run-time: 1059 • 1060 • Enter UniPro Slow_Mode or SlowAuto_Mode to ensure that the Link remains operational.cnf_L primitive to confirm the change. The new number of Data Lanes will be active. PA_ActiveRxDataLanes LOCKED_MIB_ATTRIBUTE when L1. 1056 The number of active Data Lanes shall be controlled by setting the appropriate value in PA_ActiveTxDataLanes and PA_ActiveRxDataLanes of the PA_MIB via the PA_LM_SET. and either the DL Layer has no valid data to send or there is a request to change the power state to SLEEP_STATE. The actual number of available Data Lanes of a Device is implementation-specific and can be less than four. the transmitter PHY Adapter shall ensure that.req primitive. the PHY byte clock is kept active without data (PHY IDLE symbols are introduced) for the number of cycles indicated by PA_TxTrailingClocks before pausing the Link.Version 1. 1065 In case the underlying PHY is in a state with interruptible data transmission. FAST_STATE and SLOW_STATE. 1063 Note that this procedure does not describe any potential updates of Data Link Layer parameters which might be associated with the changed number of Data Lanes. a UniPro Device shall use Data Lane 0.e.

it restarts the Link Startup sequence with Phase 1. 1068 The way the transmitter performs the Link Startup sequence depends on PA_TxLinkStartupHS. 1074 Once Node A receives a TRG_UPR2 event from Node B it enters Phase 4. 1071 The Link Startup sequence is initiated when the PA Layer of Node A gets a PA_LM_LINKSTARTUP. Node A sends TRG_UPR2 events until it receives a TRG_UPR2 event from Node B. The DME resets Node B which initiates the Link Startup Sequence on Node B (see Section 9.req primitive from its DME. The time Node A waits for a response from Node B before abandoning the Link Startup sequence is undefined. Node B enters Phase 1 of the Link Startup sequence and begins sending TRG_UPR1 events. one end of a Link (Node A) initiates the Link Startup sequence to establish communication with the remote end of the Link (Node B). All other data received by Node A is ignored. e. e. it notifies its DME with a PA_LM_LINKSTARTUP.4. sends two more TRG_UPR2 events and enters Phase 5 where it reports to its DME using PA_LM_LINKSTARTUP. a special option may be used.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1066 The number of additional PHY byte clock cycles depends on the implementation.g. MIPI Alliance Member Confidential 95 . to simplify support for FPGA-based endpoints. Copyright © 2007-2011 MIPI Alliance. of the receiving Device.g. 1073 During Phase 3. 1072 When Node A receives the TRG_UPR1 event from Node B.ind primitive. Any incoming TRG_UPR1 event is ignored. and enters SlowAuto_Mode.4 Link Startup Sequence 1067 UniPro trigger events should map to special low-speed PHY events (Escape mode events for D-PHY).3).5. the Link Startup sequence shall use the high-speed UniPro trigger events.cnf_L that the Link Startup sequence succeeded. Node A ignores any other incoming data during Phase 2. Node A enters Phase 1 of the Link Startup sequence where its PA Layer continuously sends TRG_UPR1 events until it receives a TRG_UPR1 event from Node B. 1075 Node B performs the same sequence as Node A. Node A enters Phase 3 of the Link Startup sequence. 5. If PA_TxLinkStartupHS equals FALSE or if the Attribute is not present.7. in debugging equipment. the Link Startup sequence shall use the low-speed (normal) UniPro trigger events. one end of the Link initiates the Link Startup sequence or both ends initiate the Link Startup sequence at approximately the same time.Version 1.1 Link Startup Scenarios (informative) 1069 Two different scenarios are possible during the Link Startup sequence. However. If PA_TxLinkStartupHS equals TRUE. Inc. However. it enters Phase 2 of the Link Startup sequence and sends two additional TRG_UPR1 events. When Node B receives the TRG_UPR1 event. 1070 In the first scenario. After sending the additional TRG_UPR1 events. if Node A receives any other data while waiting for the TRG_UPR2 event. All rights reserved.7. in which the direction towards the FPGA of the Link Startup sequence is executed in high speed data transmission mode. number of pipeline stages. 5.40. shown in Figure 25.

cnf_L n Link Startup Phase Single trigger event RX event that initiates a change in phase Figure 25 Link Startup Sequence Example with One Node Initiating the Sequence (D-PHY only) Copyright © 2007-2011 MIPI Alliance.req PA_LM_RESET.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 PA_LM_LINKSTARTUP. MIPI Alliance Member Confidential 96 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Node A DME PA_LM_RESET.cnf_L PA_LM_LINKSTARTUP.req PA_LM_RESET.40.cnf_L TRG_UPR1 PA_LM_ENABLE_LAYER.req 1 PA_LM_ENABLE_LAYER.Version 1. Inc. All rights reserved.ind PA_LM_RESET.req TRG_UPR1 PA Layer PA Layer Node B DME PA_LM_LINKSTARTUP.cnf_L PA_LM_ENABLE_LAYER.req PA_LM_ENABLE_LAYER.cnf_L 5 5 TRG_UPR2 PA_LM_LINKSTARTUP.

After receiving a TRG_UPR1 event. both ends of the Link (nodes) start the Link Startup sequence simultaneously. shown in Figure 26. MIPI Alliance Member Confidential 97 .Version 1. both nodes receive the PA_LM_LINKSTARTUP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1076 In the second scenario. Both nodes start sending TRG_UPR1 events while waiting to receive TRG_UPR1 events from the other node.req primitive from their respective DMEs at approximately the same time and enter Phase 1. Copyright © 2007-2011 MIPI Alliance. Inc. 1077 Both nodes continue through the Link Startup sequence. In this scenario. All rights reserved. All other data is ignored by both nodes.40. each node enters Phase 2 of the Link Startup sequence and sends two additional TRG_UPR1 events before moving to Phase 3.

req PA_LM_ENABLE_LAYER.00 31-Jan-2011 MIPI Alliance Specification for UniPro Node A DME PA_LM_RESET. All rights reserved.cnf_L 5 5 PA_LM_LINKSTARTUP. MIPI Alliance Member Confidential 98 .40.req PA_LM_ENABLE_LAYER.req PA Layer PA Layer Node B DME PA_LM_RESET.cnf_L PA_LM_RESET.Version 1. Inc.req PA_LM_RESET.req PA_LM_LINKSTARTUP.cnf_L TRG_UPR1 TRG_UPR1 1 1 TRG_UPR1 TRG_UPR1 TRG_UPR1 2 2 TRG_UPR1 TRG_UPR2 TRG_UPR2 3 3 TRG_UPR2 4 TRG_UPR2 TRG_UPR2 4 TRG_UPR2 PA_LM_LINKSTARTUP.cnf_L PA_LM_LINKSTARTUP.cnf_L n Link Startup Phase Single trigger event RX event that initiates a change in phase Figure 26 Link Startup Sequence Example with Both Nodes Initiating the Sequence (D-PHY only) Copyright © 2007-2011 MIPI Alliance.cnf_L PA_LM_ENABLE_LAYER.req PA_LM_ENABLE_LAYER.

the Type B comma codes are currently reserved. When PA_PDU [16] is ‘0’. the PA_PDU [15:8] bits shall map linearly to the input of the Encoded D-PHY encoder. If the value of PA_LegacyDPHYEscDL is FALSE. Copyright © 2007-2011 MIPI Alliance.00. When PA_PDU bit 16 is ‘1’. The value of PA_LegacyDPHYEscDL defines which mapping is used for transm ission.00.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. but makes better use of the encoding provided by the Encoded D-PHY. the B1 bit shall be transmitted first and the X2 bit shall be transmitted last.7. 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. with PA_PDU[7] as most significant bit and PA_PDU[0] as least significant bit. Within each symbol. 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 D-PHY Symbol #0 Figure 27 D-PHY Symbol #1 Encoded D-PHY Symbol Mapping 1082 The content of the PA_PDU [16:8] bits shall be mapped to the first symbol (High Symbol). 1081 As shown in Figure 27. MIPI Alliance Member Confidential 99 . The High Symbol is transmitted first over the Link.5 Symbol Mapping 1078 The Encoded D-PHY encodes 8b words into 9b words.00.40. 1080 Two different symbol mappings are defined to provide compatibility for all versions of UniPro. each PA_PDU is translated to exactly two Encoded D-PHY 9b symbols.00.Version 1. as defined in Table 17. All rights reserved. the symbol mapping is not compatible with UniPro v1. UniPro utilizes the regular exception codes and the Type A comma code assigned to protocol usage for the encoding of Escaped Data PA_PDUs. Inc. 1079 Some of the Type A comma codes are used for PHY purposes and one is assigned to protocol usage. The PA_PDU[7:0] bits shall map linearly to the input of the Encoded D-PHY encoder. 1083 The mapping of PA_PDU content to the Encoded D-PHY Low symbol is defined in Table 16. offering in addition four ‘Type A’ comma codes. the content of the PA_PDU [7:0] bits shall be mapped to the second symbol (Low Symbol). If t he value of PA_LegacyDPHYEscDL is TRUE. two ‘Type B’ comma codes and sixteen ‘Regular Exception Codes’. the symbol mapping is compatible with UniPro v1. with PA_PDU bit 15 as the most significant bit and PA_PDU bit 8 as the least significant bit. Table 16 PA_PDU[7:0] 0 to 255 Encoded D-PHY Low Symbol Mapping Encoded D-PHY Symbol D000 to D255 1084 The mapping of PA_PDU content to the Encoded D-PHY High symbol is defined in Table 17.

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. is called an undefined symbol. respectively. Inc. C417 or C600. with PAErrorCode set to BAD_PHY_SYMBOL or UNMAPPED_PHY_ESC_SYMBOL. An Encoded D-PHY 9-bit symbol that is a valid 9-bit code. it shall be flagged to the DL Layer using the PA_ERROR. 5. C400. Table 19 UniPro Power State FAST_STATE UniPro Power State to D-PHY State Mapping D-PHY State HS D-PHY Clock Lane State (PA_TxForceClock = FALSE) HS Copyright © 2007-2011 MIPI Alliance. and the second a DL escaped data symbol (‘SOF TC1’). Table 18 PA_PDU Type Data DL Escaped Data Encoded D-PHY Symbol Mapping Example (informative) PA_PDU[15:8] 0b1111 1110 0b0000 0001 PA_PDU[7:0] 0b0000 0001 0b0000 1000 Encoded D-PHY High Symbol D254 C600 Encoded D-PHY Low Symbol D001 D008 PA_PDU[16] 0 1 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. MIPI Alliance Member Confidential 100 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 17 PA_PDU[16] 0 PA_PDU[15:8] 0 to 255 ESC_PA 1 ESC_DL ESC_DL Encoded D-PHY High Symbol Mapping Encoded D-PHY Symbol D000 to D255 C400 C600 C417 PA_LegacyDPHYEscDL N/A N/A FALSE TRUE 1085 Table 18 shows examples for the symbol mapping of various PA_PDU types when PA_LegacyDPHYEscDL is FALSE.40. 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.Version 1. The first example represents normal DL data symbol. 1090 Receiving a C400. All rights reserved.ind primitive. but not one of D000-D255. a C417 or a C600 9-bit symbol for PA_PDU[15:8] shall be mapped to ESC_DL.ind primitive with PAErrorCode set to UNEXPECTED_PHY_ESC_SYMBOL.6 Power State Mapping 1091 The mapping between UniPro and D-PHY power states is defined in Table 19. 1089 If an invalid or undefined symbol is received. 1087 An Encoded D-PHY 9-bit symbol that is not a valid data or escape code is called an invalid symbol. 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. A PA_PDU containing a C400. 1088 When received.7.

6. 1093 In the UniPro FAST_STATE. triggers sent to an FPGA may need to be sent in high-speed mode. the transmit Clock Lane shall run in the actual UniPro power mode. When PA_TxForceClock equals TRUE. In both cases.7.2. Table 20 D-PHY Error SoT Sync Error SoT Error D-PHY to UniPro Error Mapping PPI Signal (informative) ErrSotSyncHS ErrSotHS ErrEsc ErrSyncEsc ErrControl PhyErrorCode 0 1 3 4 5 Escape Mode Entry Command Error LP Transmission Sync Error False Control Error 1096 All D-PHY error events should be indicated to the DME with the PA_LM_ERROR. 1098 The low-speed (normal) and high-speed UniPro trigger (FPGA support for debugging) event mapping is described in Section 5. The error events are identified by their PhyErrorCode value.7. 5. 5. for D-PHY. Thus. The status of the Clock Lane depends on PA_TxForceClock (see Table 36). no additional PHY Data Lanes shall be used for data transmission.7. data transmission is interruptible in the FAST_STATE.8 Trigger Event Mapping 1097 A UniPro trigger event shall be transmitted and received via PHY Data Lane 0. the definitions of Section 5. 1099 Note that for a Device connected to an FPGA. When PA_TxForceClock equals FALSE. All rights reserved. 1094 In the UniPro SLOW_STATE. data transmission is interruptible in the SLOW_STATE.7.1 and those of [MIPI01] shall remain the same. the D-PHY HS state has an interruptible data transmission. independent of the actual UniPro power mode.8.40. As a result. the D-PHY shall perform high speed data transmission (HS) on all activated PHY Data Lanes. the D-PHY inserts PHY IDLE symbols. For D-PHY. while triggers sent in the return direction may be sent in the default low-speed mode. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 101 . When a UniPro stack stops data transmission when D-PHY is in the HS state. Inc. the two directions of a Link have independent power modes.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 19 UniPro Power State to D-PHY State Mapping (continued) D-PHY State LPDT STOP ULPS Shutdown D-PHY Clock Lane State (PA_TxForceClock = FALSE) STOP STOP ULPS Shutdown UniPro Power State SLOW_STATE SLEEP_STATE HIBERNATE_STATE OFF_STATE 1092 These definitions apply to D-PHY Data Lanes.1 and Section 5. the transmit Clock Lane shall run in the HS mode. As UniPro requires an encoded D-PHY.Version 1. respectively.7 Error Mapping 1095 Table 20 shows the mapping of D-PHY errors to corresponding PhyErrorCode values.ind primitive. In this state. the D-PHY shall perform low power data transmission (LPDT) on PHY Data Lane 0 only.8.

MIPI Alliance Member Confidential 102 . Table 22 UniPro Trigger TRG_UPR1 TRG_UPR2 TRG_EPR High-speed Trigger Event to D-PHY Mapping Mapping to PA Symbol ESC_PA symbol with EscParam_PA set to ‘0b01101111’ ESC_PA symbol with EscParam_PA set to ‘0b01110100’ Not supported 1105 Note that EndPointReset is not supported when high-speed triggers are used.8.7.10 Actions Performed during Reset 1107 After receiving the PA_LM_RESET.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. this duration should be as short as the PHY implementation allows while complying with [MIPI01]. 5. this shall be indicated by the PA Layer to the DL Layer with the PA_INIT. 1102 For the TRG_UPR1 event. MASTER as defined in Table 23.40. The time spent in the STOP state should be as short as practical.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. For the TRG_UPR2 and TRG_EPR events. High-speed mapping should only be used if the transmitter is known to be attached to a Device with a receiver that is incapable of supporting the low-speed triggers.7. Copyright © 2007-2011 MIPI Alliance. 1104 High-speed UniPro triggers shall be transferred via D-PHY using the mapping in Table 22.9 (Re-)Initialization 1106 The PA_INIT.7.req primitive.1 Low-speed Triggers 1100 Low-speed UniPro triggers shall be transferred via D-PHY using the mapping in Table 21.2 High-speed Triggers 1103 Table 22 defines how UniPro trigger events are mapped in the high-speed Link Startup mode. MASTER followed by ‘Unknown-4’ trigger STOP state followed by ‘Unknown-5’ trigger STOP state followed by “Remote Application Reset” trigger 1101 A low-speed UniPro trigger is mapped to a single D-PHY trigger event preceded by the STOP state for a specific duration. All rights reserved.2.8. This is to ensure the minimum STOP state duration seen by the attached receiver.cnf_L primitive.7. the transmitter shall not perform high-speed data transmission between the first TRG_UPR1 and the last TRG_UPR2. When the original state is reached again. 5. 5. the PA Layer shall reset all of the TX D-PHY Lanes. as defined in [MIPI01]. During a Link Startup sequence using low-speed UniPro triggers. If the original state is interruptible. Table 21 UniPro Trigger TRG_UPR1 TRG_UPR2 TRG_EPR Low-speed Trigger Event to D-PHY Mapping Mapping to D-PHY STOP state for duration of TINIT.6. Inc. 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.Version 1. the duration of the preceding STOP state shall be TINIT.

00 31-Jan-2011 MIPI Alliance Specification for UniPro 1108 The PHY shall initialize as defined in the “Initialization” section of the D-PHY specification [MIPI01].1 General Requirements 1111 Implementations that use D-PHY shall use 8b9b encoding as described in Annex C of [MIPI01]. bidirectional Lanes are not supported. In addition. UniPro reduces the possible configurations by only using certain optional features and by restricting the physical timing margins. Some features are optional.7. 5. The UniPro specification.6. All rights reserved.11 Physical Layer Requirements 1110 The D-PHY specification allows a number of different configurations.MASTER and TINIT.Version 1. 5. the LPDT mode requirement does not apply.7.SLAVE timings are defined in Table 23.11.7. Inc.7.8.2 D-PHY Timing Requirements 1124 UniPro requires from a D-PHY instance to fulfill the timing requirements in Table 23. while others are mandatory. Table 23 Parameter THS-PREPARE +THS-ZERO THS-EXIT Global Operation Timing Parameters Min 145 + 10*UI 100 Typ Max 145 + 20*UI 100 + 10*UI Unit ns ns Max allowed min Notes Description Time to drive HS-0 before the sync sequence Time to drive LP-11 after HS burst Copyright © 2007-2011 MIPI Alliance. The respective TINIT. MIPI Alliance Member Confidential 103 . its transmitter shall be either in the STOP or LPDT mode which is according to the UniPro SlowAuto_Mode. e. 1112 The D-PHY shall provide for the transmit path (see [MIPI01] for reference): 1113 • 1114 • 1115 1116 One TX Clock Lane: CIL-MCNN One to four TX Data Lanes • • TX Data Lane 0 shall provide LPDT and triggers: CIL-MFAN TX Data Lanes 1 to 3 need not to provide LPDT and triggers: CIL-MFEN 1117 The D-PHY shall provide the following Lane types for the receive path. FPGA-based debugging equipment.g. In such a UniPro Device. however.11.40. 1123 Note that the general requirements for the D-PHY transmitter and receiver apply to UniPro Devices using the Normal D-PHY Link Startup (see Section 5. see [MIPI01]: 1118 • 1119 • 1120 1121 One RX Clock Lane: CIL-SCNN One to four RX Data Lanes • • RX Data Lane 0 shall provide LPDT and triggers: CIL-SFAN RX Data Lanes 1 to 3 need not to provide LPDT and triggers: CIL-SFEN 1122 UniPro mandates one or more unidirectional Data Lanes per direction. also has an optional Link Startup in High-speed Mode (see Section 5. D-PHY shall detect and flag non-existing 9b code words.2) to enable FPGA-based Devices that do not contain a full D-PHY implementation. 5.3). 1109 After PHY initialization. A D-PHY Data Lane with bidirectional capability (supports turn-around requests) is used by a UniPro stack as a unidirectional Lane.

All rights reserved. Inc. MIPI Alliance Member Confidential 104 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 23 Parameter TWAKEUP Global Operation Timing Parameters (continued) Min 1 Typ Max Unit ms Notes Description Recovery time from ultra-low power mode Time that the transmitter shall continue sending HS clock after the last associated Data Lane has transitioned to LP mode TCLK-POST 60 + 52*UI 60 + 62*UI ns TCLK-PREPARE + time for lead TCLK-PREPARE + HS-0 drive period before TCLK-ZERO starting clock Minimum time that the HS clock must be set prior to any associated Data Lane beginning the transmission from LP to HS mode Time to drive HS differential state after last payload clock bit of a HS transmission burst TX shall drive STOP state for at least this period during reset After POR.SLAVE 100 125 150 μs Copyright © 2007-2011 MIPI Alliance.MASTER 60 60 + 10*UI ns 200 μs TINIT.40. D-PHY RX shall be initialized when it has seen STOP state for at least this period 300 300 + 10*UI ns TCLK-PRE 8 UI Max allowed min TCLK-TRAIL TINIT.Version 1.

req primitives.2 PHY Control and Attributes 1138 Each M-TX and M-RX has a separate set of Attributes as defined in [MIPI05]. MK1. All rights reserved.req and PA_LM_PEER_SET.40. 1126 The M-PHY primitives and Attributes referred in this section are defined in [MIPI05]. respectively.req and PA_LM_SET. MIPI Alliance Member Confidential 105 .1 Data Transmission 1127 An M-TX is capable of transmitting 8-bit data symbols and a few control symbols. the following M-PHY primitives are also used for controlling and for monitoring the PHY: 1142 1143 1144 1145 • • • • M-CTRL-CFGREADY M-CTRL-RESET M-CTRL-LINERESET M-CTRL-LCCReadStatus 1146 The PA Layer shall provide an access to all local M-PHY MODULE Attributes via the PA_LM_GET. The M-PHY Attributes (0x00 to 0xFF.Version 1. An M-PHY transmitter and an M-PHY receiver are called M-TX and M-RX. These Attributes are accessed using the following M-PHY M-TX-CTRL-SAP and M-RX-CTRL-SAP primitives: 1139 • 1140 • M-CTRL-CFGGET M-CTRL-CFGSET 1141 In addition. FILLER. The peer M-PHY MODULE Attributes are accessible via the PA_LM_PEER_GET. see [MIPI05]) are linearly mapped to UniPro Attributes 0x0000 to 0x00FF. M-PHY’s TX_Amplitude Attribute (0x25) can be accessed using UniPro Attribute ID 0x0025. A UniPro stack shall use the following M-PHY control symbols: MK0.8. to detect errors. A particular M-TX or M-RX is identified using a selector where the values 0 to 3 are mapped to TX logical Lanes 0 to 3 and the values 4 to 7 are mapped to RX logical Lanes 0 to 3. Inc. 1147 The following Attributes are write-protected due to their critical nature in the PA Layer’s power mode control: 1148 • 1149 • TX_MODE TX_PWMGEAR Copyright © 2007-2011 MIPI Alliance.8. 5. For example. MK2.req primitives. 1128 PA TX uses the following M-PHY M-TX-DATA primitives to transmit M-PHY symbols and to control the Link’s state: 1129 1130 1131 1132 • • • • M-LANE-SYMBOL M-LANE-PREPARE M-LANE-BurstEnd M-LANE-SaveState 1133 PA RX uses the following M-PHY M-RX-DATA SAP primitives to receive M-PHY symbols. and to detect changes in the Link’s state: 1134 1135 1136 1137 • • • • M-LANE-SYMBOL M-LANE-PREPARE M-LANE-BurstEnd M-LANE-HIBERN8Exit 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.8 PHY Adapter to M-PHY Interaction 1125 This section defines the interaction between the PHY Adapter and an M-PHY physical layer [MIPI05].

3 Symbol Mapping 1170 Each PA_PDU is translated to exactly two M-PHY symbols. in which MK0 functions as an M-PHY Start of Burst marker. In other words. The deskew pattern may be transmitted at any point in time.8. FILLER> in order to guarantee PA symbol alignment.40. The deskew pattern is also used when resynchronizing Lanes (see Section 5. An access to an Attribute of an unavailable Lane shall be rejected with a BAD_INDEX error.2. low>.req primitive. A PA escaped PA_PDU is mapped to <MK1. The deskew pattern shall be transmitted simultaneously on all active Lanes. A DL escaped PA_PDU is mapped to <MK0. Inc. The formed M-PHY symbol pair is shown using the notation <high.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. Since LINE-RESET causes PHY to reset all its Attributes to their default values. MIPI Alliance Member Confidential 106 . 3) on a request from the DL with a PA_INIT. 1175 An M-PHY burst shall begin by transmitting a deskew pattern <MK0.8. MK1>. For data symbols.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 • • • • • • • • • • • • • • • • • TX_HSGEAR TX_HSRATE_Series TX_HIBERN8_Control TX_LCC_Sequencer TX_HS_Unterminated_LINE_Drive_Enable MC_HS_Unterminated_LINE_Drive_Enable MC_HS_Unterminated_Enable TX_LS_Terminated_LINE_Drive_Enable MC_LS_Terminated_LINE_Drive_Enable MC_LS_Terminated_Enable RX_MODE RX_PWMGEAR RX_HSGEAR RX_HSRATE_Series RX_Enter_HIBERN8 RX_HS_Unterminated_Enable RX_LS_Terminated_Enable 1167 Trying to set these Attributes shall be rejected with a READ_ONLY_MIB_ATTRIBUTE error.8. 5. and the burst is active. 1174 If the PA Layer does not have anything to transmit. including any idle periods. PA_PDU[7:0]>. 1171 • 1172 • 1173 • A data PA_PDU is mapped to <PA_PDU[15:8]. PA_PDU[7:0]>. 5. the highest numbered bit is the most significant bit. and the lowest numbered bit is the least significant bit.ind primitive if the PHY has been reset due to a received LINE-RESET or due to a transmitted LINE-RESET. PA_PDU[7:0]>. The “high” symbol shall be transmitted before the “low” symbol. the 2-symbol alignment is followed throughout the burst. the Application needs to SET the optimized values after each reset.10).Version 1. The receiver at the PA Layer removes the FILLERs automatically. The LINE-RESET shall be issued on all available Lanes. All rights reserved. 1169 The PA Layer shall indicate to the DME via a PA_LM_PHY_RESET. 2) at the recovery step in the power mode change operation. Copyright © 2007-2011 MIPI Alliance. the PA Layer shall transmit <FILLER. PA_PDU[15:8] and PA_PDU[7:0].

00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. The following three cases shall be detected: 1183 1.40. 1184 2. All rights reserved. PA Layer TX guarantees a minimum re-configuration time for the M-PHY before beginning a new burst. 1178 When ending a burst.4 Power State Mapping 1176 The mapping between UniPro power state and M-PHY power states is defined in Table 24. PA_ActiveTxDataLanes = 2. Inc.Version 1.8. Transmit a MK2 symbol.e. and Odd Number of PA_PDUs (informative) 1182 After the end of the burst. 1180 2.8. an M-PHY End-of-Burst marker Transmit FILLER symbols (FLR) for the period of PA_TxTrailingClocks Issue a M-LANE-BurstEnd. Table 24 UniPro Power Mode Fast_Mode FastAuto_Mode Slow_Mode SlowAuto_Mode FastAuto_Mode SlowAuto_Mode Hibernate_Mode Off_Mode UniPro Power State to M-PHY State Mapping UniPro Power State FAST_STATE M-PHY State HS-BURST SLOW_STATE PWM-BURST STALL SLEEP HIBERN8 UNPOWERED SLEEP_STATE HIBERNATE_STATE OFF_STATE 1177 A UniPro Link may use any number of Lanes in SLOW_STATE and FAST_STATE. i. The time is counted from the reception of a M-LANESaveState. HS burst ending with no configuration applied: wait for PA_StallNoConfigTime PWM burst ending with no configuration applied: wait for PA_SleepNoConfigTime Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 107 . PA Layer TX shall perform the following steps on all active Lanes (see Figure 28 for an example): 1179 1. 1181 3.ind primitive. The minimum time values are obtained in Link Startup sequence (see Section 5.req End of Burst Sequence 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 Figure 28 End of Burst Sequence with PA_TxTrailingClocks = 3.8.5) and cover both the local M-TX and the peer M-RX.

1188 The Res_Error error reported by M-RX shall be indicated to the DL Layer with a PA_ERROR.40.11). 2.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1185 3. TRG_UPR1. All rights reserved. where C is the 4-bit parameter of TRG_UPR1. 1189 If any Marker or a FILLER is received for PA_PDU[7:0]. and 3 TRG_UPR1 Mapping Examples (informative) Value of C 0b0001 0b0011 0b1111 EscParam 0x81 0x83 0x8F M-PHY Symbol Pair <MK1. Minimum and maximum values for C are 1 and 15. respectively. 0x40> <MK1. 5b6b_Error.5 Error Mapping 1187 The 3b4b_Error. or TRG_UPR2 shall be indicated to the DL Layer with a PA_ERROR.8. HS or PWM burst ending with a new configuration applied: wait for PA_SaveConfigTime 1186 When waking-up a Lane from HIBERNATE_STATE. 0x8F> Copyright © 2007-2011 MIPI Alliance. The value of PA_TActivate takes into account the peer M-RX’s TACTIVATE.Version 1. Table 26 shows examples for TRG_UPR1 mappings. This condition shall apply only when the PA Layer has acquired the Lane synchronization (see Section 5. The bit n of the parameter shall be set if a TRG_UPR0 has been received on Physical Lane n. 0x43> 1192 UniPro trigger TRG_UPR1 has a 4-bit parameter containing information regarding connected Lanes in a bitmap format.8. the PA Layer shall keep the M-TX in SLEEP_STATE for the period set in PA_TActivate. 0x41> <MK1.ind primitive having the argument UNEXPECTED_PHY_ESC_SYMBOL. The trigger is transmitted on all available Lanes with a unique parameter on each Lane. 5.ind primitive having the argument BAD_PA_PARAM.ind primitive having the argument UNMAPPED_PHY_ESC_SYMBOL. and RD_Error [MIPI05] errors reported by M-RX shall be indicated to the DL Layer with a PA_ERROR. 1190 Each received PA escaped PA_PDU with EscParam_PA other than PACP_BEGIN. Table 25 Physical Lane 0 1 2 3 TRG_UPR0 Mapping EscParam 0x40 0x41 0x42 0x43 M-PHY Symbol Pair <MK1. 5. the PA Layer shall report this to the DL Layer with a PA_ERROR.6 Trigger Mapping 1191 UniPro trigger TRG_UPR0 has a 2-bit parameter representing the physical Lane number that the trigger was transmitted on. 0x42> <MK1. TRG_UPR0.ind primitive having the argument BAD_PHY_SYMBOL. Table 26 Lane information Lane 0 Lane 0 and 1 Lane 0. The mapping to ESC_PA and further to M-PHY symbols is shown in Table 25. Inc.8. as defined in [MIPI05]. TRG_UPR1 is mapped to an escaped PA_PDU with EscParam parameter set to 0x80 + C. 0x81> <MK1. 0x83> <MK1. and possibly other system-specific timing issues. The trigger is transmitted on all available Lanes with the same value of C. 1. MIPI Alliance Member Confidential 108 .

if any. This is accomplished by issuing a PA_DL_PAUSE.e. The reception of a new PACP start symbol shall cause the PA Layer to discard any PACP frame that has not been received completely.. The receiving PA Layer shall silently ignore all PACP frames that fail the checksum check or contain invalid values. but it cannot be preempted. 1199 The valid function IDs are defined in Table 27 and described in detail in other sections. to guarantee this alignment.g. A PACP frame is transmitted as any other DL Layer or PA Layer data on active Lanes with the exception that the start of a PACP frame shall be aligned to Logical Lane 0.7. 0x8A> 1193 UniPro trigger TRG_UPR2 is mapped to an escaped PA_PDU with EscParam set to 0xC0.Version 1. if necessary. the PA Layer shall get permission to use the Link from the DL Layer. which is equal to 0x01.8. All bits that are marked as Reserved shall be set to ‘1’.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 26 Lane information Lane 3 and 1 TRG_UPR1 Mapping Examples (informative) Value of C 0b1010 EscParam 0x8A M-PHY Symbol Pair <MK1.12). 1196 Before transmitting a PACP frame.7 PA Control Protocol (PACP) 1195 The PA Layer uses PA Control Protocol (PACP) to communicate with the peer PA Layer. it shall indicate the DL Layer via the PA_DL_RESUME. an escaped PA_PDU with EscParam set to PACP_BEGIN. 1197 The PACP frame structure is shown in Figure 29. a power mode change.ind primitive that the DL Layer can continue its transmission. 1194 UniPro trigger TRG_EPR is mapped to PACP_EPR_ind (see Section 5. The PA Layer may transmit FILLERs. following the normal Lane distribution rules.4). The trigger is transmitted on all available Lanes. 16 1 0 0 0 0 15 14 13 12 11 10 ESC_PA 6 5 4 3 2 1 0 EscParam_PA = PACP_BEGIN PACP_FunctionId Parameters . All rights reserved. Inc. 0xC0>.6. When the DL Layer has reached to a state where it can pause its transmission. follow. This translates to <MK1.rsp_L primitive. The PACP frame ends with a CRC-16 field. The 16-bit field PACP_FunctionId identifies the function and also determines how many 16-bit parameters. i. e.ind primitive to the DL Layer. CRC-16 9 8 7 Figure 29 PACP Frame Structure 1198 The receiving PA Layer detects the beginning of a PACP frame from the unique start symbol. The CRC-16 checksum shall be calculated over the whole PACP frame using the same algorithm as in the DL Layer (see Section 6.8. 5. Once the PA Layer has finished the operation. it replies with a PA_DL_PAUSE. The PACP frame may be interleaved with other transmissions.40. MIPI Alliance Member Confidential 109 . Copyright © 2007-2011 MIPI Alliance. The trigger is transmitted as any PACP frame.. All fields of a PACP frame shall be encoded in Big-endian format.

four different payload lengths. Inc.8. All rights reserved. respectively.Version 1. set to 0x80 when N_DeviceID_valid is FALSE.1 PACP_PWR_req 1201 A PACP_PWR_req frame is used when changing a Link’s power configuration (see Section 5. EndPointReset request To set PA Layer in PHY testing mode Request the value of an Attribute Return the value of an Attribute Set the value of an Attribute Return result of setting the value of an Attribute 1200 The PA Layer has two counters for counting received PACP frames. PA_PACPErrorCount shall be incremented by one for each PACP start symbol that is not part of a PACP frame that incremented PA_PACPFrameCount.40. Note that in this Frame “TX” and “RX” refer to the outbound and inbound directions of the requestor. 5. Description Power mode change request Power mode change confirmation Capability information. The counters shall automatically roll-over to zero on an overflow.12.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 27 PACP_FunctionId 0x010E 0x020D 0x0306 0x0400 0x0500 0x0602 0x0703 0x0805 0x0901 0x0A3F 0x0A7D 0x0ABD 0x0AFD Name PACP_PWR_req PACP_PWR_cnf PACP_CAP_ind PACP_EPR_ind PACP_TEST_MODE_req PACP_GET_req PACP_GET_cnf PACP_SET_req PACP_SET_cnf PACP_TEST_DATA_0 PACP_TEST_DATA_1 PACP_TEST_DATA_2 PACP_TEST_DATA_3 PACP Functions Parameter Count 14 13 6 0 0 2 3 5 1 63 125 189 253 Encapsulated test pattern for PHY testing. set to ‘1’ if the frame contains valid PAPowerModeUserData Flags[3]: HS Series. otherwise set to the value of N_DeviceID Flags • • • • • Flags[4]: UserDataValid.7.2). set to ‘0’ for Series A and to ‘1’ for Series B (PA_HSSeries) Flags[2]: Line-reset request Flags[1]: TX-direction termination enable (PA_TxTermination) Flags[0]: RX-direction termination enable (PA_RxTermination) Copyright © 2007-2011 MIPI Alliance. PA_PACPFrameCount shall be incremented by one if the received frame has a valid FunctionID and passes the checksum verification. PA_PACPFrameCount and PA_PACPErrorCount. MIPI Alliance Member Confidential 110 . A complete frame is shown in Figure 30.8. A PA_LM_SET request to PA_PACPFrameCount or PA_PACPErrorCount shall set the counter to zero. 1203 The fields shall be as follows (related PA Layer Attribute given in parenthesis): 1204 • 1205 • 1206 1207 1208 1209 1210 DevID: Local Device ID. 1202 The frame parameters contain the requested power configuration for both directions and a data payload (PAPowerModeUserData) for DME.

RxLane: Active Lane count for RX-direction.ind (see Section 5. Set to 0x3 when entering hibernate. the receiving PA Layer shall give the data received in the PAPowerModeUser field to the DME via the PA_LM_PWR_MODE. MIPI Alliance Member Confidential 111 .2 PACP_PWR_cnf 1222 The PACP_PWR_cnf frame is a response to a PACP_PWR_req frame. else set to PA_ActiveTxDataLanes TxGear: PWM or HS gear for TX-direction (PA_TxGear) RxMode: UniPro Power mode for RX-direction (PA_PWRMode[b6:b4]). The frame structure is shown in Figure 31.8. Set to value 0x3 when entering hibernate.12. 1221 If the UserDataValid flag is set. The Status parameter shall contain the status of the requested power mode change. the receiving PA Layer shall issue a LINE-RESET before processing the received frame. All rights reserved.40. If the Line-Reset flag is asserted. 16 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 14 13 12 11 10 ESC_PA 9 8 7 6 5 4 3 2 1 0 EscParam_PA = PACP_BEGIN Flags RxGear PACP_FunctionId = PACP_PWR_req DevID Reserved TxMode TxLane TxGear RxMode PAPowerModeUserData[0] PAPowerModeUserData[1] PAPowerModeUserData[2] PAPowerModeUserData[3] PAPowerModeUserData[4] PAPowerModeUserData[5] PAPowerModeUserData[6] PAPowerModeUserData[7] PAPowerModeUserData[8] PAPowerModeUserData[9] PAPowerModeUserData[10] PAPowerModeUserData[11] CRC-16 Figure 30 PACP_PWR_req RxLane 5. Inc. The Copyright © 2007-2011 MIPI Alliance. set to ‘0’ when count = 4 (PA_ActiveRxDataLanes) • set to ‘0’ when PA_ActiveRxDataLanes=4. else set to PA_ActiveRxDataLanes RxGear: PWM or HS gear for RX-direction (PA_RxGear) 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.8.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1211 • 1212 • 1213 1214 • 1215 • 1216 • 1217 1218 • 1219 • TxMode: UniPro Power mode for TX-direction (PA_PWRMode[b2:b0]). TxLane: Active Lane count for TX-direction (PA_ActiveTxDataLanes) • set to ‘0’ when PA_ActiveTxDataLanes=4.4).7.

The possible values of the Status field are listed in Table 28.8. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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.7. Inc.ind primitive. Request was rejected due to concurrent access. 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. MIPI Alliance Member Confidential 112 .3 PACP_CAP_ind 1223 The PACP_CAP_ind frame is shown in Figure 32.8). 1224 The frame’s fields shall be set as follows (source of the information given in parenthesis): 1225 • 1226 1227 Flags • • Flags[1]: HS untermination capability (TX_HS_Unterminated_LINE_Drive_Capability) Flags[0]: LS termination capability (TX_LS_Terminated_LINE_Drive_Capability) Copyright © 2007-2011 MIPI Alliance.40.Version 1. Request was rejected due to capability mismatch. 5. 16 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_PWR_cnf Reserved PAPowerModeUserData[0] PAPowerModeUserData[1] PAPowerModeUserData[2] PAPowerModeUserData[3] PAPowerModeUserData[4] PAPowerModeUserData[5] PAPowerModeUserData[6] PAPowerModeUserData[7] PAPowerModeUserData[8] PAPowerModeUserData[9] PAPowerModeUserData[10] PAPowerModeUserData[11] CRC-16 Figure 31 PACP_PWR_cnf Status Table 28 Status PWR_OK PWR_BUSY PWR_ERROR_CAP PACP_PWR_cnf Status Values Enumeration 0 3 4 Description Request was accepted and executed.

All rights reserved. 16 1 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_EPR_ind CRC-16 Figure 33 PACP_EPR_ind 5. It does not have any parameters.8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1228 • 1229 1230 1231 1232 1233 • • • • • MaxHS: maximum HS gear.7. The frame does not have any parameters. Inc. It is used to set the peer Device in PHY testing mode.Version 1.4 PACP_EPR_ind 1234 The PACP_EPR_ind frame is shown in Figure 33. MIPI Alliance Member Confidential 113 .8. zero if HS mode unavailable (TX_HSGEAR_Capability.40. Copyright © 2007-2011 MIPI Alliance.7. TX_HSMODE_Capability) MaxPWM: maximum PWM gear (TX_PWMGEAR_Capability) TSleepNoConfig: M-PHY timing information (RX_Min_SLEEP_NoConfig_Time_Capability) TStallNoConfig: M-PHY timing information (RX_Min_STALL_NoConfig_Time_Capability) TSaveConfig: M-PHY timing information (RX_Min_SAVE_Config_Time_Capability) VersionInfo: Local UniPro version (PA_LocalVerInfo) 16 1 0 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_CAP_ind Reserved VersionInfo Reserved Reserved Reserved CRC-16 Figure 32 PACP_CAP_ind TSleepNoConfig TStallNoConfig Flags MaxHS TSaveConfig MaxPWM 5.5 PACP_TEST_MODE_req 1235 The PACP_TEST_MODE_req frame is shown in Figure 34.

the PA Layer shall send the PACP_GET_cnf frame. When the DME generate the PA_LM_PEER_GET. 1237 The frame’s fields shall be set as follows: 1238 • 1239 • MIBattribute: defines the Attribute to be accessed in the peer Device GenSelectorIndex: the index required for certain Attributes 16 1 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_GET_req MIBattribute GenSelectorIndex CRC-16 Figure 35 PACP_GET_req 5. The values taken by this field are defined in the context of the PA_LM_PEER_GET.6 PACP_GET_req 1236 The PACP_GET_req frame is shown in Figure 35.7. 1241 The frame’s fields shall be set as follows: 1242 • 1243 • ConfigResultCode: returns the result of the operation. MIPI Alliance Member Confidential 114 .Version 1.rsp primitive in Table 8 MIBvalue: holds the value of the Attribute 16 1 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_GET_cnf Reserved MIBvalue (high word) MIBvalue (low word) CRC-16 Figure 36 PACP_GET_cnf ConfigResultCode Copyright © 2007-2011 MIPI Alliance.7.00 31-Jan-2011 MIPI Alliance Specification for UniPro 16 1 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_TEST_MODE_req CRC-16 Figure 34 PACP_TEST_MODE_req 5. All rights reserved.8. This PACP frame shall be sent when a PA_LM_PEER_GET.rsp primitive or when the PHY Test Feature requests it. Inc.8.40.req primitive is generated by the DME or when the PHY Test Feature requests it.7 PACP_GET_cnf 1240 The PACP_GET_cnf frame is shown in Figure 36.

Version 1. All rights reserved.rsp primitive.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. Inc.req primitive is generated by the DME or when the PHY Test Feature requests it. MIPI Alliance Member Confidential 115 .rsp primitive in Table 8 16 1 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA ConfigResultCode CRC-16 Figure 38 EscParam_PA = PACP_BEGIN Reserved PACP_FunctionId = PACP_SET_cnf PACP_SET_cnf Copyright © 2007-2011 MIPI Alliance.9 PACP_SET_cnf 1255 The PACP_SET_cnf frame is shown in Figure 38. 1256 The frame’s fields shall be set as follows: 1257 • ConfigResultCode: returns the result of the operation. the PA Layer shall send the PACP_SET_cnf frame.40.8. This PACP frame shall be sent when a PA_LM_PEER_SET.8.8 PACP_SET_req 1244 The PACP_SET_req frame is shown in Figure 37.7.7. When the DME generates the PA_LM_PEER_SET. The values taken by this field are defined in the context of the PA_LM_PEER_SET. 1245 The frame fields shall be set as follows: 1246 • 1247 1248 1249 • 1250 1251 1252 • 1253 • 1254 • Cnf: defines the behavior of the receiving PA Layer • • 0: no PACP_SET_cnf frame shall be sent 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 T: defines the target Attribute type (AttrSetTypeType) • 0: Normal • 1: Static MIBattribute: defines the Attribute to be accessed in the peer Device GenSelectorIndex: the index required for certain Attributes MIBvalue: holds the value which the Attribute shall take 16 1 0 0 0 0 0 0 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ESC_PA EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_SET_req Reserved MIBattribute GenSelectorIndex MIBvalue (high word) MIBvalue (low word) CRC-16 Figure 37 PACP_SET_req Cnf T 5.

3. A timer. There are four variations of the basic PACP_TEST_DATA frame.40. In the example shown in Figure 40. M-TXs and M-RXs are in PWM-G1. the PA Layer shall abort the Link Startup Sequence immediately and terminate any active burst. realignment. TestPattern[n-2] CRC-16 Figure 39 PACP_TEST_DATA TestPattern[3] . each having a different FunctionID and different payload length.2 Data Lane Discovery (Phases 0 and 0b) 1264 The Link Startup Sequence starts with the discovery of the connected M-PHY Data Lanes.1 Initialization Phase 1263 Before the Link Startup Sequence.7. The only constraint is that at least one Data Lane shall be connected in each direction (because UniPro does not support unidirectional Links). All rights reserved.8.8. MIPI Alliance Member Confidential 116 . the peer PA Layers exchange capability information with each other. The frame is used in PHY testing as explained in Section 5.6. The received patterns are undefined since the receiver shall only check the header. 5. 5.. 1259 The TestPattern field carries the PHY test pattern.. is started to provide a timeout signal if the procedure does not complete within a specified time. If the timeout is triggered. The transmitted patterns are defined in Section 5. Inc. PA_LINKSTARTUP_TIMER. the length. 100 ms. and no assumptions are made regarding which TX Data Lane is connected to which RX Data Lane of the peer Device. Finally..Version 1.8. the number of connect ed Lanes (PA_ConnectedTxDataLanes and PA_ConnectedRxDataLanes). 1261 During this sequence. but not all available Data Lanes are connected. M-RXs reset and LINE-RESET issued on all TX Lanes to reset any misconfigured OMCs and peer M-RXs.8.8.8.8 Link Startup Sequence 1260 The overall view of the Link Startup Sequence is covered in Section 5. the Link capabilities (PA_MaxRxHSGear and PA_MaxRxPWMGear). the transceivers are initialized to the default configuration.10 PACP_TEST_DATA 1258 The PACP_TEST_DATA frame is shown in Figure 39. Then the connected M-PHY Lanes are identified and enumerated to produce a mapping between physical Lanes and logical Lanes. and the logical Lane mapping (PA_LogicalLaneMap) are updated.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. and the checksum while ignoring the content of TestPattern. and capability exchange parts. After this. both Devices have four TX Data Lanes and four RX Data Lanes..15. 1262 After the successful completion of the sequence.8. 16 1 0 0 0 0 0 0 15 14 13 12 11 10 ESC_PA 9 8 7 6 5 4 3 2 1 0 EscParam_PA = PACP_BEGIN PACP_FunctionId = PACP_TEST_DATA TestPattern[0] TestPattern[1] TestPattern[2] . This part describes the M-PHYspecific details of the sequence including the Data Lane discovery.15. Copyright © 2007-2011 MIPI Alliance.8. TestPattern[n-1] 5. all available M-TXs and M-RXs shall be (re-)powered.

00 31-Jan-2011 MIPI Alliance Specification for UniPro 1265 In the first phase. Exit to Phase 1. Begin burst (includes the transmission of the deskew pattern) on all available TX Lanes. 1278 10. 1270 2. If a TRG_UPR0 has been received then continue from Step 7. Send two additional TRG_UPR0s on all available TX Lanes. The TRG_UPR0 trigger data structure is defined in Section 5. 1274 6. both Devices shall repeatedly send TRG_UPR0 triggers on all available Data Lanes. but the data structure contains a field that shall be set by every transmitting Data Lane to hold that Data Lane's fixed. Inc. 1266 The peer Device shall update its local PeerTxConnectedLanesMask register to reflect the Data Lanes on which triggers have been received. End burst on all available TX Lanes. MIPI Alliance Member Confidential 117 . 1271 3. Wait for a period of PA_TActivate to wake-up M-RXs from HIBERN8 (see [MIPI05]).6. Node A LocalTxConnectedLanesMask Node B Tx PL#3 PL#2 PL#1 PL#0 TRG_UPR0 (TxLaneNumber = 11) TRG_UPR0 (TxLaneNumber = 10) TRG_UPR0 (TxLaneNumber = 01) TRG_UPR0 (TxLaneNumber = 00) X X X X Rx PeerTxConnectedLanesMask X X X X 1 1 0 0 X 0 1 0 0 PeerTxConnectedLanesMask TRG_UPR0 (TxLaneNumber = 11) TRG_UPR0 (TxLaneNumber = 10) TRG_UPR0 (TxLaneNumber = 01) TRG_UPR0 (TxLaneNumber = 00) PL#3 PL#2 PL#1 PL#0 Tx X X X X LocalTxConnectedLanesMask X X Rx X TRG_UPR0 = MK1 + TRG0_code + TxLaneNumber Figure 40 M-PHY Lanes Discovery Copyright © 2007-2011 MIPI Alliance. after which it shall send two extra TRG_UPR0 Messages before proceed to the next phase. 1267 A Device shall continue transmitting TRG_UPR0 Messages until it receives a TRG_UPR0 Message from the peer Device. Begin burst (includes the transmission of the deskew pattern) on all available TX Lanes. Continue from Step 1. 1276 8. 1275 7. 1273 5. All rights reserved. Wait for a period of PA_TActivate to wake-up M-RXs from HIBERN8 (see [MIPI05]). Send a TRG_UPR0 on all available TX Lanes.8. 1277 9.Version 1. 1268 The following steps describe Phase 0 and Phase 0b operation in detail: 1269 1. internal “Physical Data Lane number” (PL# in Figure 40).40. This information is used in subsequent phases of this sequence. 1272 4.

6. Send a TRG_UPR1 on all available TX Lanes. 1281 A Device shall continue transmitting TRG_UPR1 Messages until it receives a TRG_UPR1 Message. All rights reserved. This register assigns a Logical Data Lane number (LL#) to each connected Physical Data Lane (PL#). MIPI Alliance Member Confidential 118 . 1285 3. If a TRG_UPR1 has been received then continue from Step 4. it shall use the PeerTxConnectedLanesMask information to update its LocalTxConnectedLanesMask register. Reconfigure all available M-TXs and M-RXs to use single-Lane mode while the power mode is kept as PWM-G1.8. Continue from Step 1. Node B Tx PL#3 PL#2 PL#1 PL#0 TRG_UPR1 (PeerTxConnectedLanesMask = 0100) TRG_UPR1 (PeerTxConnectedLanesMask = 0100) TRG_UPR1 (PeerTxConnectedLanesMask = 0100) TRG_UPR1 (PeerTxConnectedLanesMask = 0100) 1288 6. but the data structure contains a field that shall be set on each available Data Lane to the PeerTxConnectedLanesMask value set in the previous phase.4 Repeated Transmission of TRG_UPR1 Messages Link Startup Sequence Termination (Phases 3 and 4) 1289 In the final phases. Inc. both Devices shall repeatedly send TRG_UPR1 triggers on all available Data Lanes. both ends of connected PHY Data Lanes have matching Logical Data Lane numbers. after which it shall send two extra TRG_UPR1 Messages before proceeding to the next phase. Copyright © 2007-2011 MIPI Alliance. The new configuration does not become effective until the end of Phase 4. 1284 2.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.8. 1282 The following steps describe Phase 1 and Phase 2 operation in detail: 1283 1. Node A LocalTxConnectedLanesMask LL#1 LL#0 X X Rx PeerTxConnectedLanesMask 1 1 0 0 1 1 0 0 X 0 1 0 0 PeerTxConnectedLanesMask TRG_UPR1 (PeerTxConnectedLanesMask = 1100) TRG_UPR1 (PeerTxConnectedLanesMask = 1100) TRG_UPR1 (PeerTxConnectedLanesMask = 1100) TRG_UPR1 (PeerTxConnectedLanesMask = 1100) PL#3 PL#2 PL#1 PL#0 Tx 0 1 0 0 LocalTxConnectedLanesMask LL#0 X Rx X TRG_UPR1 = MK1 + TRG1_code + PeerTxConnectedLanesMask Figure 41 5.8. Each Device shall update its PA_ConnectedTxDataLanes and PA_ConnectedRxDataLanes Attributes to reflect how many connected Data Lanes were discovered. 1280 Once the peer Device receives a TRG_UPR1 trigger. 1286 4.8. 1287 5. Send two additional TRG_UPR1s on all available TX Lanes. Exit to Phase 3. when the current burst is closed. The TRG_UPR1 trigger structure is defined in Section 5.8.3 Data Lane Realignment (Phases 1 and 2) 1279 In these phases.Version 1.

7.3. information about which physical Data Lanes are connected and the interconnect topology are not made available to the Application in a normative way. 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. 1298 5.8. In fact. the PA Layer transmits its capabilities and the local version information to the peer Device using PACP_CAP_ind (see Section 5. LCC-READ-MFG-INFO. 1295 2.Version 1. Then. 1299 6. 1296 3. MIPI Alliance Member Confidential 119 . Send a TRG_UPR2 on all available TX Lanes If a TRG_UPR2 has been received then continue from Step 4 Continue from Step 1 Send two additional TRG_UPR2s on all available TX Lanes Close the burst (which activates the new power mode settings) Update PA_LogicalLaneMap.8.8. the PA Layer shall order M-TX on Logical Lane 0 to perform LCC-READ-CAPABILITY.3) using the PHY configuration described in Step 5 of Section 5.8.40. and LCC-READ-VEND-INFO before Copyright © 2007-2011 MIPI Alliance. 1293 The following steps describe Phase 3 and Phase 4 operation in detail: 1294 1.8. both Physical and Logical Data Lane numbers as described in this Link Startup Sequence are invisible to higher protocol layers and to the Application. after which the Device shall send two more TRG_UPR2 Messages over all connected Data Lanes. 1300 7. 1297 4. and begin using the logical Lane numbering M-TXs and M-RXs on unconnected Lanes shall be configured to the UNPOWERED state Exit to Capability Phase Node B Tx LL#1 LL#0 X X TRG_UPR2 TRG_UPR2 Node A LocalTxConnectedLanesMask LL#1 LL#0 X X Rx PeerTxConnectedLanesMask 1 1 0 0 1 1 0 0 X 0 1 0 0 PeerTxConnectedLanesMask X TRG_UPR2 LL#0 X Rx X LL#0 X X Tx 0 1 0 0 LocalTxConnectedLanesMask TRG_UPR2 = MK1 + TRG2_code Figure 42 5. 1301 8. 1292 In these phases.5 Repeated Transmission of TRG_UPR2 Messages Capability Exchange 1302 After finishing Phase 4 of the Link Startup Sequence. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1290 Note: 1291 Because the discovery process is handled autonomously. All rights reserved. These phases essentially serve to terminate previous phases in a robust and orderly manner. and considered to be highly robust.

00 31-Jan-2011 MIPI Alliance Specification for UniPro closing the burst. 1304 The following capabilities shall be collected to the PA Layer Attributes and downgraded based on the local and remote information (M-PHY MODULE Attributes prefixed with “peer” are received in the Link Startup sequence via a PACP_CAP_ind frame): 1305 • PA_MaxRxHSGear := min(RX_HSGEAR_Capability. inserts additional deskew patterns to all active Lanes in order to fix any M-PHY symbol or PA Symbol synchronization issues. deskew pattern injection.8. peer_TX_HSGEAR_Capability) if (RX_HSMODE_Capability=TRUE and MC_HSMODE_Capability=TRUE) else 0 PA_MaxRxPWMGear := min(RX_PWMGEAR_Capability.5). may differ in capabilities. peer_TX_PWMGEAR_Capability) PA_RxHSUnterminationCapability := TRUE if (RX_HS_Unterminated_Capability=YES and MC_HS_Unterminated_Capability=YES and MC_HS_Unterminated_LINE_Drive_Capability=YES and peer_TX_HS_Unterminated_LINE_Drive_Capability=YES) else FALSE PA_RxLSTerminationCapability := TRUE if (RX_LS_Terminated_Capability=YES and MC_LS_Terminated_Capability=YES and MC_LS_Terminated_LINE_Drive_Capability=YES and peer_TX_LS_Terminated_LINE_Drive_Capability=YES) else FALSE PA_SleepNoConfigTime := max(TX_Min_SLEEP_NoConfig_Time_Capability.2).9. MC_HSBURST_Capability. peer_RX_Min_SAVE_Config_Time_Capability) 1306 • 1307 • 1308 • 1309 • 1310 • 1311 • 1312 Since the automatic downgrading process cannot take into account a Basic OMC or the restrictions from the physical interconnection.10 (Re-)Initialization 1315 The PA Layer offers two mechanisms to reinitialize the Link.Version 1.8. 1313 While the capability downgrading is done only once. PWM-G1. it shall perform capability downgrading as described in Section 5. MC_PWMGEAR_Capability. 5. the capability checking is performed whenever there is a request to change the power mode. Inc.8. The peer Device’s version information received in PACP_CAP_ind is stored in PA_RemoteVerInfo. the PA Layer forms a common capability value for the whole inbound Link beginning from the peer M-TX. at the end of the Link Startup sequence.9 Capability Management 1303 Local and remote M-TX and M-RX. and ending with the local M-RX. When the PA Layer receives a PACP_CAP_ind Frame. including any possible Advanced OMC. All rights reserved. MIPI Alliance Member Confidential 120 .8. Equations for calculating the common capability values are listed later in this section. The M-PHY Link is now in the default power mode. the peer PA Layer is responsible for verifying the Link capabilities. 1314 Other capabilities are left for the Application to handle through M-PHY Attributes (see Section 5. This finishes the Link Startup Sequence. peer_RX_Min_SLEEP_NoConfig_Time_Capability) PA_StallNoConfigTime := max(TX_Min_STALL_NoConfig_Time_Capability. To simplify the capability checking.8. The less severe mechanism. if the local Device wants to change parameters of the outbound Link.e.8.ind primitive from the M-RX on Logical Lane 0. and a M-CTRL-LCCReadStatus. as well as any possible OMC. The insertion adds a one symbol delay to the transmission and may be Copyright © 2007-2011 MIPI Alliance. The PA Layer shall verify the inbound Link capabilities. 1-Lane. 5. the Application has the ability to overwrite the calculated capabilities through these Attributes.This capability downgrading is automatically performed at the end of the Link Startup Sequence (see Section 5. For example. peer_RX_Min_STALL_NoConfig_Time_Capability) PA_SaveConfigTime := max(TX_Min_SAVE_Config_Time_Capability. i. 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.40.

The request is ignored in SLEEP_STATE since there is no active burst on-going. The request also contains the current power mode configuration.3. 1328 In the multi-Lane usage.40. 1319 3. or for PACP_REQUEST_TIMER to timeout Configure M-TX and M-RX End burst to activate the new PHY configuration Reply to the DL Layer via a PA_INIT. The procedure is as follows: 1317 1. No PowerModeUserData is exchanged and thus the UserDataValid flag is unset. PACP_REQUEST_TIMER is set to PA_PACPReqTimeout + TLINERESET and started Wait for a PACP_PWR_cnf frame from the peer Device. and possible OMC to PWM-G1 Begin burst on logical Lane 0 Request the peer Device issue LINE-RESET on the inbound Link via PACP_PWR_req. MIPI Alliance Member Confidential 121 . 1333 4.Version 1.8.2. 1316 The more severe mechanism involves reinitializing the power configuration of both inbound and outbound Links. 1332 3. Depending of the deskew requirements. Issue LINE-RESET to reset outbound M-TX.2. 1326 If the reinitialization succeeds.8. The Lane synchronization happens by aligning the incoming deskew patterns that are sent in parallel from the transmitter. this may require. 1321 5. the Lane synchronization is lost and the operation returns to Step 2 1334 In case a deskew pattern is lost and the PA Layer RX cannot acquire the Lane synchronization. The DL Layer can request this mechanism via a PA_INIT primitive (see Section 5. creating shallow deskew-FIFOs within the PA Layer RX. Lanes are not synchronized Per each active Lane. PA Layer RX discards PA symbols until it detects the deskew pattern Once all active Lanes have received the deskew pattern. the power mode is reinitialized using the active settings. Copyright © 2007-2011 MIPI Alliance.3. the PA Layer must synchronize the multiple incoming Lanes because of the skew between the Lanes and because of the independent RX clocks of the M-RXs. 1323 7.00 31-Jan-2011 MIPI Alliance Specification for UniPro requested at any point. When the burst starts. The PA Layer replies to the DL Layer with a PA_INIT. M-RX.16. PA Layer RX begins to consume PA symbols If PA Layer RX detects a new deskew pattern on any Lane. the deskewFIFOs of the synchronized Lanes overflow. 1318 2.cnf_L primitive 1320 4. and a misconfigured M-RX or OMC receives correct settings. 1322 6. which is the intended behavior. which is the high part of the deskew pattern. 1325 If there is a timeout at Step 5. 5.cnf_L primitive. for example. even though the reinitialization failed.11 Lane Synchronization 1327 PA Layer RX shall lock the PA Layer symbol synchronization on each Lane every time the deskew pattern is received. 1324 8. The PA Layer RX shall wait until the peer Device transmits another deskew pattern and shall lock on to this second pattern. Inc. All rights reserved. M-RX handles the M-PHY symbol synchronization by locking to MK0.6). 1335 A deskew-FIFO with a depth of two PA Symbols can handle the maximum Lane-to-Lane skew values specified in Section 5. The PA Layer shall be ready for a possible retry by the DL Layer. 1331 2.1). 1329 The principle operation of the aligner shall be as follows: 1330 1. The mechanism may be triggered by the DL Layer via the PA_LANE_ALIGN primitive (see Section 5. the Link is considered unusable and the reinitialization is aborted.

e.ind primitive and then shall signal the DME with PA_LM_PWR_MODE_CHANGED.1. the end power mode configuration.1 1345 The PA Layer has to arbitrate requests because both Devices might try to change a Link configuration at the same time. both requests were rejected.1.12.cnf_L primitive does not mean that the configuration has been applied. as specified in this section and illustrated in Figure 43. Note. As a result. or the request has been cancelled.8. 1346 The resolution rules are: Copyright © 2007-2011 MIPI Alliance.req primitive. or both directions.1. The requested configuration is invalid and cannot be applied (see Section 5. This last primitive completes the Link configuration and makes the PA Layer ready for the next configuration request. setting the TX power mode to UNCHANGED and the RX power mode to FastAuto_Mode. where the parameter reports the actual result of the operation. reverse. 5. The configuration may have separate settings for forward. 1340 After accepting the power mode change request. 1338 The configuration procedure shall be activated by setting PA_PWRMode via a PA_LM_SET. 1337 Power mode and Lane-count configuration are set via a PA_LM_SET.12.1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. When the configuration has been changed.8.cnf_L primitive where the parameter indicates if the configuration change can proceed.cnf_L primitive or via the PA_LM_PWR_MODE_CHANGED. covers all M-PHY-specific details.13. after a concurrency issue. Inc. A request that originates from the peer Device is signaled to the DME with PA_LM_PWR_MODE_CHANGED. The enter hibernation and exit hibernation procedures are covered in Section 5. The configuration includes UniPro power mode.ind (PWR_REMOTE). All rights reserved.8. only the RX Link is configured. 1339 The PA Layer shall first check that the given configuration is possible and then replies with the PA_LM_SET. and Lane count information.g.ind primitive.12 Link Configuration Procedure 1336 Either Device can change the power mode of a Link by assigning a new power configuration. that a reception of a successful PA_LM_SET.12.Version 1. Once the DL Layer responds with a PA_DL_PAUSE. Attributes may be set in any order since the actual Link configuration procedure begins only after setting PA_PWRMode. shall be either the previous configuration. or a new configuration. all Attributes shall be set before activating the power mode change procedure. For example. one request was rejected and one request was accepted. The failure notification is sent to the DME either via the return parameter of the PA_LM_SET. and there is a special value for keeping the current power mode.2).rsp_L primitive.8.req primitive to the related Attributes (see Section 5.ind primitive.12. In every case.e.40. The Link Configuration procedure.1).ind primitive depending upon when the concurrency was detected.8. The Attribute contains fields for both directions. the PA Layer shall first request permission from the DL Layer via the PA_DL_PAUSE. MIPI Alliance Member Confidential 122 .1 Error Handling 1341 A configuration request may be cancelled due to the following reasons. M-PHY-specific Attributes. 1342 • 1343 • 1344 • A race condition between two requests (see Section 5. the PA Layer shall notify the DL Layer via a PA_DL_RESUME. the PA Layer may reject one or both requests depending on the relative timing of those requests.3) Concurrency Resolution 5. i. GEARs. the PA Layer may begin changing the configuration.8.ind (PWR_LOCAL).12. e. i.8. only that the request was accepted by the PA Layer. An unrecoverable error in the communication (see Section 5. However. The PA Layer shall later indicate the completion of the configuration change via the PA_LM_PWR_MODE_CHANGED.9).

the conflict is detected when the DME issues a PA_LM_SET.8.Version 1. 5. e. PA_LM_SET. In this case. the second rule causes concurrent requests from both Devices to be rejected when both local and remote DeviceIDs have not yet been assigned.cnf_L primitive having a parameter BUSY. All rights reserved. to the peer DME. e.2 Detailed Operation 1355 The configuration is set via PA_HSSeries. 1357 When the remote PA Layer receives a valid PACP_PWR_req frame. Before sending the PACP_PWR_req frame to the remote PA Layer. Attributes are assumed to be set before changing the power mode.g. the return value of the PACP_PWR_cnf shall be set to PWR_ERROR_CAP. 5. possibly even inoperable. the PA Layer can transmit user-data. PA_TxTermination. the request may be cancelled in the following phases: 1351 1. it shall first check the request against its inbound Link. This can be supplied via PA_PWRModeUserData. the operation shall be aborted and the DME shall be signaled with PA_LM_PWR_MODE_CHANGED. with its Copyright © 2007-2011 MIPI Alliance. the local PA Layer requests permission from the DL Layer.1.g. The receiving PA Layer shall silently ignore all PACP frames that fail the checksum check or are otherwise invalid. the local PA Layer shall begin a burst on the outbound Link. then the equation guarantees that one of two on-going requests is accepted.3 1354 The Link Configuration Procedure uses the Link to exchange PACP frames (see Section 5. Then the remote PA Layer shall request permission from the DL Layer. In case of a failure.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1347 1. PA_TxGear. PA_RxTermination. in this case from remote to local. If the given configuration is determined to be impossible.12.req primitive to PA_PWRMode. 1356 The basic principle of the power mode change is depicted in Figure 43. The local PA Layer first checks the request against the inbound Link capabilities. PA_LM_SET. If at least one of the DeviceIDs have been set. Once this frame is received by the local PA Layer.cnf_L (INVALID_MIB_ATTRIBUTE_VALUE). the PA Layer shall respond with PA_LM_SET.8. 1349 Note. and PA_ActiveRxDataLanes. If the value exceeds the defined range. Communication Errors and Retries 1353 3.ind (PWR_FATAL_ERROR).3) with the peer Device and is thus vulnerable to bit errors. otherwise X is 0x80. 1348 2.g. Next. A remote request shall be rejected when the PA Layer is processing a local request. 1352 2. the PA Layer shall be in a state where it can accept new power mode change requests from the DME.req to a configuration Attribute.g.2 Invalid Configuration Detection 1350 If the requested configuration is invalid. where X is N_DeviceID if N_DeviceID_valid is TRUE. MIPI Alliance Member Confidential 123 . the DME shall be informed via the PA_LM_PWR_MODE_CHANGED. in this case from local to remote. PA_ActiveTxDataLanes. requires a higher speed than is supported.12. If the required configuration is determined to be invalid by the peer Device.40. PA_RxGear. In addition to the M-PHY MODULE configuration. L2 timer values. If the PA Layer timeouts when waiting for a valid PACP_PWR_cnf frame after two retransmission attempts.cnf_L (INVALID_MIB_ATTRIBUTE_VALUE). 5.req to PA_PWRMode. e.ind primitive with the parameter set to PWR_ERROR_CAP. The requesting Device is responsible for retransmitting the request after a timeout. the remote PA Layer shall exchange PAPowerModeUserData. the end configuration of the Link is indeterminate.8. The DME is notified with a PA_LM_SET. A local request shall be rejected when the PA Layer is processing a local request or a remote request from the peer Device. L2 timer values. e. However.12.1. due to conflicting configuration parameters.8. and the DevID field of the remote request is larger than or equal to X. Inc. After replying to the DME that the request was accepted. the PA Layer shall respond with PA_LM_SET.

In order to configure the possibly existing OMCs. If the status is positive. Inc.ind signal with the parameter PWR_LOCAL and PWR_REMOTE.req primitive Wait for PA_TActivate 1365 The following Attributes are set on an active M-TX. For example. respectively. Both sides shall notify their respective DL Layers about the completion of the procedure. The local PA Layer shall close the burst on the outbound Link. the inactive Lanes (awake or not) shall never be used for data communication. The local and remote PA Layer notify their respective DMEs with a PA_LM_PWR_MODE_CHANGED. it shall first check the status of the confirmation. However. Consequently. MIPI Alliance Member Confidential 124 . Then the remote PA Layer shall begin a burst on its outbound Link.00 31-Jan-2011 MIPI Alliance Specification for UniPro DME.e. the received PAPowerModeUserData is given to the local DME and the local M-PHY shall be configured with the requested parameters.Version 1. the second Lane is in HIBERN8 and thus needs to be woken up in order for the M-PHY to configure the OMCs on the second Lane. Before sending the PACP_PWR_cnf frame to the local PA Layer. after this change: 1366 • 1367 • 1368 1369 1370 1371 1372 1373 1374 • 1375 1376 1377 1378 1379 TX_LCC_Sequencer := WRITE_ATTRIBUTE if Fast_Mode or FastAuto_Mode: • • • • • TX_MODE := HS_MODE TX_HSRATE_Series := hs_series TX_HSGEAR := gear TX_HS_Unterminated_LINE_Drive_Enable := NOT termination MC_HS_Unterminated_LINE_Drive_Enable := NOT termination • MC_HS_Unterminated_Enable := NOT termination if Slow_Mode or SlowAuto_mode: • • • • • TX_MODE := LS_MODE TX_PWMGEAR := gear TX_LS_Terminated_LINE_Drive_Enable := termination MC_LS_Terminated_LINE_Drive_Enable := termination MC_LS_Terminated_Enabled := termination 1380 The following Attributes are set on an inactive M-TX.3 Configuring M-PHY 1359 The power configuration of an M-TX or an M-RX is always set during an active burst. The remote PA Layer shall close the burst on the other Link when detecting the end of burst on its inbound Link. after this change: 1381 • TX_HIBERN8_Control := ENTER Copyright © 2007-2011 MIPI Alliance.40. i. when the Lane count is increased from one to two. a Lane that is active. 1358 When the local PA Layer receives a valid PACP_PWR_cnf frame. the M-PHY shall be configured with the parameters of the request.e. i.12. a Lane that is inactive. 1360 The lane wake-up is performed as follows: 1361 • 1362 1363 1364 • For all lanes that will be activated: • Set TX_HIBERN8_Control := EXIT • Inform M-TX that configuration is ready via the M-CTRL-CFGREADY. or will be inactive. This concludes the power mode change and both PAs are ready for subsequent operations. 5. the inactive Lanes that are requested to be activated shall be woken up and put into the burst before applying the configuration. All rights reserved.8. both directions of the Link have now the new configuration activated. or will be active.

The remote DME responds with the PA_LM_PWR_MODE. The length of PAPowerModeUserData is enough to store all L2 timer values for all traffic classes. Figure 43 shows the successful case and it is used here as the basis for the description. 1398 While the reinitialization procedure (see Section 5. All rights reserved.5 Error Recovery 1399 This section describes recovery mechanisms that are used to cope with an unreliable communication path that might introduce bit-errors or symbol loss. is defined in Table 117. The unset flag instructs the receiving PA Layer to skip the data delivery to the DME completely.ind(TRUE.12. Copyright © 2007-2011 MIPI Alliance.rsp_L(payload_cnf) primitive. when the requesting PA Layer receives the response in a PACP_PWR_cnf frame. a Lane that is active. 5.40. after this change: 1394 • RX_Enter_HIBERN8 := YES 1395 After setting Attributes. the UserDataValid flag of a PACP_PWR_req frame shall be unset to mark that the PAPowerModeUserData does not carry valid data. In those operations. the configuration is marked as ready via a M-CTRL-CFGREADY primitive. 5. The PA Layer shall wait until the local DME responds with PA_LM_PWR_MODE.8.8. The local PA Layer shall deliver the payload back to the local DME with the PA_LM_PWR_MODE. PAPowerModeUserData is just a 24-byte payload for the PA Layer.4 User Data within PACP_PWR frames 1396 The PA Layer provides a method for the local and remote DME to exchange information that is needed during the power mode change. they do not support the user data exchange described above. On reception. supplies the information with the value of PA_PowerModeUserData before setting PA_PWRMode.ind(FALSE. Inc.e.10) and the hibernation procedure (see Section 5.e. payload_req) primitive. The first parameter tells if the request was originated from this side. Similarly.1) exploit functionalities of the Link Configuration procedure. The local PA Layer shall attach this information to the PACP_PWR_req frame and transmit it. or will be inactive.rsp_L( null ) before finishing the power mode change operation. which creates the power mode change request.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1382 • TX_LCC_Sequencer := WRITE_ATTRIBUTE 1383 The following Attributes are set on an active M-RX. 1397 The local DME. payload_cnf). the remote PA Layer shall deliver the payload to the remote DME via the PA_LM_PWR_MODE. i. i. The structure of PAPowerModeUserData. after this change: 1384 • 1385 1386 1387 1388 1389 • 1390 1391 1392 if Fast_Mode or FastAuto_Mode: • • • RX_MODE := HS_MODE RX_HSRATE_Series := hs_series RX_HSGEAR := gear • RX_HS_Unterminated_Enable := NOT termination if Slow_Mode or SlowAuto_mode: • • • RX_MODE := LS_MODE RX_PWMGEAR := gear RX_LS_Terminated_Enabled := termination 1393 The following Attribute is set on an inactive M-RX.8. as used by the DME.12. MIPI Alliance Member Confidential 125 .13. The information is transmitted in PAPowerModeUserData in the PACP_PWR_req and PACP_PWR_cnf frames.Version 1. it skips the data delivery to the DME. These settings become active when the Lane exits the burst. a Lane that is inactive. The remote PA Layer shall then attach the payload_cnf to the PACP_PWR_cnf frame and transmit it.8. or will be active.

1407 Transmissions after LINE-RESET use the PWM-G1 1-Lane configuration. the PA Layer shall abort the power mode request and notify the DME via a PA_LM_PWR_MODE. in all other cases the PA Layer uses the current mode. If a valid PACP_PWR_cnf Message is not received before PACP_REQUEST_TIMER expires. PACP_REQUEST_TIMER shall be set to If a valid PACP_PWR_cnf Message is not received before the timer expires. All rights reserved. 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. 1403 2. The first PACP_PWR_req PA_PACPReqTimeout. MIPI Alliance Member Confidential 126 . 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. respectively. to detect a missing PACP_PWR_cnf Message and also to detect missing end of burst of the inbound Link.ind primitive with the parameter PWR_FATAL_ERROR.Version 1. The timer is reset to PA_PACPReqTimeout. 1404 3. PACP_REQUEST_TIMER. 1405 4. 1406 When a PACP_PWR_cnf Message is received successfully.ind primitive with the parameter PWR_FATAL_ERROR. The reset flag instructs the remote PA Layer to do a LINE-RESET on the opposite direction.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1400 The local PA Layer shall have a timer. the PACP_PWR_req is sent again. Copyright © 2007-2011 MIPI Alliance. Inc.40. is transmitted. the local PA Layer shall abort the power mode request and notify the DME via a PA_LM_PWR_MODE_CHANGED. PACP_REQUEST_TIMER shall be reset to PA_PACPReqTimeout + TLINERESET to take into account the time consumed at the remote LINE-RESET. The initial timer value shall be set through PA_PACPReqTimeout and PA_PACPReqEoBTimeout. Only the local PA Layer shall take recovery actions while the remote PA Layer only follows them: 1402 1. 1401 The following list includes the steps related to error recovery. If a valid PACP_PWR_cnf Message is not received before PACP_REQUEST_TIMER expires.

When entering hibernation.Version 1.rsp_L PA_DL_PAUSE Burst TX Configure MODULEs PACP_PWR_cnf WaitEoB PACP_REQUEST_TIMER Check cnf PA_LM_PWR_MODE. MIPI Alliance Member Confidential 127 . or equal to.ind PA_LM_PWR_MODE_CHANGED.ind PA_LM_PWR_MODE_CHANGED.rsp_L Configure MODULEs End TX Burst PACP_REQUEST_TIMER WaitEoB End TX Burst PACP_REQUEST_TIMER PA_DL_RESUME. All rights reserved.ind (PWR_REMOTE) Idle Figure 43 Power Mode Change using PACP_PWR_req and PACP_PWR_cnf 5. The hibernate enter and hibernate exit procedures are described in this section. x) Check Capability PA_LM_SET.req (PA_PwrMode. Inc. THIBERN8.ind PA_LM_PWR_MODE.8. The implementation can use a timer to guarantee this condition. 1409 The time in hibernation shall be greater than. defined in [MIPI05]. They are automatically restored when exiting hibernate.40. the minimum hibernate time. the current power mode configuration.13 PA Hibernate 1408 Hibernate is separated from the normal power mode change operation.cnf_L (SUCCESS) PA_DL_PAUSE Burst TX PACP_REQUEST_TIMER PACP_PWR_req WaitCnf Check Capability PA_LM_PWR_MODE. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro Local DME Local PA Idle Remote PA Idle Remote DME PA_LM_SET.ind (PWR_LOCAL) Idle PA_DL_RESUME. are stored.ind PA_LM_PWR_MODE. including M-PHY settings and Lane count information.

req primitive to the PA Layer to put the PA Layer into hibernate. Otherwise. PWR_BUSY or PWR_FATAL_ERROR. 1411 When the procedure has completed successfully. 1413 The procedure is depicted in Figure 44. except Logical Lane 0. the Link in both directions is in HIBERNATE_STATE and the M-PHY MODULEs are in HIBERN8.cnf_L PA_LM_HIBERNATE_ENTER. Inc. All rights reserved.ind primitive with the parameter set to PWR_REMOTE to the peer DME. and Copyright © 2007-2011 MIPI Alliance. the PA Layer shall issue a PA_LM_HIBERNATE_ENTER.ind primitive User data in PACP_PWR_req and PACP_PWR_cnf frames is not used.8. In error cases.req primitive instead of using Attributes The PA Layer uses PA_LM_HIBERNATE_ENTER.ind primitives as described previously. a PA_LM_HIBERNATE_ENTER. Internally. other Attributes shall not be set 1421 The concurrency and error recovery methods are as in the normal Link Configuration procedure. and is not forwarded to the DME (see Section 5. The peer PA Layer shall issue a PA_LM_HIBERNATE_ENTER. it shall respond with the parameter set to Failure.12. other Attributes shall not be set For all active M-RXs.40.req primitive shall cause the PA Layer to set all available M-RX Lanes to HIBERNATE_STATE. the PA Layer shall use the same Link Configuration procedure as specified in Section 5.1 Entering Hibernate 1410 The DME issues a PA_LM_HIBERNATE_ENTER.8.8.cnf_L primitive with the parameter set to Success.ind primitive with the parameter set to PWR_LOCAL to the requesting DME. instead of using the Link Configuration procedure.g.cnf_L to indicate acceptance of the hibernate request The PA Layer indicates the status with the PA_LM_HIBERNATE_ENTER.Version 1. The squelch detection of an M-RX may be turned off on all Lanes. it shall respond with the PA_LM_HIBERNATE_ENTER. the primitive has other status.12 with the following modifications: 1414 • 1415 • 1416 • 1417 • 1418 • 1419 • 1420 • DME uses the PA_LM_HIBERNATE_ENTER. RX_Enter_HIBERN8 shall be set to YES.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5.4) Entering hibernate never fails due to invalid configuration or capability checking For all active M-TXs. e. 1423 The PA Layer shall generate the PA_LM_HIBERNATE_ENTER. to save power. TX_HIBERN8_Control shall be set to ENTER and TX_LCC_Sequencer to MPHY_TX_LCC_Sequencer_LCC_WRITE.13. 1422 If the Link Startup Sequence has not been started. If the PA Layer is not busy with another power mode change operation. MIPI Alliance Member Confidential 128 . 1412 After successful completion of the procedure.

13.req PA_LM_HIBERNATE_ENTER. the following information shall be retained: 1425 • 1426 • 1427 1428 1429 1430 1431 PHY configuration (retained by M-PHY MODULEs) Information gathered during Link Startup sequence: • • • • • PA_ConnectedTxDataLanes. PA_StallNoConfigTime. All rights reserved. PA_ConnectedRxDataLanes PA_LogicalLaneMap PA_MaxRxPWMGear.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.Version 1. PA_SaveConfigTime Copyright © 2007-2011 MIPI Alliance.ind (PWR_REMOTE) LinkHibernate LinkHibernate Figure 44 5.ind PA_LM_HIBERNATE_ENTER.2 Entering Hibernate (after Link Startup) Retained State Information 1424 While in HIBERNATE_STATE.40. Inc.ind PA_LM_HIBERNATE_ENTER. PA_MaxRxHSGear PA_RemoteVerInfo PA_SleepNoConfigTime.8.ind (PWR_LOCAL) PA_DL_RESUME. MIPI Alliance Member Confidential 129 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Local DME Local PA Idle Remote PA Idle Remote DME PA_LM_HIBERNATE_ENTER.

ind(PWR_LOCAL) that the hibernate has ended. it wakes up and informs the local PA Layer with the M-LANEH I B E R N 8 E x i t . the PA Layer shall retain the Link configuration active before entering HIBERNATE_STATE which is gettable through the following Attributes (see Section 5. When the exit hibernate procedure has completed.ind primitives as described previously.13. 1447 Similarly. driving DIF-N and waiting for incoming DIF-N. The PA_LM_HIBERNATE_EXIT. PA_RxTermination Exiting Hibernate 5.ind primitive shall cause the remote PA Layer to wake up its M-TXs by setting TX_HIBERN8_Control to EXIT on all active TX Lanes. PA_RxGear PA_HSSeries PA_TxTermination.ind primitive to the remote DME with the parameter set to PWR_REMOTE. PA_ActiveRxDataLanes PA_TxGear. 1445 If WAIT_HIBERN8EXIT_TIMER expires. if the PA Layer receives a M-LANE-HIBERN8Exit. the remote PA Layer shall signal the remote DME with PA_LM_HIBERNATE_EXIT. Similarly. After PA_TActivate. the local PA Layer issues a PA_LM_HIBERNATE_EXIT.ind(PWR_FATAL_ERROR) to the local DME. possibly inoperable state. At this point.ind primitive. T h e l o c a l PA L a y e r s h a l l s i g n a l t h e l o c a l D M E w i t h PA_LM_HIBERNATE_EXIT.ind primitive to the local DME with the parameter set to PWR_LOCAL. 1448 Exiting hibernate is depicted in Figure 45.req primitive shall cause the PA Layer to skip the wake-up procedure previously described. a PA_LM_HIBERNATE_EXIT.Version 1. i. Copyright © 2007-2011 MIPI Alliance. i n d p r i m i t i v e . 1443 When the remote M-RX detects DIF-N. This causes the M-TXs to begin driving DIF-N to the Lanes. it wakes up and informs the remote PA Layer with a M-LANEHIBERN8Exit. The M-LANE-HIBERN8Exit. 1446 If the Link Startup Sequence has not been started. the PA Layer shall skip the wake-up procedure previously described.cnf_L and PA_LM_HIBERNATE_EXIT. when the remote PA Layer detects the end of hibernate. The local PA Layer shall wait for PA_TActivate and then start a timer WAIT_HIBERN8EXIT_TIMER set to PA_TActivate.40.8.ind primitive while the Link Startup sequence has not begun. 1442 The PA Layer uses M-PHY signaling to exit HIBERNATE_STATE. all active TX Lanes shall be woken up by setting TX_HIBERN8_Control to EXIT. i. All rights reserved. it issues a PA_LM_HIBERNATE_EXIT. the Link is in unknown. Inc.e. The PA Layer confirms the request with a PA_LM_HIBERNATE_EXIT.ind(PWR_REMOTE) that the hibernate has ended.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1432 1433 • 1434 • • PA_RxHSUnterminationCapability.cnf_L primitive. The PA Layer shall generate the PA_LM_HIBERNATE_EXIT. PA_PACPReqEoBTimeout 1435 In addition. 1436 1437 1438 1439 1440 • • • • • PA_PWRMode PA_ActiveTxDataLanes.req primitive. the hibernate exit has failed and the local PA Layer shall issue a PA_LM_HIBERNATE_EXIT. MIPI Alliance Member Confidential 130 . driving DIF-N. PA_RxLSTerminationCapability PA_TActivate PA_PACPReqTimeout.3 1441 The DME can request the PA Layer exit hibernate by issuing a PA_LM_HIBERNATE_EXIT.ind primitive indicates that the Link is restored and is using the configuration that was active before hibernation. 1444 When the local M-RX detects DIF-N.e. First.9).

req or PA_LM_PEER_SET. PACP_SET_req and PACP_SET_cnf frames. This is accomplished by using PACP_GET_req.req request with a confirmation where ConfigResultCode is set to BUSY. 1453 When the remote PA Layer receives the PACP_GET_req frame. or PA_LM_SET.req primitives are implemented.rsp Copyright © 2007-2011 MIPI Alliance.cnf.14. When the PA Layer receives the PACP_GET_cnf frame.3).cnf_L Configure MODULEs PA_TActivate WaitTActive (DIF-N) Timer WaitRxWake (DIF-N) Configure MODULEs PA_TActivate WaitTActive Timer PA_LM_HIBERNATE_EXIT.8.req and PA_LM_PEER_SET.req. Inc.14.40. it shall forward the Attribute information to the DME via the PA_LM_PEER_GET.14 Remote Attribute GET and SET 1449 The PA Layer provides a method to set and get peer Device’s Attributes.8. The PA Layer shall wait for a PA_LM_PEER_GET. 1450 While the PA Layer is executing a power mode change or processing a PA_LM_PEER_GET.req primitive. the PA Layer shall respond to a PA_LM_PEER_GET. PA_LM_PEER_SET. The PA Layer shall wait until it receives the confirmation or the timer expires (see Section 5.ind (PWR_LOCAL) PA_LM_HIBERNATE_EXIT. 1451 The logic for transmitting PACP_GET_req and PACP_SET_req frames is optional.req primitive from the DME. Note that the same PACP frames are used also in the PHY testing. PACP_GET_cnf. MIPI Alliance Member Confidential 131 .req PA_LM_HIBERNATE_EXIT.req.8. PA_LM_GET. 5. and depends whether the PA_LM_PEER_GET.ind (PWR_REMOTE) Idle Idle Figure 45 Exiting Hibernate (after Link Startup) 5.1 GET Operation 1452 When the PA Layer receives a PA_LM_PEER_GET.req. All rights reserved.ind primitive. The PA Layer is just a transport while the actual processing of the requests is implemented in the peer Device’s DME.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Local DME Local PA LinkHibernate Remote PA LinkHibernate Remote DME PA_LM_HIBERNATE_EXIT. it shall forward the results to the DME via the PA_LM_PEER_GET. the PA Layer shall transmit a PACP_GET_req frame containing the same information that the primitive had.

40. it shall transmit a PACP_GET_cnf frame containing the results given in the primitive.cnf or PA_LM_PEER_SET.3).rsp primitive.e. the PA Layer shall set PACP_REQUEST_TIMER to PA_PACPReqTimeout. The number of passed and failed test patterns can be read from the PA_PACPFrameCount and PA_PACPErrorCount counters (see Section 5.14. the DUT. depending of the request. 1459 To be able to define a generic way to test the M-PHY. the PA Layer shall support 2 modes of operation: the normal operating mode and a dedicated mode for testing the MPHY. the PA Layer shall wait until it receives the confirmation or the timer expires (see Section 5. the PA Layer of the DUT shall go to the testing mode. it shall forward the results to the DME via the PA_LM_PEER_GET. When transmitting a PACP_GET_req or PACP_SET_req frame. 5. the PA Layer shall abort the DME’s request by issuing a PA_LM_PEER_GET. If the Cnf flag was set. The PA Layer of the DUT shall stop to forward any PA Symbols to the Data Link Layer and shall not accept any PA Symbols from the Data Link Layer.12. 1461 The following operations shall be available in the PHY test mode: 1462 • 1463 • Lane merging.14. which can generate and send certain patterns of M-PHY symbols to the M-PHYs. a specific M-PHY Test Feature is required. All rights reserved.Version 1. 5. Therefore. it shall forward the Attribute information to the DME via the PA_LM_PEER_SET. with the parameter ConfigResultCode set to PEER_COMMUNICATION_FAILURE.8.5 for PACP_PWR_req.8. the flag may be unset if the confirmation is not required.ind primitive. 1455 When the remote PA Layer receives the PACP_SET_req frame. The behavior and functionalities may differ from the normal operation.req primitive from the DME. The PA Layer shall be able to receive a PACP_TEST_MODE_req frame during Link Startup sequence in order to provide a mechanism for test equipment to bypass the normal Link Startup procedure. 1460 Since the PA Layer and the M-PHY Test Feature need to be both in direct contact with the M-PHY. MIPI Alliance Member Confidential 132 . 1457 Note. This Test Feature is essentially a controllable state machine. If the timer expires before receiving the confirmation frame. which can be received and analyzed by a specialized tool. When the PA Layer receives the PACP_SET_cnf frame.8. the replay mechanism of PACP_GET and SET_req is identical to the one specified in Section 5. the Tester shall send a PACP_TEST_MODE_req frame. When the PA Layer receives the primitive.15 PHY Testing 1458 This section describes the PA Layer’s operation in the PHY test-mode. 5.8. so that in receiver testing.7).14. the Test Feature shall use the frame verification of a PACP frame. distribution. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro primitive. When a UniPro Device.cnf primitive. the PA Layer shall transmit a PACP_SET_req frame containing the same information that the primitive had. but in PHY testing.cnf. receives the PACP_TEST_MODE_req frame. with the exception that the LINE-RESET phase is not used here. If the PA Layer fails to receive a response after three transmissions (i. To set the PA Layer of a DUT in a testing mode. an implementation may share the replay functionality (including the timer) between these two features.8. The Cnf flag of the PACP_SET_req frame shall be set always when the request is originated from the DME. The PA Layer shall wait for a PA_LM_PEER_SET. When the PA Layer receives the primitive.3 Replay Mechanism 1456 The PA Layer has a replay mechanism to protect against random communication errors.8.2 SET Operation 1454 When the PA Layer receives a PA_LM_PEER_SET. the PA Layer shall transmit a PACP_GET_cnf frame containing the status given in the primitive. two retries). These test patterns are encapsulated into PACP frames. and if the Cnf flag in the PACP_SET_req frame was set. the PA Layer shall retransmit the request frame. and synchronization Reception and decoding of the following PACP frames Copyright © 2007-2011 MIPI Alliance.

Note. including those that are specified to be write-protected in the normal mode. Instead. the PA Layer TX shall send FILLERs. When there is no data to be sent. The PA Layer shall select the variation based on the value in PA_ActiveTxDataLanes. the bit is automatically cleared. which is normally gathered during the Link Startup sequence. The reception of the frame shall cause the PA Layer to cancel an active Link Startup sequence immediately and enter into test mode. shall be manually set via PACP_SET_req frames: 1472 1473 1474 1475 1476 1477 • • • • • • PA_ConnectedTxDataLanes PA_ConnectedRxDataLanes PA_LogicalLaneMap PA_SleepNoConfigTime PA_StallNoConfigTime PA_SaveConfigTime 1478 In the test-mode. CJTPAT and CRPAT with four variations for different lane counts.15. When there is no data to be sent. the PA Layer TX shall issue a M-LANELINERESET. the PA Layer TX shall create a new burst for each transmitted PACP frame. the M-PHY MODULE’s power configuration is not handled by the PA Layer’s normal power mode change operation. The generated test pattern sequence is selected with the TestPatternSelect parameter in PA_PHYTestControl. If ContBurst is set in PA_PHYTestControl.2. 1479 M-TXs shall be controlled as follows: 1480 • 1481 • 1482 • 1483 • If ContBurst is unset in PA_PHYTestControl. the M-PHY MODULE’s configuration shall be set via PACP_SET_req frames directly to the M-PHY MODULE’s Attributes. Copyright © 2007-2011 MIPI Alliance. The CJTPAT and CRPAT test sequences are given in Section 5.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1464 1465 1466 • 1467 1468 • PACP_GET_req and PACP_SET_req • PACP_TEST_DATA Transmission and encoding of the following PACP frames • • PACP_GET_cnf and PACP_SET_cnf PACP_TEST_DATA 1469 The PACP_TEST_MODE_req frame shall be sent on a single Lane before or during the Link Startup sequence.40. The PA Layer shall encode the test pattern data into a PACP_TEST_DATA frame as shown in Table 29. The M-LANE-CFGREADY. The PA Layer shall generate the CJTPAT sequence when Test PatternSelect is set to zero and the CRPAT sequence when TestPatternSelect is set to one.8.8. Therefore.req on all PA_ConnectedTxDataLanes.req to all M-TXs and M-RXs. the PA Layer TX shall issue a M-LANECFGREADY. 1470 The PA Layer shall exit from the test-mode with power-on reset. When LineReset is set in PA_PHYTestControl.15.1 and Section 5. 1484 The PA Layer shall send test patterns when SendTestPattern is set in PA_PHYTestControl. MIPI Alliance Member Confidential 133 . respectively. the PA Layer shall allow all access to M-PHY MODULE’s Attributes. All rights reserved. When CfgReady is set in PA_PHYTestControl. 1471 The following information. the bit is automatically cleared. Note. the M-TX shall be in SAVE state.req primitive is controlled via PA_PHYTestControl. the PA Layer TX shall keep the M-TX in BURST mode.Version 1. Inc. The PA Layer supports two Test Patterns.

15. All rights reserved. Empty cell equals zero (i.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 29 Pattern CJTPAT CRPAT CJTPAT CRPAT CJTPAT CRPAT CJTPAT CRPAT Active Lanes 1 PHY Test Pattern PACP Frames PACP Frame PACP_TEST_DATA_0 Payload CJTPAT_1 CRPAT_1 CJTPAT_2 CRPAT_2 CJTPAT_3 CRPAT_3 CJTPAT_4 CRPAT_4 CRC-16 0xAE43 0xFFA6 0x9AE7 0xE543 0x6A6C 0xBBBE 0x68D4 0x43E6 2 PACP_TEST_DATA_1 3 PACP_TEST_DATA_2 4 PACP_TEST_DATA_3 5. The left column specifies the PA Layer Symbol while the value in the CJTPAT_n column specifies how many times that symbol is transmitted.e. Table 30 PA Symbol CJTPAT Test Patterns Repeat Count CJTPAT_1 0x0ABD 0x0AFD 0x7E7E 0x7E74 0x7EAB 0xB5B5 0xB55E 0x4A7E 0x7E7E 0x7E6B 0x7E54 0x4A4A 0x4ABE 0xB57E 0x9AAB 0x9AE7 0x0AAB 21 1 1 6 1 1 21 1 1 6 1 1 1 CJTPAT_2 CJTPAT_3 1 CJTPAT_4 2 42 2 2 12 2 2 42 2 2 12 2 2 1 63 3 3 18 3 3 63 3 3 18 3 3 1 1 1 84 4 4 24 4 4 84 4 4 24 4 4 2 Copyright © 2007-2011 MIPI Alliance.8. Inc. the symbol is not transmitted at all).40. MIPI Alliance Member Confidential 134 .1 CJTPAT Sequences 1485 The payload of the CJTPAT Test Pattern PACP frames shall be as specified in Table 30. These symbols shall be transmitted in the order shown in the table from top to bottom.

Therefore. PA_RxGear.15. The symbols are abbreviated to capital letters for editorial reason.req of these Attributes is not necessarily the value that was previously set. PA_ActiveRxDataLanes. 1505 All PHY Adapter Layer Attributes should be readable. maximum of four Lanes per direction All capabilities of all M-TXs are equal All capabilities of all M-RXs are equal Maximum Lane-to-Lane skew less than • • • • 40 ns at PWM 16 ns at HS-G1 8 ns at HS-G2 4 ns at HS-G3 5. Table 31 A 0xB314 B 0x5EFB C 0x3559 D CRPAT Test Pattern PA Symbols E 0x2347 F 0x6B8F G 0xAAB8 H 0x0ABD K 0x0AFD L 0xAAB1 0xBED7 5.8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 5. PA_TxTermination.16 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 • • • • • • Physical Layer Requirements 1492 UniPro requires an M-PHY instance to fulfill the following requirements: M-PHY Type I The PWM-G1 mode is mandatory Minimum of one Lane per direction. PA_HSSeries. 1506 A PA_LM_GET. and Table 35 show PHY Adapter Layer Attributes that may be accessed via PA_LM_GET and PA_LM_SET primitives. the value returned from a PA_LM_GET.8. Inc. and PA_RxTermination Attributes shall return the value of the currently active parameter of the Link. All rights reserved. during system initialization.40. e.Version 1. settable PHY Adapter Layer Attributes shall be set prior to normal operation.9 Management Information Base and Protocol Constants 1503 Table 33. PA_PWRMode. Copyright © 2007-2011 MIPI Alliance.2 CRPAT Sequences 1486 The payload of the CRPAT Test Pattern PACP frames shall be as follows: 1487 1488 1489 1490 • • • • CRPAT_1: 10*(ABCDEF) + 1*(ABG) CRPAT_2: 10*(ABBCCDDEEFFA) + 1*(ABBCG) CRPAT_3: 1*(H) + 10*(ABCBCDCDEDEFEFAFAC) + 1*(ABCBCDGG) CRPAT_4: 2*(K) + 10*(ABCDBCDECDEFDEFAEFABFABC) + 1*(ABCDBCDEGLG) 1491 In the above sequences. PA_TxGear. the number defines the repeat count of the symbol vectors given in the parenthesis.g. Table 34. MIPI Alliance Member Confidential 135 .req to PA_ActiveTxDataLanes. 1504 For the current version of UniPro. The mapping of letters to PA Symbols is given in Table 31.

5. With D-PHY.9. PA_TxTrailingClocks 0x1564 Integer Symbol 0 to 255 255 255 MIPI Alliance Specification for UniPro Table 34 Attribute PA_PHY_Type Attribute ID 0x1500 PHY Type PHY Adapter (gettable.40. All rights reserved. settable) Common Attributes Type Integer Integer Unit Lane Lane Valid Attribute Value(s) 1 to PA_AvailTxDataLanes 1 to PA_AvailRxDataLanes Mandatory Value(s) 1 1 Reset Value 1 1 Description Active TX Data Lanes Active RX Data Lanes Number of PHY byte clock cycles forced without data before a mode change from FAST_STATE or SLOW_STATE to SLEEP_STATE.1 PHY Adapter Common Attributes Table 32 PHY Adapter Protocol Constants Description The maximum number of PHY data lanes supported by the PA Layer Type Integer Unit Lane Value 4 Version 1. MIPI Alliance Member Confidential 136 Table 33 Attribute PA_ActiveTxDataLanes PA_ActiveRxDataLanes Attribute ID 0x1560 0x1580 PHY Adapter (gettable. Inc. static) Common Attributes Description Unit Enumeration Valid Attribute Value(s) Encoded D-PHY = 0 M-PHY = 1 . also before a data transmission pause while in FAST_STATE or SLOW_STATE.00 31-Jan-2011 Constant PA_MaxDataLanes Copyright © 2007-2011 MIPI Alliance.

HIBERNATE_STATE = 3.40. HIBERNATE_STATE = 3. FAST_STATE = 1.00 31-Jan-2011 Available TX Data Lanes Available RX Data Lanes Minimum number of PHY byte clock cycles without data to receive before a mode change from FAST_STATE or SLOW_STATE to SLEEP_STATE. SLOW_STATE = 2.Table 34 Attribute PA_AvailTxDataLanes PA_AvailRxDataLanes Attribute ID 0x1520 0x1540 PHY Adapter (gettable. Copyright © 2007-2011 MIPI Alliance. Inc. SLEEP_STATE = 4 PA_TxPWRStatus 0x1567 TX power state status Enumeration MIPI Alliance Specification for UniPro PA_RxPWRStatus 0x1582 RX power state status Enumeration . static) Common Attributes (continued) Description Unit Integer Integer Valid Attribute Value(s) 1 to PA_MaxDataLanes 1 to PA_MaxDataLanes Version 1. dynamic) Common Attributes Description Unit Valid Attribute Value(s) OFF_STATE = 0. All rights reserved. or before a pause in data transmission while in FAST_STATE or SLOW_STATE. MIPI Alliance Member Confidential 137 PA_MinRxTrailingClocks 0x1543 Integer 0 to 255 Table 35 Attribute Attribute ID PHY Adapter (gettable. FAST_STATE = 1. SLOW_STATE = 2. SLEEP_STATE = 4 OFF_STATE = 0.

per Lane Mbps. settable) D-PHY-specific Attributes Description When asserted TRUE and the PHY provides a Clock Lane. TRUE=1 SlowAuto_Mode PA_LegacyDPHYEscDL 0x1570 Indicates if the UniPro v1. TRUE=1 FALSE FALSE PA_TxPWRMode 0x1563 TX power mode Enumeration Off=0 Fast_Mode=1. FastAuto_Mode=4.2 PHY Adapter D-PHY-specific Attributes Table 36 PHY Adapter (gettable. per Lane Mbps. Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1. All rights reserved.00 legacy ESC_DL mapping is enabled.00 31-Jan-2011 Attribute Attribute ID Copyright © 2007-2011 MIPI Alliance. per Lane Valid Attribute Value(s) Implementation-specific Implementation-specific Implementation-specific Implementation-specific Maximum TX Lane speed (FAST_STATE) Maximum TX Lane speed (SLOW_STATE) Maximum RX Lane speed (FAST_STATE) Maximum RX Lane speed (SLOW_STATE) If Attribute is implemented. Hibernate=3.5. MIPI Alliance Member Confidential 138 PA_TxForceClock 0x1562 Boolean FALSE=0. the Clock Lane shall be always on.00. Inc. independent of the UniPro stack power mode. it shall be set to zero for Devices that do not support SLOW_STATE (see PA_TxLinkStartupHS) . Slow_Mode=2. per Lane Mbps. static) D-PHY-specific Attributes Description Unit Mbps. SlowAuto_Mode=5 FALSE=0. Boolean FALSE MIPI Alliance Specification for UniPro Table 37 Attribute PA_MaxTxSpeedFast PA_MaxTxSpeedSlow PA_MaxRxSpeedFast PA_MaxRxSpeedSlow Attribute ID 0x1521 0x1522 0x1541 0x1542 PHY Adapter (gettable.9.40.

3 PHY Adapter M-PHY-specific Attributes Table 39 PHY Adapter (gettable.9. dynamic) D-PHY-specific Attributes Description Actual TX Data Lane speed (FAST_STATE) Actual TX Data Lane speed (SLOW_STATE) Unit Mbps. per Lane Valid Attribute Value(s) Implementation-specific Implementation-specific 5. TRUE = 1 Version 1. Link Startup is done in Fast_State (for interfacing to FPGAs only) Copyright © 2007-2011 MIPI Alliance.40. All rights reserved. Inc. static) D-PHY-specific Attributes (continued) Description Unit Enumeration Valid Attribute Value(s) FALSE = 0. MIPI Alliance Member Confidential 139 Table 38 Attribute PA_TxSpeedFast PA_TxSpeedSlow Attribute ID 0x1565 0x1566 PHY Adapter (gettable. per Lane Mbps.9 . dynamic) M-PHY-specific Attributes Description Peer Device version information.00 31-Jan-2011 If TRUE. Unit 16-bit word Valid Attribute Value(s) Attribute PA_RemoteVerInfo Attribute ID 0x15A0 MIPI Alliance Specification for UniPro See Section 9. Available after a successful Link StartUp Sequence.Table 37 Attribute PA_TxLinkStartupHS Attribute ID 0x1544 PHY Adapter (gettable.

12). SlowAuto_M SlowAuto_M ode. TRUE=1 A=1 B=2 Fast_Mode=1. Inc. UNCHANGED=7 Mandatory Value(s) Reset Value Copyright © 2007-2011 MIPI Alliance.40. Slow_Mode=2. settable) M-PHY-specific Attributes Description Type Unit Valid Attribute Value(s) PWM_G1 =1 PWM_G2 =2 PWM_G3 =3 PWM_G4 =4 PWM_G5 =5 PWM_G6 =6 PWM_G7 =7 HS_G1=1 HS_G2=2 HS_G3=3 FALSE=0. MIPI Alliance Member Confidential 140 PA_TxGear 0x1568 TX Gear in PWM or HS Mode Enumeration PWM_G1 PWM_G1 PA_TxTermination PA_HSSeries 0x1569 0x156A TX Termination TX and RX Frequency Series in High Speed Mode TX/RX power mode: TX[b3:b0] RX[b7:b4] Boolean Enumeration FALSE.8. FastAuto_Mode=4. ode UNCHANGE D MIPI Alliance Specification for UniPro . TRUE FALSE A PA_PWRMode 0x1571 Setting of this Attribute triggers the Link Configuration procedure (see Section 5. SlowAuto_Mode=5. All rights reserved. Enumeration Slow_Mode.00 31-Jan-2011 Table 40 Attribute Attribute ID PHY Adapter (gettable.Version 1.

Specifies whether or not the inbound Link supports terminated line in PWM mode.40.00 31-Jan-2011 Copyright © 2007-2011 MIPI Alliance.Table 40 Attribute Attribute ID PHY Adapter (gettable. settable) M-PHY-specific Attributes (continued) Description Type Unit Valid Attribute Value(s) PWM_G1 =1 PWM_G2 =2 PWM_G3 =3 PWM_G4 =4 PWM_G5 =5 PWM_G6 =6 PWM_G7 =7 HS_G1=1 HS_G2=2 HS_G3=3 FALSE=0. TRUE FALSE PA_MaxRxPWMGear 0x1586 Maximun RX Low Speed Gears (PWM) Integer PWM_G1 to RX_PWMG EAR_Capab ility PWM_G1 MIPI Alliance Specification for UniPro PA_MaxRxHSGear 0x1587 Maximun RX High Speed Gears (HS). Integer NO_HS to RX_HSGEA R_Capability NO_HS PA_RxHSUnterminationCa pability PA_RxLSTerminationCapa bility 0x15A5 Boolean FALSE FALSE 0x15A6 Boolean FALSE FALSE . TRUE=1 Mandatory Value(s) Reset Value Version 1. MIPI Alliance Member Confidential 141 PA_RxGear 0x1583 RX Gear in PWM or HS Mode Enumeration PWM_G1 PWM_G1 PA_RxTermination 0x1584 RX Termination Boolean FALSE. All rights reserved. Inc. 0 means no HS available Specifies whether or not the inbound Link supports unterminated line in HS mode. TRUE=1 FALSE=0. TRUE=1 PWM_G1 =1 PWM_G2 =2 PWM_G3 =3 PWM_G4 =4 PWM_G5 =5 PWM_G6 =6 PWM_G7 =7 NO_HS=0 HS_G1=1 HS_G2=2 HS_G3=3 FALSE=0.

5 and Section 5.8. Time to wait in SAVE before activating a burst in order to wakeup OMC and remote M-RX.40.00 31-Jan-2011 PA_PACPReqTimeout 0x1590 Expiration value of the PACP_REQUEST_TIMER when the PA Layer is waiting for a cnf Message (see Section 5.9 0 MIPI Alliance Specification for UniPro PA_TActivate 0x15A8 Integer 10 μs 0 to 1000 0 to 232-1 0 to 232-1 1000 PA_PACPFrameCount1 PA_PACPErrorCount1 0x15C0 0x15C1 Integer Integer 0 0 .14. All rights reserved. Number of erroneous PACP frames received.3). settable) M-PHY-specific Attributes (continued) Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1.8.8.12.5). Integer ms 0 to 63 63 Copyright © 2007-2011 MIPI Alliance.12. Inc. The actual duration of the timeout period shall be the value set in the Attribute ±10% Local version info. Delivered during Link Startup sequence to the peer Device and stored in PA_RemoteVerInfo in the peer Device. The actual duration of the timeout period shall be the value set in the Attribute ±10% Expiration value of the PACP_REQUEST_TIMER when the PA Layer is waiting for the end of burst (see Section 5. MIPI Alliance Member Confidential 142 PA_PACPReqEoBTimeout 0x1591 Integer ms 0 to 15 15 PA_LocalVerInfo 0x15A9 16-bit word See Section 9.Table 40 Attribute Attribute ID PHY Adapter (gettable. Number of valid PACP frames received.

00 31-Jan-2011 PA_PHYTestControl 0x15C2 PHY Test Feature control register b0 : ContBurst b1 : CfgReady b2 : LineReset b3 : TestPatternTransmit b4 : TestPatternSelect Setting this Attribute has sideeffects (see Section 5.40.Table 40 Attribute Attribute ID PHY Adapter (gettable. All rights reserved. Number of TX Data Lanes connected Number of RX Data Lanes connected 12 x 16-bit word Integer See Table 117 0 to PA_AvailTx DataLanes 0 to PA_AvailRx DataLanes 0 0 to PA_MaxDataLanes 0 0x1581 Integer 0 to PA_MaxDataLanes 0 MIPI Alliance Specification for UniPro . Inc.8. MIPI Alliance Member Confidential 143 5-bit word All 0 PA_PWRModeUserData [0 to 11] PA_ConnectedTxDataLane s2 PA_ConnectedRxDataLan es2 0x15B0 to 0x15BB 0x1561 Data to be sent within PACP_PWR_req and delivered to the remote DME. settable) M-PHY-specific Attributes (continued) Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1. Copyright © 2007-2011 MIPI Alliance.15).

40.Table 40 Attribute Attribute ID PHY Adapter (gettable. settable) M-PHY-specific Attributes (continued) Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1. Bits [13:12]: Physical Lane of Logical Lane 2. Bits [5:4]: Physical Lane of Logical Lane 2. Bits [15:14]: Physical Lane of Logical Lane 3. RX Lanes: Bits [9:8]: Physical Lane of Logical Lane 0. Bits [3:2]: Physical Lane of Logical Lane 1. Minimum time to wait between bursts in HS mode when no new configuration was performed. Inc. Bits [7:6]: Physical Lane of Logical Lane 3. MIPI Alliance Member Confidential 144 PA_LogicalLaneMap2 0x15A1 16-bit word Implementation-specific Any MIPI Alliance Specification for UniPro PA_StallNoConfigTime2 0x15A3 Integer SI 1 to 255 255 . Bits [11:10]: Physical Lane of Logical Lane 1. Attribute contains a valid value after a successful Link StartUp Sequence. TX Lanes: Bits [1:0]: Physical Lane of Logical Lane 0. PA_SleepNoConfigTime2 0x15A2 Minimum time to wait between bursts in PWM mode when no new configuration was performed.00 31-Jan-2011 Logical to Physical Lane mapping. All rights reserved. Integer SI 1 to 15 15 Copyright © 2007-2011 MIPI Alliance.

00 31-Jan-2011 PA_SaveConfigTime2 Minimum time to wait between bursts when a new configuration was performed. See Section 9. 2. Attribute should be set only when needed by PHY Testing (see Section 5.40. Inc. settable) M-PHY-specific Attributes (continued) Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1.15). Statistic. Integer 40 ns 1 to 250 250 Copyright © 2007-2011 MIPI Alliance. All rights reserved.3 for reset behavior.8. MIPI Alliance Specification for UniPro . MIPI Alliance Member Confidential 145 1.Table 40 Attribute Attribute ID 0x15A4 PHY Adapter (gettable.

Inc. The Data Link Layer Management SAP (DL_LM_SAP) is provided to the Device Management Entity (DME) for configuration and control purposes. is invisible to the DL Service Users. All rights reserved. The DL Layer in turn relies on the service provided by the PA_SAP. Traffic Class 0 shall always be present CRC generation Retransmission of a Frame in case of error(s) 1518 • 1519 • 1520 Key features for receive direction: 1521 • 1522 • Frame decomposition Capability to receive preempted Frames Copyright © 2007-2011 MIPI Alliance. 1511 The way in which the supporting communication resources are utilized to achieve this transfer. The DL Layer provides following key features. 1508 This section does not specify individual implementation or products. nor does it constrain the implementation of Data Link Layer and its interfaces within a system. Network Layer (L3) Device Management Entity (DME) DL_LM SAP DL_TC0 SAP DL_TC1 SAP Management Plane DL_LM Entity TC0 Entity Data Plane TC1 Entity DL_ MIB Data Link Layer (L2) Figure 46 Data Link Layer SAP Model 6. The DL Layer service to the Network Layer is provided through two Traffic Class-specific Service Access Points (DL_TCx_SAP). 1509 Figure 46 shows the SAP model used for the Data Link Layer. MIPI Alliance Member Confidential 146 .40.1 Data Link Layer Service Functionality and Features 1510 The DL Layer provides services to assure the transparent and reliable transfer of user-data between DL Service Users. 1512 Key features for transmit direction: 1513 1514 1515 1516 1517 • • • • • Frame composition Optional Frame preemption Triggering of PHY initialization Flow control Support for up to two Traffic Classes by priority-based arbitration.00 31-Jan-2011 MIPI Alliance Specification for UniPro 6 Data Link Layer (L2) 1507 The principal objective of this section is to specify the characteristics and behavior of a conceptual Data Link Layer service and Data Link Layer protocol.Version 1.

1 1535 Table 42 lists the parameters that appear in the DL_TCx_SAP primitives.1. At the recipient side. Each Traffic Class uses a dedicated Service Access Point (SAP) for transferring data.req 1536 This primitive is used to send a DL_SDU over a dedicated TC of the DL Layer.1 DL_DATA.3.1 Data Transfer Primitives 1534 The primitives covered in this section are listed in Table 41. L2ResultCode Enumeration NO_PEER_TC 6. The user may transmit any integral number of bytes greater than zero up to the DL_MTU.3 Local Response Response 6.3.4 Local Confirm 6.3. MIPI Alliance Member Confidential 147 . 1533 At the sending side.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1523 1524 1525 1526 1527 • • • • • Generation of flow control credit information Support for two Traffic Classes reception CRC verification Detection of various errors and autonomous reaction to them Autonomous acknowledgment of all unacknowledged Frames 6.1. Table 42 Name DL_SDU Type byte stream DL_TCx_SAP Primitive Parameters Valid Range 1 to DL_MTU SUCCESS 0 1 Value Description Specifies the length of the data passing through the DL_TCx_SAP before transmission or after reception Indicates the result of the DL_DATA.3.Version 1. data is passed via the DL_TCx_SAP in DL_SDUs to the DL Layer to transfer it to a peer DL Layer.2 1529 • 1530 • 1531 • Services Assumed from PHY Adapter Layer Sending and receiving a control symbol Sending and receiving a data symbol PHY initialization 1528 The DL Layer assumes following services from PHY Adapter Layer to fulfill its services to DL Service User: 6. All rights reserved.1.1. Copyright © 2007-2011 MIPI Alliance.req request.3.3 DL_TCx_SAP 1532 Services to a DL Service User are provided via the DL_TCx_SAP.1. The TC is given by the SAP used.2 Confirm Request 6.3. The Traffic Class identification is performed based on the used SAP.40. 6. Inc. the DL Layer delivers received data in DL_SDUs to the upper layer. Table 41 Name DL_DATA DL_TCx_SAP Data Transfer Primitives Indication 6. The two defined SAPs are DL_TC0_SAP and DL_TC1_SAP.

req primitive shall cause DL Service Provider to transfer DL_SDU to its peer DL Layer. when the DL Service Provider can accept a new request to transfer a DL_SDU. the Data Link Service Provider shall set L2ResultCode to NO_PEER_TC. 1546 The semantics of this primitive are: 1547 DL_DATA.1. 1554 The DL Service User may emit a new DL_DATA.3. 1550 If DL_PeerTCxPresent is TRUE. The DL_SDU provided by DL_DATA.cnf_L primitive is shown in Figure 254 of [MIPI02]. is ready to accept a new DL_DATA.cnf_L primitive corresponding to a previously emitted DL_DATA.req primitive to send a DL_SDU. MIPI Alliance Member Confidential 148 .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.cnf_L primitive.req primitive.req primitive. the peer Device implements TCx.1.req( DL_SDU ) 1539 When Generated 1540 The DL Service User shall generate a DL_DATA. L2 in this case.e. meaning the DL_SDU is not put in the transmitter logical buffer. the Data Link Service Provider shall set L2ResultCode to SUCCESS. 6.3. 1552 Effect on Receipt 1553 Following the emission of a DL_DATA. 1555 Behavioral Description 1556 The state diagram describing the behavior of the DL_DATA.req primitive.e.req primitive immediately following a reset or after the reception of the DL_DATA. Copyright © 2007-2011 MIPI Alliance.cnf_L( L2ResultCode ) 1548 When Generated 1549 This primitive shall be generated by the Data Link Service Provider after the receipt of a DL_DATA.req primitive is shown in Figure 254 of [MIPI02].Version 1.req is ignored.40. 1551 If DL_PeerTCxPresent is FALSE. All rights reserved. i. the peer Device does not implement TCx. the DL Service User shall not emit a new DL_DATA.3 DL_DATA.2 DL_DATA. 1541 Effect on Receipt 1542 The reception of a DL_DATA.req primitive. 1543 Behavioral Description 1544 The state diagram describing the behavior of the DL_DATA.req primitive and prior to the reception of a DL_DATA. 6.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1537 The semantics of this primitive are: 1538 DL_DATA. Inc.cnf_L 1545 This primitive informs the DL Service User that the Service Provider. and is not sent on the Link. i. The DL_SDU may consist of any integral number of bytes greater than zero up to DL_MTU.

6. All rights reserved. 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.ind primitive.ind primitive. The DL_MIB is regarded as “contained” within the DL_LM entity.8.3.rsp_L primitive is shown in Figure 268 of [MIPI02].Version 1.rsp_L in response to a DL_DATA. is ready to accept a new DL_DATA. 1564 Behavioral Description 1565 The state diagram describing the behavior of the DL_DATA.4 DL_LM_SAP 1575 The Data Link Layer Management (DL_LM) SAP offers three groups of Service Primitives: Configuration primitives.rsp_L primitive. Multiple accesses to the DL_MIB via the Configuration primitives shall not occur concurrently. This information is represented as a DL Layer-specific Management Information Base (DL_MIB).00 31-Jan-2011 MIPI Alliance Specification for UniPro 1558 The semantics of this primitive are: 1559 DL_DATA. the Data Link Layer shall not emit a new DL_DATA.ind primitive.rsp_L( ) 1569 When Generated 1570 The DL Service User shall generate DL_DATA. 6. 1576 The Configuration primitives enable access to configuration information specific to the DL Layer.ind primitive is shown in Figure 268 of [MIPI02]. or after reception of the DL_DATA. 1573 Behavioral Description 1574 The state diagram describing the behavior of the DL_DATA.ind or DL_ESCAPED_DATA. 1577 The Control primitives provide direct control of the DL Layer. The available Data Link Layer Attributes are defined in Section 6.ind primitive and prior to the reception of a DL_DATA.rsp_L primitive corresponding to a previously emitted DL_DATA. Copyright © 2007-2011 MIPI Alliance. 1562 Effect on Receipt 1563 Upon reception of a DL_DATA.ind primitive.1. Control primitives are generated by the DME and can occur concurrently. Control primitives and Status primitives.ind to indicate that the DL Service User can accept and process a new DL_PDU.ind primitive only just after reset.rsp_L 1566 This primitive informs the Service Provider that the DL Service User.40. the DL Layer Service User shall consume DL_SDU on a Traffic Class associated with the SAP. L3 in this case.ind( DL_SDU ) 1560 When Generated 1561 The primitive shall be generated when the DL Layer Service Provider receives a DL_PDU at the local RX. MIPI Alliance Member Confidential 149 .4 DL_DATA. Inc. 1567 The semantics of this primitive are: 1568 DL_DATA. The Data Link Layer may emit a new DL_DATA. 1571 Effect on Receipt 1572 Following the emission of a DL_DATA.

4. These primitives are prefixed by DL_LM.8 SUCCESS 0 1 2 3 0 1 Select whether the actual value (NORMAL) or the reset value (STATIC) of the Attribute is set Indicates the result of the request Value Description The address of the MIB Attribute The value of the MIB Attribute MIBvalue Variable ConfigResultCode Enumeration INVALID_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE READ_ONLY_MIB_ATTRIBUTE NORMAL AttrSetType Enumeration STATIC 6.4. Table 43 Name DL_LM_GET DL_LM_SET DL_LM Configuration Primitives Indication Local Response Response Local Confirm 6.1 Configuration Primitives 1579 The DL_LM configuration primitives. MIPI Alliance Member Confidential 150 .4.40.1.4 Confirm Request 6.3 1581 The parameters used for these primitives are defined in the next table. GET and SET.1.1. Copyright © 2007-2011 MIPI Alliance.1 6.4. Table 44 Name MIBattribute Type Integer DL_LM Configuration Primitive Parameters Valid Range 0x2000 to 0x2FFF and the MIB Attribute within that range are defined in Section 6.4.req 1582 This primitive requests information about a given DL_MIB Attribute identified by MIBattribute. 6.1. 1580 The GET and SET primitives are represented as requests with associated confirm primitives.1.req( MIBattribute ) 1585 The primitive parameter is defined in Table 44.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1578 The Status primitives indicate status information of the DL Layer. are used by the DME to retrieve and store values. Inc. All rights reserved. respectively.8 As defined in Section 6. 1586 When Generated 1587 This primitive is generated by the DME to obtain information from the DL_MIB.2 6.4. The primitives are summarized in Table 43. for the configuration Attributes in the DL_MIB. 1583 The semantics of this primitive are: 1584 DL_LM_GET.Version 1.1 DL_LM_GET. Status primitives are generated by the DL Layer and can occur concurrently.

Version 1.cnf_L to the MIB Attribute value. Table 45 ConfigResultCode DL_LM_GET.4.cnf_L ConfigResultCode Values Condition The request succeeds. the MIB Attribute indicated by DL_LM_GET. 1593 The semantics of this primitive are: 1594 DL_LM_GET.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1588 Effect on Receipt 1589 The DL_LM entity attempts to retrieve the requested MIB Attribute value from DL_MIB and responds with DL_LM_GET. i.cnf_L is undefined.40. SUCCESS INVALID_MIB_ATTRIBUTE 1597 When Generated 1598 The DL Layer shall generate the DL_LM_GET.cnf_L( ConfigResultCode.2 DL_LM_GET.e. MIPI Alliance Member Confidential 151 . 1601 Behavioral Description 1602 The state diagram describing the behavior of the DL_LM_GET.1.4.req from the DME. MIBvalue carries the MIB Attribute value.cnf_L primitive is shown in Figure 142 of [MIPI02]. The value of MIBvalue in DL_LM_CC_GET.req primitive is shown in Figure 142 of [MIPI02].req MIBattribute is invalid or not implemented. 1599 Effect on Receipt 1600 The DME is informed about the result of the operation. For any other value of ConfigResultCode.cnf_L to one of the values shown in Table 45 for the condition given in the table. Inc. 1596 The DL Layer shall set ConfigResultCode in DL_LM_GET. 6. MIBvalue ) 1595 The primitive parameters are defined in Table 44. 6.cnf_L 1592 This primitive reports the results of an information request about the DL_MIB.req MIBattribute is gettable. The DL Layer shall set MIBvalue in DL_LM_GET.cnf_L that gives the result. and in case ConfigResultCode is SUCCESS.1. 1590 Behavioral Description 1591 The state diagram describing the behavior of the DL_LM_GET. Copyright © 2007-2011 MIPI Alliance. The MIB Attribute indicated by DL_LM_GET. All rights reserved. The DL Layer should not set ConfigResultCode to INVALID_MIB_ATTRIBUTE_VALUE or READ_ONLY_MIB_ATTRIBUTE.cnf_L primitive in response to a DL_LM_GET.3 DL_LM_SET. MIBvalue is undefined.req 1603 This primitive attempts to set the indicated DL_MIB Attribute indicated by MIBattribute to the MIBvalue value.

req MIBattribute exists. INVALID_MIB_ATTRIBUTE READ_ONLY_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE 1618 When Generated 1619 The DL Layer shall generate the DL_LM_SET.req from the DME.cnf_L primitive in response to a DL_LM_SET.req MIBattribute is invalid or not implemented. but the value of DL_LM_SET. or outside of the valid value range. 1614 The semantics of this primitive are: 1615 DL_LM_SET.cnf_L that gives the result. for the MIB Attribute.4. The DL_LM responds with DL_LM_SET. but is not settable.cnf_L to one of the values shown in Table 46 for the condition given in the table.cnf_L( ConfigResultCode ) 1616 The primitive parameter is defined in Table 44. 1611 Behavioral Description 1612 The state diagram describing the behavior of the DL_LM_SET.req MIBattribute exists and is settable. the MIB Attribute indicated by DL_LM_SET. The MIB Attribute indicated by DL_LM_SET. Table 46 ConfigResultCode SUCCESS DL_LM_SET.e. MIBattribute.req primitive is shown in Figure 142 of [MIPI02]. 1609 Effect on Receipt 1610 The DL_LM attempts to set the value of the specified MIB Attribute in its database.req MIBvalue is outside of the implemented range.cnf_L ConfigResultCode Values Condition The request succeeds.req MIBvalue. All rights reserved. If AttrSetType is STATIC. 1617 The DL Layer shall set ConfigResultCode in DL_LM_SET. 1607 When Generated 1608 This primitive is generated by the DME to set the value of indicated DL_MIB Attribute. MIBvalue ) 1606 The primitive parameters are defined in Table 44.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.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1604 The semantics of this primitive are: 1605 DL_LM_SET.req( AttrSetType. 6. Inc. The MIB Attribute indicated by DL_LM_SET. i. MIPI Alliance Member Confidential 152 . the Attribute indicated by MIBattribute and SelectorIndex does not support setting its reset value. The MIB Attribute indicated by DL_LM_SET. Copyright © 2007-2011 MIPI Alliance.req MIBattribute is set to the value of DL_LM_SET.1.40.Version 1.

2.4.4.4.1 DL_LM_RESET. 1625 The primitives covered in this section are listed in Table 47.2.2.2. Until the reset/boot completes.cnf_L primitive is shown in Figure 142 of [MIPI02]. All rights reserved. 1622 Behavioral Description 1623 The state diagram describing the behavior of the DL_LM_SET.4.9 1626 Table 48 lists the parameters that appear in the DL_LM_SAP control primitives.3 6.2.Version 1. the Data Link Layer does not perform data transmit or receive operations.4.2.7 6.req at the Data Link Layer. and should have no further effects at the DME. The TCx entities discard all DL_SDUs currently processed and located in any logical buffer. 1628 The semantics of this primitive are: 1629 DL_LM_RESET. Copyright © 2007-2011 MIPI Alliance.5 6. Table 47 Name DL_LM_RESET DL_LM_ENABLE_LAYER DL_LM_LINKSTARTUP DL_LM_HIBERNATE_ENTER DL_LM_HIBERNATE_EXIT DL_LM_SAP Control Primitives Indication Local Response Response Local Confirm 6.8 6.req( ResetLevel ) 1630 When Generated 1631 This primitive is generated by the DME when it needs to reset the Data Link Layer.6 6.2 Control Primitives 1624 The Service Primitives in this section are provided for controlling the Data Link Layer.2.cnf_L confirms the success or failure of the DL_LM_SET.2.4.4 6.2.2 6. 1632 Effect on Receipt 1633 The DL Layer resets transmitter and receiver to the power-on reset states and values.10 Confirm Request 6.req 1627 This primitive requests to reset the Data Link Layer. MIPI Alliance Member Confidential 153 .4. Inc.4.4.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1620 Effect on Receipt 1621 DL_LM_SET.1 6.40.4.2.4.4. 6. Table 48 Name ResetLevel Type Enumeration DL_LM_SAP Control Primitive Parameters Valid Range COLD WARM Value 0 1 Description Defines the reset level of the requested reset 6.2.

The ResetLevel WARM resets the DL Layer without the statistics.2) and is generated by the DME after the Data Link Layer comes out of reset and the PHY Adapter Layer is ready to be used. 6.40. if they exist.2.7) as required by the UniPro boot procedure. 1653 When this state is reached.2.cnf_L primitive during the boot procedure to indicate to the DME that the DL came out of reset. as required by the UniPro boot procedure. 1642 Effect on Receipt 1643 The DME is informed that the DL came out of reset. 1638 The semantics of this primitive are: 1639 DL_LM_RESET.cnf_L primitive is shown in Figure 144 of [MIPI02].cnf_L primitive.4. this is indicated to the DME with the DL_LM_ENABLE_LAYER.4. Inc.1).Version 1.req primitive is shown in Figure 146 of [MIPI02].req( ) 1649 When Generated 1650 The DL_LM_ENABLE_LAYER. 1651 Effect on Receipt 1652 The DL shall reach the state where it is ready to receive the AFCs as part of the L2 initialization protocol (see Section 6.req primitive starts the L2 initialization protocol (see Section 6. 1647 The semantics of this primitive are: 1648 DL_LM_ENABLE_LAYER. See Section 6.cnf_L( ) 1640 When Generated 1641 The DL uses the DL_LM_RESET.req 1646 The DL_LM_ENABLE_LAYER. 1644 Behavioral Description 1645 The state diagram describing the behavior of the DL_LM_RESET.3 DL_LM_ENABLE_LAYER. All rights reserved.cnf_L 1637 The DL_LM_RESET.7. thus being ready to exercise the L2 initialization protocol. 1635 Behavioral Description 1636 The state diagram describing the behavior of the DL_LM_RESET.11.7). Copyright © 2007-2011 MIPI Alliance. 1654 Behavioral Description 1655 The state diagram describing the behavior of the DL_LM_ENABLE_LAYER.req primitive is shown in Figure 144 of [MIPI02]. MIPI Alliance Member Confidential 154 .11.2 DL_LM_RESET. 6.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1634 The ResetLevel COLD resets the complete DL Layer including the statistics.cnf_L primitive is used during the UniPro reset procedure (see Section 9.req primitive is part of the UniPro boot procedure (see Section 9.

1663 Behavioral Description 1664 The state diagram describing the behavior of the DL_LM_ENABLE_LAYER.11.cnf_L primitive is generated by the DL after it reached the state where the L2 initialization protocol may be started.2.40.req 1665 This primitive attempts to establish a Link to the peer Device by starting the Data Link Layer Initialization.req( ) 1668 When Generated 1669 The DME shall generate this when it wants to establish a Link to the peer Device.4. 6. 1674 The semantics of this primitive are: 1675 DL_LM_LINKSTARTUP.cnf_L primitive is used during the UniPro boot procedure (see Section 9.cnf_L 1673 This primitive is used during the UniPro boot procedure (see Section 9.cnf_L primitive is shown in Figure 146 of [MIPI02]. MIPI Alliance Member Confidential 155 . See Section 6.cnf_L primitive. This is indicated to the DME with the DL_LM_LINKSTARTUP.5 DL_LM_LINKSTARTUP.cnf_L( ) 1659 When Generated 1660 The DL_LM_ENABLE_LAYER.Version 1.cnf_L( ) 1676 When Generated 1677 This primitive is generated by the Data Link Layer after the Data Link Layer Initialization is completed.2) to indicate to the DME that the DL is ready for the L2 initialization protocol.2. 6.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.4.4. 1672 Once the Data Link Layer Initialization is finalized.4 DL_LM_ENABLE_LAYER.11.cnf_L 1656 The DL_LM_ENABLE_LAYER.2. All rights reserved. 1661 Effect on Receipt 1662 The DME is informed about the readiness of the Data Link Layer for the L2 initialization protocol during the boot procedure. 1670 Effect on Receipt 1671 The Data Link Layer Initialization shall start.00 31-Jan-2011 MIPI Alliance Specification for UniPro 6. Copyright © 2007-2011 MIPI Alliance.6 DL_LM_LINKSTARTUP. 1657 The semantics of this primitive are: 1658 DL_LM_ENABLE_LAYER.7 1666 The semantics of this primitive are: 1667 DL_LM_LINKSTARTUP. the Data Link Layer shall enter normal operation. Inc.

40. 1685 Effect on Receipt 1686 The Data Link Layer shall first reach the Frozen state. 6.cnf_L( ) 1703 When Generated 1704 This primitive is generated by the Data Link Layer in response to a DL_LM_HIBERNATE_ENTER.2. Inc. 6. and shall retain the value of the following Attributes: 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 • • • • • • • • • • • • DL_TC0TXFCThreshold DL_FC0ProtectionTimeOutVal DL_TC0ReplayTimeOutVal DL_AFC0ReqTimeOutVal DL_AFC0CreditThreshold DL_TC0OutAckThreshold DL_TC1TXFCThreshold DL_FC1ProtectionTimeOutVal DL_TC1ReplayTimeOutVal DL_AFC1ReqTimeOutVal DL_AFC1CreditThreshold DL_TC1OutAckThreshold 1699 Just before hibernating. Copyright © 2007-2011 MIPI Alliance.4.2. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1678 Effect on Receipt 1679 The DME is informed about the completion of the Data Link Layer Initialization. Then the Data Link Layer is hibernated.8 DL_LM_HIBERNATE_ENTER. the Data Link Layer shall indicate its intentions to the DME with the DL_LM_HIBERNATE_ENTER.req primitive and it indicates that the Data Link Layer is hibernating. 1701 The semantics of this primitive are: 1702 DL_LM_HIBERNATE_ENTER.Version 1.4. where all its timers shall be stalled.cnf_L primitive. 1705 Effect on Receipt 1706 The DME is informed about the completion of all necessary actions require of the Data Link Layer to hibernate.7 DL_LM_HIBERNATE_ENTER.cnf_L 1700 This primitive is used to indicate that the Data Link Layer is about to hibernate. MIPI Alliance Member Confidential 156 .req( ) 1683 When Generated 1684 The DME shall generate this primitive when it wants to hibernate the Data Link Layer. 1681 The semantics of this primitive are: 1682 DL_LM_HIBERNATE_ENTER.req 1680 This primitive requests the Data Link Layer to go to Hibernate.

3.3 6. 1712 Effect on Receipt 1713 The Data Link Layer shall transition to its reset state.Version 1.3.4.4.5 6.3.3. restore the value of any Attributes retained when entering the Hibernate State (see Section 6.2 6.00 31-Jan-2011 MIPI Alliance Specification for UniPro 6.4.9 DL_LM_HIBERNATE_EXIT.4. 6.4.cnf_L( ) 1717 When Generated 1718 This primitive is generated by the Data Link Layer in response to a DL_LM_HIBERNATE_EXIT.2.4. 6.cnf_L 1714 This primitive is used to indicate to the DME that the Data Link Layer has returned to normal operation after hibernating.10 DL_LM_HIBERNATE_EXIT.4. Table 49 Name DL_LM_ERROR DL_LM_CTRL_NOFRAME DL_LM_TC1_NOFRAME DL_LM_TC0_NOFRAME DL_LM_CTRL_FRAME DL_LM_TC1_FRAME DL_LM_SAP Status Primitives Indication 6. Inc. It indicates that the Data Link Layer is not hibernating and has returned to normal operation.req( ) 1710 When Generated 1711 The DME shall generate this primitive when it wants to unhibernate the Data Link Layer. 1722 The primitives covered in this section are listed in Table 49.cnf_L to indicate to the DME its return to normal operation. 1719 Effect on Receipt 1720 The DME is informed of the completion of all necessary actions required by the Data Link Layer to return to normal operation after hibernating.4. MIPI Alliance Member Confidential 157 . the Data Link Layer shall generate the DL_LM_HIBERNATE_EXIT.req 1707 This primitive is used to request the Data Link Layer to stop hibernating and return to normal operation.4 6. 1708 The semantics of this primitive are: 1709 DL_LM_HIBERNATE_EXIT. When the Data Link Layer Initialization is completed.2.4. All rights reserved. 1715 The semantics of this primitive are: 1716 DL_LM_HIBERNATE_EXIT.1 6.4.req primitive.6 Local Response Response Local Confirm Confirm Request Copyright © 2007-2011 MIPI Alliance. then enable itself and finally shall start the Data Link Layer Initialization.2.40.3 Status Primitives 1721 The Service Primitives in this section are provided for status provision by the Data Link Layer.7).3.3.

Table 50 Name Type DL_LM_SAP Primitive Parameters Valid Range NAC_RECEIVED TCx_REPLAY_TIMER_EXPIRED AFCx_REQUEST_TIMER_EXPIRED Value 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Indicates to the DME in case an error event occurred in the Data Link Layer Description FCx_PROTECTION_TIMER_EXPIRED CRC_ERROR RX_BUFFER_OVERFLOW MAX_FRAME_LENGTH_EXCEEDED DLErrorCode Enumeration WRONG_SEQUENCE_NUMBER AFC_FRAME_SYNTAX_ERROR NAC_FRAME_SYNTAX_ERROR EOF_SYNTAX_ERROR FRAME_SYNTAX_ERROR BAD_CTRL_SYMBOL_TYPE PA_INIT_ERROR PA_ERROR_IND_RECEIVED 6. 1730 There are four types of events that are reported: 1731 • 1732 1733 1734 • Events causing a Frame retransmission • NAC_RECEIVED shall indicate a NAC Frame has been received • TCx_REPLAY_TIMER_EXPIRED shall indicate the TCx_REPLAY_TIMER has expired Events caused by a possible failure of AFC transmission Copyright © 2007-2011 MIPI Alliance.4.40. 1725 The semantics of this primitive are: 1726 DL_LM_ERROR. 1728 When Generated 1729 This primitive is generated by the Data Link Layer when an error-related event is detected. All rights reserved. MIPI Alliance Member Confidential 158 .7 Local Response Response Local Confirm Confirm 1723 Table 50 lists the parameters that appear in the DL_LM_SAP status primitives.ind 1724 The Service Primitive indicates to the DME an error event in the Data Link Layer.3.3. Inc.1 DL_LM_ERROR.ind( DLErrorCode ) 1727 The primitive parameter is defined in Table 50.4.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 49 Name DL_LM_TC0_FRAME DL_LM_SAP Status Primitives (continued) Request Indication 6.

2 DL_LM_CTRL_NOFRAME. 1755 The semantics of this primitive are: 1756 DL_LM_CTRL_NOFRAME.40.ind has been received Failure to (re-)initialize the PHY using PA_INIT. 1759 Effect on Receipt 1760 This indication may be used to take action for power management procedures. MIPI Alliance Member Confidential 159 .ind( ) 1757 When Generated 1758 The Data Link Layer generates this primitive when there are no new Control Frames to transmit. which cause a NAC to be reported to the other side • • CRC_ERROR shall indicate a CRC error has been detected on either a Data or a Control Frame RX_BUFFER_OVERFLOW shall indicate that the RX buffer overflows.Version 1.3. All rights reserved. Copyright © 2007-2011 MIPI Alliance.req • PA_INIT_ERROR shall indicate that the PA_INIT.ind primitive is shown in Figure 149 of [MIPI02]. MAX_FRAME_LENGTH_EXCEEDED shall indicate that a Frame with a payload longer than the DL_MTU has been received WRONG_SEQUENCE_NUMBER shall indicate a correct Frame with a wrong Frame Sequence Number has been received AFC_FRAME_SYNTAX_ERROR shall indicate that an AFC symbol not followed by two data symbols has been received NAC_FRAME_SYNTAX_ERROR shall indicate that a NAC symbol not followed by one data symbol has been received EOF_SYNTAX_ERROR shall indicate that an EOF_EVEN or an EOF_ODD symbol not followed by one data symbol has been received FRAME_SYNTAX_ERROR shall indicate that an unexpected framing sequence has been received BAD_CTRL_SYMBOL_TYPE shall indicate if an unsupported Data or Control Frame is received 1740 1741 1742 1743 1744 1745 1746 1747 1748 • 1749 • • • • • • • • PA_ERROR_IND_RECEIVED shall indicate that PA_ERROR.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1735 1736 1737 • 1738 1739 • • AFCx_REQUEST_TIMER_EXPIRED shall indicate the AFCx_REQUEST_TIMER has expired FCx_PROTECTION_TIMER_EXPIRED shall indicate the FCx_PROTECTION_TIMER has expired Events caused by an error detected on the RX Link. Inc.4.req has failed 1750 Effect on Receipt 1751 This indication may be used to take action for statistical procedures. 1752 Behavioral Description 1753 The state diagram describing the behavior of the DL_LM_ERROR. likely because of an erroneous SOF symbol or because an attempt was made to send data over a Traffic Class which is not implemented. 6.ind 1754 The Service Primitive indicates to the DME that there are no Control Frames queued in the Data Link Layer transmitter.

ind( ) 1766 When Generated 1767 The Data Link Layer generates this primitive when there is no TC1 data to send and all transmitted TC1 Frames are acknowledged. 1773 The semantics of this primitive are: 1774 DL_LM_TC0_NOFRAME.3. 6.4 DL_LM_TC0_NOFRAME.ind primitive is shown in Figure 228 of [MIPI02]. AFC1 or NAC Frame).40.Version 1. 1779 Behavioral Description 1780 The state diagram describing the behavior of the DL_LM_TC0_NOFRAME.5 DL_LM_CTRL_FRAME.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. 1768 Effect on Receipt 1769 This indication may be used to take action for power management procedures. 1764 The semantics of this primitive are: 1765 DL_LM_TC1_NOFRAME.3. All rights reserved.ind( ) 1775 When Generated 1776 The Data Link Layer generates this primitive when there is no TC0 data to send and all transmitted TC0 Frames are acknowledged.4.4. 6. 1770 Behavioral Description 1771 The state diagram describing the behavior of the DL_LM_TC1_NOFRAME. Inc. 1777 Effect on Receipt 1778 This indication may be used to take action for power management procedures.ind primitive is shown in Figure 228 of [MIPI02].ind 1781 The Service Primitive indicates to the DME that the DL Layer has to transmit a Control Frame (AFC0.4. MIPI Alliance Member Confidential 160 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 1761 Behavioral Description 1762 The state diagram describing the behavior of the DL_LM_CTRL_NOFRAME.3 DL_LM_TC1_NOFRAME. 6. 1782 The semantics of this primitive are: 1783 DL_LM_CTRL_FRAME.ind( ) Copyright © 2007-2011 MIPI Alliance.3.ind primitive is not shown yet in [MIPI02].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.

4.3.ind( ) 1793 When Generated 1794 The Data Link Layer generates this primitive when there is at least one TC1 Data Frame to send or not all transmitted TC1 Frames are acknowledged.ind primitive is shown in Figure 228 of [MIPI02]. 1786 Effect on Receipt 1787 This indication may be used to take action for power management procedures.3.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.6 DL_LM_TC1_FRAME.4.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. 6. Inc.7 DL_LM_TC0_FRAME.ind( ) 1802 When Generated 1803 The Data Link Layer generates this primitive when there is at least one TC0 Data Frame to send or not all transmitted TC0 Frames are acknowledged. 1806 Behavioral Description 1807 The state diagram describing the behavior of the DL_LM_TC0_FRAME. 6.Version 1. 1804 Effect on Receipt 1805 This indication may be used to take action for power management procedures.40.ind primitive is shown in Figure 228 of [MIPI02]. 1788 Behavioral Description 1789 The state diagram describing the behavior of the DL_LM_CTRL_FRAME. MIPI Alliance Member Confidential 161 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 1784 When Generated 1785 The Data Link Layer generates this primitive when there is a Control Frame to transmit. 1800 The semantics of this primitive are: 1801 DL_LM_TC0_FRAME. Copyright © 2007-2011 MIPI Alliance. 1791 The semantics of this primitive are: 1792 DL_LM_TC1_FRAME. 1795 Effect on Receipt 1796 This indication may be used to take action for power management procedures. 1797 Behavioral Description 1798 The state diagram describing the behavior of the DL_LM_TC1_FRAME.ind primitive is not shown yet in [MIPI02]. All rights reserved.

These Frames always have a Start of Frame (SOF) symbol.2.8).Version 1. These Control Frames are different from the Data Frames as they do not have SOF and EOF_EVEN or EOF_ODD symbols. MIPI Alliance Member Confidential 162 .5. If both TCs are supported. a common NAC Frame. 1814 Additionally. Control Frames are used for flow control and reliability.6. i. where the highlighted boxes each represent a family of Frames. 1812 Figure 47 shows the supported Frames and also the derived Frames. 1810 Note that this does not mean that these 17-bit symbols pass across the Link. for all Traffic Classes. or Frames.4). The Frame length is flexible for each Traffic Class (see Section 6. but the maximum Frame length is limited to DL_SYMBOL_MTU symbols (excluding SOF symbol.5. depending on the priority rule (see Section 6. each Traffic Class possesses a separate AFC Frame and. they can preempt Data Frames.5 Structure and Encoding of Protocol Data Units 1808 DL Layer PDUs (DL_PDUs). Inc. possibly a padding byte. Data Link Layer Frames Data Frames (TCx) Control Frames Traffic Class 0 Data Frames (TC0) Traffic Class 1 Data Frames (TC1) Acknowledgement and Flow Control (AFCx) Frames Negative Acknowledgement Control (NAC) Frames Traffic Class 0 AFC (AFC0) Frames Traffic Class 1 AFC (AFC1) Frames Figure 47 Control and Data Frames Taxonomy 1813 The DL Layer shall support Data Frames of at least one Traffic Class.e.40. The PHY Adapter Layer or PHY Layer can translate the symbols using a suitable encoding scheme. These Control Frames may be transmitted during Data Frames. 1809 The most significant bit of a symbol is used to distinguish Data symbols from Control symbols. Data Frames are used to transfer data between two DL Layers located on different UniPorts.00 31-Jan-2011 MIPI Alliance Specification for UniPro 6. which depends on its type.1 and Section 6. EOF_EVEN or EOF_ODD symbol. one or more data bytes. the DL Layer shall support Data Frames of two Traffic Classes with different priorities. respectively. an End of Frame (EOF_EVEN or EOF_ODD) and an error protection symbol. 1811 The DL Layer supports two categories of Frames: Data Frames and Control Frames. All rights reserved. These symbols use different PA Layer Service Primitives to cause the PA Layer to use the appropriate encoding scheme suited to the underlying PHY. COF and CRC symbols). consist of a series of 17-bit symbols encoded as Data symbols or Control symbols as defined in Section 6. Copyright © 2007-2011 MIPI Alliance. Each Control Frame is of fixed length. ESC_DL together with Control Symbol Type acts as start of a Frame for respective Control Frame.

5. 1820 The ESC_DL character is used as a DL Layer control symbol identifier as shown in Figure 49. Bit 16 shall be set to ‘0’ for a data symbol in the DL 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. 6.ind Service Primitive that is provided by the PHY Adapter Layer as a control symbol. Data Link Layer minimizes the number of control symbol identifiers.2 Control Symbol 1818 The control symbol shall be used by DL Layer to receive or transmit control information. of a control symbol. 1822 Table 51 shows the currently defined MS byte of control symbol. Copyright © 2007-2011 MIPI Alliance. The Control Symbol Type field refers to a control symbol identity and the parameter field specifies parameter values that have different meanings for different control symbols. 16 1 15 14 13 12 11 10 ESC_DL Figure 49 9 8 7 6 5 4 Ctrl Symbol Type 3 2 1 Parameter 0 Control Symbol Definition 1821 Note that data and control symbols can be translated to an encoding scheme suitable for the PHY by the PA Layer. MIPI Alliance Member Confidential 163 . All rights reserved.req Service Primitive which is provided by the PHY Adapter Layer to send a control symbol and shall consider PA_SDU received from PA_ESCDATA. The DL Layer shall not use the reserved values. and. therefore.5. 1819 The DL Layer shall use PA_ESCDATA. The identification bit (bit16) is not passed via the Service Primitive. The LS byte is partitioned into a Control Symbol Type field and a parameter field. The undefined values are reserved for future use. 16 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Data Figure 48 Data Link Layer Data Symbol 6. Bit 16 shall be set to ‘1’ for a control symbol in the DL Layer. The identification bit (bit16) is not passed via the Service Primitive.ind Service Primitive of the PHY Adapter Layer as a data symbol.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1815 Transmission gaps within Data Link Layer Frames resulting in the PHY inserting PHY Idle symbols while in HS mode should be avoided. and bits 7 to 0 form the LS byte. 1817 DL Layer shall use PA_DATA. Bits 15 to 8 form the MS byte. Figure 48 shows the DL Layer data symbol structure. If received they shall be discarded.req Service Primitive which is provided by the PHY Adapter Layer to send a data symbol and shall consider PA_SDU received from PA_DATA. Inc. The number of such special PHY characters is limited.1 Data Symbol 1816 The DL Layer shall use data symbol to transmit or receive data information.Version 1.

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

Table 51
Control Symbol MS Byte ESC_DL

Control Symbol MS Byte Encoding
Tx_Data Bit[16] 1 Tx_Data, Bits[15:8] 00000001 Description DL Layer control symbol identifier

1823 Table 52 shows all DL Layer control symbols with the corresponding Control Symbol Type and a short description.

Table 52
Control Symbol SOF EOF_EVEN EOF_ODD COF Type 0b000 0b001 0b010 0b011 0b100 NAC AFC 0b101 0b110 0b111

Control Symbol Type Field Definition
Description Start Of Frame. Parameter includes Traffic Class identifier. End of Frame for even L2 payload. Parameter indicates Frame Sequence Number. End Of Frame for odd L2 payload. Parameter indicates Frame Sequence Number. Continuation Of preempted Frame. Parameter includes Traffic Class identifier. Reserved Start of a Negative Acknowledgment Control Frame. Parameter includes a flag to request the remote end reinitialize its TX PHY. Start of an Acknowledgment and Flow Control Frame. Parameter includes Traffic Class identifier and AFC type identification. Reserved

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.

Table 53
Control Symbol SOF EOF_EVEN EOF_ODD COF AFC NAC

Control Symbols Parameter Field Definition
Parameter Field

Bit 4 TC

Bit 3

Bit 2

Bit 1 Reserved

Bit 0

Frame Sequence Number Frame Sequence Number TC TC Reserved CReq Reserved Reserved RReq

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 164

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

Table 54
TC 11 10 01 00

Traffic Class Identification
Traffic Class Reserved Reserved TC1 TC0

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.

6.5.3

Data Frames

1829 All Traffic Classes in DL Layer shall use the same format of user Data Frames, which shall encapsulate upper layer PDU. Each upper layer PDU shall be encapsulated in one Data Link Layer Frame, and one Data Frame shall only encapsulate one upper layer PDU. A Data Frame shall always start with a SOF symbol. After the SOF symbol, the Data Frame shall, as payload, include all the data symbols composing the Frame’s SDU, i.e., the PDU provided by L3. In case the Frame payload contains an odd number of bytes, the last data symbol shall carry the last payload byte in the symbol’s most significant byte, and the least significant byte shall contain 0x00. In case of preemption, COF symbols shall be included in between data symbols when Frame transmission is resumed. The Data Frame shall end with either an EOF_EVEN symbol or an EOF_ODD symbol when it encapsulates an even or an odd number of payload bytes, respectively. The EOF_EVEN or EOF_ODD symbol shall be followed by a data symbol carrying the Frame checksum using the CCITT CRC16 [ITUT03] standard as described in Section 6.6.12. 1830 For all Data Link Layer Data Frames, the following rules shall apply: 1831 • 1832 • The Data Link Layer Data Frames are protected by a CCITT CRC-16 [ITUT03] checksum. The Data Link Layer Data Frame information shall be used only when the CRC checksum is correct.

1833 Figure 50 shows a Data Link Layer Data Frame with an even number of DL_SDU bytes. Figure 51 shows a Data Link Layer Data Frame with an odd number of DL_SDU bytes plus a padding byte. The maximum length of DL_SDU shall not exceed DL_SYMBOL_MTU symbols (including the padding byte, but excluding SOF symbol, EOF_EVEN or EOF_ODD symbol, COF and CRC symbols).

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 165

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

16 1 0 0 . . . 0 0 1 0

15

14

13

12 11 10 ESC_DL

9

8

7

6 5 SOF

4 TC

3

2 1 0 Reserved

DL_SDU – Byte 0 . . .

DL_SDU – Byte 1

DL_SDU – Byte n-2 (n <= DL_MTU) DL_SDU – Byte n-1 (n <= DL_MTU) ESC_DL EOF_EVEN Frame Seq. Number CCITT CRC-16
Figure 50 Data Frame with Even Number of DL_SDU Bytes

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

15

14

13

12 11 10 ESC_DL

9

8

7

6 5 SOF

4 TC

3

2 1 0 Reserved

DL_SDU – Byte 0 . . .

DL_SDU – Byte 1

DL_SDU – Byte n-1 (n <= DL_MTU) Padding Byte = 0x00 ESC_DL EOF_ODD Frame Seq. Number CCITT CRC-16
Figure 51 Data Frame with Odd Number of DL_SDU Bytes

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.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 166

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

16 1 0 0 . . . 0 0 1 0 1 0 0 . . . 0 0 1 0

15

14

12 11 10 ESC_DL DL_SDU – Byte 0

13

9

8

7

6 5 4 3 2 1 0 SOF TC Reserved DL_SDU – Byte 1

. . .

DL_SDU – Byte x-2 ESC_DL ESC_DL DL_SDU – Byte (x)

DL_SDU – Byte x-1 RReq NAC Reserved CCITT CRC-16 COF TC Reserved DL_SDU – Byte (x+1)
. . .

DL_SDU – Byte n-2 (n <= DL_MTU) ESC_DL

DL_SDU – Byte n-1 (n <= DL_MTU) Frame Seq. Number

EOF_EVEN CCITT CRC-16
Data Frame with Preemption

Figure 52

6.5.4
1837 • 1838 • 1839 •

Control Frames

1836 For all Data Link Layer Control Frames, the following rules shall apply: The Data Link Layer Control Frames are protected by a CCITT CRC-16 [ITUT03] checksum. The Data Link Layer Control Frame information shall be used only when the CRC checksum is correct. The Data Link Layer Control Frames shall not be preempted. Data Link Layer Acknowledgment and Flow Control Frame

6.5.4.1

1840 The Data Link Layer Acknowledgment and Flow Control (AFC) Frame is used for acknowledging correctly received Data Frames and for exchanging flow control information of the corresponding Traffic Class. The AFC Frame shall always start with an AFC control symbol, which is followed by two data symbols. The AFC Frame includes the Traffic Class identification, Credit Transmit Request (CReq) bit, Frame Sequence Number and the flow control credit value. 1841 The acknowledgment (Frame Sequence Number) and flow control (Credit Value) information are assigned to the Traffic Class identified by the TC field. The AFC Frame fields shall be structured as shown in Figure 53.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 167

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

16 1 0 0

15

12 11 10 9 8 7 6 5 4 3 2 1 0 CReq Reserved ESC_DL AFC TC Frame Seq. Number Reserved Credit Value CCITT CRC-16
Figure 53 AFC Frame

14

13

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. 6.5.4.2 Data Link Layer Negative Acknowledgment Control Frame

1846 The Data Link Layer Negative Acknowledgment Control (NAC) Frame shall be sent when the receiver detects an error (see Section 6.6.11) in any Frame or if a Data Frame is received with a wrong Frame Sequence Number or if the reverse Link needs to be reinitialized. The NAC Frame length shall be two symbols. The NAC Frame fields shall be structured as shown in Figure 54. The NAC Frame contains a RReq bit to request the remote end to reinitialize its TX PHY.

16 1 0

15

14

13

12 11 10 ESC_DL

9

6 5 NAC CCITT CRC-16
NAC Frame

8

7

4

3 2 1 0 RReq Reserved

Figure 54

1847 The reserved bits shall be set to ‘1’ when transmitting and shall be ignored at the receiver.

6.6

Protocol Features

1848 The following sections describe the control and data flow in the DL Layer for the transmitter and receiver.

6.6.1

PDU Composition Feature

1849 The upper layer PDU is encapsulated always in one DL Layer Frame. Each upper layer PDU shall be encapsulated in a separate DL Layer Frame. The upper layer shall provide a PDU of size that fits within the maximum Frame length allowed for TX in the DL Layer. Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 168

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.
Upper Layer PDU – Traffic Class X

SOF

DL-SDU – Traffic Class X

EOF

CRC

Data Link Layer Frame

Figure 55 6.6.1.1 Preemption

Composition of PDU with Even Length DL_SDU

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.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 169

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

Upper Layer PDU – Traffic Class Y

Upper Layer PDU – Traffic Class X

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)

Figure 56

Composition with Preemption (Traffic Class Y > X)

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 • 1858 1859 1860 • The preemption shall not occur: • between EOF_EVEN or EOF_ODD and CRC symbols • within AFC and NAC Frames (including the CRC symbol(s)) The preemption may happen at any symbol boundary except where the above rule is valid

6.6.2

PDU Decomposition Feature

1861 The DL receiver removes the header (SOF symbol) and the trailer (EOF_EVEN or EOF_ODD symbol and CRC symbol) that have been added by the remote DL Layer from the incoming Frame and passes the DL_SDU to the upper layer if the CRC check is passed for the received Frame, the Frame Sequence Number is in the expected order and the received Frame is not a Frame that was already previously passed to the upper layer (retransmitted Frame). The decomposition without preemption is shown in Figure 57.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 170

6.3.3 Buffering Mechanism 1863 A retransmission capability shall be provided in the transmitter per Traffic Class to retain Frames after transmission until they are acknowledged for that Traffic Class. Copyright © 2007-2011 MIPI Alliance. The DL Layer shall accept upper layer PDU only if it is capable of retransmitting it. This retention allows the Frames to be retransmitted if not successfully transmitted earlier. the DL Layer implementation shall be able to receive a Frame of the maximum payload size (DL_MTU) for any Traffic Class and shall not deliver to the upper layers data from a Frame with any of the errors defined in Section 6. In addition. Figure 58 shows the decomposition with preemption. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Data Link Layer Frame – Traffic Class X SOF DL_SDU – Traffic Class X EOF CRC Upper Layer PDU – Traffic Class X Figure 57 Decomposition with Even Length DL_SDU 1862 In case of preemption also COF control symbols are removed before passing the Frame to the Network Layer.4 Arbitration Scheme 1868 Table 55 lists the DL Layer priority in descending order of priority for all Frame types. 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 Upper Layer PDU – Traffic Class X Upper Layer PDU – Traffic Class Y Figure 58 Decomposition with Preemption 6. 1867 For any Traffic Class. the DL Layer implementation shall be able to retransmit any Frame it sent until the Frame is acknowledged.Version 1.4.40.1. MIPI Alliance Member Confidential 171 .6. 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. Inc. 6. 1864 The following rules apply for all TC buffers: 1865 • 1866 • The upper layer PDU shall be available to DL Layer completely prior to Frame start.

When the Frozen state is reached. Inc. coordination between the PHY Adapter Layer (L1. and the PA_DL_PAUSE. the DL Layer shall immediately generate the PA_DL_PAUSE.ind primitive. no Frame transmission shall be started.6. but shall happen no later than after the transmission of any ongoing Frames.rsp_L. number of active Lanes. the DL Layer shall not send any new symbols to the PA Layer. MIPI Alliance Member Confidential 172 . All rights reserved. Such coordination is orchestrated by the PHY Adapter Layer. power mode. Acknowledgment and Flow Control (AFC) Frame for Traffic Class 1 triggered by conditions other than the conditions that trigger AFC1 (promoted). through the PA_DL_PAUSE. Acknowledgment and Flow Control (AFC) Frame for Traffic Class 0 triggered by expiry of AFC0_REQUEST_TIMER or due to reception of an AFC0 with CReq bit set. 1870 When PA_DL_PAUSE. If Frames are not being transmitted.rsp_L. when the need occurs. i.40. all Data Link Layer timers shall be stopped. Copyright © 2007-2011 MIPI Alliance. Traffic Class 1 Data Frames Acknowledgment and Flow Control (AFC) Frame for Traffic Class 0 triggered by conditions other than the conditions that trigger AFC0 (promoted).Version 1.rsp_L shall be generated. etc. during and after the property is changed.5 Change of Certain Link Properties 1869 When there is a change of certain properties of the Link. Traffic Class 0 Data Frames that can be used for traffic for which the latency is less critical Frame Type Control Control AFC0 (promoted) Control AFC1 TC1 AFC0 Control Data Control Lowest Priority TC0 Data 6.ind is received.e. The Frozen state may be reached by the Data Link Layer at any point within a transmitted Frame.5) and the Data Link Layer (L2) is necessary to ensure proper operation before. After generating the PA_DL_PAUSE.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 55 Priority Highest Priority DL Layer Frame Name NAC AFC1 (promoted) Supported Priorities Description Negative Acknowledgment Control (NAC) Frame Acknowledgment and Flow Control (AFC) Frame for Traffic Class 1 triggered by expiry of AFC1_REQUEST_TIMER or due to reception of an AFC1 with CReq bit set.

6.rsp_L is generated at the latest at this point Figure 59 Latest Point in Time when PA_DL_PAUSE. The completion times of TC0 and TC1 are shown in the figure.1.4). shall resume normal operation and shall send any pending Frames according to the arbitration scheme.ind is received: no new frame is sent The TC1 Frame is sent and the TC0 Frame resumes COF TC0 #0 EOF CRC PA_DL_PAUSE.rsp_L primitive is generated.1. The credits are used only for Data Frame payload and padding byte and shall not be used for Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro TC0 SOF TC0 #0 TC1 A TC1 Frame preempts the ongoing TC0 Frame SOF TC1 #0 EOF CRC PA_DL_PAUSE.40. Upon reception of the primitive PA_DL_RESUME. The transmitter shall keep track of the amount of free logical buffer space in the receiver. the Data Link Layer shall leave the Frozen state. A Data Frame shall only be started if the following conditions are satisfied: • Enough credits are available to send the complete DL_SDU to the remote end • Number of unacknowledged Frames is less than sixteen The transmission of a preempted (see Section 6.rsp_L can be transmitted any time between the start of the PA_DL_PAUSE. All rights reserved. reset and restart all timers.6. PA_DL_PAUSE.1) a Data Frame of lower priority.ind primitive sent to the Data Link Layer.ind. The DL Layer shall re-enable Frame transmission. Frames of higher priority may preempt (see Section 6.ind is received when a TC1 Frame preempting a TC0 Frame is transmitted. when exiting the Frozen state and resuming normal operation that Frame shall be continued from the point of interruption. 6. No new Frames are transmitted and the current TC1 Frame is transmitted to completion. 1873 If the Frozen state is entered during the transmission of a Frame. if it was not already generated.6.rsp_L is Generated 1871 Figure 59 exemplifies the behavior previously described in the case where the PA_DL_PAUSE. 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.6 1876 • 1877 • 1878 1879 1880 • TCx Data Frame Transmission 1875 The following rules shall be applied for the transmission of a Data Frame for any Traffic Class: Frames shall be transmitted according to the arbitration scheme (see Section 6.7 Flow Control 1881 The Data Link Layer utilizes a dedicated credit flow control scheme per Traffic Class. This allows the transmitter to start a Data Frame of a Traffic Class if the remote receiver has free logical buffer space for this TC for the complete Frame. Inc.6.ind primitive and completion of the TC0 Frame timer. 6.1) Data Frame shall be continued with a COF symbol.Version 1.6. 1874 The PHY Adapter Layer indicates the operation has completed with a PA_DL_RESUME. MIPI Alliance Member Confidential 173 .

respectively. Note that the 8-bit R. It is delayed in time and often does not reflect the actual amount of credit available at the receiver.5 layer. 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. The DL Layer shall increment A by the integer quotient of the newly created logical buffer empty space in bytes Copyright © 2007-2011 MIPI Alliance. U..Version 1. Overflow of the 8-bit registers shall be ignored. MIPI Alliance Member Confidential 174 . used. data sent to the other end which is less than DL_CreditUnitSize bytes.g. whereas the receiver block of a node handles the registers S and A. 1883 During the boot procedure.7). The node shall internally track the number of partial credits sent. then A shall be set to 31.00 31-Jan-2011 MIPI Alliance Specification for UniPro transmitting SOF.e. U and A shall be the same as the credit value size of an AFC Frame (see Figure 53). but a slightly older version of this number. the following register values: 1885 1886 1887 1888 1889 1890 • • • • • • R. the integer quotient of the number of bytes sent divided by DL_CreditUnitSize. All rights reserved. The partial credit sum shall be less than one credit unit size at any time. Stores the number of partial credits of A 1891 The transmitter part of a node handles the registers R and U. for each TC. Inc. i. 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 node shall increment U by the number of whole credit units sent. sent or available. Stores the number of credits received U. as data may be held in the transmitter when space exists in the receiver. This creates a conservative view of the space available. This ‘error’ may actually impact system performance. they shall not be updated again during retransmission of that Data Frame. if the logical buffer size is 1000 bytes.40. S. it will always be robust. for each Traffic Class. U. 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. i. the Part_U value is replaced by the number of partial credits sent modulo DL_CreditUnitSize. EOF_EVEN. Credits are self-healing. 1892 When a node receives an error-free AFC Frame for a Traffic Class. EOF_ODD. 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. Stores the number of partial credits of U Part_A. That is. in Part_U. However. whereas the granularity of their representation is one credit unit size. COF and CRC symbols. 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. S. The size of credit registers R.e. This works because the credits represent the total number of credits since boot time. Stores the total number of credits used S. e. which is 8-bits. A is initialized to the size of the receiving logical buffer in credit units (DL_CreditUnitSize). Note that the number of credits received is often pessimistic. the value received in credit value field of the AFC Frame shall replace the value of R. and S are 0. as this error only understates the space available and never overstates it. One partial credit represents one byte. The system is based on registers that represent the total number of credits that have been available since boot up/reset. it will be corrected by the transmission of a next/new more up to date AFC Frame. The initial values of R. if a credit Frame is dropped due to either CRC checksum failure of AFC Frame or AFC Frame is not detected. Stores the total number of credits sent A. 1893 When an L2 transmitter sends payload or padding bytes to the L1. i. As the credit values are updated during the original transmission of a Data Frame. Stores the total number of credits available Part_U. and Control Frames. U shall be incremented by one and Part_U shall be decremented by DL_CreditUnitSize. 1884 Each node must maintain. Whenever the sum of partial credits sent in Part_U exceeds DL_CreditUnitSize bytes. modulo 256. A registers actually contain the number of total credits received. each side exchanges.e.

6. All rights reserved.req). Copyright © 2007-2011 MIPI Alliance. A and S belong to the same Traffic Class as DL_AFCxCreditThreshold.7). the value of S shall be replaced by the value of A. 1907 If DL transmitter has a Data Frame to send and fewer credits than DL_TCxTXFCThreshold.00 31-Jan-2011 MIPI Alliance Specification for UniPro divided by DL_CreditUnitSize. TX of a TCx has less credits than DL_TCxTXFCThreshold and data to send The Data Link Layer is in the initialization phase. Inc.Version 1. MIPI Alliance Member Confidential 175 . DL_CreditValeSizeBits 1900 Note. A shall be incremented by one and Part_A shall be decremented by DL_CreditUnitSize. where 1899 DL_CreditValSizeBits is the number of bits used to represent Credit Value field in AFC Frame and DL_CreditUnitSize is the size of one credit unit in bytes. 1910 FCx_PROTECTION_TIMER shall be reset when at least one of the following conditions is valid: 1911 • 1912 • With the expiration of FCx_PROTECTION_TIMER 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 • 1915 • The TCx of the peer node is present (see Section 6. The timeout value of FCx_PROTECTION_TIMER is denoted as DL_FCxProtectionTimeOutVal and the calculation details are provided in Section 6. 1905 1906 x represents the Traffic Class number. 0 or 1. ( R + 2 numbers in the result. 1896 At any time a node is allowed to send at most: 1897 [((R + 2 DL_CreditValSizeBits – U ) mod 2 DL_CreditValSizeBits ) × DL_CreditUnitSize – Part_U ] bytes 1898 in Data Frame(s). 1895 The AFC sending node shall set the AFC credit value field with the contents of A when an AFC Frame is sent.cnf_L as a result of a request for PHY (re-)initialization (PA_INIT.40. 1902 A node shall transmit an AFC Frame due to flow control when the following condition occurs: 1903 [(A + 2 DL_CreditValSizeBits – S ) mod 2 DL_CreditValSizeBits ] > DL_AFCxCreditThreshold 1904 where. 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. 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. 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. – U ) mod 2 DL_CreditValSizeBits addresses wrap around issues and avoids negative 1901 A DL Layer shall not transmit a Data Frame on a TC if the size of the Frame payload including the padding byte is bigger than the above defined value. The following formula is used to compare the number of credits available to DL_TCxTXFCThreshold: 1908 [((R + 2 – U ) mod 2 < DL_TCxTXFCThreshold × DL_CreditUnitSize DL_CreditValSizeBits DL_CreditValSizeBits )×2 DL_CreditValSizeBits – Part_U ] 1909 The FCx_PROTECTION_TIMER is used for protecting against loss of credits due to the loss of the AFCx Frame.9. At the same time.

for TC0 it is given by DL_TC0RxInitCreditVal.req shall be triggered. All AFC Frame transmission rules are explained in Section 6.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1917 After sending an AFCx Frame with CReq bit set and the FCx_PROTECTION_TIMER expires without receiving the AFCx Frame. 1920 More details are given in Section 6.40.6. Figure 60 illustrates the same example as Table 56 using a Message Sequence Chart.2.g. MIPI Alliance Member Confidential 176 . All rights reserved. Copyright © 2007-2011 MIPI Alliance. Figure 61 depicts difference between R and U credits at remote node TX. the receiver’s initial credit value. Local node transmits AFC0 Frames to remote node and remote node transmits Data Frames of TC0 to local node.8.6. a NAC Frame with the RReq bit set shall be transmitted before the transmission of an AFCx Frame with CReq bit set.4. See Section 6. then PA_INIT.10. 1921 Table 56 provides an example of the changes in the various credit-tracking registers after boot up. is assumed to be sixteen and the DL_AFCxCreditThreshold is set to fifteen. In the example. After receiving PA_INIT. The graph shows the variation of (R – U) credits during data transmission and AFC Frame reception.cnf_L. Inc.Version 1. e.6. 1918 Note: 1919 The priority of the AFCx Frame is raised when responding to an AFCx Frame with CReq bit set.

All rights reserved. MIPI Alliance Member Confidential 177 T0 T1 T2 T3 T4 Init Local node sends an AFC Frame with a value of 16 Remote node receives the AFC Frame and updates its value Remote node sends 256 bytes Local node receives 256 bytes Local node L3 reads 256 bytes. Inc.Version 1. i.e. Local node could send an AFC Frame but in this example. Local node can send an AFC Frame now Local node sends an AFC Frame with a value of 31 (adding 15 credits = 480 bytes) 16 16 16 16 16 T5 24 0 16 0 0 0 16 0 0 16 8 0 MIPI Alliance Specification for UniPro T6 T7 T8 T9 T10 T11 24 24 30 30 30 31 0 0 20 20 20 26 16 16 16 16 16 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16 16 16 16 16 16 0 0 0 0 0 0 0 0 0 0 0 0 16 16 16 16 16 16 14 14 14 15 15 15 26 26 26 26 26 26 T12 31 26 31 0 0 0 16 0 0 16 15 26 .40. it must read 480 bytes Remote node sends 218 bytes Local node receives 218 bytes Local node reads 212 bytes Remote node sends 32 bytes Local node receives 32 bytes Local node reads 38 bytes. it is considered that it must wait for 15 new available credits.00 31-Jan-2011 Table 56 Example of Flow Control Register Changes after Boot Up Local Node RX TX Sent (S) 0 16 16 16 16 Rcvd (R) 0 0 0 0 0 Used (U) 0 0 0 0 0 Partial Credits of U 0 0 0 0 0 Avail (A) 16 16 16 16 16 RX Partial Credits of A 0 0 0 0 0 Sent (S) 0 0 0 0 0 Rcvd (R) 0 0 16 16 16 Remote Node TX Used (U) 0 0 0 8 8 Partial Credits of U 0 0 0 0 0 Time Comments / Event Avail (A) Partial Credits of A 0 0 0 0 0 Copyright © 2007-2011 MIPI Alliance.

Inc.Table 56 Example of Flow Control Register Changes after Boot Up (continued) Local Node RX TX Sent (S) 31 31 31 31 … Rcvd (R) 0 0 0 0 … Used (U) 0 0 0 0 … Partial Credits of U 0 0 0 0 … Avail (A) 16 16 16 16 … RX Partial Credits of A 0 0 0 0 … Sent (S) 0 0 0 0 … Rcvd (R) 31 31 31 31 … Remote Node TX Used (U) 15 16 16 16 … Partial Credits of U 26 0 0 0 … Version 1. MIPI Alliance Member Confidential 178 T13 T14 T15 T16 … Remote node receives the AFC Frame Remote node sends 6 bytes Local node receives 6 bytes Local node reads 6 bytes … 31 31 31 32 … MIPI Alliance Specification for UniPro .40. All rights reserved.00 31-Jan-2011 Time Comments / Event Avail (A) Partial Credits of A 26 26 26 0 … Copyright © 2007-2011 MIPI Alliance.

00 31-Jan-2011 MIPI Alliance Specification for UniPro Local TX R=0 U=0 PU=0 AFC TC0 0#31 CV16 CRC A=16 PA=0 Remote RX S=0 Remote TX R=0 U=0 PU=0 Local RX A=16 PA=0 S=0 AFC TC0 0#31 CV16 CRC SOF TC0 #0 256 EOF CRC SOF TC0 #1 218 EOF CRC SOF TC0 #2 32 EOF CRC SOF R=16 U=8 PU=0 TC0 #0 256 EOF CRC SOF R=16 U=14 PU=26 TC0 #1 218 EOF CRC SOF R=16 U=15 PU=26 TC0 #2 32 EOF CRC R=16 U=0 PU=0 A=16 PA=0 S=16 Local upper layer reads 256 bytes (8 credits) from buffer A=24 PA=0 S=16 Local upper layer reads 212 bytes (6 credits + 20 bytes) from buffer A=30 PA=20 S=16 Local upper layer reads 38 bytes (1 credit + 6 bytes) from buffer A=31 PA=26 S=16 AFC TC0 0#2 CV31 CRC AFC TC0 0#2 CV31 CRC SOF TC0 #3 6 EOF CRC SOF R=31 U=16 PU=0 TC0 #3 6 EOF CRC R=31 U=15 PU=26 A=31 PA=26 S=31 Local upper layer reads 6 bytes from buffer A=32 PA=0 S=31 Figure 60 Message Sequence Chart for Flow Control Register Changes after Boot Up Example Copyright © 2007-2011 MIPI Alliance. All rights reserved.40. MIPI Alliance Member Confidential 179 . Inc.Version 1.

As the DL Layer communicates flow control and acknowledgment in the same Frame (AFC Frame.e.6. shall consume a partial credit (partial credits of U).2). i.4) the generation of AFC Frame for the pending acknowledgment(s) may not be immediate and follow the AFC Frame generation rules (see Section 6. During retransmission all flow control information shall be accepted (see Section 6. 1923 At the receiver the padding byte shall be discarded and available partial credits (partial credits of A) incremented by one.6.8. When a Frame Sequence Number is received in an AFC Frame.8 Acknowledgment Operation 1925 Each DL Layer Data Frame sent by the local transmitter shall be acknowledged either individually or in a group (an acknowledgment to more than one Frame. The remote receiver shall acknowledge Frame(s) only when it receives the Frame(s) in good condition (see Section 6. the receiver shall schedule an acknowledgment with the Frame Sequence Number of this Frame. grouped acknowledgment) by the remote receiver. If a Frame is corrupted. The AFC Frame contains current credit information of the receiver logical buffer and an acknowledgment with Frame Sequence Number of the last correctly received Frame for that Traffic Class. Inc.e.00 31-Jan-2011 MIPI Alliance Specification for UniPro Flow Control Operation at TX 18 16 Credits Received (R) . The DL Layer shall drop a Frame in its entirety and not process the Frame in any way if the CRC checksum is incorrect or has an unexpected Frame Sequence Number and shall transmit a Negative Acknowledgment Control (NAC) Frame. if it is used in a Data Frame at transmitter side. All rights reserved.10). 1924 During retransmission the credit used by register U shall not be incremented because the credits have already been consumed during the original transmission. 6.6. it is unreliable to Copyright © 2007-2011 MIPI Alliance. i. all Frames sent up to and including the Frame referenced by the Frame Sequence Number shall be considered acknowledged.5. CRC error.Version 1.Credits Used (U) 14 12 10 8 6 4 2 0 T0 T1 T2 T3 T4 T5 T6 T7 T8 Time T9 T10 T11 T12 T13 T14 T15 T16 Reset state. MIPI Alliance Member Confidential 180 . no credits available Credits consumption consumption during Credits data transmission during data transmission Credits received in AFC frame Credits received in AFC frame Credits consumption during data transmission Variation of credits Figure 61 Variation of Credits during Data Transmission Example 1922 Padding byte.11).40.6. If a Data Frame is received error-free (correct CRC symbol and with expected Frame Sequence Number). see Section 6..

00 31-Jan-2011 MIPI Alliance Specification for UniPro depend on it to make any decision (to identify if it is a TC0 or TC1. 1936 If an AFCx (where x is 0 for TC0. The Frame Sequence Number shall be transmitted within an AFC Frame (see Section 6. The Frame Sequence Number is incremented with transmission of a Frame of that Traffic Class. TC0Frame#6 and TC0Frame#7 Copyright © 2007-2011 MIPI Alliance. Each Traffic Class (TC) shall use its own Frame Sequence Numbers independently of other TCs. The following example illustrates this case for TC0: 1937 • 1938 • Local RX receives AFC0#3 Frame Local TX sends Frames TC0Frame#4. or greater than the last (re)transmitted Data Frame of the corresponding TC. Data Frame or a Control Frame). The retransmission shall be processed according to the arbitration scheme. they shall be all transmitted sequentially.1) of the corresponding TC to acknowledge correctly received Frame(s). All rights reserved. i. The Frame Sequence Number wrap around mechanism shall be ensured. the Frame Sequence Numbers shall not be shared among TCs. 1926 The following sections provide information on Frame Sequence Number and acknowledgment timeout operation. 6. The Frame Sequence Number is a part of EOF_EVEN/EOF_ODD symbol.8. the Frame Sequence Number shall be incremented. TC0Frame#5. the last good Frame Sequence Number received shall be set to 31. 1935 During Data Frame retransmission.Version 1. then flow control information shall be accepted but the acknowledgment information in the AFCx Frame shall be considered as outdated and discarded.2 Retransmission and Frame Acknowledgment Timeout Mechanism 1934 A dedicated replay timer (TCx_REPLAY_TIMER) shall be provided for each Traffic Class (TC0 and TC1) to identify unacknowledged transmitted Frame(s). When a Data Frame of a Traffic Class with an expected Frame Sequence Number is correctly received. Inc. Frame Sequence Numbers shall have the following characteristics: 1928 • 1929 • 1930 • 1931 • 1932 • A separate Frame Sequence Number is available for each Traffic Class. The limit of sixteen outstanding Frames is due to the fact that the DL Layer shall guarantee in order delivery and shall detect replayed Frames. The range of Frame Sequence Numbers is from 0 to 31 for each TC.6. When reset.. 1933 The incrementing Frame Sequence Number with its wrapping mechanism supports a maximum of 16 outstanding Frames for grouped acknowledgment at any time for each Traffic Class. even when an acknowledgment for a Frame under a retransmission or still to be retransmitted is received. the payload and Frame Sequence Number(s) shall be identical to the original transmission per Traffic Class.5. A wrap around mechanism shall be used so that once the Frame Sequence Number of a Data Frame of a TC reaches thirty-one it shall roll over and repeat the Frame Sequence Number from 0 for the next Data Frame for that TC. The next expected receive Frame Sequence Number shall be 0.6. If the Frame Sequence Number in the AFCx Frame is either not in the outstanding Frames. 1 for TC1) Frame is received. When Frames are being retransmitted.8. then the Frame Sequence Number in the AFCx Frame is compared to the last sent Data Frames or up to the previously retransmitted Frame (considering wrap around mechanism and allowed maximum number of outstanding Frames) in order to accept it. There is a dedicated AFC Frame for each Traffic Class (AFC0 for TC0 and AFC1 for TC1). The valid range is from 0 to 31. MIPI Alliance Member Confidential 181 .e. The timer guards against the possibility of an AFC or a NAC Frame encountered errors and were discarded. The Frame Sequence Number wrap around mechanism shall be ensured.1 Frame Sequence Number Identification 1927 A 5-bit Frame Sequence Number shall be used with each Data Frame.4. This replay timer shall not be reset if AFCx Frames are received for previously acknowledged Frames and there is at least one unacknowledged Frame in the logical buffer. 6.40.

An illustration of the Frame acknowledge timer and replay timer for TC0 is given in Figure 62.9. then the received Frame shall be identified as a retransmitted Frame and shall be discarded. then an AFC Frame (current information on flow control and acknowledgment status) for TC1. then all unacknowledged Data Frames.req Service Primitive of the PHY Adapter Layer if the RReq bit in the NAC Frame is not set. If a NAC Frame is detected during the transmission of any Control Frame then the transmitter shall not stop the Control Frame under transmission. If PA_INIT. Initially both timers are in a reset state. If the received Frame Sequence Number is not an expected one. The remote RX starts AFC0_REQUEST_TIMER after reception of TC0 Frame#0. The timer operations for TC1 are similar to TC0. resets and stops AFC0_REQUEST_TIMER. After some time. a PA _ L A N E _ A L I G N . if any. the remote TX sends AFC0#0 acknowledging TC0 Frame#0. the Frame is assumed not successfully transmitted. and TC0Frame#7) 1947 If the TCx_REPLAY_TIMER expires for a given TCx Data Frame without receiving an acknowledgment. an acknowledgment shall be scheduled either individually or in a group for each correctly received Data Frame. TC0Frame#5.req Service Primitive. As there are no outstanding TC1 Data Frames.Version 1. Retransmitted lower priority Frames can be preempted by higher-priority non-replayed Frames. where x = 0 or 1) guards against losing AFC or NAC Frame detection. After that. The DL_TCxReplayTimeOutVal and the DL_AFCxReqTimeOutVal for a TC shall be programmed such that this is the case. AFC Frames and all unacknowledged Data Frames. of TC0. t he n th e T X s h a l l w a i t f o r PA_ I N I T. if any. then the DL Layer shall trigger 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. The Frame acknowledge timer (AFCx_REQUEST_TIMER) shall guarantee that the remote transmitter schedules an AFC Frame before the transmitter TCx_REPLAY_TIMER expires. 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. for all TCs shall be transmitted according to the priority scheme. 1949 The receiver of a NAC Frame shall perform the following sequence: The DL Layer may trigger PA_INIT. then an AFC Frame (with current flow control and acknowledgment status) for TC0 and then all unacknowledged Data Frames. 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. After the completion of PHY initialization (indicated by the PA_INIT. The local TX sends TC0 Frame#0 to remote RX and starts TC0_REPLAY_TIMER. If any one of that is matching to the correctly received Frame Sequence Number. If the EOF_EVEN or EOF_ODD symbol is sent this Frame shall not be stopped.6. the local TX do not send any TC1 Data Frames Local TX sends AFC (current information on flow control and acknowledgment status) for TC0 Local TX starts replaying Frame from TC0Frame#4 to TC0Frame#7 During TC0Frame #4 replay.cnf_L the procedure will continue. r e q s h a l l b e t r i g g e r e d . All rights reserved. then it shall be compared with last sixteen Frame Sequence Numbers prior to the expected Frame Sequence Number.. I f PA _ I N I T. 1951 The replay timer (TCx_REPLAY_TIMER. local RX receives AFC0#7 Frame The local RX accepts flow control information but discards acknowledgment information from AFC0#7 Frame and continue with the replay (TC0Frame#4.40. of TC1.cnf_L Service Primitive) the DL Layer shall transmit a NAC Frame with the RReq bit set.req of the PHY Adapter Layer if the RReq bit in the NAC Frame is set. whether the Frame is identified as a retransmitted Frame or not. Examples of formulas to calculate timeout values are given in Section 6.r e q is n ot t r i g ge r e d .e.c n f _ L .req After confirmation by PA_INIT.req is t r ig g e r e d. i. TC0Frame#6. In any case.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1939 • 1940 • 1941 • 1942 1943 1944 1945 1946 • • • • • Local TX triggers retransmission due to timeout (last acknowledged Frame was TC0Frame#3) Local TX triggers PA_INIT. they are stopped. MIPI Alliance Member Confidential 182 . 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. Inc. if any. The receiver shall trigger PA_INIT. Copyright © 2007-2011 MIPI Alliance.

Copyright © 2007-2011 MIPI Alliance.40. MIPI Alliance Member Confidential 183 .cnf_L as a result of a request for PHY (re-)initialization (PA_INIT.cnf_L as a result of a request for PHY (re-)initialization (PA_INIT.00 31-Jan-2011 MIPI Alliance Specification for UniPro Local TX SOF TC0 #0 EOF CRC Remote RX Remote TX Local RX SOF TC0 #0 EOF CRC AFC TC0 #0 CRC AFC TC0 #0 CRC TC0_REPLAY_TIMER AFC0_REQUEST_TIMER Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired 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 • 1954 • 1955 • 1956 • with the transmission of the last symbol of a TCx Data Frame (CRC symbol) with the reception of a correct AFCx Frame which acknowledges at least one unacknowledged Data Frame with the reception of a correct NAC Frame with the expiration of TCx_REPLAY_TIMER 1957 TCx_REPLAY_TIMER shall run when all of the following conditions are valid: 1958 • 1959 • there exists at least one unacknowledged transmitted TCx Data Frame the DL Layer is not waiting for PA_INIT.req) 1960 The TCx_REPLAY_TIMER should be stopped when any of the above TCx_REPLAY_TIMER run rules is not satisfied.Version 1. All rights reserved.req) 1968 The AFCx_REQUEST_TIMER should be stopped when the above AFCx_REQUEST_TIMER run rules are not satisfied. Inc. 1961 AFCx_REQUEST_TIMER shall be reset when at least one of the following conditions is valid: 1962 1963 1964 1965 • • • • with the reception of a correct TCx Data Frame with the reception of a correct NAC Frame with the transmission of an AFCx Frame 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.

Link wake up time (PhyWakeUpTime).6. All rights reserved. PHY Adapter Latency includes TX and RX PHY Adapters. 1990 Here. which must be received by the local transmitter to process it before TCx_REPLAY_TIMER expires. 1978 ForwardLinkPhyProcessing considers PHY transmitter and receiver pipeline stages flushing (PhyTxPipelineFlush and PhyRxPipelineFlush) [MIPI01]. 1988 1989 PhyTxPipelineFlush. Data Link Layer processing in forward Link direction (ForwardLinkDLLProcessing) in µsec. 1985 Similarly. These times are derived from the value in PA_TxTrailingClocks.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1969 NOTE: With the expiration of the AFCx_REQUEST_TIMER the priority of the AFCx Frame is raised.6. Inc.9 Timeout Values Calculation (informative) TCx_REPLAY_TIMER and 1970 The timeout values of AFCx_REQUEST_TIMER.Version 1. MIPI Alliance Member Confidential 184 . Preemption support at transmitter side. FAST_STATE or SLOW_STATE. FCx_PROTECTION_TIMER depend on the following parameters: 1971 • 1972 • 1973 • 1974 • 1975 • 1976 • 1977 • Physical layer processing in forward Link direction (ForwardLinkPhyProcessing) in bits. OneSymbolTransfer is the time required to transfer a PA symbol over the Link.1). as the state of the Link varies more dynamically where as the values of timeout are computed during boot up/configuration phase. 1979 The value of ForwardLinkPhyProcessing in bits is given as: 1980 ForwardLinkPhyProcessing = PhyTxPipelineFlush + PhyRxPipelineFlush + PhyAdapterLatency + OneSymbolTransfer 1981 where. Physical layer processing in reverse Link direction (ReverseLinkPhyProcessing) in bits.6. The time required to transfer one DL maximum transfer unit (DL_SYMBOL_MTU) size Frame over the Link (MaxFrameTransferTime) in µsec. the ReverseLinkPhyProcessing in bits is expressed as: 1986 ReverseLinkPhyProces sin g = PhyTxPipelineFlush + PhyRxPipelineFlush + PhyAdapterLatency + AFCxFrameTransfer 1987 where. 6. Data Link Layer processing in the reverse Link direction (ReverseLinkDLLProcessing) in µsec. PhyAdapterLatency is the total time taken to process a symbol in the PHY Adapter at the TX and RX sides. PHY Adapter Latency includes TX and RX PHY Adapters. For worst case timeout values calculation.4. 1982 1983 1984 PhyTxPipelineFlush and PhyRxPipelineFlush are the time required to flush the TX and RX PA logic. See Section 6. Copyright © 2007-2011 MIPI Alliance. PhyRxPipelineFlush and PhyAdapterLatency are as defined above. Link wake up time is expressed in µs. AFCxFrameTransfer is equal to 3*OneSymbolTransfer. the reverse Link transfers AFC Frame. if the PHY Link is in FastAuto_Mode or SlowAuto_Mode as described in PHY Adapter Layer (see Section 5.40. latency due to PHY Adapter Layer and one full symbol may be needed to flush the PHY Adapter Layer in worst case. respectively. it may require time to get into one of the possible active states. this parameter is considered even though the Link is not in inactive state.

All rights reserved. and the CRC symbol and has a value of three symbols. 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. DL Layer overhead and the Link speed. 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. 1998 Using above defined parameters.Version 1. 1999 sin g DL_AFCxReqTimeOutVal ≥ ForwardLinkPhyProces -------------------------------------------------------------------------. EOF_EVEN or EOF_ODD symbol. respectively. DLLOverhead consists of the SOF symbol. timeout values for AFCx_REQUEST_TIMER and TCx_REPLAY_TIMER are calculated using following expressions.40.+ MaxFrameTransferTime ForwardLinkDataRate + MaxFrameGap + ForwardLinkDLLProces sin g 2000 where. DL_AFCxReqTimeOutVal is the expiration value of the AFCx_REQUEST_TIMER as defined in Table 59. This value is computed from following expression: 1992 ( DL_SYMBOL_MTU + DLLOverhead ) × DLLSymbolSize MaxFrameTransferTime = ----------------------------------------------------------------------------------------------------------------------------------------------------ForwardLinkDataRate 1993 where.00 31-Jan-2011 MIPI Alliance Specification for UniPro 1991 The MaxFrameTransferTime depends on the DL_SYMBOL_MTU. ForwardLinkDataRate is the bit rate of the Link on which the Frame is transferred. MIPI Alliance Member Confidential 185 . 1994 1995 1996 1997 DL_SYMBOL_MTU is the DL Layer’s maximum SDU in symbols. 2002 2003 2004 If preemption is supported at the transmitter side then: 2005 2006 the DL_TCxReplayTimeOutVal is given by the following equation: ReverseLinkPhyProces sin g DL_TCxReplayTimeOutVal ≥ DL_AFCxReqTimeOutVal + ------------------------------------------------------------------------ReverseLinkDataRate + ReverseLinkDLLProces sin g + PhyWakeUpTime 2007 2008 the DL_FCxProtectionTimeOutVal is given by the following equation: sin g DL_FCxProtectionTimeOutVal ≥ ForwardLinkDLLProces sin g + ForwardLinkPhyProces -------------------------------------------------------------------------ForwardLinkDataRate + PhyWakeUpTime sin g + ReverseLinkDLLProces sin g + ReverseLinkPhyProces ------------------------------------------------------------------------ReverseLinkDataRate 2009 If preemption is not supported at the transmitter side then: 2010 2011 the DL_TCxReplayTimeOutVal is given by the following equation: sin g DL_TCxReplayTimeOutVal ≥ DL_AFCxReqTimeOutVal + ReverseLinkPhyProces ------------------------------------------------------------------------ReverseLinkDataRate + ReverseLinkDLLProces sin g + PhyWakeUpTime DL_SYMBOL_MTU + DLLOverhead ) × DLLSymbolSize +( -------------------------------------------------------------------------------------------------------------------------------------------------------ReverseLinkDataRate Copyright © 2007-2011 MIPI Alliance. DLLSymbolSize is the DL Layer symbol size of 9-bits for D-PHY and 10-bits for M-PHY. which is used to capture limitations that some implementation might have and that impact the timeout values. Inc.

PhyRxPipelineFlush. Further. it is assumed that TX and RX are located at different nodes. the calculation example is based on single Lane M-PHY Link with 8b10b line coding for the forward and reverse direction. PhyWakeUpTime is the time required by the PHY Adapter to bring the Link into active mode. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2012 2013 the DL_FCxProtectionTimeOutVal is given by the following equation: DL_FCxProtectionTimeOutVal ≥ ReverseLinkPhyProcessing ----------------------------------------------------------------ForwardLinkDataRate + ForwardLinkDLLProcessing + PhyWakeUpTime ( DL_SYMBOL_MTU + DLLOverhead ) × DLLSymbolSize + -----------------------------------------------------------------------------------------------------------------------------------------------ForwardLinkDataRate ReverseLinkPhyProcessing + ReverseLinkDLLProcessing + ----------------------------------------------------------------ReverseLinkDataRate ( DL_SYMBOL_MTU + DLLOverhead ) × DLLSymbolSize + -----------------------------------------------------------------------------------------------------------------------------------------------ReverseLinkDataRate 2014 where. In Table 58. 2020 The Table 57 is informative that illustrates calculation of timeout values for above said timers if preemption is supported at transmitter side. defined by the M-PHY Attribute TX_HS_PREPARE_LENGTH LS_PREPARE_length=7. 2022 The values for M-PHY MODULEs are taken from [MIPI05].40. defined by a field of the M-PHY Attribute TX_HS_SYNC_LENGTH SYNC_range=0. a given reference configuration was used to compute the PHY Wake-up time for M-PHY MODULEs and is as follow: 2023 2024 2025 2026 • • • • HS_PREPARE_length=7. defined by a field of the M-PHY Attribute TX_HS_SYNC_LENGTH 2027 The parameters PhyTxPipelineFlush.Version 1. the maximum data rate is assumed to be 1 Gbps. Due to reset rules. 2015 2016 2017 2018 2019 DL_TCxReplayTimeOutVal is the expiration value of the TCx_REPLAY_TIMER. All rights reserved. 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. MIPI Alliance Member Confidential 186 . 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. which might deviate from the actual specification. Copyright © 2007-2011 MIPI Alliance. the timeout values are same even for grouped acknowledgment. Since the PHY Wakeup time can be configured by value stored in some M-PHY Attributes. DL_FCxProtectionTimeOutVal is the expiration FCx_PROTECTION_TIMER as defined in Table 59. value of the ReverseLinkDataRate is the bit rate of the incoming Link as seen from the local TX. PhyWakeUpTime. 2021 The values for D-PHY are taken from [MIPI01]. To simplify the calculations. ForwardLinkDLLProcessing and ReverseLinkDLLProcessing (for TX and RX) are physical layer implementation-specific. defined by the M-PHY Attribute TX_LS_PREPARE_LENGTH SYNC_length=7. PhyAdapterLatency.

Version 1.646 3. μs 10 10 18 144 3 3 2 9 4 0. bits PHY Pipeline TX. Symbols AFC Frame Size.503 28. Mbps 9 9 9 1250 1250 9 1250 1250 Copyright © 2007-2011 MIPI Alliance.1 12 0.55 207 243 2.4 365. All rights reserved.743 1000 1000 18 144 3 3 2 9 4 0.743 1000 10 18 144 3 3 2 9 4 0. Mbps DLL Symbol Size on PHY lines. Symbols NAC Frame Size.8 49.6 340. μs PHY Adapter Latency (including TX and RX).1 3 5 55 207 243 264. μs PHY Pipeline RX. μs DL_FCxProtectionTimeOutVal. Inc.1 1 5 55 207 243 264. Mbps RX Data Rate.743 27. Native PHY Symbols DLLReverseLinkProcessingTime.646 3.1 1 5 0.1 12 0. bits ReverseLinkPhyProcessing. Symbols DLLOverhead.503 6.903 25. Native PHY Symbols MaxFrameGap.1 12 0.55 207 243 2.8 10 1000 18 144 3 3 2 9 4 0. μs DL_TCxReplayTimeOutVal. bits MaxFrameTransferTime.6 340.4 343. bits DL_SYMBOL_MTU. μs PHY Wake-up (STOP->mode). MIPI Alliance Member Confidential 187 . Native PHY Symbols DLLForwardLinkProcessingTime. Symbols Native PHY Symbol Size. μs ForwardLinkPhyProcessing. Mbps RX Data Rate.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 57 Calculation of Timeout Values for D-PHY with TX Preemption Support (informative) D-PHY Parameter TX LPDT RX LPDT RX HS TX HS RX LPDT RX HS TX Data Rate.846 3.1 12 0.1 3 5 0.686 Table 58 Calculation of Timeout Values for M-PHY with TX Preemption Support (informative) M-PHY Parameter TX PWM-G1 RX PWM-G1 RX HSG1 TX HS-G1 RX PWM-G1 RX HSG1 TX Data Rate. μs DL_AFCxReqTimeOutVal.

After AFCx_REQUEST_TIMER has expired. the following rules shall be used to trigger the transmission of AFCx Frames with the CReq bit set to zero: 2030 2031 2032 2033 • • • • After reception of a NAC Frame.352 3.6 62.Version 1.186 3.10 AFCx Frame Transmission 2028 AFC Frame transmission after reception of an AFCx Frame with the CReq bit set shall be enabled. bits MaxFrameTransferTime. μs DL_AFCxReqTimeOutVal.1 2.744 6. μs DL_TCxReplayTimeOutVal.3 407.1 12 0. All rights reserved. μs PHY Pipeline RX.40.1 0. Symbols Native PHY Symbol Size. Native PHY Symbols DLLForwardLinkProcessingTime. In this case.508 32. μs 20 144 3 3 2 10 4 0. AFC Frame transmission shall be disabled for a given TCx after the initial AFC exchange if the TCx is not present in the peer Device.614 0. In all other cases. Native PHY Symbols DLLReverseLinkProcessingTime.5 20 144 3 3 2 10 4 0. Symbols DLLOverhead.1 0. After TCx_REPLAY_TIMER has expired.1 12 0.55 230 270 2.112 5 55 230 270 326.3 439.1 12 0. Symbols NAC Frame Size.1 12 0.352 3. the AFCx Frame’s priority shall be promoted. When the difference between the current received Frame Sequence Number that needs to be acknowledged (currentTCxFrSeqNum) and the last acknowledged Frame Sequence Number (lastAFCxFrSeqNum) exceeds the DL_TCxOutAckThreshold threshold: [ ( 32 + currentTCxFrSeqNum – lastAFCxFrSeqNum ) mod 32 ] > DL_TCxOutAckThreshold 2034 Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 188 .4 20 144 3 3 2 10 4 0.112 5 0.6 407.1 2. Native PHY Symbols MaxFrameGap. μs DL_FCxProtectionTimeOutVal.55 230 270 2. μs PHY Adapter Latency (including TX and RX).00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 58 Calculation of Timeout Values for M-PHY with TX Preemption Support (informative) (continued) M-PHY Parameter TX PWM-G1 RX PWM-G1 RX HSG1 TX HS-G1 RX PWM-G1 RX HSG1 DLL Symbol Size on PHY lines. bits ReverseLinkPhyProcessing.75 30. μs ForwardLinkPhyProcessing. 2029 In all other cases. Inc.638 20 144 3 3 2 10 4 0.6.6 407. Symbols AFC Frame Size. bits PHY Pipeline TX.22 5 55 230 270 326. which is the case when DL_PeerTCxPresent is FALSE.186 35. bits DL_SYMBOL_MTU. μs PHY Wake-up (SLEEP->PWM or STALL -> HS).22 5 0.

. Copyright © 2007-2011 MIPI Alliance. Inc.40. i.6.7) 2042 AFC Frames may be sent before a NAC Frame transmission to minimize the number of retransmitted Data Frames. 6. 2038 • After a reception of an AFCx Frame with the CReq bit set. and in the case of Data or AFC.Version 1. wrong Frame Sequence Number. they can be of any TC. For first AFC sent during initial AFC exchange (see Section 6. 2039 The following rule shall be used to trigger transmission of AFCx Frames with CReq bit set to one: 2040 • 2041 • After FCx_PROTECTION_TIMER has expired.11 NAC Frame Transmission 2043 Prior the transmission of a NAC Frame.e. when that Data Frame has not been preempted Reception of a COF symbol continuing a Data Frame of a different TC Reception of an EOF_EVEN.req shall be triggered. After transmitting a NAC Frame. NAC transmission shall be disabled until the DL Layer receives one Data or Control (AFC or NAC) Frame without any error. e. The response to this case shall be transmission of AFCx with priority promoted. undefined Control Symbol Type or TC Reception of an unexpected framing sequence. EOF_EVEN or EOF_ODD symbol when a Frame has not been started Reception of a SOF symbol when a Data Frame of the same Traffic Class is already ongoing and the Data Frame is not currently preempted Reception of a SOF symbol with TC=0 when a TC1 Data Frame is already ongoing Reception of a COF symbol during a Data Frame of the same Traffic Class.6. even when DL_PeerTCxPresent is FALSE.g. any partially received Data Frame shall be discarded. All rights reserved. data symbols received between Frames 2055 • 2056 • 2057 • 2058 • 2059 • 2060 • 2061 When any of the above errors are detected at the receiver. EOF_ODD or a data symbol when a Data Frame is preempted Reception of a DL control symbol with invalid values for defined fields.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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: [(2 DL_CreditValSizeBits 2036 + A – S ) mod 2 DL_CreditValSizeBits ] > DL_AFCxCreditThreshold 2037 More details are given in Section 6. CRC error.g. 2044 A NAC Frame (may or may not have RReq bit set) shall be transmitted when at least one of the following conditions occurs: 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 • • • • • • • • • • A CRC error in an incoming Frame A RX buffer overflow of any TC Reception of a Frame with a payload length more than DL_SYMBOL_MTU symbols in any TC An incorrect Frame Sequence Number in the received Data Frame for any TC (see following description) An AFCx symbol not followed by two data symbols A NAC symbol not followed by one data symbol An EOF_EVEN or EOF_ODD symbol not followed by a data symbol. etc. CRC symbol Reception of a PA_ERROR.ind Reception of a COF. the primitive PA_LANE_ALIGN. e. MIPI Alliance Member Confidential 189 .7.

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

2062 A NAC Frame with the RReq bit set shall be transmitted when at least one of the following conditions occurs: 2063 • 2064 • The FCx_PROTECTION_TIMER expires while waiting to receive an AFCx Frame in response to a previously sent AFCx Frame with CReq bit set. 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: 2066
0 < ( 32 + RcvSeq – ExpSeq ) mod 32 < 16

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.

6.6.12

Error Detection Mechanism

2069 The Data Link Layer shall detect transmission errors using CCITT CRC-16 [ITUT03] for all Data Frames and Control Frames (AFC and NAC). The CRC shall cover all symbols, including any COF symbols, from the first control symbol of the Frame (SOF, AFC or NAC symbol) up to, but not including, the CRC symbol of the Frame, as shown in Figure 63. Also, bit 16 of the DL Layer data symbol that carries the CRC checksum, which is always set to zero, shall not be covered by CRC.
CRC Coverage

SOF

DL_SDU – Traffic Class X

EOF

CRC

Figure 63 2070 The CRC-16 has the following polynomial: 2071
G(x) = X
16

CRC Coverage

+X

12

+X +1

5

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

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 190

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

16 0

15 X
15

14

13

12

11

10

9

8 X
8

7 X
7

6

5

4 ...

3

2

1

0 X0

...

Figure 64

Bit Allocation for CRC-16 Checksum in DL Layer Data Symbol

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.

6.6.13
2077 • 2078 • 2079 •

PHY Initialization Condition

2076 The PA_INIT.req shall be triggered if at least one of the following conditions is fulfilled: after reception of NAC Frame with the RReq bit set when FCx_PROTECTION_TIMER expires after being triggered by an AFCx Frame with CReq bit set after TCx_REPLAY_TIMER expires

2080 The PA_INIT.req may be triggered if at least one of the following conditions is fulfilled: 2081 • 2082 • before transmission of a NAC Frame with the RReq bit not set after reception of a NAC Frame with the RReq bit not set

2083 If the PHY (re-)initialization using PA-INIT.req Service Primitives continues to fail, autonomous error recovery is exhausted and a fatal error is assumed to have occurred. In this case, the DL_LM_ERROR.ind Service Primitive shall be called with DLErrorCode set to PA_INIT_ERROR. As a result, the endpoint application may reset the UniPro stack (see Section 9.3.2). Applications will most likely also need to be reset and restarted.

6.7

Data Link Layer Initialization

2084 The Data Link Layer initialization consists of the initial credit exchange, and is the process of preparing the Link to execute its normal operation. The initial credit exchange is started when the DME generates the DL_LM_LINKSTARTUP.req primitive, which shall be called only when the DL has been previously enabled by the DME. The DME shall enable the DL Layer by generating the DL_LM_ENABLE_LAYER.req primitive and is completed only after the reception of the DL_LM_ENABLE_LAYER.cnf_L primitive. 2085 After reception of the DL_LM_LINKSTARTUP.req primitive, the DL shall first transmit the AFC Frame for Traffic Class 1 (AFC1) and then transmit the AFC Frame for Traffic Class 0 (AFC0). Both AFC Frames shall have the CReq bit set. The Frame Sequence Number and the credit value carried by these two AFC Frames are the reset values of the last acknowledged Frame Sequence Number (31 as defined in Section 6.6.8) and number of accumulated credits A (the size of the receiving logical buffer in credit units as defined in Section 6.6.7) for the two Traffic Classes, respectively. 2086 As long as the first AFCx Frame was not received, the FCx_PROTECTION_TIMER runs (see Section 6.6.7). The FCx_PROTECTION_TIMER behavior (see Section 6.6.7), rules for AFC Frame transmission (see Section 6.6.10) and NAC Frame transmission ( Section 6.6.11) ensure reliable exchange of credits during initialization. 2087 If the DL Layer receives the first AFCx Frame with a flow control credit value of zero, DL_PeerTCxPresent shall be set to FALSE. If the DL Layer receives flow control credits greater than, or equal to, ten in the first Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 191

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

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.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 192

Version 1.40.00 31-Jan-2011

MIPI Alliance Specification for UniPro

Local TX
TC0 TC1 AFC CReq TC1 #31 CRC AFC CReq TC0 #31 CRC

Remote RX
Sending an AFC1 with the CReq bit set starts the FC1_PROTECTION_TIMER Sending an AFC0 with the CReq bit set starts the FC0_PROTECTION_TIMER

Remote TX

Local RX

Remote end not ready to receive data

NAC RReq CRC AFC CReq TC1 #31 CRC AFC CReq TC0 #31 CRC

Sending an AFC1 with the CReq bit set starts the FC1_PROTECTION_TIMER Sending an AFC0 with the CReq bit set starts the FC0_PROTECTION_TIMER AFC CReq TC1 #31 CRC AFC CReq TC0 #31 CRC

Sending an AFC1 with the CReq bit set starts the FC1_PROTECTION_TIMER

Remote end not ready to receive data

AFC CReq TC1 #31 CRC AFC CReq TC0 #31 CRC Sending an AFC0 with the CReq bit set starts the FC0_PROTECTION_TIMER

Receiving credits >= DL_TC1TXFCThreshold stops the timer. Receiving credits >= DL_TC0TXFCThreshold stops the timer. L2 initialization complete.

AFC After receiving an AFC1 with the CReq bit set, a normal AFC1 is sent After receiving an AFC0 with the CReq bit set, a normal AFC0 is sent TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #0 EOF CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #0 EOF CRC Local FC0_PROTECTION_TIMER FC1_PROTECTION_TIMER Receiving credits >= DL_TC0TXFCThreshold stops the timer. L2 initialization complete. Remote FC0_PROTECTION_TIMER FC1_PROTECTION_TIMER Receiving credits >= DL_TC1TXFCThreshold stops the timer.

Legend

Timer Stopped

Timer Reset and Running

Timer Running

Timer Expired

Figure 65

Initial Credit Exchange Example

6.8

Management Information Base and Protocol Constants

2092 Table 59 and Table 61 show the Data Link Layer Attributes. 2093 Table 60 lists the Protocol Constants used by the protocol specification and defines valid values for the Attributes. 2094 In the tables in this section all Attributes should be readable. 2095 A settable Data Link Layer Attribute that has more than one mandatory value should be writable. 2096 All UniPro Attributes shall reset to a default value specified in the Table 59. Some UniPro Attributes shall allow Attributes to load a persistent value instead. Persistent values may be stored and provisioned in a form of Non Volatile Memory, eFuse, etc. storage.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 193

Version 1.40.00 31-Jan-2011

Table 59
Attribute Attribute ID

Data Link Layer (gettable, settable) Attributes
Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value

TC0 Parameters

DL_TC0TXFCThreshold1

0x2040

Threshold for triggering an AFC0 Frame with CReq bit set to request flow control update from remote end. This Attribute is retained during hibernate. Expiration value of the FC0_PROTECTION_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate. Expiration value of the TC0_REPLAY_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate. Expiration value of the AFC0_REQUEST_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate.

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 194

Integer

DL_CreditUnitSize

1 to DL_PeerTC0RxInitC reditVal – 1

9

9

DL_FC0ProtectionTimeOutVal

0x2041

Integer

µs

0 (OFF), 1 to 1023

1 to 1023

511

MIPI Alliance Specification for UniPro

DL_TC0ReplayTimeOutVal

0x2042

Integer

µs

0 (OFF), 1 to 4095

1 to 4095

4095

DL_AFC0ReqTimeOutVal

0x2043

Integer

µs

0 (OFF), 1 to 4095

1 to 4095

2047

Table 59
Attribute Attribute ID

Data Link Layer (gettable, settable) Attributes (continued)
Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value

Version 1.40.00 31-Jan-2011

DL_AFC0CreditThreshold

0x2044

Threshold for AFC0 triggering based on available TC0 credits at receiver. This Attribute is retained during hibernate. Number of outstanding acknowledgments for TC0 (number of TC0 Data Frames received before an AFC0 Frame is sent). This Attribute is retained during hibernate.

Integer

DL_CreditUnitSize

0 to 127

0 to 8

0

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 195

DL_TC0OutAckThreshold

0x2045

Integer

Frame

0 to 15

0 to 15

0

TC1 Parameters

DL_TC1TXFCThreshold1

0x2060

Threshold for triggering an AFC1 Frame with CReq bit set to request flow control update from remote end. This Attribute is retained during hibernate. Expiration value of the FC1_PROTECTION_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate.

Integer

DL_CreditUnitSize

1 to DL_PeerTC1RxInitC reditVal – 1

9

9

MIPI Alliance Specification for UniPro

DL_FC1ProtectionTimeOutVal

0x2061

Integer

µs

0 (OFF), 1 to 1023

1 to 1023

511

Table 59
Attribute Attribute ID

Data Link Layer (gettable, settable) Attributes (continued)
Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value

Version 1.40.00 31-Jan-2011

DL_TC1ReplayTimeOutVal

0x2062

Expiration value of the TC1_REPLAY_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate. Expiration value of the AFC1_REQUEST_TIMER The actual duration of the timeout period shall be the value set in the Attribute ±10%. This Attribute is retained during hibernate. Threshold for AFC1 triggering based on available TC1 credits at receiver. This Attribute is retained during hibernate. Number of outstanding acknowledgments for TC1 (number of TC1 Data Frames received before an AFC1 Frame is sent). This Attribute is retained during hibernate.

Integer

µs

0 (OFF), 1 to 4095

1 to 4095

4095

Copyright © 2007-2011 MIPI Alliance, Inc. All rights reserved. MIPI Alliance Member Confidential 196

DL_AFC1ReqTimeOutVal

0x2063

Integer

µs

0 (OFF), 1 to 4095

1 to 4095

2047

DL_AFC1CreditThreshold

0x2064

Integer

DL_CreditUnitSize

0 to 127

0 to 8

0

MIPI Alliance Specification for UniPro

DL_TC1OutAckThreshold

0x2065

Integer

Frames

0 to 15

0 to 15

0

MIPI Alliance Member Confidential 197 DL_CreditValSizeBits DL_CreditUnitSize Table 61 Attribute Attribute ID Data Link Layer (gettable.00 31-Jan-2011 Table 60 Attribute Data Link Layer Protocol Constants Description Type Unit Value DL_MTU DL_SYMBOL_MTU Maximum Payload Length Maximum number of symbols in a DL_MTU size payload (DL_SYMBOL_MTU = DL_MTU/2) Number of bits used to represent Credit Value field in an AFC Frame Size of one credit unit Integer Integer Integer Integer Byte Symbol Bit Byte 288 144 8 32 Copyright © 2007-2011 MIPI Alliance. Inc. All rights reserved.Version 1. FALSE = 0 MIPI Alliance Specification for UniPro DL_CreditUnitSize 10 to 128 DL_TC1TxMaxSDUSize 0x2003 TC1 Transmitter Maximum SDU Size Integer Symbol 1 to DL_SYMBOL_MTU . TC0 Bool TRUE = 1.40. FALSE = 0 DL_TC0TxMaxSDUSize DL_TC0RxInitCreditVal1 DL_TC0TxBufferSize DL_PeerTC0Present DL_PeerTC0RxInitCreditVal1 0x2001 0x2002 0x2005 0x2046 0x2047 TC0 Transmitter Maximum SDU Size TC0 Receiver Initial Credit Value (initial register A value) TC0 Transmitter Buffer Size Peer Device supports TC0 Peer TC0 Receiver Initial Credit Value (initial register A value) TC1 Integer Integer Integer Bool Integer Symbol DL_CreditUnitSize DL_CreditUnitSize 1 to DL_SYMBOL_MTU 10 to 128 10 to 128 TRUE = 1. static) Attributes Description Type Unit Valid Attribute Value(s) DL_TxPreemptionCap 0x2000 Preemption capability on transmit side for both Traffic Classes.

The maximum value depends on the receiver buffer size. MIPI Alliance Specification for UniPro . Inc. static) Attributes (continued) Description Type Unit Valid Attribute Value(s) Version 1. FALSE = 0 Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 198 DL_PeerTC1Present DL_PeerTC1RxInitCreditVal1 DL_CreditUnitSize 0. 10 to 128 TRUE = 1. 10 to 128 1.Table 61 Attribute Attribute ID Data Link Layer (gettable.40. 10 to 128 0.00 31-Jan-2011 DL_TC1RxInitCreditVal1 DL_TC1TxBufferSize 0x2004 0x2006 0x2066 0x2067 TC1 Receiver Initial Credit Value (initial register A value) TC1 Transmitter Buffer Size Peer Device supports TC1 Peer TC1 Receiver Initial Credit Value (initial register A value) Integer Integer Bool Integer DL_CreditUnitSize DL_CreditUnitSize 0. All rights reserved.

All rights reserved.Version 1.2 Network Layer Addressing 2107 This section defines the abstract syntax and semantics of the Network address. Transport Layer (L4) Device Management Entity (DME) N_LM SAP N_TC0 SAP N_TC1 SAP SAP Management Plane N_LM Entity N_MIB Data Plane TC0 Entity Network Layer (L3) TC1 Entity N_TRAP1 SAP N_TRAP0 Figure 66 Network Layer SAP Model 7. its protocol behavior and the Network Protocol Data Units (N_PDUs) used by the Network Layer. The Network service to the Transport Layer is provided through two Traffic Class-specific Service Access Points (N_TCx_SAP). The Network Layer in turn relies on the service provided by the appropriate DL_TCx_SAP. The N_TRAPx_SAP is provided as an entry to divert or inject Long Header Packets from or to software such that an existing UniPro implementation can be extended in software to support future UniPro features when they become available. It aims at providing as much implementation flexibility as possible given the restrictions needed to achieve a high degree of interoperability. The Network Layer Management SAP (N_LM_SAP) is provided to the Device Management Entity (DME) for configuration and control purposes. Although the current version of UniPro only provides limited capabilities in the Network Layer.1 Network Layer Service Functionality and Features 2099 The Network Layer shall provide the following features and services to provide for the transfer of user-data between Network Service Users. 2098 Figure 66 shows the SAP model used for the Network Layer. a DeviceID concept is provided for compatibility with future extensions which provide full Network routing capability. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7 Network Layer (L3) 2097 This section defines the service provided by the Network Layer.40. 7. 2100 2101 2102 2103 2104 2105 • • • • • • Addressing Packet Composition and Packet Decomposition Packet format recognition Error handling Support for at least one Traffic Class Long Header trap to enable L3 and L4 extensions to future versions of UniPro 2106 The Network Layer shall not limit the user-data with regard to its content and its representation. Inc. MIPI Alliance Member Confidential 199 .

defined as DeviceID. N_SDUs may be discarded upon any occurrence of certain conditions. also defined in Table 80. 2112 The maximum size of a Packet depends on the N_MaxPacketSize value defined in Table 80. All rights reserved. uniquely identifying a specific Device. which can be exchanged between Network Service Users. 7. e. An N_SDU is the only unit. Packets shall only be exchanged between SAPs belonging to the same Traffic Class as depicted in Figure 68. which is the highest possible DeviceID supported in the current version of UniPro. defined later on. The order of Packets shall not be changed and Packets shall not be duplicated during transmission. 2111 In addition. Inc. The uniqueness of DeviceIDs within a UniPro Network shall be ensured. namely TC0 or TC1. MIPI Alliance Member Confidential 200 . Network Address and DeviceID 2108 In general a Network address. Transport Layer – L4.Version 1.9. i.40. which are also referred to as Packets.00 31-Jan-2011 MIPI Alliance Specification for UniPro Transport Layer (L4) N_TC0 SAP N_TC1 SAP N_TCx SAP group identified by a single DeviceID TC0 Entity TC1 Entity Network Layer (L3) Figure 67 N_SAPs. identifies one Network Layer SAP group (N_TCx_SAP) (refer to Figure 67).e.g. e.g.4. 2109 The DeviceID. The maximum size of user-data is limited by the Network Layer Maximum Transfer Unit (N_MTU) size. By means of the used entity. specified in Section 7. The transport is performed by means of Network Protocol Data Units (N_PDUs). is a 7-bit value. N_TC0_SAP or N_TC1_SAP. ranging from 0 to N_MaxDeviceID (see Table 80). Every single Packet is transmitted independently from each other Packet. Copyright © 2007-2011 MIPI Alliance.3 Data Communication between Devices 2110 Data is passed between the Network Layer and its users in Network Service Data Units (N_SDUs) qualified by certain parameters via SAPs by means of Service Primitives. the DeviceID identifies uniquely any individual Network Layer SAP. unsupported header type. and addressed by the Network Service User.

Copyright © 2007-2011 MIPI Alliance. The DL_TCx_SAP is defined in Section 6.4 Services Assumed from the Data Link Layer 2113 The Data Link Layer provides its services to the Network Layer via DL_TCx_SAP. All rights reserved. Inc. Refer to Section 6 for detailed property descriptions. 2118 The Network Layer inherits characteristics from the underlying Data Link Layer services as shown in Figure 69 to enhance the basic Network Service.40.Version 1. 2114 The Network Layer requires the following services and properties provided by the Data Link Layer: 2115 • 2116 • Reliable data transmission In-order delivery of data belonging to the same TC 2117 Data transmission and reception by means of Packets are supported by the exchange of parameters and indications between the Network Layer and the Data Link Layer. These parameters and indications allow the Network Layer to control and be informed of the data transmission and reception.00 31-Jan-2011 MIPI Alliance Specification for UniPro Device 1 User A User B Service User Device 2 User X User Y N_TC0 SAP a N_TC1 SAP b Network Service Network Layer (L3) Service Provider N_TC0 SAP x N_TC1 SAP y TC0 Entity TC1 Entity TC0 Entity TC1 Entity Data Transfer between User A and User X via N_TC0 SAPs Data Transfer between User B and User Y via N_TC1 SAPs Figure 68 Network Layer Data Transfer Using Different Traffic Classes 7.3. MIPI Alliance Member Confidential 201 .

2122 To ensure interoperability between the different versions of UniPro.6 N_TCx_SAP 2123 The N_TCx_SAP provides the services for basic data transmission. routing Packets based on logical Device identifiers. which shall not be modified and shall not be re-ordered by the provider. In the current version of UniPro only point-to-point Links are supported. that means no routing and switching is necessary and therefore these Network Layer-specific features and protocols are not specified here.e. 7. Copyright © 2007-2011 MIPI Alliance. data is passed via the N_TCx_SAP in N_SDUs to the Network Layer to transfer it to the peer Network Layer. 7.40. All rights reserved. although there are two separate entities TC0 and TC1 drawn. Inc. the Network Layer services supported by the current version of UniPro are targeted to be a sub-set of any forthcoming UniPro Network Layer services. namely DeviceID. At the recipient side. the Network Layer’s responsibility is to provide the transport of Packets from the transmitting resource through the Network to the receiving resource. the Network Layer model consists of two identical TCx entities.Version 1. this does not imply any implementation choice.5 Limitations and Compatibility Issues 2121 As already specified.00 31-Jan-2011 MIPI Alliance Specification for UniPro N_TC0 SAP N_TC1 SAP Network Layer (L3) TC0 Entity TC1 Entity DL_TC0 SAP DL_TC1 SAP Data Link Layer (L2) Figure 69 Relationship of Network Service Characteristics and Underlying Services 2119 In order to support the given characteristics and to keep them independent. i. 2120 Note. 7.1 Data Transfer Primitives 2126 The primitives covered in this section are listed in Table 62. 2124 At the sending side. MIPI Alliance Member Confidential 202 . The user may transmit any integral number of bytes greater than zero up to the N_MTU. The Traffic Class identification is done based on the used SAP.6. the Network Layer delivers received data in N_SDUs to the upper layer. 2125 The N_TCx_SAP shall support the transmission of user-supplied data between users.

2 7. and is defined in Table 80.8 7. 2129 The provided DestPeerDeviceID shall identify the recipient of the payload. 2131 The semantics of this primitive are: 2132 N_DATA_SHDR.req from Layer 4 and by N_DATA_SHDR.1.6. All rights reserved.6.6.40.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.6.e.6 2127 Table 63 lists the parameters that appear in the N_TCx_SAP primitives.1 N_DATA_SHDR. Inc. Table 63 Name Type N_TCx_SAP Primitive Parameters Valid Range Value Description DestPeerDeviceID DeviceIDOffset Integer 0 to N_MaxDeviceID 0 to N_MaxDeviceIDOffse t Specifies the DeviceID of the destination Device of the N_SDU Specifies the DeviceID offset that is used for the encoding and decoding of CPortIDs.req and N_DATA_LHDR_TRAP. which is derived from Transport Layer protocol constants. MIPI Alliance Member Confidential 203 .1.1. The length of the payload shall be in the range from 1 to DL_MTU L2Payload byte string OK LhdrTrapStatus Enumeration LOST_DATA 0 1 Indicates whether received data has been lost in Layer 3 due to a slow Application 7.5 7.8.1 7.1.ind between the L3 extension and Layer 3.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 62 Name Request N_TCx_SAP Primitives Indication Local Response Response Local Confirm Confirm N_DATA_SHDR N_DATA_LHDR_TRAP 7.1.6. The value of N_TCxTxMaxSDUSize depends on the value of DL_TCxTxMaxSDUSize and the value of N_MaxHdrSize. N_MaxDeviceIDOffset]. The DeviceIDOffset parameter shall be in the range [0.2 Specifies the data passed by N_DATA_SHDR.ind to Layer 4.7 7.1.6.Version 1.1.3 7.6. The length of the payload shall be in the range from 1 to N_MTU Integer Payload byte string L3ResultCode Enumeration SUCCESS NO_PEER_TC 0 1 Indicates the result of the request Specifies the data passed by N_DATA_LHDR_TRAP. Payload ) Copyright © 2007-2011 MIPI Alliance. DeviceIDOffset. no source DeviceID or other L3-specific information will be transferred.1. 2130 The user may transmit any integral number of bytes that shall be greater than zero up to the N_TCxTxMaxSDUSize.req( DestPeerDeviceID.6. i.4 7.6. See Section 8.1.1.1).

cnf_L with L2ResultCode set to NO_PEER_TC.cnf_L primitive corresponding to a previously emitted N_DATA_SHDR.cnf_L.req primitive immediately following a reset or after the reception of the N_DATA_SHDR. 2151 This primitive is invoked by the L3_TC_tx process. 2149 Behavioral Description 2150 The state diagram describing the behavior of the N_DATA_SHDR.40. prior to return to the Idle state. Copyright © 2007-2011 MIPI Alliance. so L3 in this case. is ready to accept a new N_DATA_SHDR. 2135 Effect on Receipt 2136 The instructed Network Layer shall initiate the transmission of the given payload.req primitive.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2133 When Generated 2134 The Network Service User shall generate a N_DATA_SHDR.req primitive. the returned L3ResultCode shall be SUCCESS. The L3_TC_tx process defines the behavior associated with the handshake between N_DATA_SHDR. 2137 Behavioral Description 2138 The state diagram describing the behavior of the N_DATA_SHDR. 7. 2146 Effect on Receipt 2147 Following the emission of a N_DATA_SHDR. the value of the L3ResultCode shall be NO_PEER_TC. 2140 The semantics of this primitive are: 2141 N_DATA_SHDR.cnf_L primitive is shown in Figure 333 of [MIPI02]. c n f _ L p r i m i t i v e .req primitive.req primitive.1. which implies that the TCx Traffic Class is present in the peer Device.cnf_L( L3ResultCode ) 2142 When Generated 2143 This primitive shall be generated when the Network Service Provider is ready to accept a new request to transfer user payload. The Network Layer learns about the peer Device not implementing the TCx Traffic Class when it receives DL_DATA.req primitive to send user payload to the specified recipient. 2148 The Network Service User may emit a new N_DATA_SHDR. All other L3ResultCode values should indicate a failure. t h e N e t w o r k L a y e r S e r v i c e U s e r s h a l l n o t e m i t a n e w N_DATA_SHDR.6. All rights reserved. Inc. MIPI Alliance Member Confidential 204 .req and N_DATA_SHDR. 2145 If the peer Device does not implement the TCx Traffic Class. when leaving the WaitDLCnfL state.req primitive is shown in Figure 333 of [MIPI02].Version 1.req primitive and prior to the reception of a N _ D ATA _ S H D R .cnf_L 2139 This primitive informs the Service User that the Service Provider.2 N_DATA_SHDR. 2144 If the Network Service Provider is ready to accept a new N_DATA_SHDR.

All rights reserved. when leaving the WaitDLRspL state.6. 2159 Behavioral Description 2160 The state diagram describing the behavior of the N_DATA_SHDR. the Network Layer Service User should consume the payload. the Network Layer shall not emit a new N_DATA_SHDR.req 2171 The N_DATA_LHDR_TRAP. The DeviceIDOffset shall be provided to the Service User for Transport Layer decoding purposes (see Section 8. carried by a DT SH N_PDU.req primitive is used to provide a Long Header Packet for transmission to the Data Link Layer.ind 2152 This primitive shall report the reception of user payload. 2168 Behavioral Description 2169 The state diagram describing the behavior of the N_DATA_SHDR. Payload ) 2155 When Generated 2156 This primitive shall be generated when the Network Service Provider has successfully processed a received DL SH N_PDU. The Network Layer may emit a new N_DATA_SHDR.ind primitive and prior the reception of a N_DATA_SHDR. The L3_TC_rx process defines the behavior associated with the handshake between N_DATA_SHDR.3 N_DATA_SHDR.ind primitive. Inc.rsp_L primitive.6.2).rsp_L primitive corresponding to a previously emitted N_DATA_SHDR. no sender is identified.11. 7. The payload may consist of any integral number of bytes greater than zero up to the N_MTU. prior to return to the Idle state.ind( DeviceIDOffset. Copyright © 2007-2011 MIPI Alliance.5 N_DATA_LHDR_TRAP.4 N_DATA_SHDR.40.ind primitive.rsp_L.rsp_L 2161 This primitive informs the Network Layer that the Transport Layer is ready to accept a new N_DATA_SHDR. 2157 Effect on Receipt 2158 Upon reception of a N_DATA_SHDR.rsp_L( ) 2164 When Generated 2165 This primitive shall be generated when the Transport Layer is ready to accept and process a new N_PDU. 2153 The semantics of this primitive are: 2154 N_DATA_SHDR. 2166 Effect on Receipt 2167 Following the emission of a N_DATA_SHDR.1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7.rsp_L primitive is shown in Figure 336 of [MIPI02].1.1. MIPI Alliance Member Confidential 205 . 2170 This primitive is invoked by the L3_TC_rx process.ind primitive.ind primitive is shown in Figure 336 of [MIPI02].6.Version 1. 7. 2162 The semantics of this primitive are: 2163 N_DATA_SHDR.ind primitive. or after the reception of N_DATA_SHDR.ind and N_DATA_SHDR.ind primitive only just after reset.

All other L3ResultCode values should indicate a failure. 7. the returned L3ResultCode shall be SUCCESS.1.req primitive.req primitive is shown in Figure 334 of [MIPI02].40.cnf_L with L2ResultCode set to NO_PEER_TC. Copyright © 2007-2011 MIPI Alliance. 7.req primitive immediately following a reset or after the reception of the 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. 2176 Effect on Receipt 2177 The received Data Link Layer payload shall be transmitted to the Data Link Layer without any processing.6.cnf_L( L3ResultCode ) 2183 When Generated 2184 This primitive shall be generated when the Network Layer is ready to accept a new request from the Network Layer extension. 2185 If the peer Device does not implement the TCx Traffic Class.req primitive to send a Long Header Packet to Data Link Layer. the value of the L3ResultCode shall be NO_PEER_TC.Version 1. The Network Layer learns about the peer Device not implementing the TCx Traffic Class when it receives DL_DATA. 2186 Effect on Receipt 2187 Following the emission of a N_DATA_LHDR_TRAP. 2189 Behavioral Description 2190 The state diagram describing the behavior of the N_DATA_LHDR_TRAP.req( L2Payload ) 2174 When Generated 2175 A Network Layer extension shall generate a N_DATA_LHDR_TRAP. The specification of the Network Layer extension is outside the scope of this document.ind 2191 This N_DATA_LHDR_TRAP.cnf_L primitive is shown in Figure 334 of [MIPI02]. If the Network Layer is ready and TCx is present in the peer Device.cnf_L primitive corresponding to a previously emitted N_DATA_LHDR_TRAP.ind primitive reports the reception of user-data to the Network Layer extension.6 N_DATA_LHDR_TRAP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2172 The semantics of this primitive are: 2173 N_DATA_LHDR_TRAP. All rights reserved. 2188 The Network Layer extension may emit a new N_DATA_LHDR_TRAP.1. Inc. MIPI Alliance Member Confidential 206 .7 N_DATA_LHDR_TRAP. the Network Layer extension shall not emit a new N_DATA_LHDR_TRAP.req primitive and prior to the reception of a N_DATA_LHDR_TRAP.6.cnf_L primitive. 2181 The semantics of this primitive are: 2182 N_DATA_LHDR_TRAP.req primitive. 2178 Behavioral Description 2179 The state diagram describing the behavior of the N_DATA_LHDR_TRAP.req primitive.

All rights reserved.rsp_L primitive is shown in Figure 336 of [MIPI02].rsp_L primitive indicates that the Network Layer extension is ready to accept a new N_DATA_LHDR_TRAP. r s p _ L p r i m i t i v e . 7. 2202 The semantics of this primitive are: 2203 N_DATA_LHDR_TRAP. 2196 The primitive shall indicate in LhdrTrapStatus whether any data has been dropped from the previous generation of the primitive.rsp_L( ) 2204 When Generated 2205 This primitive shall be generated when the Network Layer extension is ready to accept and process a new Data Link Layer payload. Copyright © 2007-2011 MIPI Alliance.40.1.ind primitive. and a value of LOST_DATA shall indicate that data was dropped.ind( L2Payload.ind primitive. 2206 Effect on Receipt 2207 Following the emission of a N_DATA_LHDR_TRAP.7 N_LM_SAP 2210 The Network Layer Management (N_LM_SAP) offers three groups of Service Primitives: Configuration primitives.rsp_L 2201 The N_DATA_LHDR_TRAP. are forwarded to the Network Layer extension.rsp_L primitive corresponding to a previously issued N_DATA_LHDR_TRAP.ind primitive.ind primitive only just after reset. therefore. 7. Long Headers cannot be interpreted in the current version of UniPro.ind primitive and prior to reception of a N _ D ATA _ L H D R _ T R A P. LhdrTrapStatus ) 2194 When Generated 2195 The primitive shall be generated when the Data Link Layer payload received from the Data Link Layer has the L3s bit set to ‘0’ indicating a Long Header. 2208 Behavioral Description 2209 The state diagram describing the behavior of the N_DATA_LHDR_TRAP. 2197 Effect on Receipt 2198 The Network Layer extension processes the Long Header Packet. and. The Data Link Layer payload shall be forwarded without modification to the Network Layer extension. The Network Layer may emit a new N_DATA_LHDR_TRAP.Version 1.8 N_DATA_LHDR_TRAP.6. MIPI Alliance Member Confidential 207 . Inc.ind primitive is shown in Figure 336 of [MIPI02]. which implements future features of UniPro. An LhdrTrapStatus value of OK shall indicate that no data has been dropped. or after reception of the N_DATA_LHDR_TRAP. 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. t h e N e t w o r k L a y e r s h a l l n o t e m i t a n e w N_DATA_LHDR_TRAP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2192 The semantics of this primitive are: 2193 N_DATA_LHDR_TRAP. 2199 Behavioral Description 2200 The state diagram describing the behavior of the N_DATA_LHDR_TRAP.

respectively.7. Table 64 Name N_LM_SAP Configuration Primitives Indication Local Response Response Local Confirm Confirm Request N_LM_GET N_LM_SET 7.Version 1. GET and SET. Table 65 Name Type N_LM_SAP Configuration Primitive Parameters Valid Range Value Description MIBattribute Integer MIBattribute values fall between 0x000 and 0xFFF.3 7. MIBvalue Variable NORMAL SetType AttrSetType STATIC 1 SUCCESS INVALID_MIB_ATTRIBUTE ConfigResultCode Enumeration INVALID_MIB_ATTRIBUTE_VALUE READ_ONLY_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE 0 1 2 3 4 Indicates the result of the request Copyright © 2007-2011 MIPI Alliance.7. 2215 The GET and SET primitives are represented as requests with associated confirm primitives.7.4 2216 The parameters used for these primitives are defined in the next table. The primitives are summarized in Table 64.1.1. This information is represented as a Network Layer-specific Management Information Base (N_MIB). These primitives are prefixed by N_LM.14 The address of the MIB Attribute The value of the MIB Attribute 0 Indicates that the Attribute is addressed. The available Network Layer Attributes are defined in Section 7.14 As defined in Section 7. The N_MIB is regarded as “contained” within the N_LM entity.7.1 Configuration Primitives 2214 The N_LM configuration primitives. MIPI Alliance Member Confidential 208 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 2211 The Configuration primitives enable access to Network Layer Attributes. 7. 2213 The Status primitives indicate status information of the Network Layer.7. are used by the DME to retrieve and store values. Indicates that the non-volatile reset value of the Attribute is addressed.40.1. Status primitives are generated by the Network Layer and can occur concurrently. Inc.1. for the configuration Attributes in the N_MIB. 2212 The Control primitives provide direct control of the Network Layer. Multiple accesses to the N_MIB via the Configuration primitives shall not occur concurrently. All rights reserved.2 7. The valid MIBattribute values are defined in Section 7.14. Control primitives are generated by the DME and can occur concurrently.1 7.

The Network Layer should not set ConfigResultCode to INVALID_MIB_ATTRIBUTE_VALUE or READ_ONLY_MIB_ATTRIBUTE. 2227 The semantics of this primitive are: 2228 N_LM_GET.req from the DME.cnf_L( ConfigResultCode.req primitive is shown in Figure 325 of [MIPI02].req( MIBattribute ) 2220 When Generated 2221 This primitive is generated by the DME to obtain the value of the Attribute identified by MIBattribute.req MIBattribute is gettable. and.1. 2222 Effect on Receipt 2223 The Network Layer entity shall attempt to retrieve the requested Attribute value and respond with N_LM_GET.cnf_L 2226 This primitive indicates the success or failure of N_LM_GET.cnf_L is undefined. Copyright © 2007-2011 MIPI Alliance. All rights reserved.cnf_L to the Attribute value. Inc.req. The Attribute indicated by MIBattribute exists.e.2 N_LM_GET.cnf_L is undefined. 7. MIPI Alliance Member Confidential 209 . MIBvalue ) 2229 The primitive parameters are defined in Table 65. 2218 The semantics of this primitive are: 2219 N_LM_GET. Table 66 ConfigResultCode N_LM_GET.cnf_L that gives the retrieved value. The Network Layer shall set MIBvalue in N_LM_GET.cnf_L primitive in response to the most recent N_LM_GET.Version 1. The value of MIBvalue in N_LM_GET.cnf_L to one of the values shown in Table 66 for the condition given in the table. the MIB Attribute indicated by N_LM_GET.40.cnf_L ConfigResultCode Values Condition SUCCESS The request succeeds. returns the Attribute value. i.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7. 2230 The Network Layer shall set ConfigResultCode in N_LM_GET. is successful. The Attribute indicated by MIBattribute is invalid or not implemented. The value of MIBvalue in N_LM_GET.req 2217 This primitive requests the value of the Attribute identified by MIBattribute.7.7. but is not gettable.1 N_LM_GET. 2224 Behavioral Description 2225 The state diagram describing the behavior of the N_LM_GET. INVALID_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE 2231 When Generated 2232 The Network Layer entity shall generate the N_LM_GET.1.

req. 2252 The Network Layer entity shall set ConfigResultCode in N_LM_SET.req( SetType. the Network Layer shall attempt to set the reset value of the Attribute addressed by MIBattribute to the MIBvalue. MIBattribute. MIPI Alliance Member Confidential 210 .1. 2238 The semantics of this primitive are: 2239 N_LM_SET. The N_LM entity should not set ConfigResultCode to WRITE_ONLY_MIB_ATTRIBUTE.cnf_L to one of the values shown in Table 67 for the conditions given in the table.cnf_L( ConfigResultCode ) 2251 The primitive parameter is defined in Table 65. i. 2235 Behavioral Description 2236 The state diagram describing the behavior of the N_LM_GET.3 N_LM_SET.cnf_L primitive is shown in Figure 325 of [MIPI02]. 2249 The semantics of this primitive are: 2250 N_LM_SET. 2241 When Generated 2242 This primitive is generated by the DME to set the value or reset value of the indicated Attribute.40. MIBvalue is undefined.cnf_L 2248 This primitive reports the results of an attempt to set the value of an Attribute or its reset value.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2233 Effect on Receipt 2234 The DME is informed about the result of the operation. the value or reset value of the Attribute indicated by MIBattribute is set to the value of MIBvalue. 2243 Effect on Receipt 2244 If SetType is set to NORMAL. the Network Layer shall attempt to set the Attribute addressed by MIBattribute to the MIBvalue.req primitive is shown in Figure 325 of [MIPI02]. MIBvalue carries the Attribute value. and in case ConfigResultCode is SUCCESS.cnf_L ConfigResultCode Values Condition SUCCESS The request succeeds.Version 1. For any other value of ConfigResultCode.7.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. 2246 Behavioral Description 2247 The state diagram describing the behavior of the N_LM_SET.4 N_LM_SET. Inc. MIBvalue ) 2240 The primitive parameters are defined in Table 65. All rights reserved. 7. Table 67 ConfigResultCode N_LM_SET.cnf_L to inform DME of the result of N_LM_SET.e. 2245 The Network Layer uses N_LM_SET. Copyright © 2007-2011 MIPI Alliance.1.7. If SetType is set to STATIC. 7.

cnf_L confirms the success or failure of the N_LM_SET.req at the Network Layer. 2255 Effect on Receipt 2256 N_LM_SET. The Attribute indicated by MIBattribute exists.7. but is not settable.2. and should have no further effects at the DME.7. 2257 Behavioral Description 2258 The state diagram describing the behavior of the N_LM_SET.7.2.7. 2260 The primitives covered in this section are listed in Table 68. This ConfigResultCode value shall only be used if SetType is NORMAL.7 7.7. the Attribute indicated by MIBattribute and SelectorIndex does not support setting its reset value.4 7.cnf_L ConfigResultCode Values (continued) Condition ConfigResultCode INVALID_MIB_ATTRIBUTE The MIBattribute value is invalid.2.2. or otherwise If SetType is STATIC. INVALID_MIB_ATTRIBUTE_VALUE but the value of MIBvalue is outside of the implemented range. 2253 When Generated 2254 The Network Layer shall generate the N_LM_SET. Table 68 Name N_LM_SAP Control Primitives Indication Local Response Response Local Confirm Confirm Request N_LM_RESET N_LM_ENABLE_LAYER N_LM_HIBERNATE_ENTER N_LM_HIBERNATE_EXIT 7.8 2261 Table 69 lists the parameters that appear in the N_LM_SAP control primitives. or outside of the valid value range.2.3 7.6 7.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 67 N_LM_SET.2 7. READ_ONLY_MIB_ATTRIBUTE The Attribute indicated by MIBattribute exists and is settable (SetType = NORMAL) or allows its reset value to be set (SetType = STATIC).7.cnf_L primitive is shown in Figure 325 of [MIPI02].7. for the Attribute.7. or otherwise the Attribute indicated by MIBattribute and SelectorIndex is not implemented.req from the DME.cnf_L primitive in response to the most recent N_LM_SET.2 Control Primitives 2259 The Service Primitives in this section are provided for controlling the Network Layer.2. 7.40.2.Version 1.5 7.1 7.2. MIPI Alliance Member Confidential 211 . Inc.7. Copyright © 2007-2011 MIPI Alliance. All rights reserved.

Version 1.40. 2270 Behavioral Description 2271 The state diagram describing the behavior of the N_LM_RESET. 2263 The semantics of this primitive are: 2264 N_LM_RESET. 2279 Behavioral Description 2280 The state diagram describing the behavior of the N_LM_RESET.cnf_L.11.req 2262 This primitive requests reset of the Network Layer.7. Copyright © 2007-2011 MIPI Alliance. The Network Layer is reset in combination with resetting of all the other UniPro layers as described in the reset procedure.2.1).2 N_LM_RESET. Then. 2267 Effect on Receipt 2268 The Network Layer sets itself to the reset states and Attribute values. and discards all N_SDUs currently processed.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 69 Name Type N_LM_SAP Control Primitive Parameters Valid Range Value Description ResetLevel Enumeration COLD WARM 0 1 Defines the reset level of the requested reset 7.req to indicate that the Network Layer came out of reset.cnf_L to the DME. the Network Layer shall not react to any Network Layer SAP primitive other than N_LM_RESET. 7. 2277 Effect on Receipt 2278 The DME is informed that the Network Layer came out of reset. 2273 The semantics of this primitive are: 2274 N_LM_RESET.7. Inc.req( ResetLevel ) 2265 When Generated 2266 This primitive is generated by the DME when it needs to reset the Network Layer.1 N_LM_RESET. MIPI Alliance Member Confidential 212 . the Network Layer shall generate N_LM_RESET.cnf_L primitive is shown in Figure 324 of [MIPI02].req primitive is shown in Figure 324 of [MIPI02].2.cnf_L 2272 The N_LM_RESET.cnf_L primitive is used during the UniPro reset procedure (see Section 9.cnf_L( ) 2275 When Generated 2276 The N_LM_RESET.cnf_L primitive is issued to the DME in response to N_LM_RESET. After issuing N_LM_RESET.req 2269 The ResetLevel COLD resets the complete Network Layer including the statistics and configuration Attributes.req and N_LM_ENABLE_LAYER. The ResetLevel WARM resets the Network Layer without the statistics. All rights reserved.

Inc.7.11.2).7.req( ) 2284 When Generated 2285 The N_LM_ENABLE_LAYER.cnf_L primitive is used during the UniPro boot procedure (see Section 9. Copyright © 2007-2011 MIPI Alliance. all Network Layer functionality and SAP primitives shall be enabled.cnf_L 2290 The N_LM_ENABLE_LAYER.cnf_L( ) 2293 When Generated 2294 The N_LM_ENABLE_LAYER.5 N_LM_HIBERNATE_ENTER.req primitive is shown in Figure 324 of [MIPI02].11.req primitive requests the Network Layer enter hibernation.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7. 7.cnf_L primitive is shown in Figure 324 of [MIPI02]. and is generated by the DME after the Network Layer came out of reset and the Data Link Layer was enabled. After issuing N_LM_ENABLE_LAYER.req primitive is part of the UniPro boot procedure (see Section 9. 2282 The semantics of this primitive are: 2283 N_LM_ENABLE_LAYER.req primitive is used during the UniPro boot procedure (see Section 9. 7.4 N_LM_ENABLE_LAYER. MIPI Alliance Member Confidential 213 .Version 1.2.req( ) 2302 When Generated 2303 The DME generates the N_LM_HIBERNATE_ENTER.cnf_L to the DME.2. All rights reserved.2.cnf_L.11. 2300 The semantics of this primitive are: 2301 N_LM_HIBERNATE_ENTER.req in response to 2299 The N_LM_HIBERNATE_ENTER.7.req primitive to request the Network Layer enter hibernation.2) to indicate to the DME that the Network Layer is enabled.cnf_L primitive is issued to the DME N_LM_ENABLE_LAYER.3 N_LM_ENABLE_LAYER. 2297 Behavioral Description 2298 The state diagram describing the behavior of the N_LM_ENABLE_LAYER. 2295 Effect on Receipt 2296 The DME is informed that the Network Layer is enabled. 2288 Behavioral Description 2289 The state diagram describing the behavior of the N_LM_ENABLE_LAYER. 2286 Effect on Receipt 2287 The Network Layer shall respond with N_LM_ENABLE_LAYER.req to indicate that the Network Layer was enabled.2).40.req 2281 The N_LM_ENABLE_LAYER. 2291 The semantics of this primitive are: 2292 N_LM_ENABLE_LAYER.

req 2317 The N_LM_HIBERNATE_EXIT.req primitive to request the Network Layer to exit hibernation. 2306 Behavioral Description 2307 The state diagram describing the behavior of the N_LM_HIBERNATE_ENTER.cnf_L primitive is generated by the Network Layer in response to a N_LM_HIBERNATE_ENTER. 2322 Effect on Receipt 2323 The Network Layer shall go to its reset state and restore the N_DeviceID and N_DeviceID_valid from their retained values. All rights reserved. 2315 Behavioral Description 2316 The state diagram describing the behavior of the N_LM_HIBERNATE_ENTER. 7.req primitive is shown in Figure 327 of [MIPI02].cnf_L 2308 The N_LM_HIBERNATE_ENTER.7.cnf_L primitive to the DME. the Network Layer shall retain N_DeviceID and N_DeviceID_valid .req( ) 2320 When Generated 2321 The DME generates the N_LM_HIBERNATE_EXIT. the Network Layer shall issue the N_LM_HIBERNATE_EXIT.cnf_L primitive is shown in Figure 327 of [MIPI02]. 7.req primitive and it indicates that the Network Layer is hibernating. 2313 Effect on Receipt 2314 The DME is informed about the Network Layer entering hibernate.req primitive is shown in Figure 327 of [MIPI02].cnf_L primitive is used to indicate that the Network Layer is about to hibernate.Version 1.cnf_L( ) 2311 When Generated 2312 The N_LM_HIBERNATE_ENTER. Inc. 2309 The semantics of this primitive are: 2310 N_LM_HIBERNATE_ENTER.2.cnf_L primitive and then enter hibernation. During hibernation.2.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2304 Effect on Receipt 2305 The Network Layer shall issue the N_LM_HIBERNATE_ENTER. Then.6 N_LM_HIBERNATE_ENTER.req primitive is used to request the Network Layer to exit hibernation and return to normal operation. MIPI Alliance Member Confidential 214 . 2324 Behavioral Description 2325 The state diagram describing the behavior of the N_LM_HIBERNATE_EXIT. Copyright © 2007-2011 MIPI Alliance. and may lose all other state information.40.7 N_LM_HIBERNATE_EXIT.7. 2318 The semantics of this primitive are: 2319 N_LM_HIBERNATE_EXIT.

Table 70 Name N_LM_SAP Status Primitives Indication Local Response Response Local Confirm Confirm Request N_LM_DISCARD 7. Table 71 Name Type N_LM_SAP Status Primitive Parameters Valid Range Value Description UNSUPPORTED_HEADER_TYPE BAD_DEVICEID_ENC 1 2 Indicates the reason for discarding a N_PDU Indicates that a Long Header Packet has been dropped because the L3 extension was not available to accept the Packet L3DiscardReasonCode Enum LHDR_TRAP_PACKET_DROPPING 3 Copyright © 2007-2011 MIPI Alliance.cnf_L 2326 The N_LM_HIBERNATE_EXIT. All rights reserved.7.Version 1.1 2337 Table 71 lists the parameters that appear in the N_LM_SAP status primitives. 2333 Behavioral Description 2334 The state diagram describing the behavior of the N_LM_HIBERNATE_EXIT.3 Status Primitives 2335 The Service Primitives in this section are provided for gathering status information of the Network Layer.40.3. MIPI Alliance Member Confidential 215 .cnf_L primitive is generated by the Network Layer in response to a N_LM_HIBERNATE_EXIT. 2331 Effect on Receipt 2332 The DME is informed about the Network Layer exiting hibernate. 2336 The primitives covered in this section are listed in Table 70.req primitive and it indicates that the Network Layer has exited hibernation and is operating normally.8 N_LM_HIBERNATE_EXIT.cnf_L primitive is shown in Figure 327 of [MIPI02].7.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7.2.cnf_L( ) 2329 When Generated 2330 The N_LM_HIBERNATE_EXIT. Inc. 2327 The semantics of this primitive are: 2328 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. 7.7.

Inc. 2342 When Generated 2343 This primitive shall be generated by the Network Layer as a result of performing the discard N_PDU feature.1 DT SH N_PDU 2351 If the L3s bit is set to ‘1’.1. 7. All rights reserved.ind( L3DiscardReasonCode ) 2341 When the N_LM_DISCARD. the N_PDU is known as DT SH N_PDU. 2339 The semantics of this primitive are: 2340 N_LM_DISCARD.9.9.4.8. 2344 Effect on Receipt 2345 The DME is notified of the cause of the discard. 2346 Behavioral Description 2347 The state diagram describing the behavior of the N_LM_DISCARD.ind 2338 This primitive indicates that the discard N_PDU feature has been performed (refer to Section 7.ind primitive is shown in Figure 326 of [MIPI02]. 2349 A Packet (N_PDU) shall contain an integral number of bytes greater than zero and shall be limited to N_MaxPacketSize.4) and reports the reason for triggering the operation. 7.8. 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. This restriction forces the Packet to always fit entirely into a DL Frame. Table 72 N_PDU Name Mnemonic User-data Network Layer PDU Types Overall Header Size Remarks/Limitations Section Data N_PDU with short L3 header DT SH N_PDU 8-bit Payload length shall be in the range from 1 to N_MTU 7.1.7.40. Copyright © 2007-2011 MIPI Alliance.1 N_LM_DISCARD.3.Version 1. MIPI Alliance Member Confidential 216 .1 Data N_PDUs 2350 Table 72 lists the Data Network Protocol Data Units (DT N_PDU) types that shall be supported.1 7.ind is generated the provided L3DiscardReasonCode shall be set according to the cases described in Section 7.8 Structure and Encoding of Network Protocol Data Units 2348 This section defines the Network Layer Protocol Data Units (usually referred to as Packets) and shows the header fields and their meaning. This information may be used to take action upon or for statistical procedures.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7.8.

2 7.1 7.8.12). Inc. N_SDU.8. .2. i.8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 7 L3s=1 6 5 4 3 2 1 0 DestDeviceID_Enc Payload – Byte 0 . 7.2 N_PDU Fields 2353 Table 73 lists the N_PDU fields.40. All rights reserved.2.2 Payload (N_SDU) 1 to N_MTU Carries the payload of a Packet bytes 7.2.1. The N_DATA_LHDR_TRAP Service Primitive carries an existing N_PDU in which the L3s bit is set to '0' (see Section 7. any integral number of data bytes.3 7. Upon reception of an N_PDU with the L3s bit set to ‘1’. Payload – Byte n-1 (n <= N_MTU) Figure 70 Network Layer Data N_PDU with Short Header (DT SH N_PDU) 2352 The natural DT SH N_PDU granularity is bytes. .ind (see Section 7.ind (see Section 7. Copyright © 2007-2011 MIPI Alliance. The N_DATA_SHDR Service Primitive shall set the L3s header field to ‘1’. value also encodes parts of L4 DestPeerCPortID. the N_PDU is processed by the Network Layer and the payload forwarded to Transport Layer via N_DATA_SHDR.e.1 L3 Header Type Field (L3s) 2354 The L3s header field serves as a header type bit. A received N_PDU with L3s set to '0' is forwarded unmodified to the Network Layer extension via N_DATA_LHDR_TRAP. MIPI Alliance Member Confidential 217 .11.6. in the range from 1 to N_MTU can be transferred. Table 73 Field Name Network Layer N_PDU Header Fields Field Size Remarks/Limitations Section Field Description L3s DestDeviceID_Enc L3 Header type field Address identifying the destination of a Packet User-data (Network Service Data Unit) 1-bit 7-bit Identifies the N_PDU Note.8.2. The value is determined by the Service Primitive used. refer to Section 8.Version 1.12). i. 2355 Table 74 shows the supported settings.3).e.8.

2 Destination Device ID 2356 The DestDeviceID_Enc field shall encode the DestPeerDeviceID and DeviceIDOffset parameters provided via the N_DATA_SHDR.2. MIPI Alliance Member Confidential 218 . The encoding shall follow the formula below: 2357 DestDeviceID_Enc = DestPeerDeviceID + DestDeviceIDOffset 2358 Any integral number in the range from 0 to N_MaxDeviceID shall be supported.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 74 Field Name Size Value Settings of the L3s Field Meaning Remarks 0 L3s 1-bit Long Header Data N_PDU is used The Long Header Data N_PDU will be defined in a future version of UniPro.req primitive.8. All rights reserved.8. 2359 Table 75 shows the supported settings. Copyright © 2007-2011 MIPI Alliance.8.3 Payload – Network Service Data Unit 2360 The N_SDU field carries the payload data given by the Service User and can therefore carry any value.3 Relationship of N_PDU Type Selection and Service Primitive Usage 2361 The correct N_PDU type for transmission and upon reception shall be determined by the association in Table 77. Table 76 Field Name Size Value Settings of the Payload Field Meaning Remarks Payload 1 to N_MTU bytes Any byte string Payload Size depends on the configured maximum payload size of the sending N_TCx entity (N_TCxTxMaxSDUSize) 7. Currently.12). Table 75 Field Name Size Settings of the DestDeviceID_Enc Field Value Meaning Remarks DestDeviceID_Enc 7-bit 0 to N_MaxDeviceID Encoded DeviceID value of targeted Device 7.Version 1.2.40. Inc. 1 Short Header Data N_PDU (DT SH Caused by N_DATA_SHDR N_PDU) is used primitive use 7. N_PDUs with L3=0 are received from or forwarded to the Network Layer extension via the Long Header Trap (see Section 7.

The decomposition feature extracts header information of received Packets and uses additionally layer-specific local state information to form the Protocol Control Information. Protocol Control Information (PCI) Passed via Service Primitives from Service User (L4) Obtained from L3 local information Served L3 header construction Transport Layer (L4) N_TCx SAP Network Layer (L3) T_PDU PCI N_SDU Composition Process N_PDU Figure 71 Network Layer Composition Process Data Unit = Segment Data Unit = Packet 7.9. this feature constructs and adds a L3 header to the provided N_SDU to form an N_PDU.1 Protocol Features N_PDU Composition Feature 2362 This feature is responsible for the composition of Network Protocol Data Units (N_PDUs). called Protocol Control Information (PCI). All rights reserved. For the construction of the N_PDU additional control information is needed. Copyright © 2007-2011 MIPI Alliance.9.40.8. The PCI is obtained from local layer-specific state information and parameters given by means of Service Primitive requests.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 77 Used Service Primitive Service Primitive to N_PDU Association Table Remarks Selected N_PDU Type N_DATA_SHDR DT SH N_PDU Data Short Header Network Protocol Data Unit 7. MIPI Alliance Member Confidential 219 .Version 1. Inc. As depicted in Figure 71.9 7.2.2 N_PDU Decomposition Feature 2364 This feature is responsible for the decomposition of the N_PDUs. 2363 The state diagram describing the behavior of the N_PDU Composition Feature is shown in the L3_TC_tx SDL process of [MIPI02]. The header consists of different fields specified in Section 7.

An N_PDU with L3s=0 is forwarded unmodified to the Layer 3 extension as described in Section 7.3 Header Format Analysis Feature 2368 The feature shall determine the incoming N_PDU type and shall perform decoding of the DestDeviceID_Enc field.Version 1. the Network Layer shall perform all actions necessary to free up any resources used for the particular affected process. All rights reserved. 2367 The state diagram describing the behavior of the N_PDU Decomposition Feature is shown in the L3_TC_rx SDL process of [MIPI02]. either N_DATA_SHDR.9.12. The fields of an N_PDU with L3s=1 are extracted as described in Section 7.2. the DeviceIDOffset parameter shall be computed from the DestDeviceID_Enc field specified by the following formula: DeviceIDOffset = DestDeviceID_Enc – N_DeviceID If N_DeviceID_valid is set to FALSE. the DeviceIDOffset parameter shall be set to ‘0’.00 31-Jan-2011 MIPI Alliance Specification for UniPro Protocol Control Information (PCI) Derived from decoded L3 header Passed via Service Primitives to Service User (L4) Potentially checked against L3 local information Transport Layer (L4) N_TCx SAP Network Layer (L3) T_PDU PCI N_SDU Decomposition Process N_PDU Figure 72 Network Layer Decomposition Process Data Unit = Segment Data Unit = Packet 2365 The user-data is obtained from the N_SDU field.4 Discard N_PDU Feature 2374 In case of any occurrences of the situations listed in Table 78.8.40.ind (L3s =0).ind (L3s = 1) or N_DATA_LHDR_TRAP. 7. the Header Format Analysis feature is used.ind primitive.9. Copyright © 2007-2011 MIPI Alliance. 2366 For the construction of the PCI. MIPI Alliance Member Confidential 220 . The state diagram describing the behavior of the discard N_PDU feature is shown in the L3_TC_rx SDL process of [MIPI02]. The user-data and parts of the PCI shall be provided to the Network Service User by means of the appropriate Service Primitive indications. 2373 The resulting value of DeviceIDOffset shall be provided to the Transport Layer via the N_DATA_SHDR. 7. and the N_PDU is processed as follows: 2370 2371 2372 If N_DeviceID_valid is set to TRUE. Inc. 2369 The N_PDU type is determined by the L3s field and identifies the appropriate Service Primitive indication to call.

If N_DeviceID_valid is FALSE.2 • • • The type of the N_PDU shall be recovered The present header fields shall be recovered The DeviceIDOffset shall be decoded according to the formula given in Section 7.9. whose Currently. otherwise it shall be discarded.6. All rights reserved.11 2383 • 2384 2385 2386 2387 2388 • Packet Reception 2382 Upon the reception of a Packet the following operations shall be performed in the following order: The received N_PDU shall be decomposed by means of the N_PDU decomposition feature involving the header format analysis feature and in accordance to Section 7.2 • • The present header fields shall be computed and shall be set accordingly The Payload field shall be filled with the given user-data 2381 The state diagram describing these behaviors is shown in the L3_TC_tx SDL process of [MIPI02].00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 78 ReasonCode Discard N_PDU ReasonCode Description Description Example UNSUPPORTED_HEADER_TYPE A N_PDU was received.9.40.3 The selected N_PDU shall be composed by means of the N_PDU composition feature and in accordance to the encoding rules defined in Section 7.8. this ReasonCode is header contains unsupported unused in Layer 3 values N_DeviceID_valid is set.3 2389 • • The user-data shall be obtained from the Payload field If N_DeviceID_valid is TRUE. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 221 .4 the Discard N_PDU feature shall be performed. and either an N_PDU was received with a DestDeviceID_Enc less than N_DeviceID or the computed DeviceIDOffset is greater than N_MaxDeviceIDOffset Indicates that a Long Header Packet has been dropped because the L3 extension was not available to accept the Packet A N_PDU with DestDeviceID_Enc set to ‘0’ is received by a Device with N_Device_ID set to ‘1’ and N_Device_ID_valid set to TRUE BAD_DEVICEID_ENC LHDR_TRAP_PACKET_DROPPING 7. The user-data shall be indicated to the Network Service User by means of the corresponding Service Primitives according to Section 7. Inc.1 and with accordingly set parameters. 7. 2376 For the transmission of Packets the following operations shall be performed in the order listed below: 2377 • 2378 • 2379 2380 The correct N_PDU type shall be determined according to the rules defined in Section 7. If the DestDeviceID_Enc is greater than or equal to N_DeviceID. the Packet shall be accepted.8.Version 1. the DestDeviceID_Enc shall be checked against the N_DeviceID to ensure that the Packet arrived at the correct destination.8.10 Packet Transmission 2375 A source Device shall transmit N_SDUs in the order in which they arrived at the local TCx N_SAP. 2390 Upon any exception listed in Section 7. this check is not performed.

in software.rsp_L from the Layer 3 extension. MIPI Alliance Member Confidential 222 . or to its Reset Value otherwise. That is. any incoming Short Header Packet.. if one exists. the process shall guarantee Short Header progress. shall be processed immediately. 2395 When the Long Header Trap receiver (see SDL process L3_TC_rx) receives a L2 payload from Layer 2 with the L3s bit set to ‘0’. i. UniPro provides support for Layer 3 short headers. The Long Header Trap is a feature that allows a UniPro implementation to be extended.req results in the generation of a corresponding Data Link Layerspecific DL_DATA. i. the N_LM_DISCARD. 2393 The Long Header Trap transmitter (see SDL process L3_TC_tx) forwards Packets from the Layer 3 extension to Layer 2 without modification.13 Network Layer and Data Link Layer Interaction 2398 The generation of a N_DATA_SHDR.e. Inc. 2396 The flow of incoming Short Header Packets shall not be affected by the Long Header Trap. 7..12 Long Header Trap 2392 Currently. 2394 The arbitration process between Short Header Packets and Long Header Packets is unspecified. in case: 2402 • 2403 • The Packet processing for reception has been performed successfully The discard N_PDU feature has not been performed 7. 7.g.req by the accordant Network Layer TCx Entity.ind primitive is issued with L3DiscardCode equal to LHDR_TRAP_PACKET_DROPPING. 2405 Table 80 lists the Protocol Constants used by the protocol specification and defines valid values for the Attributes. shall be either dropped or stored outside the Short Header Packet processing path.. TC0 or TC1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2391 The state diagram describing these behaviors is shown in the L3_TC_rx SDL process of [MIPI02]. See Section 9 for more details. i. it shall forward the unmodified L2 payload to the Layer 3 extension. However. and shall conform to the Layer 3 Long Header Packet format as defined in future versions of UniPro.40. Copyright © 2007-2011 MIPI Alliance.e. in case: 2399 • 2400 • The Packet processing for transmission has been performed successfully The Service Primitives are called correctly. A Packet received from a Layer 3 extension shall have the L3s bit set to ‘0’. All rights reserved. with L3s bit set to ‘0’. Layer 3 Long Header support will be added. the parameters are in the defined valid range 2401 The receipt of a Data Link Layer-specific DL_DATA. 2408 At reset. to generate an N_DATA_SHDR.ind associated with delivery of a data unit shall cause the involved Network Layer TCx Entity. to support future Layer 3 Long Header Packets and the features based on them. 2406 All Network Layer Attributes should be readable. if Layer 3 waits for the N_DATA_LHDR_TRAP. i.Version 1. a settable Attribute shall be reset to its corresponding static value. e. In future releases.ind. 2407 The Network Layer AttributeID and Protocol constants are defined as shown in the L3_Attributes package of [MIPI02]. Any incoming Long Header Packet.14 Management Information Base and Protocol Constants 2404 Table 79 and Table 81 show the Network Layer Attributes. 2397 The state diagram describing these behaviors is shown in the L3_TC_rx SDL process of [MIPI02]. such as Configuration. When a Long Header Packet is dropped.e.e. with L3s bit set to ‘1’. The Long Header Trap will be discontinued when Layer 3 Long Header support is added to the UniPro specification.

00 31-Jan-2011 Table 79 Attribute Attribute ID Description Network Layer (gettable.9..9. FALSE=0 FALSE MIPI Alliance Specification for UniPro Table 80 Attribute Description Network Layer Protocol Constants Type Unit Value Notes N_MaxPacketSize N_MaxHdrSize N_MTU N_MaxDeviceIDOffset N_MaxDeviceID Maximum Packet Size (PDU size) Maximum L3 header size Network Layer Maximum Transfer Unit Maximum DeviceID offset Maximum DeviceID Integer Integer Integer Integer Integer Byte Byte Byte N_MTU + N_MaxHdrSize 1 T_MaxSegmentSize 63 127 .9.3 and Section 7. All rights reserved. Copyright © 2007-2011 MIPI Alliance..3 and Section 7. settable) Attributes Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Notes N_DeviceID 0x3000 Local DeviceID used for checking the DestDeviceID_Enc field in the Network Layer Header (see Section 7.40.9. Specifies whether N_DeviceID Attribute value is valid. and turns on the checking of the DestDeviceID_Enc field in the Network Layer Header (see Section 7.4 for more details). Inc. This Attribute is retained during hibernation.4 for more details). MIPI Alliance Member Confidential 223 Integer 0 to N_MaxDeviceID 0 N_DeviceID_valid 0x3001 Boolean TRUE=1. This Attribute is retained during hibernation.Version 1.

Integer Integer Byte Byte 1 to N_MTU 1 to N_MTU Copyright © 2007-2011 MIPI Alliance.40. The value of N_TC0TxMaxSDUSize should not exceed (DL_TC0TxMaxSDUSize – N_MaxHdr_size). MIPI Alliance Member Confidential 224 1. The value of N_TC1TxMaxSDUSize should not exceed (DL_TC1TxMaxSDUSize – N_MaxHdr_size). Maximum transmit payload (SDU) size per Packet for TC1. MIPI Alliance Specification for UniPro . All rights reserved. Inc. static) Attributes Description Type Unit Valid Attribute Value(s) N_TC0TxMaxSDUSize1 N_TC1TxMaxSDUSize 2 0x3020 0x3021 Maximum transmit payload (SDU) size per Packet for TC0.Version 1.00 31-Jan-2011 Table 81 Attribute Attribute ID Network Layer (gettable. 2.

Copyright © 2007-2011 MIPI Alliance. 8.Version 1. 2410 Figure 73 shows the SAP model used for the Transport Layer. The Transport Layer in turn relies on the service provided by the N_TCx_SAP.2 Transport Layer Addressing 2420 This section defines the abstract syntax and semantics of the Transport address. 2412 2413 2414 2415 2416 2417 2418 • • • • • • • Addressing Segmentation and Reassembly Segment Composition and Segment Decomposition Segment format recognition Connections End-to-End flow-control Error handling 2419 The Transport Layer shall not limit the user-data with regard to its content and its representation. All rights reserved. The Transport service to the Application Layer is provided by means of the Transport Layer Connection-oriented Service Access Point (T_CO_SAP). The Transport Layer Management SAP (T_LM_SAP) is provided to the Device Management Entity (DME) for configuration and control purposes.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8 Transport Layer (L4) 2409 This section defines the service provided by the Transport Layer. Inc. its protocol behavior and the Transport Protocol Data Units (T_PDUs) used by the Transport Layer (TL). MIPI Alliance Member Confidential 225 . Application Layer (LA) T_CO SAP a T_CO SAP b Management Plane Device Management Entity (DME) T_LM SAP Data Plane T_Core Entity T_LM Entity T_MIB Transport Layer (L4) Figure 73 Transport Layer SAP Model 8. It aims to provide as much implementation flexibility as possible given the restrictions needed to achieve a high degree of interoperability.1 Transport Layer Service Functionality and Features 2411 The Transport Layer shall provide the following features and services for the transfer of user-data between Transport Layer users.40.

for example. but the association is made on a per-connection basis. the T_PeerDeviceID and T_PeerCPortID. 2425 Data is passed between the Transport Layer and its users by means of Transport Service Data Units (T_SDUs) qualified by certain parameters via SAPs by means of Service Primitives. logical communication channel between two CPorts. and parameters identifying the peer CPort.2.00 31-Jan-2011 MIPI Alliance Specification for UniPro Application Layer (LA) App Application Application Application App T_CO SAP[0] T_CO SAP[1] T_CO SAP[3] T_CO SAP[9] T_CO SAP[5] T_CO SAP[10] T_CO SAP[11] T_CO SAP[13] T_CO SAP[25] T_CO SAP[31] T_Core Entity Transport Layer (L4) N_TC0 SAP N_TC1 SAP TC0 Entity Network Layer (L3) TC1 Entity Figure 74 T_SAPs. Traffic Class and End-to-End Flow-control. qualify Connections with various properties such as QoS information. This is because each destination 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*321 (with x = 1 to 64). MIPI Alliance Member Confidential 226 .Version 1. Transport Address and CPortID 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. Each Connection owns a set of certain properties qualifying different service characteristics.g. this will reduce the maximum number of addressable Devices by three units. 2422 Note: 2423 CPortID values above 31 should only be used if necessary. A CPort is not bound to a single Traffic Class. The corresponding address translation process is described in Section 8. 8. For example.40. the number of available Network Layer Device addresses is reduced by x-1. 2428 The transport is performed by means of Transport Protocol Data Units (T_PDUs). All rights reserved.3 Connection-oriented (CO) Data Communication 2424 Connections in UniPro are used to distinguish data streams to. The CPortID number (‘x’ in the SAP notation) shall range from 0 to T_MaxCPortID (defined in Table 108). which are also referred to as Segments. defined later on. if a Device uses CPortID values up to 100 (implying x = 4). e.11. A CPort shall not be able to support multiple simultaneous Connections. 2427 A Connection describes a bidirectional. Copyright © 2007-2011 MIPI Alliance. respectively between two CPorts Users (see Figure 75).g. e. Inc. 2426 The Transport Service provides and maintains Connections for the data transmission between two CPorts.

The Transport Layer supports T_SDUs of arbitrary length. 8.5 End-to-End Flow Control (E2E FC) 2434 The E2E FC feature is intended to regulate the flow of T_PDUs independently of the flow control of other layers. 2436 The Transport Layer also assumes that the underlying Data Link Layer provides link-level flow control. 2431 It is assumed by the Transport Layer that Segments. are used by the CPort Users to communicate. MIPI Alliance Member Confidential 227 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Device 1 User A User B Service User Device 2 User X User Y T_CO SAP a T_CO SAP b Transport Service Transport Layer (L4) Service Provider T_CO SAP x T_CO SAP y CPort CPort CPort CPort Connection between User A and User X Connection between User B and User Y Figure 75 Concept of a Transport-level Connection 8. but can be disabled after reset on a per-Connection basis. T_SDUs. Inc. 2435 It is assumed by the Transport Layer that the underlying services provide reliable link-level data transmission. Due to payload length. 2433 The state diagram describing the reassembly behavior is shown in the L4_CPort_rx SDL processes of [MIPI02]. 2430 The maximum payload a Segment can carry is referred to as Transport Layer Maximum Transfer Unit (T_MTU) and is defined in Table 108. 2432 The state diagram describing the segmentation behavior is shown in the L4_CPort_tx SDL processes of [MIPI02].4 Segmentation and Reassembly 2429 In UniPro.Version 1. For controlling the reassembly process at the receiving side.40. which are carried by means of L3 Packets. For that reason. This E2E Flow Control is intended to prevent Copyright © 2007-2011 MIPI Alliance. An additional configurable End-to-End Flow Control (E2E FC) mechanism shall be provided and enabled upon reset. segmenting of T_SDUs into T_PDUs and reassembling of T_PDUs into T_SDUs shall be supported. All rights reserved. an End-Of-Message (EOM) indication bit is carried within every T_PDU. multiple T_PDUs may be needed to carry one T_SDU from peer-to-peer over a Connection. belonging to the same Traffic Class and going to the same Device are not re-ordered. also referred to as Messages. The maximum Segment size (T_MaxSegmentSize) is defined in Table 108.

Instead. The user may transmit a zero size Message Fragment if the EOM is set to TRUE. the data transmission and reception. T_CO_SAP primitives have undefined behavior. Copyright © 2007-2011 MIPI Alliance.7 Limitations and Compatibility Issues 2442 Conceptually.1 Data Transfer Primitives 2450 The primitives covered in this section are listed in Table 82. in either direction or in both directions simultaneously on a Connection. The E2E FC can also prevent certain types of deadlock situations. 2448 Prior to any data-transmission between two users. either during initial configuration using the DME or at design-time. 2438 The Transport Layer requires the following services and properties provided by the Network and lower layers: 2439 • 2440 • Reliable data transmission In-order delivery of data belonging to the same Traffic Class 2441 Data transmission and reception by means of Segments are supported by the exchange of requests and indications between the Transport Layer and the Network Layer.11. These parameters and indications allow the Transport Layer to control.1.6.8 T_CO_SAP 2444 The T_CO_SAPs provide the services for basic data transmission. The N_SAP is defined in Section 7. a CPort User may still communicate using full messages by providing the whole Message to the T_CO_DATA. 2446 Even though the T_CO_SAP allows the transfer of Message Fragments. the Transport Layer supports T_SDUs (Messages) of arbitrary length. 2445 The data transfer Service Primitives shall be used to transfer user-data called Transport Service Data Units (T_SDUs) or Messages. Inc. 8.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro interactions between Connections due to congestion caused by shared L2 resources. The user shall not transmit a zero size Message Fragment if the EOM is set to FALSE. the Transport Layer may transmit a T_PDU with zero length payload to transmit a FCT token or an EOM. 2449 T_CO_SAP primitives shall not be called when the UniPro stack is in Hibernate. a Connection needs to be opened as described in Section 8. the order and the boundaries of the T_SDUs passed through the T_CO_SAP.8. Note that internally. 8. While the UniPro stack is in Hibernate. MIPI Alliance Member Confidential 228 .40.11. The Transport Service shall preserve the content. 2443 In the current version of UniPro a standardized Connection management protocol is not provided. A receiver shall be able to correctly process zero length payload Segments. The DME-based Connection configuration is described in Section 8. 8. Connections shall be statically opened by setting CPort Attributes.req and setting the EOM to TRUE. All rights reserved. There is no guarantee that the received Message Fragment boundaries are the same as the transmitted Message Fragment boundaries. and be informed of. The T_CO_SAP offers primitives to transfer Message Fragments.6 Services Assumed from the Network Layer 2437 The Network Layer provides its services to the Transport Layer via the N_SAP (refer to Figure 74). also known as Head of Line blocking (HOL). 8.1. The user may transmit a zero size Message. 2447 Data transmission is supported by flow-control services governing the exchange of Segments either locally or in an end-to-end manner.

Table 83 Name Type T_CO_SAP Primitive Parameters Valid Range Value Description Message Fragment byte string Any byte string One or more bytes specifying the data passing the T_CO_SAP before transmission or after reception 0 1 Indicates a correct Message Fragment Indicates that the Message Fragment is incomplete Indicates that data dropping due to CSD and/or CSV preceded the Message Fragment Indicates that the Message Fragment is incomplete and data dropping preceded the Message Fragment Indicates no end of Message at the end of the Message Fragment Indicates that the end of the Message Fragment is a Message boundary Indicates the Message Fragment is not the first Fragment of Message Indicates the Message Fragment is the first fragment of Message Specifies the amount of data in bytes the particular Transport Layer SAP (CPort) is permitted to pass Returns the number of accepted Credits FRAGMENT_CORRECT FRAGMENT_CORRUPT FragmentStatus Enum FRAGMENT_AFTER_GA P 2 FRAGMENT_CORRUPT_ AFTER_GAP 3 FALSE EOM Bool TRUE 0 1 FALSE SOM Bool TRUE 0 1 Credits Integer 1 to T_MaxE2EFCCredits CreditsAccepted Integer 0 to T_MaxE2EFCCredits Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 229 .4 8.1. 2453 Table 83 lists the parameters that appear in the T_CO_SAP primitives.8.5 8.8.2 8.1.8.1.1.1. Inc.Version 1.8. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 82 Name Request T_CO_SAP Primitives Indication Local Response Response Local Confirm Confirm T_CO_DATA T_CO_FLOWCONTROL 8.1 8.3 8.6 2451 Note: 2452 The identifier “CO” in the primitives describes the Connection-oriented service type.1.8.40.8.

the L4CPortResultCode shall be INVALID_FRAGMENT.40.2 T_CO_DATA.Version 1. Inc.cnf_L( L4CPortResultCode ) 2466 When Generated 2467 This primitive shall be generated by the CPort as a result of a T_CO_DATA.req. in which case the Message Fragment shall not be transmitted.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 83 Name Type T_CO_SAP Primitive Parameters (continued) Valid Range Value Description SUCCESS NO_CONNECTION L4CPortResultCode Enum CREDITS_EXCEEDED NO_CPORT NO_PEER_TC INVALID_FRAGMENT 0 1 2 3 6 7 Indicates the result of the request 8. If the Message Fragment provided with T_CO_DATA. All other L4CPortResultCode values should indicate a failure.req has a size of zero and the EOM flag is set to FALSE. In the absence of a Connection.8.req( MessageFragment. and shall be set to FALSE otherwise. The Message Fragment may have any positive size. A Message Fragment may have a zero size only if EOM is set to TRUE. 2459 Effect on Receipt 2460 The instructed CPort shall transmit the given Message Fragment on the associated Connection. MIPI Alliance Member Confidential 230 . EOM) 2457 When Generated 2458 The CPort User generates a T_CO_DATA. 2461 Behavioral Description 2462 The state diagram describing the behavior of the T_CO_DATA. 2455 The semantics of this primitive are: 2456 T_CO_DATA.8. 8.req primitive to send a Message Fragment via the associated Connection.req 2454 This primitive requests the transfer of a Message Fragment to a peer CPort via the associated Connection.req succeeds the returned L4CPortResultCode shall be SUCCESS.1. An attempted transmission is interpreted as the successful or unsuccessful service usage of the underlying layer. 2464 The semantics of this primitive are: 2465 T_CO_DATA.cnf_L 2463 This primitive reports the result of a Message Fragment transfer attempt to a specified recipient. The confirmation indicates the success or failure of an attempted transmission. 2468 When the T_CO_DATA.req primitive is shown in the L4_CPort_tx SDL process of [MIPI02]. Copyright © 2007-2011 MIPI Alliance.1 T_CO_DATA. the L4CPortResultCode shall be NO_CONNECTION.1. The EOM parameter shall be set to TRUE when the Message Fragment is the last Fragment of the Message. All rights reserved.

The Transport Layer learns about the peer Device not implementing the TCx Traffic Class when it receives N_DATA_SHDR. FragmentStatus shall be set to FRAGMENT_CORRUPT_AFTER_GAP. 2476 The semantics of this primitive are: 2477 T_CO_DATA. FragmentStatus shall be set to FRAGMENT_CORRECT. Inc. 2473 Behavioral Description 2474 The state diagram describing the behavior of the T_CO_DATA. the value of the L4CPortResultCode shall be NO_PEER_TC.req.8. If the a complete Message Fragment is delivered. 2472 The CPort User may emit a new T_CO_DATA.3 T_CO_DATA. The SOM shall be set to TRUE if the Message Fragment is the first Fragment of the Message. EOM. and data has been dropped between the last and the current Message Fragment.11.2). 2481 Typically. If none of the above errors has occurred. All rights reserved. Copyright © 2007-2011 MIPI Alliance.req primitive.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2469 If the peer Device does not implement the TCx Traffic Class.ind 2475 This primitive reports the reception of a complete or incomplete Message Fragment.req primitive immediately following a reset or after the reception of the T_CO_DATA.cnf_L primitive. On a given T_CO_SAP.ind may be different in size compared to the transmitted Message Fragments or the received Segments. FragmentStatus shall be set to FRAGMENT_AFTER_GAP. 8.req primitive on this T_CO_SAP. and shall be set to FALSE otherwise. FragmentStatus indicates an error when parts of the data inside and/or before Message Fragment were discarded due to the CPort Safety Valve feature (Section 8. only indicate data dropping in between Message Fragments.cnf_L with L3ResultCode set to NO_PEER_TC. but data was not dropped between the last and the current Message Fragments. The Message Fragments delivered using T_CO_DATA. thus.ind primitive shall be generated by the affected CPort to deliver to the Transport user Message Fragment resulting from data received at that CPort by means of a Connection. 2480 If an incomplete Message Fragment is delivered. and data was dropped between the last and the current Message Fragment.11. instead this has to be determined by the associated Connection. and shall be set to FALSE otherwise.40.cnf_L primitive is shown in the L4_CPort_tx SDL process of [MIPI02].cnf_L primitive corresponding to a previously emitted T_CO_DATA. SOM. 2482 Note: 2483 An implementation should only deliver complete Messages Fragments and. If an incomplete Message Fragment is delivered.8. MIPI Alliance Member Confidential 231 .ind( MessageFragment. following the emission of a T_CO_DATA. FragmentStatus shall be set to FRAGMENT_CORRUPT.Version 1.1.cnf_L or N_DATA_LHDR_TRAP. The EOM shall be set to TRUE if the Message Fragment is the last Fragment of the Message.9) or by the Controlled Segment Dropping feature (Section 8. FragmentStatus ) 2478 When Generated 2479 The T_CO_DATA.req primitive and prior to the reception of a T_CO_DATA. No sender is identified by the indication. 2470 Effect on Receipt 2471 The Transport user is notified of the results of the attempt by the CPort to transfer a Message Fragment provided with the most recent T_CO_DATA. the CPort User shall not emit a new T_CO_DATA.

following the emission of a T_CO_DATA.E2EFC is '0' and T_CPortFlags.1. 2498 The semantics of this primitive are: 2499 T_CO_FLOWCONTROL. and T_LocalBufferSpace shall be set to T_MaxE2EFCCredits. If by adding Credits T_LocalBufferSpace would exceed T_MaxE2EFCCredits.ind primitive and prior to the reception of a T_CO_DATA. the CPort User shall issue the T_CO_FLOWCONTROL.E2EFC is '1'.rsp_L primitive. 2486 Behavioral Description 2487 The state diagram describing the behavior of the T_CO_DATA. 2493 Effect on Receipt 2494 On a given T_CO_SAP.E2EFC is '0' and T_CPortFlags.req is not necessary. the CPort shall not emit a new T_CO_DATA.40.1.5 T_CO_FLOWCONTROL.rsp_L 2488 This primitive informs the CPort that the CPort User is ready to accept a new T_CO_DATA. Inc.ind on that SAP. 2495 Behavioral Description 2496 The state diagram describing the behavior of the T_CO_DATA. the CPort shall increment T_LocalBufferSpace with the value of Credits supplied by T_CO_FLOWCONTROL. The CPort may emit a T_CO_DATA.4 T_CO_DATA. the amount of accepted credits (CreditsAccepted) shall be set to (T_MaxE2EFCCredits – T_LocalBufferSpace) when issuing the T_CO_FLOWCONTROL. 8.req.ind primitive is shown in the L4_CPort_rx SDL process of [MIPI02]. MIPI Alliance Member Confidential 232 . 8.CSD_n is '0'.req 2497 This primitive is the service request primitive for the Connection flow control service.req primitive. All rights reserved. 2489 The semantics of this primitive are: 2490 T_CO_DATA.Version 1.req primitive to the CPort to request control of the flow of user-data associated with a Connection from the Transport Layer.cnf_L primitive. When T_CPortFlags.8.rsp_L primitive corresponding to a previously emitted T_CO_DATA.8. the use of T_CO_FLOWCONTROL. the CPort User shall consume the Message Fragment. 2502 Effect on Receipt 2503 When receiving the T_CO_FLOWCONTROL. or T_CPortFlags.rsp_L( ) 2491 When Generated 2492 This primitive shall be generated when the CPort User can accept and process a new T_PDU. The maximum value of T_LocalBufferSpace is limited to T_MaxE2EFCCredits.rsp_L primitive is shown in the L4_CPort_rx SDL process of [MIPI02].8.ind primitive. When T_CPortFlags.req( Credits ) 2500 When Generated 2501 The CPort User sends a T_CO_FLOWCONTROL.11.CSD_n is '1'. or after the reception of a T_CO_DATA. Refer to Section 8. Copyright © 2007-2011 MIPI Alliance.req to signal its ability to consume more data.ind primitive on a SAP only just after reset.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2484 Effect on Receipt 2485 Upon reception of a T_CO_DATA.ind primitive.ind primitive.

2517 When the T_CO_FLOWCONTROL. It confirms the completion of a T_CO_FLOWCONTROL.cnf_L( CreditsAccepted. the given Credits are recognized and the sending of corresponding FCTs is scheduled.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. The CPort User shall ensure that the Credits given represent less than or equal the amount of data the user can accept and that the amount of Credits shall not exceed T_MaxE2EFCCredits. 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. see Table 107) shall be tracked. T_CPortFlags. the number of outstanding Credits to be sent (T_CreditsToSend.cnf_L 2512 This primitive is the service confirm primitive for the Connection flow control service. L4CPortResultCode ) 2515 When Generated 2516 This primitive shall be generated by the CPort as a result of a T_CO_FLOWCONTROL. When E2E FC is enabled. and shall be decremented by T_TxTokenValue each time a FCT is sent.e. 8. MIPI Alliance Member Confidential 233 .E2EFC equals ‘1’. 2518 Effect on Receipt 2519 The Transport user is notified of the results of the service request completion. 2513 The semantics of this primitive are: 2514 T_CO_FLOWCONTROL. the T_CO_FLOWCONTROL.req. the T_CreditsToSend counter shall be incremented by the value in the parameter Credits. see Table 108). Inc. while only one FCT can be signaled to the peer CPort at a time.1). All other values of L4CPortResultCode should indicate a failure.req. All rights reserved. This does not necessarily mean that the transmission of FCT(s) to a peer CPort was successfully completed. 2510 Behavioral Description 2511 The state diagram describing the behavior of the T_CO_FLOWCONTROL.e.40.req primitive is shown in Figure 372 of [MIPI02].6 T_CO_FLOWCONTROL.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2504 In case the end-to-end flow control feature is enabled for the particular Connection. limited to the maximum number of E2E FC Credits (T_MaxE2EFCCredits.1. i.10. In case the maximum number of Credits is exceeded the L4CPortResultCode shall be CREDITS_EXCEEDED and the value of CreditsAccepted shall be set to the number of Credits that have been accepted by the Transport Layer. which is defined per Connection and per direction (T_TxTokenValue. Copyright © 2007-2011 MIPI Alliance. In the absence of a Connection the L4CPortResultCode of the confirm Service Primitive shall be NO_CONNECTION. 2505 One FCT corresponds to a specific number of Credits in bytes.cnf_L primitive. T_TxTokenValue is used for calculating the amount of FCTs to be sent to the connected peer CPort. see Table 107). T_RxTokenValue.req and indicates success or failure of the local operation.req succeeds the returned L4CPortResultCode shall be SUCCESS and the value of CreditsAccepted should carry the value of the corresponding T_CO_FLOWCONTROL. 2507 The request is locally completed with a T_CO_FLOWCONTROL. i.Version 1. 2506 Since the primitive can accept more Credits than one Token is worth.8. 2508 Additional Comments 2509 Control of the flow of data on a Connection is independent of control of the flow on other Connections.

1.Version 1. All rights reserved.4 2528 The parameters used for these primitives are defined in Table 85.9 T_LM_SAP 2522 The Transport Layer Management (T_LM) SAP offers three groups of Service Primitives: Configuration primitives. Status primitives are generated by the Transport Layer and can occur concurrently. 8.17 As defined in Section 8. Table 84 Name T_LM_SAP Configuration Primitives Indication Local Response Response Local Confirm Confirm Request T_LM_GET T_LM_SET 8.9. 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. 2525 The Status primitives indicate status information of the Transport Layer. 8. The invocation of a SET. The valid MIBattribute values are defined in Section 8. GET and SET.9. respectively.2 8. These primitives are prefixed by T_LM.9.req primitive may require the Transport Layer to perform certain defined actions.1 8.9.17. Table 85 Name Type T_LM_SAP Configuration Primitive Parameters Valid Range Value Description MIBattribute Integer defined by MIBattribute MIBattribute values fall between 0x000 and 0xFFF. 2524 The Control primitives provide direct control of the Transport Layer.17 The address of the MIB Attribute The value of the MIB Attribute Indicates the targeted CPort or Test Feature when relevant MIBvalue SelectorIndex Integer 0 to T_NumCPorts – 1 Copyright © 2007-2011 MIPI Alliance.40. for the Transport Layer Attributes. MIPI Alliance Member Confidential 234 .3 8. are used by the DME to retrieve and store values. The primitives are summarized in Table 84. Control primitives are generated by the DME and can occur concurrently.1. Inc. 2527 The GET and SET primitives are represented as requests with associated confirm primitives.1.1 Configuration Primitives 2526 The T_LM configuration primitives.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2520 Behavioral Description 2521 The state diagram describing the behavior of the T_CO_FLOWCONTROL.9.cnf_L primitive is shown in Figure 372 of [MIPI02].1.

SelectorIndex ) 2532 The primitive parameters are defined in Table 85.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 85 Name T_LM_SAP Configuration Primitive Parameters (continued) Type Valid Range Value Description NORMAL SetType AttrSetType STATIC 0 Indicates that the Attribute is addressed. 2530 The semantics of this primitive are: 2531 T_LM_GET. For Attributes not associated with the SelectorIndex. 2533 When Generated 2534 This primitive is generated by the DME to obtain the value of the Attribute identified by MIBattribute.Version 1. 8.9. 2535 Effect on Receipt 2536 The Transport Layer shall attempt to retrieve the requested Attribute value and respond with T_LM_GET. if relevant. Copyright © 2007-2011 MIPI Alliance.cnf_L that gives the retrieved value.9. 2537 Behavioral Description 2538 The state diagram describing the behavior of the T_LM_GET.req primitive is shown in Figure 348 of [MIPI02]. The SelectorIndex shall be interpreted either as a CPort index or a Test Feature index based on the Attribute ID. All rights reserved. MIPI Alliance Member Confidential 235 .1. 1 SUCCESS INVALID_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE ConfigResultCode Enumeration READ_ONLY_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE BAD_INDEX LOCKED_MIB_ATTRIBUTE BAD_TEST_FEATURE_INDEX 0 1 2 3 4 5 6 7 Indicates the result of the request 8.req( MIBattribute.40.2 T_LM_GET.cnf_L 2539 This primitive indicates the success or failure of T_LM_GET.1. the SelectorIndex. and. Inc.req 2529 This primitive requests the value of the Attribute identified by MIBattribute and. returns the Attribute value. the SelectorIndex shall be ignored. is successful.1 T_LM_GET. Indicates that the non-volatile reset value of the Attribute is addressed.req.

but is not gettable. Table 86 ConfigResultCode T_LM_GET. T_NumTestFeatures INVALID_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE BAD_INDEX BAD_TEST_FEATURE_INDEX 2544 When Generated 2545 The Transport Layer shall generate the T_LM_GET. The value of SelectorIndex is greater than. All rights reserved. MIBvalue is undefined.e. The value of MIBvalue in T_LM_GET.req MIBattribute exists. the SelectorIndex shall be ignored.Version 1. 8. 2543 The Transport Layer shall set ConfigResultCode in T_LM_GET. MIBvalue carries the Attribute value. The value of MIBvalue in T_LM_GET. The Attribute indicated by MIBattribute is invalid or not implemented. MIBvalue. the MIB Attribute indicated by T_LM_GET.cnf_L to one of the values shown in Table 86 for the condition given in the table. 2548 Behavioral Description 2549 The state diagram describing the behavior of the T_LM_GET. The Transport Layer should not set ConfigResultCode to INVALID_MIB_ATTRIBUTE_VALUE or READ_ONLY_MIB_ATTRIBUTE. if relevant. or equal to. 2546 Effect on Receipt 2547 The DME is informed about the result of the operation. The Transport Layer shall set MIBvalue in T_LM_GET.req MIBattribute is gettable.cnf_L primitive in response to the most recent T_LM_GET. MIBvalue ) 2542 The primitive parameters are defined in Table 85. or equal to. 2551 The semantics of this primitive are: 2552 T_LM_SET.cnf_L( ConfigResultCode. The value of SelectorIndex is greater than.1.40.cnf_L is undefined.req from the DME.9. SelectorIndex ) Copyright © 2007-2011 MIPI Alliance. T_NumCPorts. MIPI Alliance Member Confidential 236 .cnf_L to the Attribute value. i. and in case ConfigResultCode is SUCCESS. The SelectorIndex shall be interpreted either as a CPort index or a Test Feature index based on the Attribute ID.cnf_L is undefined. MIBattribute. For any other value of ConfigResultCode.cnf_L primitive is shown in Figure 348 of [MIPI02].req( SetType. For Attributes not associated with the SelectorIndex. Inc.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. the SelectorIndex.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2540 The semantics of this primitive are: 2541 T_LM_GET.cnf_L ConfigResultCode Values Condition SUCCESS The request succeeds. The Attribute indicated by T_LM_GET.

9. 2565 The Transport Layer shall set ConfigResultCode in T_LM_SET. or otherwise If SetType is STATIC. This ConfigResultCode value shall only be used if SetType is NORMAL. Table 87 ConfigResultCode T_LM_SET. 2559 Behavioral Description 2560 The state diagram describing the behavior of the T_LM_SET. The T_LM entity should not set ConfigResultCode to WRITE_ONLY_MIB_ATTRIBUTE.cnf_L to one of the values shown in Table 87 for the conditions given in the table. or otherwise the Attribute indicated by MIBattribute and SelectorIndex is not implemented. INVALID_MIB_ATTRIBUTE READ_ONLY_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE Copyright © 2007-2011 MIPI Alliance. the value or the reset value of the Attribute indicated by MIBattribute and SelectorIndex is set to the value of MIBvalue. Inc. The MIBattribute value is invalid. the Transport Layer shall attempt to set the Attribute addressed by MIBattribute to the MIBvalue.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2553 The primitive parameters are defined in Table 85. or outside of the valid value range.req primitive is shown in Figure 347 of [MIPI02]. i.Version 1. 2558 The Transport Layer uses T_LM_SET. If SetType is set to STATIC. All rights reserved. but is not settable.40. 8.cnf_L to inform the DME of the result of T_LM_SET. The Attribute indicated by MIBattribute and SelectorIndex exists. the Transport Layer shall attempt to set the reset value of the Attribute addressed by MIBattribute to the MIBvalue. the Attribute indicated by MIBattribute and SelectorIndex does not support setting its reset value.cnf_L( ConfigResultCode ) 2564 The primitive parameter is defined in Table 85. but the value of MIBvalue is outside of the implemented range.4 T_LM_SET.cnf_L ConfigResultCode Values Condition SUCCESS The request succeeds.1. MIPI Alliance Member Confidential 237 . 2554 When Generated 2555 This primitive is generated by the DME to set the value or reset value of the indicated Attribute.e.req. 2556 Effect on Receipt 2557 If SetType is set to NORMAL. 2562 The semantics of this primitive are: 2563 T_LM_SET. The Attribute indicated by MIBattribute and SelectorIndex exists and is settable (SetType = NORMAL) or allows its reset value to be set (SetType = STATIC).cnf_L 2561 This primitive reports the results of an attempt to set the value of an Attribute or its reset value. for the Attribute.

2. 2570 Behavioral Description 2571 The state diagram describing the behavior of the T_LM_SET.9.6 8.9. or equal to. Table 88 Name T_LM_SAP Control Primitives Indication Local Response Response Local Confirm Confirm Request T_LM_RESET T_LM_ENABLE_LAYER T_LM_HIBERNATE_ENTER T_LM_HIBERNATE_EXIT 8.9.2.5 8.cnf_L primitive in response to the most recent T_LM_SET.9. and should have no further effects at the DME.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 87 T_LM_SET.2. Inc. Table 89 Name Type T_LM_SAP Control Primitive Parameters Valid Range Value Description ResetLevel Enumeration COLD WARM 0 1 Defines the reset level of the requested reset Copyright © 2007-2011 MIPI Alliance.2. BAD_INDEX BAD_TEST_FEATURE_INDEX 2566 When Generated 2567 The Transport Layer shall generate the T_LM_SET.2 8.Version 1.9.40. All rights reserved.3 8. MIPI Alliance Member Confidential 238 . The value of T_LM_GET.req SelectorIndex is outside of the range of available CPorts.2.cnf_L confirms the success or failure of the T_LM_SET.9.req from the DME.9.req SelectorIndex is greater than. 2573 The primitives covered in this section are listed in Table 88. 8.req at the Transport Layer.cnf_L primitive is shown in Figure 347 of [MIPI02]. The CPort indicated by T_LM_SET.7 8.2.2 Control Primitives 2572 The Service Primitives in this section are provided for controlling the Transport Layer. This ConfigResultCode value shall only be used if SetType is NORMAL.2.8 2574 Table 89 lists the parameters that appear in the T_LM_SAP control primitives.1 8. 2568 Effect on Receipt 2569 T_LM_SET.4 8. but it belongs to a CPort that is in the CONNECTED state.2.9. T_NumTestFeatures.9.cnf_L ConfigResultCode Values (continued) Condition ConfigResultCode LOCKED_MIB_ATTRIBUTE The Attribute indicated by MIBattribute and SelectorIndex exists and is settable.

cnf_L.9.req primitive is shown in Figure 345 of [MIPI02].cnf_L primitive is used during the UniPro reset procedure (see Section 9. 2595 The semantics of this primitive are: 2596 T_LM_ENABLE_LAYER.req( ) Copyright © 2007-2011 MIPI Alliance. the Transport Layer shall not react to any Transport Layer SAP primitive other than T_LM_RESET.req and T_LM_ENABLE_LAYER.9.req 2582 The ResetLevel COLD resets the complete Transport Layer including the statistics and configuration Attributes.Version 1. 2576 The semantics of this primitive are: 2577 T_LM_RESET.2). 8.40. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8. 8.1 T_LM_RESET.cnf_L primitive is shown in Figure 351 of [MIPI02]. Inc.3 T_LM_ENABLE_LAYER.11.cnf_L to the DME. 2590 Effect on Receipt 2591 The DME is informed that the Transport Layer came out of reset.req primitive is used during the UniPro boot procedure (see Section 9.req( ResetLevel ) 2578 When Generated 2579 This primitive is generated by the DME when it needs to reset the Transport Layer.2 T_LM_RESET.2.cnf_L( ) 2588 When Generated 2589 The T_LM_RESET. 2583 Behavioral Description 2584 The state diagram describing the behavior of the T_LM_RESET. The Transport Layer is reset in combination with resetting of all the UniPro protocol layers as described in the reset procedure. 2580 Effect on Receipt 2581 The Transport Layer sets itself to the reset states and Attribute values.1).11.req 2575 This primitive requests the reset of the Transport Layer. The ResetLevel WARM resets the Transport Layer without the statistics. 2586 The semantics of this primitive are: 2587 T_LM_RESET.cnf_L 2585 The T_LM_RESET. After issuing T_LM_RESET.cnf_L primitive is issued to the DME in response to T_LM_RESET.9. Then. and discards all Segments and/or Messages currently processed.req 2594 The T_LM_ENABLE_LAYER. the Transport Layer shall generate T_LM_RESET. 2592 Behavioral Description 2593 The state diagram describing the behavior of the T_LM_RESET.2. MIPI Alliance Member Confidential 239 .2.req to indicate that the Transport Layer came out of reset.

11. 2601 Behavioral Description 2602 The state diagram describing the behavior of the T_LM_ENABLE_LAYER. MIPI Alliance Member Confidential 240 .cnf_L primitive is used during the UniPro boot procedure (see Section 9.cnf_L primitive is issued to the DME T_LM_ENABLE_LAYER. After issuing T_LM_ENABLE_LAYER. Inc.cnf_L( ) 2606 When Generated 2607 The T_LM_ENABLE_LAYER. 2617 Effect on Receipt 2618 The Transport Layer shall issue the T_LM_HIBERNATE_ENTER. 8.req to indicate that the Transport Layer was enabled.req primitive is part of the UniPro boot procedure (see Section 9. 8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2597 When Generated 2598 The T_LM_ENABLE_LAYER.Version 1.cnf_L primitive is shown in Figure 346 of [MIPI02]. During hibernation.2).9.2) to indicate to the DME that the Transport Layer is enabled. 2608 Effect on Receipt 2609 The DME is informed that the Transport Layer is enabled.req in response to 2612 The T_LM_HIBERNATE_ENTER.9.5 T_LM_HIBERNATE_ENTER.4 T_LM_ENABLE_LAYER.req primitive is shown in Figure 346 of [MIPI02].req primitive to request the Transport Layer to enter hibernation.cnf_L 2603 The T_LM_ENABLE_LAYER.11. and is generated by the DME after the Transport Layer came out of reset.cnf_L to the DME.40. and the Network Layer was enabled. and may lose all its state.2.cnf_L primitive to the DME and then enter hibernation.2. Copyright © 2007-2011 MIPI Alliance. 2613 The semantics of this primitive are: 2614 T_LM_HIBERNATE_ENTER.req( ) 2615 When Generated 2616 The DME generates the T_LM_HIBERNATE_ENTER. 2604 The semantics of this primitive are: 2605 T_LM_ENABLE_LAYER.cnf_L. All rights reserved. 2610 Behavioral Description 2611 The state diagram describing the behavior of the T_LM_ENABLE_LAYER.req primitive is used to request the Transport Layer to enter hibernation. 2599 Effect on Receipt 2600 The Transport Layer shall respond with T_LM_ENABLE_LAYER. all Transport Layer functionality and SAP primitives shall be enabled. the Transport Layer should not retain any Attribute.

7 T_LM_HIBERNATE_EXIT.cnf_L primitive is used to indicate to the DME that the Transport Layer is about to hibernate. MIPI Alliance Member Confidential 241 . 2635 Effect on Receipt 2636 The Transport Layer shall go to its reset state.2. Copyright © 2007-2011 MIPI Alliance. 8.40. 2626 Effect on Receipt 2627 The DME is informed about the Transport Layer entering hibernate.2.req primitive and it indicates that the Transport Layer is hibernating. 8.6 T_LM_HIBERNATE_ENTER. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2619 Behavioral Description 2620 The state diagram describing the behavior of the T_LM_HIBERNATE_ENTER. 2622 The semantics of this primitive are: 2623 T_LM_HIBERNATE_ENTER.cnf_L primitive to the DME. All rights reserved.9.cnf_L primitive is shown in Figure 350 of [MIPI02].req primitive is shown in Figure 350 of [MIPI02]. 8.cnf_L primitive is generated by the Transport Layer in response to a T_LM_HIBERNATE_ENTER. Then the Transport Layer shall set its Attributes to their reset values and then issue the T_LM_HIBERNATE_EXIT.9.cnf_L 2621 The T_LM_HIBERNATE_ENTER.req 2630 The T_LM_HIBERNATE_EXIT. 2631 The semantics of this primitive are: 2632 T_LM_HIBERNATE_EXIT.cnf_L 2639 The T_LM_HIBERNATE_EXIT.cnf_L( ) 2624 When Generated 2625 The T_LM_HIBERNATE_ENTER. 2637 Behavioral Description 2638 The state diagram describing the behavior of the T_LM_HIBERNATE_EXIT.req primitive to request the Transport Layer to exit hibernation.9.req primitive is used to request the Transport Layer to exit hibernation and return to normal operation.cnf_L primitive is used to indicate to the DME that the Transport Layer has exited hibernation and is operating normally.req( ) 2633 When Generated 2634 The DME generates the T_LM_HIBERNATE_EXIT.2.8 T_LM_HIBERNATE_EXIT.req primitive is shown in Figure 350 of [MIPI02]. 2628 Behavioral Description 2629 The state diagram describing the behavior of the T_LM_HIBERNATE_ENTER.Version 1.

2649 The primitives covered in this section are listed in Table 90.1 T_LM_DISCARD.cnf_L( ) 2642 When Generated 2643 The T_LM_HIBERNATE_EXIT.ind 2651 This primitive indicates that the Discard T_PDU feature has been performed (refer to Section 8.cnf_L primitive is shown in Figure 350 of [MIPI02].9. Table 91 Name Type T_LM_SAP Status Primitive Parameters Valid Range Value Description UNSUPPORTED_HEADER_TYPE UNKNOWN_CPORTID NO_CONNECTION_RX L4DiscardReasonCode Enum CONTROLLED_SEGMENT_DROPPING BAD_TC E2E_CREDIT_OVERFLOW SAFETY_VALVE_DROPPING 1 2 3 4 5 6 7 Indicates the reason for discarding a T_PDU 8. MIPI Alliance Member Confidential 242 .9. Table 90 Name Request T_LM_SAP Status Primitives Indication Local Response Response Local Confirm Confirm T_LM_DISCARD 8.Version 1. 2644 Effect on Receipt 2645 The DME is informed about the Transport Layer exiting hibernate.3 Status Primitives 2648 The Service Primitives in this section are provided for status provision by the Transport Layer.cnf_L primitive is generated by the Transport Layer in response to a T_LM_HIBERNATE_EXIT.req primitive and it indicates that the Transport Layer has exited hibernation and is operating normally. 2646 Behavioral Description 2647 The state diagram describing the behavior of the T_LM_HIBERNATE_EXIT. Inc.11.11) and reports the reason for triggering the operation.1 2650 Table 91 lists the parameters that appear in the T_LM_SAP status primitives.3. 8.3. Copyright © 2007-2011 MIPI Alliance.9.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2640 The semantics of this primitive are: 2641 T_LM_HIBERNATE_EXIT. All rights reserved.

The size of a received Segment is bigger than the space left in the RX buffer. 2659 Behavioral Description 2660 The state diagram describing the behavior of 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. CPort Safety Valve mechanism has discarded data. given by the value of T_LocalBufferSpace.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2652 The semantics of this primitive are: 2653 T_LM_DISCARD. i. 8.11 in more detail. NO_CONNECTION_RX 3 CONTROLLED_SEGMENT_DROPPING 4 BAD_TC 5 E2E_CREDIT_OVERFLOW 6 SAFETY_VALVE_DROPPING 7 2655 When Generated 2656 This primitive shall be generated by the T_LM entity as a result of performing the discard T_PDU feature. A user-data carrying T_PDU targeting a CPort is received that has no established Connection. The Segment was dropped at the receiver due to insufficient buffer space.40. Copyright © 2007-2011 MIPI Alliance.ind primitive is shown in the L4_CPort_rx SDL process of [MIPI02]. The CPort a received T_PDU is targeting does not exist. Table 92 L4DiscardReasonCode T_LM_DISCARD. MIPI Alliance Member Confidential 243 . This can occur only when End-to-End Flow Control is disabled. 2662 A Segment (T_PDU) shall contain an integral number of bytes greater than zero and shall be limited to T_MaxSegmentSize.Version 1. Inc.ind( L4DiscardReasonCode ) 2654 When the T_LM_DISCARD. This guarantees that any Segment shall always fit in exactly one Packet (N_PDU).ind Reason Codes Value Description UNSUPPORTED_HEADER_TYPE UNKNOWN_CPORTID 1 2 A T_PDU was received whose header contains unsupported values.e. A T_PDU was received with a Traffic Class that is different than the T_TrafficClass Attribute of the destination CPort. All rights reserved. is not in the CONNECTED state. 2657 Effect on Receipt 2658 The DME is notified of the discard.10 Structure and Encoding of Transport Protocol Data Units 2661 This section defines the Transport Layer Protocol Data Units (usually referred to as Segments) and shows the header fields and their meaning.11.

Inc. this field is fixed to ‘1’ indicating a DT SH T_PDU Contains the five least significant bits of the addressed CPort Signals a new Flow Control Token DestCPortID_Enc FCT 5-bit 1-bit Copyright © 2007-2011 MIPI Alliance.2 T_PDU Fields 2666 Table 94 describes the T_PDU fields.1.10.1.40. referred to as DT SH T_PDU and identified by the L4s bit set to ‘1’.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8.1 8. FCT EOM Payload – Byte n-1 ( n <= T_MTU) Figure 76 Data T_PDU with Short Header (DT SH T_PDU) 2665 The natural T_PDU granularity is bytes. Table 94 Field Name Field Description T_PDU Header Fields Field Size Remarks/Limitations L4s L4 Header type field Least significant bits of destination CPortID Flow Control Token 1-bit Identifies the used T_PDU type. All rights reserved.10. . any integral number of data bytes in the range from 0 to T_MTU can be transferred.1 DT SH T_PDU 2664 The current version of UniPro only defines a DT T_PDU with a short header. 7 L4s=1 6 5 4 3 2 1 0 DestCPortID_Enc Payload – Byte 0 .10. Table 93 T_PDU Name Mnemonic Transport Layer PDU Types Remarks/Limitations Section Overall Header Size Data T_PDU with short header DT SH T_PDU 8-bit Payload is limited to T_MTU 8. i.Version 1. The DT SH T_PDU is used to transfer User data between peer CPorts.e. . 8.req primitive. DT SH T_PDUs are sent using the N_DATA_SHDR. MIPI Alliance Member Confidential 244 .1 Data T_PDUs 2663 Table 93 lists the Data Transport Protocol Data Unit (DT T_PDU) types that shall be supported.10.

2. MIPI Alliance Member Confidential 245 . All rights reserved.1 L4 Header Type Field (L4s) 2667 The L4s header field serves as a header type bit. the T_PDU shall be discarded (see Section 8.11) and a notification according to Section 8.9. 2668 Table 95 shows the supported settings. In the current version of UniPro. 2671 Table 96 shows the supported settings.2 Copyright © 2007-2011 MIPI Alliance. no corresponding Service Primitive supported Caused by the use of the T_CO_DATA primitive 8. If a Device supports more than thirty-two CPorts. a Segment created as a result of T_CO_DATA. 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. 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. Upon reception of a Segment with the L4s bit set to ‘0’. Payload Message Fragment 0 to T_MTU bytes 8.3. There is no relation enforced between the Segment Payload and the TX and RX Message Fragments as transferred through T_CO_DATA SAP. Table 95 Field Name Size Value Settings of the L4s Field Meaning Remarks 0 L4s 1-bit 1 Reserved Short Header Data T_PDU (DT SH T_PDU) is used Not allowed.Version 1.40. 2670 In various cases a 5-bit CPortID may be enough. Table 96 Field Name Size Settings of the DestCPortID_Enc field Meaning Remarks Value DestCPortID_Enc 5-bit Least significant bits of 0 to 31 PeerCPortID Least Significant bits and remaining most significant bits are determined by the formulas given in Section 8.1 shall be given.req Service Primitive shall have the L4s header bit set to ‘1’.11.11.10.11.10.2.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 94 Field Name T_PDU Header Fields (continued) Field Size Remarks/Limitations Field Description EOM End Of Message 1-bit Identifies the last Segment of a Message Carries a Message chunk with a maximum size that depends on the configured maximum payload size of the used Traffic Class x (T_TC[x]TxMaxSDUSize).2 DestCPortID_Enc 2669 The DestCPortID_Enc field shall contain the five least significant bits of the CPortID of the targeted CPort.2. Inc.

The Transport Layer may also notify the receiving application when parts of a Message are available. the first payload byte of any subsequent Segment shall be considered the first byte of a new Message. in-order delivery.40.4 End of Message (EOM) 2674 The EOM field is used to mark the final Segment of a Message. The order of the intermediate Segments is preserved by means of the required Network properties. The payload may carry any value. 8.11..2.e. 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. Inc.1. 8.2. When the EOM bit is set. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8.10. Note that short Messages may be carried by a single Segment.2. Table 97 Field Name Size Value Settings of the FCT Field Meaning Remarks 0 FCT 1-bit 1 No Flow Control Token received/sent Flow Control Token is carried by T_PDU 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 segmentation process takes care of splitting Messages so that each resulting Segment does not exceed the T_MTU size.5 Payload 2677 The payload field carries the Message given by the CPort User and is potentially segmented by the CPort.3 Flow Control Token (FCT) 2672 The FCT field is used to signal a Flow Control Token to support the E2E Flow-control service (refer to Section 8. one or more Segments without the EOM flag set have been received. i.8.ind.4.11.10.Version 1. e.g. the Transport Layer shall notify the receiving application after the last Segment has been processed by means of a T_CO_DATA.1).8.10. 2676 Upon reception of a Segment with the EOM bit set. The conditions when a FCT is signaled are specified in Section 8. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 246 . Table 98 Field Name Size Value Settings of the EOM field Meaning Remarks 0 EOM 1-bit 1 The End of Message has not been reached The last byte of the most recent received or transmitted Fragment contains the last byte of the potentially segmented Message 2675 As already introduced in Section 8.

which is provided by the Network Layer. which is extracted from the header. Connection opening and closing via protocol data units (PDUs) across the Link.11 8.11.E2EFC = ‘1’). Inc. The Connection parameter Attributes shall be set according to the following rules: 2681 2682 2683 2684 2685 2686 • • • • • • The T_PeerDeviceID Attribute of each CPort shall be set to the N_DeviceID of the peer CPort. 2680 A Connection is opened between two peer CPorts. each of the two CPorts shall set the T_PeerBufferSpace Attribute of the local CPort to the same value as T_LocalBufferSpace Attribute of the peer CPort.E2EFC shall be set to the same value for both CPorts. UniPro does not yet support a standardized Connection management protocol. its peer CPort can receive. The T_PeerCPortID Attribute of each CPort shall be set to the CPortId of the peer CPort The T_TrafficClass Attribute shall be set to the same value for both CPorts.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 99 Field Size Value Settings of the Payload Field Meaning Remarks Payload 0 to T_MTU bytes Any byte string A complete Message or a portion of a Message 8. If E2E FC is enabled (T_CPortFlags. using the DME_SET and DME_PEER_SET primitives. is used to compute the DestDeviceID_Enc field in the Network Layer Header. i.40.e. The T_ConnectionState Attribute shall be the last Attribute to be set at each CPort. In the current specification. If E2E FC is enabled (T_CPortFlags. These values represent the amount of data that the CPort where T_PeerBufferSpace is set can initially transmit. The remaining most significant bits of the T_PeerCPortID are translated to form the DeviceIDOffset. the Connection may be closed to allow the involved CPorts to be used by a different Connection 2679 As already stated. The T_CPortMode Attribute for each CPort shall be set to CPORT_APPLICATION.1 Protocol Features Connection Management Feature 2678 Prior to any data transmission. where. The Connection parameter Attributes listed in Table 107 shall be set during Connection opening.11.E2EFC = ‘1’) or the E2E FC is disabled and CSD is enabled (T_CPortFlags. together with the T_PeerDeviceID. the T_TxTokenValue Attribute of each CPort and the T_RxTokenValue Attribute of the peer CPort shall be set to the same value.2 Address Translation Feature 2692 The Address translation feature provides the means to handle CPortIDs with more than 5-bits to enable addressing Devices with more than thirty-two CPorts. hence. Connections shall be opened to ensure that the CPorts defining a Connection are correctly configured. and. The T_ConnectionState Attribute for each CPort shall be set to CONNECTED. The T_CPortFlags. 2687 • 2688 • 2689 • 2690 • 2691 • 8. For received Segments the DestCPortID_Enc. The Attributes are set via the DME.CSD_n = '0'). MIPI Alliance Member Confidential 247 . and the DeviceIDOffset. shall be translated to determine the targeted CPort.E2EFC = ‘0’and T_CPortFlags. Connection opening is supported either based on a non-volatile Attribute reset values or using DME-based local and remote Attribute setting. All rights reserved. 2693 For the transmission the destination CPortID and destination DeviceIDOffset shall be determined as follows: Copyright © 2007-2011 MIPI Alliance. The T_CreditsToSend Attribute for each CPort shall be set to 0. When the Connection is not needed anymore. which is passed to the Network Layer.Version 1. The T_ProtocolID Attribute shall be set to the same value for both CPorts.

The segmenting state is maintained for each Connection.40. The segmenting process is invoked on a given Message when the Message is larger than the payload a Segment can carry.e. if any. i.e. a new segmenting process shall only take place after a previous one has finished. In contrast. Copyright © 2007-2011 MIPI Alliance. are sent in sequence. whereas Message Fragment boundaries. All rights reserved. which is visualized in the figure by a flag symbol. Application Layer (LA) T_CO SAP[x] Transport Layer (L4) A_PDU T_SDU Segmentation Process T_SDU[1/3] T_SDU[2/3] T_SDU[3/3] A_PDU T_SDU Data Unit = Message Data Unit = Message T_SDU[1/1] Internal Data Unit = Message Fragment (a) (b) Figure 77 Transport Layer Segmentation Process 2704 In Figure 77. Message boundaries are preserved at the Transport Layer handles. such as the last Segment of a Message or when the Segment is sent due to a Flow Control Token transmitted request. MIPI Alliance Member Confidential 248 . as exemplified in Figure 77a. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2694 2695 DestCPortID_Enc = T_PeerCPortID & 0x1F DeviceIDOffset = T_PeerCPortID >> 5 2696 The T_PeerDeviceID parameter shall be passed unchanged to the Network Layer: 2697 DestPeerDeviceID = T_PeerDeviceID 2698 For the reception the targeted CPortID shall be determined as follows: 2699 CPortID = DestCPortID_Enc + ( DeviceIDOffset << 5 ) 8. the segmentation scheme should create Segments of T_TCxTxMaxSDUSize length except when special conditions occur. i. Messages. 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. 2705 The state diagram describing the behavior of the Segmentation Feature is shown in the L4_CPort_tx SDL processes of [MIPI02].Version 1. The EOM parameter of a DT T_PDU indicates whether or not there are subsequent DT T_PDUs in the sequence carrying parts of the T_SDU. but shall be not exceed T_TCxTxMaxSDUSize. where TCx corresponds to the Segment traffic class. may change.5) into Segments on the transmitting side. As default. the application hands over a Message (an A_PDU that then becomes a T_SDU) to the Transport Layer.3 Segmentation Feature 2700 Segmenting is the process of splitting Messages into one or more ordered data chunks that are then composed (refer to Section 8. 2702 The Segment payload may have any length. 2703 The two scenarios for segmentation on the TX side are shown in Figure 77. 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’).11.11. 2701 It shall be ensured that T_SDUs.

8.ind Service Primitive. the reassembly process starts and is continued as long as no further data T_PDUs with EOM set are received.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2706 In exceptional cases. 2710 The state diagram describing the behavior of the Reassembly Feature is shown in the L4_CPort_rx SDL processes of [MIPI02]. Inc.11. 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 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.4 Reassembly Feature 2708 After the transmission to the destination the reassembly process takes place on the receiving side. All rights reserved. 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. The first payload byte of any subsequent Segment shall be considered the first byte of a new Message. 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. 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 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. MIPI Alliance Member Confidential 249 . no relationship is specified between the received Message Fragment size and the transmitted Message Fragment size or the received Segment size. mainly encountered during error recovery.40. it is merely a conceptual model. it is merely a conceptual model. This is the exact counterpart of the segmentation process and is depicted in Figure 78a. The Transport Layer is however responsible for ensuring that a Segment payload never exceeds the T_MTU limit.Version 1. Whenever an EOM is received. As stated in Section 8. The T_CO_DATA. 8. Copyright © 2007-2011 MIPI Alliance. a Segment without any payload may be sent with the EOM set to one. Application Layer (LA) T_CO SAP[x] Transport Layer (L4) A_PDU T_SDU Reassembly Process T_SDU[1/3] T_SDU[2/3] T_SDU[3/3] A_PDU T_SDU Data Unit = Message Data Unit = Message T_SDU[1/1] Internal Data Unit = Message Segment (a) (b) Figure 78 Transport Layer Reassembly Process 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. 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.3.ind Service Primitive offers the flexibility to provide either entire Messages or Message Fragments to the application. In this case.1.

For the construction of the T_PDU additional control information is needed.11. 2717 For the construction of the PCI the header format analysis feature is used. In addition it is identified whether or not a received T_PDU targets an existing CPort with an associated established Connection. The user-data and parts of the PCI shall be provided to the Transport Service User by means of the appropriate Service Primitive indications.7 Header Format Analysis Feature 2718 The feature determines the incoming T_PDU type and extracts the T_PDU header fields present in the correspondent T_PDU structure. Protocol Control Information (PCI) Derived from decoded L4 header information Passed via Service Primitives to Service User (LA) Potentially checked against L4 local information PCI T_SDU[x/y][ ] Decomposition Process T_PDU Internal Data Unit = Message Fragment Data Unit = Segment Figure 80 Transport Layer Decomposition Process 2716 The user-data is obtained from the T_SDU field. The PCI is obtained from local layerspecific state information and parameters given by means of Service Primitive requests.6 T_PDU Decomposition Feature 2715 This feature is responsible for the decomposition of the T_PDUs. MIPI Alliance Member Confidential 250 .Version 1. The decomposition feature extracts header information of received Packets and uses additionally layer-specific local state information to form the Protocol Control Information. 8.40.5 T_PDU Composition Feature 2712 This feature is responsible for the composition of Transport Protocol Data Units (T_PDUs). Copyright © 2007-2011 MIPI Alliance. Inc. The header consists of different fields specified in Section 8. 2714 The current segmenting state shall set the EOM parameter in the accordant data T_PDU.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8.11. the composition process is performed on complete or portions of T_SDUs (expressed by T_SDU[x/y] in Figure 79). 8. this feature constructs and adds a L4 header to the provided T_SDU to form a T_PDU. called Protocol Control Information (PCI).11. Protocol Control Information (PCI) Passed via Service Primitives from Service User (LA) Obtained from L4 local information Serves L4 header construction PCI T_SDU[x/y][ ] Composition Process T_PDU Internal Data Unit = Message Fragment Data Unit = Segment Figure 79 Transport Layer Composition Process 2713 In the Transport Layer.10. All rights reserved. As depicted in Figure 79.2.

E2E FC may be disabled. 2727 The E2E FC feature provides an effective means to prevent Head of Line (HOL) blocking and potential deadlock situations. If T_ConnectionState is not CONNECTED. the discard T_PDU feature (Section 8. 2730 A receiving CPort shall also support the CPort Safety Valve (CSV) feature (see Section 8.2).11.8. i.8. even when application RX buffer space is known to be available for the data supplied by the CPort. 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. 2721 Depending on the determined T_PDU structure. 2729 When the E2E FC feature is disabled.2.1). Any Connection-oriented T_PDU arriving at the destination Device should be able to progress to a buffer that is reserved for that Connection. The CPort User shall ensure that at any time a Message or Message Fragment indicated by the CPort is immediately consumed. 8. 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. This requirement serves to prevent HOL blocking and resulting congestion or deadlocks. The fields to be extracted are specified in Section 8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2719 The T_PDU type is determined by the L4s field and identifies the T_PDU header structure. 2728 Alternatively. 2726 E2E FC ensures the transmitting CPort knows how much buffer space at the receiving CPort is currently available for its T_PDUs.e. In the case where a T_PDU is received with the L4s bit set to '0'. To prevent congestion when the receiving CPort buffer is full. T_ConnectionState of the particular CPort must be CONNECTED. First.9). If T_ConnectionState is not CONNECTED. A CPort should use E2E FC for all Connections. The transmitting CPort uses E2E FC to prevent overflowing the receiving CPort buffer (see Section 8. the discard T_PDU feature shall be performed. The CSD feature is provided to achieve this goal. the EOM shall be extracted and the content shall be signaled to the Reassembling protocol feature. E2E FC and CSD prevent application RX buffer overflow. 2731 CSV works independently of the E2E FC or CSD.40. EOM shall not be processed. This corruption is signaled to the application. The CSV feature protects system-level integrity by avoiding HOL blocking. All rights reserved. If not.2).11.11) shall be performed. If not. it shall be checked whether a Connection exists for that CPort.11. Copyright © 2007-2011 MIPI Alliance. Inc.10. incoming data Segments should be discarded (dropped) using the Controlled Segment Dropping (CSD) feature (see Section 8.Version 1.8.1.11.11. 2722 The destination CPortID shall be determined by the Address translation protocol feature (Section 8. using CSD leads to data corruption of the received data stream. it shall be checked whether the CPort exists. A Connection between a pair of CPorts can be configured either with the End-to-End Flow Control (E2E FC) feature enabled or with the E2E FC feature disabled. MIPI Alliance Member Confidential 251 . FCT shall not be processed. A CPort shall provide support for E2E FC and shall default to this mode after reset.11. the T_PDU is discarded. 2723 If T_ConnectionState is CONNECTED. CSV discards one or more Segments when an application stops accepting data. allowing the transmitting CPort to send data without knowing how much buffer space at the receiving CPort is currently available for its T_PDUs.8 Explicit Flow Control Features 2725 The UniPro L4 Explicit Flow Control is a feature used to regulate the flow of T_PDUs between two CPorts on one Connection. while CSV protects against an application stopping receiving data. 2720 In the current version of UniPro the L4s field shall be set to ‘1’.11. After that. Although CSD helps ensure system-level integrity. 2724 If T_ConnectionState is CONNECTED. there is no guarantee that CPort-specific buffer space is available.

req Service Primitive with the appropriate parameter value set.E2EFC shall indicate whether E2E FC is enabled ('1') or not ('0'). 2736 T_PeerBufferSpace holds the actual number of bytes a transmitter is allowed to send.8. This counter shall be incremented with the parameter Credits provided with the T_CO_FLOWCONTROL.Version 1. CSD_n and CSV_n). T_TxTokenValue shall be equal to T_RxTokenValue of the connected peer CPort and vice versa. This does not automatically provide E2E reliability as there is a possibility to lose data at the destination. 2735 T_PeerBufferSpace and T_CreditsToSend shall track the current values related to E2E FC. due to lack of resources for processing incoming data. These Attributes shall be set during Connection setup. T_CPortFlags consists of 3 bits (E2EFC.8.1 End-to-End Flow Control Feature 2733 The point-to-point (P2P) reliability provided by the Data Link Layer guarantees that every Segment injected into the Network is correctly and reliably delivered to the destination.CSD_n and T_CPortFlags. 2739 The amount of T_PeerBufferSpace shall not exceed the amount of data the Transport user at the peer CPort can consume. The CPort shall transmit Segments if and only if the contained payload size is smaller or equal to the T_PeerBufferSpace value. Inc. 2737 A Token is signaled by the FCT header field of a DT T_PDU. T_CPortFlags. All rights reserved. Whether a Token was received shall be determined and signaled by the header format analysis feature. 2738 T_CreditsToSend identifies how many Credits are to be sent to the peer CPort by means of FCTs. 2740 The following sections and the subsequent Message Sequence Charts (MSCs) exemplify the E2E FC procedure. CSD and CSV features described in this section. The T_PeerBufferSpace counter shall be decremented by the amount of data sent. T_CPortFlags.CSV_n are specified in Section 8. Copyright © 2007-2011 MIPI Alliance.11. T_RxTokenValue and T_TxTokenValue shall not exceed the size of the receiver buffer as this would prevent the receiver from sending a token to the transmitter. also measured in bytes.11.11. It shall be incremented by T_RxTokenValue upon any received Flow Control Token. Table 100 Step E2E Flow Control Steps Description 1 The receiving CPort User should indicate that it can process new portion(s) of data by invoking the T_CO_FLOWCONTROL. 8. respectively.cnf_L. measured in bytes. MIPI Alliance Member Confidential 252 . T_TxTokenValue and T_RxTokenValue are associated with a particular CPort and in turn apply to the single Connection this CPort is involved in. Use of E2E FC ensures that the transmitting CPort does not send more data than the Transport user at the receiving CPort is capable of accepting and provides E2E reliability by that means. The MSCs provided are not meant to be exhaustive.40.9.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2732 See the L4_CPort_rx SDL process of [MIPI02] for reference algorithms defining the behavior of the receiving CPort E2E FC.req Service Primitive and shall be decremented by T_TxTokenValue whenever a DT T_PDU with FCT header field set to one (‘1’) has been transmitted. T_TxTokenValue shall determine the value of a Token transmitted. which causes incrementing the T_CreditsToSend counter by the value confirmed by T_CO_FLOWCONTROL. T_RxTokenValue shall determine the value of a Token received. 2734 T_CPortFlags.2 and Section 8.

Version 1. In case T_PeerBufferSpace is greater than zero. Inc. and potentially subsequent.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 100 Step E2E Flow Control Steps (continued) Description 2 In case the T_CreditsToSend counter value is greater than or equal to T_TxTokenValue. 2743 In Figure 81 the principal usage of E2E FC and a subsequent data transmission is outlined. The CPort shall ensure that any Segment transmission can be completed without running out of credits. the receiving CPort shall either: trigger the transmission of one or more DT T_PDUs with FCT set to one (‘1’) to the peer CPort if no data transfer is scheduled by the transmitter and decrement the T_CreditsToSend counter by T_TxTokenValue per FCT sent or set the FCT field to one (‘1’) for the next. MIPI Alliance Member Confidential 253 . Copyright © 2007-2011 MIPI Alliance.40. 3 4 2741 Note: 2742 Step 1 to step 3 may be performed at any time in parallel to the execution of step 4. The amount of data sent shall be subtracted from T_PeerBufferSpace. Note the CPortID parameters are omitted in the figure to enhance readability. Upon reception of a DT T_PDU with FCT header field set to one (‘1’) the transmitting CPort shall increment the T_PeerBufferSpace counter by T_RxTokenValue. DT T_PDUs scheduled by the transmitter and decrement the T_CreditsToSend by T_TxTokenValue per FCT sent Step 2 shall be repeated until the T_CreditsToSend counter value is less than T_TxTokenValue. All rights reserved. the sending CPort shall send as much data as indicated by T_PeerBufferSpace.

FRAGMENT_CORRECT) T_CO_DATA.Message[0 to 271]) T_PeerBufferSpace=240 DT SH T_PDU (EOM=1.FCT=0. Copyright © 2007-2011 MIPI Alliance.req(Credits=600) T_CO_FLOWCONTROL.Message[272 to 399]) T_PeerBufferSpace=112 T_CO_DATA.40. Inc.FCT=0.cnf_L(SUCCESS) Figure 81 Data Transmission using E2E FC 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.T_[Rx/Tx]TokenValue=256 T_CO_FLOWCONTROL.00 31-Jan-2011 MIPI Alliance Specification for UniPro TS Provider A TS Provider B CONNECTED. T_E2EFCEnabled=TRUE.req(Message[400]) DT SH T_PDU (EOM=0. MIPI Alliance Member Confidential 254 .ind(Message[400].cnf_L(600.Version 1.FCT=1) T_CreditsToSend=88 T_PeerBufferSpace=512 T_CO_DATA. The sending Transport Layer interrupts the process for this particular CPort and Connection until new credits are given from the receiving side. SUCCESS) T_PeerBufferSpace=0 T_CreditsToSend=600 DT SH T_PDU (EOM=0. All rights reserved.FCT=1) T_CreditsToSend=344 T_PeerBufferSpace=256 DT SH T_PDU (EOM=0. Note the CPortID parameters are omitted in the figure to enhance readability.

req(Credits=600) T_CO_FLOWCONTROL. T_CPortFlags. T_CPortFlags.req(Credits=200) Not enough T_PeerBufferSpace to transmit next scheduled segment.FCT=1) T_CreditsToSend=344 T_PeerBufferSpace=256 DT SH T_PDU (EOM=0. when T_CPortFlags. As a result.CSD_n shall indicate whether Controlled Segment Dropping (CSD) is enabled ('0') or not ('1'). MIPI Alliance Member Confidential 255 .E2EFC = '0').FCT=0.00 31-Jan-2011 MIPI Alliance Specification for UniPro TS Provider A TS Provider B CONNECTED. T_LocalBufferSpace shall hold the actual number of bytes a receiver is allowed to receive and forward to the CPort User.2 Controlled Segment Dropping Feature 2746 In case the E2E FC is disabled (T_CPortFlags. T_CO_FLOWCONTROL.40.. 2747 When CSD is enabled.Message[0 to 271]) T_CO_FLOWCONTROL. which is possible due to P2P reliability of the underlying Network. 2748 CSD support may be omitted for cases where E2E FC cannot be disabled. SUCCESS) T_CreditsToSend=288 DT SH T_PDU (EOM=0.Version 1. 8.FCT=1) T_CreditsToSend=32 T_PeerBufferSpace=496 DT SH T_PDU (EOM=1.FCT=0.cnf_L(200. Inc. T_PeerBufferSpace=240 T_CO_FLOWCONTROL.cnf_L(600.req Service Primitive to indicate the RX buffer space associated to the CPort.Message[272 to 519]) T_PeerBufferSpace=248 T_CO_DATA. The Transport Layer does not use CSD on a connection with E2E FC enabled.FCT=1) T_CreditsToSend=88 T_PeerBufferSpace=512 T_CO_DATA.req(Message[520]) DT SH T_PDU (EOM=0. 2749 When CSD is enabled. T_LocalBufferSpace shall be incremented by the value of the Credits Copyright © 2007-2011 MIPI Alliance.ind(Message[520]. SUCCESS) T_PeerBufferSpace=0 T_CreditsToSend=600 DT SH T_PDU (EOM=0.8.11.cnf_L(SUCCESS) Figure 82 Interrupted Data Transmission using E2E FC 2745 Note: the E2E FC procedure does not need to acknowledge FCT signals. Wait for new credits. T_E2EFCEnabled=TRUE. the CPort User uses the. and FCT signals do not contain synchronization information.E2EFC is '1'.CSD_n shall ignored. All rights reserved. T_[Rx/Tx]TokenValue=256 T_CO_FLOWCONTROL. FRAGMENT_CORRECT) T_CO_DATA.

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. The amount of data received is subtracted from T_LocalBufferSpace.cnf_L(SUCCESS) Due to a lack of LFC Credits the incoming Message Fragments are dropped The loss of Messages can not be determined on the sending side Figure 83 Discard of Segment Payload Due to Lack of Credits 2757 Figure 84 illustrates the data transmission procedure using Controlled Segment Dropping to allow reception of incoming Segment payload.Message[272 to 399]) T_CO_DATA. CPortID parameters are omitted in the figure to enhance readability. All rights reserved. In case T_LocalBufferSpace is greater than zero.req Service Primitive and decremented by the amount of data received and forwarded to the receiving CPort User.req Service Primitive with the appropriate parameter value set. the receiving CSD-enabled CPort is entitled to receive as much payload data as indicated by T_LocalBufferSpace.40. 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. 2751 If CSD is enabled. which causes incrementing the T_LocalBufferSpace counter with that value. TS Provider A TS Provider B CONNECTED.00 31-Jan-2011 MIPI Alliance Specification for UniPro parameter upon any invocation of the T_CO_FLOWCONTROL.FCT=0. CPortID parameters are omitted in the figure to enhance readability.FCT=0. 2750 If CSD is disabled. Otherwise.req(Message[400]) DT SH T_PDU (EOM=0. MIPI Alliance Member Confidential 256 . 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. Inc. Loss of Segment payload is marked with a black circle at the end of an arrow. Copyright © 2007-2011 MIPI Alliance. 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. 2754 • 2755 The first step might be performed at any time in parallel to the second step. the CPort shall do no checks on the Segment payload size. the payload of the current Segment is discarded.Version 1.Message[0 to 271]) DT SH T_PDU (EOM=1. T_E2EFCEnabled=FALSE T_LocalBufferSpace=0 T_CO_DATA. Otherwise. 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. 2756 The MSC in Figure 83 shows the situation where the payload of all incoming Segments are discarded due to a lack of Credits.

FCT=0. 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. T_E2EFCEnabled=FALSE T_LocalBufferSpace=0 T_CO_FLOWCONTROL. Inc.req(Message[400]) DT SH T_PDU (EOM=0.Version 1.FCT=0.Message[0 to 271]) T_LocalBufferSpace=328 DT SH T_PDU (EOM=1. All rights reserved. Copyright © 2007-2011 MIPI Alliance.Message[272 to 399]) T_CO_DATA.ind(Message[400]. CPortID parameters are omitted in the figure to enhance readability. parts of the overall Message are lost. Loss of Segment payload is marked with a black circle at the end of an arrow.cnf_L(SUCCESS) T_LocalBufferSpace=200 T_CO_DATA.00 31-Jan-2011 MIPI Alliance Specification for UniPro TS Provider A TS Provider B CONNECTED. SUCCESS) T_CO_DATA. due to interim lack of credits. FRAGMENT_CORRECT) Figure 84 Successful Data Transmission with Controlled Segment Dropping 2758 The MSC depicted in Figure 85 exemplifies a situation where.req(Credits=600) T_LocalBufferSpace=600 T_CO_FLOWCONTROL. MIPI Alliance Member Confidential 257 .cnf_L(600.40.

Message[544 to 599]) T_LocalBufferSpace=172 T_CO_DATA.00 31-Jan-2011 MIPI Alliance Specification for UniPro TS Provider A TS Provider B CONNECTED. FRAGMENT_CORRUPT) Service user is notified with FRAGMENT_CORRUPT parameter set Figure 85 Unsuccessful Data Transmission Due to Interim Lack of Credits 8. In a well-designed system. For example.req(Credits=200) T_LocalBufferSpace=228 T_CO_FLOWCONTROL. 2761 A correct operation of the CPort Safety Valve implies that a CPort shall accept a stream of Segments without causing any throttling of the incoming stream through backpressure – regardless of how slowly the application accepts the incoming data.11.Message[272 to 543]) Not enough T_LocalBufferSpace to receive Message Fragment.FCT=0. Full recovery is unlikely because the problem is essentially a design issue within the receiving Device. it would be undesirable if the “misbehaving” application would cause backpressure and impact other (generally unrelated) traffic on the UniPro Network. T_E2EFCEnabled=FALSE T_LocalBufferSpace=0 T_CO_FLOWCONTROL. T_CO_FLOWCONTROL.FCT=0. The CPort shall discard any incoming Segment payload that cannot be delivered immediately. This loss of data integrity is signaled to the application. This means that when E2E FC is turned on.9 CPort Safety Valve 2759 The receiver part of a CPort has a “CPort Safety Valve” mechanism that becomes active when the receiving application.40.cnf_L(300.Version 1. 2760 The price one pays for the CSV mechanism is that the CPort’s received data stream will be corrupted due to dropped data whenever the CSV mechanism is triggered.req(Message[0 to 599]) DT SH T_PDU (EOM=0. the CPort Safety Valve mechanism (CSV) should never trigger. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 258 . SUCCESS) T_CO_DATA.FCT=0.req(Credits=300) T_LocalBufferSpace=300 T_CO_FLOWCONTROL. cannot accept the payload of incoming Segments at the rate at which the corresponding Data Frames are received across the Network. which otherwise could impact performance and possibly cause deadlocks.Message[0 to 271]) T_LocalBufferSpace=28 DT SH T_PDU (EOM=0. Reassembling process should be informed.cnf_L(200. Inc. SUCCESS) DT SH T_PDU (EOM=1. for whatever reason. which can decide how to handle this.ind(Message[328].cnf_L(SUCCESS) T_CO_DATA. if a software application crashes. All rights reserved. Connections are still reliable. which will be dropped.

2763 CSV works independently of E2E FC and CSD.11. 2769 On every invocation of the Discard T_PDU feature the T_LM_DISCARD.11.Version 1.40. 8.8. Inc. this shall be indicated to the application when a next Message Fragment is passed up to the application by setting the FragmentStatus parameter to a non-zero value.2.10. one or more Segment payloads had to be dropped because the CPort received more data than could fit into T_LocalBufferSpace. or without any of them being turned on.1 if the E2E FC is enabled for the particular Connection 8.10. This indicates that the Message Fragment and the Message the Fragment belongs to are corrupt.12 Segment Transmission 2770 A source Device shall transmit T_SDUs in the order in which they arrived at the local T_CO_SAP. This is not supposed to happen in a well-designed system and may indicate a conformance issue within either endpoint or a system configuration error. The T_SDU shall be segmented according to the procedure defined in Section 8. 8.11.11. or both. 2766 The dropping of one or more Segment payloads due to the CSD mechanism shall also be signaled to the DME using the T_LM_DISCARD indication with L4DiscardReasonCode set to CONTROLLED_SEGMENT_DROPPING.3 The selected T_PDU shall be composed by means of the T_PDU composition feature (Section 8.13 Segment Reception 2780 Upon the reception of a Segment the following operations shall be performed in the order listed below: Copyright © 2007-2011 MIPI Alliance.CSV_n shall indicate whether CPort Safety Valve is enabled ('0') or not ('1').1. 2765 The dropping of one or more Segment payloads due to the CSV mechanism shall be signaled to the DME using the T_LM_DISCARD indication with L4DiscardReasonCode set to SAFETY_VALVE_DROPPING. MIPI Alliance Member Confidential 259 . this shall be signaled to the DME using the T_LM_DISCARD indication with L4DiscardReasonCode set to E2E_CREDIT_OVERFLOW.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2762 T_CPortFlags.10 Error Reporting for CSD and CSV 2764 When the payload of one or more data Segments is discarded due to Controlled Segment Dropping or the CPort Safety Valve mechanisms.11 Discard T_PDU Feature 2768 In case of any occurrences of the situations listed in Table 92.2 • The present header fields shall be set with the values • • provided and maintained by the protocol features involved provided by the Service Primitive invoked The payload field shall be filled with the current Message Segment of the given Message or Message Fragment The resulting T_PDU shall be transmitted in accordance to the E2E FC procedure defined in Section 8. the Transport Layer shall perform all actions necessary to free up any resources used for the particular affected process. 2771 For the transmission of Segments the following operations shall be performed in the order listed below: 2772 • 2773 • 2774 • 2775 2776 2777 2778 2779 • • The correct T_PDU type shall be determined according to the rules defined in Section 8. 8.11. 2767 If. that one or more Message Fragments were lost. All rights reserved. and can be used in conjunction with both E2E FC and CSD. with E2E FC enabled.5) and in accordance to the encoding rules defined in Section 8.ind shall be given with the corresponding L4DiscardReasonCode.

this error shall be indicated to the receiving CPort User. 8. MIPI Alliance Member Confidential 260 . 2793 An example of an arbitration scheme where TC1 segments have precedence over TC0 segments.15.11. In case of interim Segment loss.11.2 • • The type of the T_PDU shall be recovered The present header fields shall be recovered and the resulting values shall be made available to the corresponding protocol features 2782 2783 2784 2785 • 2786 • 2787 • 2788 • • The user-data (or Segments of user-data) shall be obtained from the payload field The T_SDU shall be reassembled according to the procedure defined in Section 8.4 The T_PDU should be received and processed in accordance to the Controlled Segment Dropping procedure defined in Section 8. Analyzer of incoming Messages (T_SDUs) with the capability to report errors. 2791 For segment transmission. 2792 For an implementation that supports multiple Traffic Classes.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2781 • The received T_PDU shall be decomposed by means of the T_PDU decomposition feature (Section 8.4. and CPorts within Traffic Class are served using a round robin scheme is shown in the L4_TC_tx SDL process of [MIPI02].3 8. Both components are configurable and can be controlled via Attributes manipulated by the DME. The user-data shall be indicated to the Cport User by means of the corresponding Service Primitives according to Section 8. the CPorts mapped to the higher-priority Traffic Classes shall have precedence over CPorts mapped on lower-priority Traffic Classes.15.11.9. 8. Additional arbitration schemes may also be provided.6) involving the header format analysis feature (Section 8. and requires Transport Layer arbitration across CPorts mapped on different Traffic Classes. 8.11. TstSrc is a traffic generator and TstDst is a traffic analyzer. TstSrc and TstDst shall be used together and thus any usage of the term “Test Feature” refers to a TstSrc and TstDst pair as shown in Figure 86. the Transport Layer shall use segment-level round robin as a default arbitration scheme between CPorts mapped to the same Traffic Class. the connections are mapped to one of the available Traffic Classes. Table 101 Component Test Feature Overview Description Section TstSrc TstDst Programmable traffic generator that creates sequences of Messages (T_SDUs) containing well-defined byte sequences of well-defined lengths.11. which is then used for the entire connection duration.Version 1.8. Inc.15 UniPro Test Feature 2794 The UniPro Test Feature consists of two components. the Segment is dropped according to the Safety Valve procedure defined in Section 8.7) and in accordance to Section 8.6. When opened. TstSrc and TstDst. As a result. as described in Table 101. 2789 Upon any exception listed in Section 8.2 if the E2E FC is disabled for the particular Connection If the receiving application cannot accept the data.4 Copyright © 2007-2011 MIPI Alliance.10. The Traffic Class priority shall be determined according to the Data Link Layer definition in Section 6. the Transport Layer may have multiple connections simultaneously open.11.1 and with accordingly set parameters after the T_SDU has been reassembled.40.14 CPort Arbitration 2790 The Transport Layer provides support for multiple CPorts.11 the Discard T_PDU feature shall be performed. All rights reserved. The example also includes a few optimizations which are not mandated by this specification.8.

If the Device contains one CPort. Table 102 Determining the Number of Test Feature Instances in a DUT Minimum Number of Test Feature instances in the DUT Minimum Number of CPorts Available for Testing Number of CPorts in the DUT 1 2 or more 1 2 1 2 2796 The number of Test Feature instances in a Device shall be available through a static. The CP_Adapter shall be controlled via T_CPortMode. A Device can contain multiple Test Feature instances. All rights reserved. Inc. gettable-only Attribute at L4 DME called T_NumTestFeatures. 2797 TF_Dispatcher specifies the actual interconnection between the CPorts and Test Feature instances. MIPI Alliance Member Confidential 261 . It is worth noting that the TF_Dispatcher is not configurable and thus it is an implementation-specific block.00 31-Jan-2011 MIPI Alliance Specification for UniPro Application 1 Application 2 Application N Application N+1 Test Feature (TF) T_CO_T F SAP Test Feature (TF) T_CO_T F SAP TF Dispatcher T_LM SAP Device Management Entity (DME) T_CO SAP T_CO_TF SAP T_CO SAP T_CO_TF SAP T_CO_TF SAP T_CO SAP CP Adapter CP Adapter CP Adapter T_CO SAP T_CO SAP T_CO SAP T_CO SAP T_Core Entity Transport Layer + Test Feature (L4+TF) Figure 86 Test Feature Location within the Transport Layer 2795 The Test Feature is located below the LA and within the L4 as shown in Figure 86. The number of instances depends on the number of implemented CPorts in the Device. The previous conditions are needed to be able to test arbitration at L4. then the Device shall contain at least one instance of the Test Feature.40.Version 1. TF_Dispatcher and CP_Adapter. These requirements are summarized in Table 102. 2798 CP_Adapter performs the multiplexing and demultiplexing of the SAP primitives directed to and received from the CPort. which sets the CPort either in the Copyright © 2007-2011 MIPI Alliance. if the Device contains two or more CPorts. The interconnection between the Test Feature instances and the CPorts shall be implemented via two intermediate components. then the Device shall contain at least two instances of the Test Feature.

cport_id_value++) { 2808 request_primitive T_LM_SET.40. cport_id_value <= T_NumCPorts. Similarly.g. 2805 2806 for (tf_index = 1.e. tf_index++) { 2807 for (cport_id_value = 1. 2803 Declare ConnectionMode as Enumeration of {CONNECTED.req(T_TstCPortID.15. When a Copyright © 2007-2011 MIPI Alliance. 8.3.3 8. 2815 } 2816 else { 2817 connecitvity_matrix[tf_index][cport_id_value] = UNKNOWN. MIPI Alliance Member Confidential 262 . TstSrc is active and shall generate Messages. T_TstCPortID specifies the CPort which shall be tested by the Test Feature instance. 2810 if (response == SUCCESS) { 2811 connectivity_matrix[tf_index][cport_id_value] = CONNECTED. T_CPortMode shall be maintained by every CPort regardless of whether or not it can be tested by the Test Features.cnf_L(response).1 Algorithm for Discovering the Test Feature Instances in a DUT (informative) 2802 The following algorithm may be used by the Tester to discover the available number of Test Feature instances in a DUT and the range of testable CPorts. tf_index <= T_NumTestFeatures.req with the EOM parameter set to TRUE for transmitting entire Messages. e. All rights reserved. 2818 } 2819 } 2820 } 8.1 Traffic Generator (TstSrc) Activation 2822 TstSrc shall be activated and start generating Messages via an Attribute called T_TstSrcOn. then the Test Feature instance shall report this as an error to the requester. 2809 receive_confirmation T_LM_SET. 2804 Declare connectivity_matrix as Matrix of ConnectionMode[T_NumTestFeatures][T_NumCPorts].Version 1. 2799 The assignment of a specific Test Feature instance to a given CPort is controlled via T_TstCPortID. which shall take two values only. the CP_Adapter is not connected to the TF_Dispatcher.2 Configuration Primitives 2821 All Attributes defined for the Test Feature shall be accessible through the T_LM primitives defined in Section 8. NO_CPORT. 2812 } 2813 else if (response == NO_CPORT) { 2814 connectivity_matrix[tf_index][cport_id_value] = NO_CPORT. Inc. cport_id_value. when the CPort is connected to the Test Feature instance.15. 2800 The CP_Adapter shall be locked. not settable.9. either TRUE or FALSE.1. the Test Feature instance Attributes shall be locked if the TstSrc or TstDst are enabled. UNKNOWN}.00 31-Jan-2011 MIPI Alliance Specification for UniPro application mode or test mode. If T_TstSrcOn is TRUE. TstSrc shall use T_CO_DATA. If T_TstSrcOn is FALSE. tf_index).15. which shall be maintained by every Test Feature instance. 8. i. If the Tester attempts to set T_TstCPortID to a CPort ID which cannot be associated with the Test Feature instance for any reason.15. 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. then TstSrc shall be deactivated and does not generate any Messages.

4 Byte Pattern 2828 TstSrc generates a byte stream which is used to fill Messages according to the pattern specified in T_TstSrcPattern. TstSrc shall generate Messages with a length in bytes equal to the value of this Attribute. in T_TstSrcInterMessageGap.2 2826 TstSrc shall be configured to generate either a finite or infinite stream of Messages via an Attribute called T_TstSrcMessageCount. The byte pattern is unique and endless as long as TstSrc is activated. MIPI Alliance Member Confidential 263 . inclusively.3. TstSrc shall turn itself off by setting T_TstSrcOn to FALSE. as long as it is on. The following rules shall apply for the sawtooth pattern: 2829 • 2830 • The first byte in the pattern shall have a zero value. shall introduce gap delays between consecutive Messages equal to the value. in microseconds. Copyright © 2007-2011 MIPI Alliance. 8. Otherwise.2) and that number of Messages has been generated. which is set to 255. Inc. All rights reserved. i.00 31-Jan-2011 MIPI Alliance Specification for UniPro Message is being transmitted. Currently. the Test Feature specification only defines one pattern for the generated traffic which is sawtooth pattern. then TstSrc shall generate an infinite stream of Messages.15.15.e.3. which shall be able to hold any value in the range 1 to 65535. 2823 TstSrc shall be deactivated if any of the following conditions occurs: 2824 • 2825 • T_TstSrcOn is set to FALSE. TstSrc shall add T_TstSrcIncrement to the value of each subsequent byte in the pattern and shall roll-over at the maximum value. 8.3.5 2832 TstSrc. If T_TstSrcMessageCount is set to zero. Number of Generated Messages 8. the TstSrc shall wait for the corresponding T_CO_DATA. After generating that number of Messages. TstSrc is configured to generate a finite number of Messages (see Section 8.e. Figure 87 shows an example in which TstSrc is configured to transmit two Messages with Inter-message gap enabled. by setting T_TstSrcOn to TRUE.3 Message Length 2827 The length of the generated Messages by TstSrc shall be configured via an Attribute called T_TstSrcMessageSize.cnf_L Service Primitive.cnf_L to the next T_CO_DATA.3.15. the pattern shall start at the first byte of the first generated Message and it crosses the boundaries of the generated Messages.req.40. Inter-message Gap 2831 • 8.15. i.15.Version 1. TstSrc shall generate a number of Messages equal to the non-zero value assigned to T_TstSrcMessageCount. The pattern shall be reset whenever TstSrc is re-activated.3. The gap delay is measured from T_CO_DATA.

Inc.req Ready SrcOnWaitCnfL T_CO_DATA.req 5@$0@%"5"DOG@5@$0@%"5"@5TUDOG@5@$0@%"5"@5TUDOG@SrcOn t_MessageGapTimer(T_TstSrcInterMessageGap) Ready CONNECTED SrcOn SrcOff Figure 87 Inter-message Gap Example Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro MSC InterMessageGap_Example L4_TstSrc T_CO_TF_Dispatcher_Tx L4_Tx_Multiplexer L4_CPort_tx 5@$0@%"5"@5TUSFR 5@$0@%"5"@5TUSFR WaitCnf T_CO_DATA.cnf_L 5@$0@%"5"@5TUDOG@5@$0@%"5"@5TUDOG@t_MessageGapTimer(T_TstSrcInterMessageGap) Ready CONNECTED SrcOn SrcOn 5@$0@%"5"@5TUSFR 5@$0@%"5"@5TUSFR WaitCnf Ready SrcOnWaitCnfL T_CO_DATA.Version 1. MIPI Alliance Member Confidential 264 .40. All rights reserved.

Copyright © 2007-2011 MIPI Alliance. All rights reserved. As a result.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2833 TstSrc shall only insert the gap delay between two Messages.Version 1. MIPI Alliance Member Confidential 265 .40. Inc. TstSrc does not precede the first Message with a gap delay and does not succeed the last Message with a gap delay.

All rights reserved. the gap time between two Messages.6 Summary of the General Test Feature and TstSrc Attributes Version 1. Table 103 Attribute Attribute ID TstSrc (settable. or to its Reset Value otherwise.3.00 31-Jan-2011 2834 At reset.15. zero: infinite Message stream).40. MIPI Alliance Member Confidential 266 T_TstSrcOn T_TstSrcPattern T_TstSrcIncrement T_TstSrcMessageSize T_TstSrcMessageCount 0x4081 0x4082 0x4083 0x4084 0x4085 Message generation state Pattern used for Message generation The increment value between two consecutive bytes The size of each generated Message The number of Messages generated (Non-zero: finite Message stream. gettable) Attributes Description Type Units Valid Attribute Value(s) Mandatory Value(s) Reset Value Copyright © 2007-2011 MIPI Alliance. a settable Attribute shall be reset to its corresponding static value. if one exists. The actual duration of the timeout period shall be the value set in the Attribute ±10%. Boolean Enum Integer Integer Integer Byte Message FALSE=0. TRUE=1 FALSE=0 FALSE Sawtooth 1 256 256 Sawtooth=0 0 to 255 1 to 65535 0 to 65535 T_TstSrcInterMessageGap 0x4086 Integer µs 0 to 65535 0 MIPI Alliance Specification for UniPro Table 104 Attribute Attribute ID General Test Feature (settable. gettable) Attributes Description Type Units Valid Attribute Value(s) Mandatory Value(s) Reset Value T_TstCPortID 0x4080 The ID of the CPort-under-test Integer 0 to T_MaxCPortID Any . Inc.8. See Section 9 for more details. If non-zero.

2845 An example which illustrates the E2EFC behavior within TstDst is shown in Figure 88.15. the amount of data in bytes shall be added to the TstDst end-to-end credits. When data is received.req Service Primitive shall be equal to the lesser of T_TstDstFCCredits and the available TstDst end-to-end credits. The analysis capability of TstDst is configurable and can be enabled and disabled as desired (see Section 8. shall use the Flow Control primitives to allow the associated CPort to track the local available buffer space. then it does not request a T_CO_FLOWCONTROL. Three Attributes are available for controlling the flow control Service Primitives. 2842 TstDst tracks the amount of received data and generates an equal amount of end-to-end credits back. It indicates the maximum number of credits that shall be passed by TstDst to the T_CO_FLOWCONTROL.req Service Primitive may be issued. 2844 The third Attribute is called T_TstDstInitialFCCredits. 8. The number of credits that the TstDst sends shall be less than or equal to the amount of received data.2 2840 TstDst. 2841 The first Attribute is called T_TstDstFCCredits.req is issued. End-to-End Flow Control 8.4.4. The Credits parameter of the issued T_CO_FLOWCONTROL. If T_TstDstOn is TRUE. This Attribute is intended to ensure that the associated CPort tracks the local available buffer space after reset in the test mode which can be used either for issuing End-to-End Flow Control (E2EFC) tokens or Controlled Segment Dropping (CSD). the TstDst end-to-end credits shall be set to 0. called T_TstDstInterFCTokenGap defines the period in microseconds at which the T_CO_FLOWCONTROL. A first error is discovered in the incoming Message stream. 2843 The second Attribute. 2837 TstDstOn shall automatically deactivate itself if any of the following conditions occur: 2838 • 2839 • T_TstDstOn is set to FALSE.4).4. All rights reserved.req Service Primitive immediately after enabling the TstDst.Version 1.15. then TstDst shall be deactivated and does not consume any Messages.15. This means that the TstDst emulates normal application behavior. If T_TstDstOn is set to FALSE.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8. Initially. If TstDst does not receive any incoming data. its Credits parameter value shall be subtracted from the TstDst end-to-end credits. It indicates the number of credits that shall be passed by the TstDst to T_CO_FLOWCONTROL.req Service Primitive. The T_CO_FLOWCONTROL.40. MIPI Alliance Member Confidential 267 . as long as it is on. When T_CO_FLOWCONTROL. TstDst sits on top of the T_Core as shown in Figure 86. TstDst is active and shall consume Messages. Inc.15.1 Activation 2836 TstDst shall be activated to start consuming the Messages from the associated CPort via an Attribute called T_TstDstOn. Copyright © 2007-2011 MIPI Alliance.4 Traffic Analyzer (TstDst) 2835 TstDst acts as a consumer and analyzer of the incoming T_SDUs.req Service Primitive shall be issued only when TstDst end-to-end credits are available.req Service Primitive.

40.cnf_L ( T_TstDstFCCredits = 480. T_TstCPortID = 1 T_CO_FLOW CONTROL.req 5@$0@%"5"@5TUJOE 5@$0@%"5"@5TUJOE 5@$0@%"5"@5TUJOE ( MessageSize = 1000 ) Ready ( MessageSize = 1000 ) DstTFWaitRspL ( MessageSize = 1000 ) WaitMsgRspL 5@$0@%"5"@5TUSTQ@5@$0@%"5"@5TUSTQ@t_FCGapTimer(T_TstDstInterFCTokenGap) Ready OnFC DstTF CONNECTED 5@$0@%"5"@5TUSTQ@- T_CO_FLOW CONTROL_Tst. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro MSC TstDst_E2EFC_Example L4_TstDst T_CO_TF_Dispatcher_Rx L4_Rx_Demultiplexer L4_CPort_rx Off TFmap ( T_TstCPortID ) Ready T_CO_FLOW CONTROL_Tst. SUCCESS) CONNECTED OnFC T_CO_FLOW CONTROL_Tst. SUCCESS) CONNECTED OnNoFC ( T_TstDstFCCredits = 480. T_TstCPortID = 1 WaitCnfL Ready DstTFWaitCnfL T_CO_FLOW CONTROL.req (T_TstDstFCCredits = 480.req ) (T_TstDstFCCredits = 512 ) DstTFWaitCnfL T_CO_FLOW CONTROL. SUCCESS.req (T_TstDstInitialFCCredits = 992.cnf_L T_CO_FLOW CONTROL_Tst.cnf_L T_CO_FLOW CONTROL_Tst.req (T_TstDstFCCredits = 512. T_TstCPortID = 1 ) (T_TstDstInitialFCCredits = 992 ) T_CO_FLOW CONTROL. T_TstCPortID = 1 ) t_FCGapTimer(T_TstDstInterFCTokenGap) ( T_TstDstFCCredits = 512. SUCCESS. T_TstCPortID = 1 WaitCnfL Ready ) T_CO_FLOW CONTROL_Tst. T_TstCPortID = 1 ) Ready ( T_TstDstFCCredits = 480.cnf_L DstTF Ready OnNoFC ( T_TstDstInitialFCCredits = 992.cnf_L T_CO_FLOW CONTROL_Tst.cnf_L T_CO_FLOW CONTROL_Tst.cnf_L T_CO_FLOW CONTROL_Tst.req ) (T_TstDstInitialFCCredits = 992. SUCCESS. SUCCESS ) CONNECTED T_CO_FLOW CONTROL_Tst.Version 1.cnf_L ( T_TstDstFCCredits = 512. T_TstCPortID = 1 WaitCnfL Ready ) (T_TstDstFCCredits = 480. MIPI Alliance Member Confidential 268 . SUCCESS.req T_CO_FLOW CONTROL. Inc. T_TstCPortID = 1 ) DstTF Ready ( T_TstDstFCCredits = 512.req T_CO_FLOW CONTROL_Tst. T_TstCPortID = 1 ) DstTF Figure 88 E2EFC Behavior in TstDst Example Copyright © 2007-2011 MIPI Alliance.cnf_L T_CO_FLOW CONTROL_Tst.req (T_TstDstFCCredits = 512. T_TstCPortID = 1 ) (T_TstDstFCCredits = 480 ) DstTFWaitCnfL T_CO_FLOW CONTROL.

2851 T_TstDstMessageSize specifies the expected Message size for the incoming Messages. Inc. UNEXPECTED_BYTE_VALUE 3 2855 When the TstDst detects any of the errors shown in Table 105. If there is a mismatch between the actual increment between consecutive bytes and the value of this Attribute and T_TstDstErrorDetectionEnable is set to TRUE.4. TstDstPattern.4. MIPI Alliance Member Confidential 269 . If an error is found. starting from 1. it shall increment T_TstDstMessageCount every time T_CO_DATA. T_TstDstIncrement represents the expected increment between two consecutive bytes in the incoming Messages.40.1. 2852 In the case of the sawtooth pattern. Table 105 Error Possible Errors at TstDst Description Error Code FRAGMENT_CORRUPT INVALID_MSG_SIZE 1 2 The incoming Message Fragment is labeled as “CORRUPT” by T_CO_DATA. When T_CO_DATA. Otherwise. and follow the error handling procedure explained in Section 8.ind.4.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8. T_TstDstMessageCount shall not be changed. It is the responsibility of the Tester to set the T_TstDstMessageCount to a known value before TstDst is turned on.Version 1. Mismatch between the incoming Message length and T_TstDstMessageSize. All rights reserved.4.15. TstDst shall check the size and payload of the incoming Messages based on T_TstDstIncrement and T_TstDstMessageSize. this error code indicates a mismatch in the increment between the consecutive bytes in the incoming Message and T_TstDstIncrement.4. This Attribute shall be reset to zero after analyzing every incoming Message and finding no errors within it. 2853 In the case of the sawtooth pattern. overwrite the Attribute value with the byte which has the incorrect increment. In case of the Sawtooth pattern. 8.15.15. T_TstDstIncrement and T_TstDstMessageOffset.ind is called with the EOM flag set to TRUE. 2847 The TstDst shall never automatically clear T_TstDstMessageCount.3 Message Counting 2846 When TstDst is on. If there is a mismatch between the incoming Message size and the value of this Attribute and T_TstDstErrorDetectionEnable is set to TRUE.4.1. then TstDst shall consider this an error.15. 2849 If T_TstDstErrorDetectionEnable is TRUE.4 Message Analysis 2848 Message analysis functionality is configurable and is controlled via the five Attributes T_TstDstErrorDetectionEnable. then the index of the byte carrying the incorrect increment shall overwrite the Attribute. T_TstDstMessageOffset represents the index.4. 2850 T_TstDstPattern indicates the expected pattern for the incoming Messages. 8. T_TstDstMessageSize.15. of the byte which has the incorrect increment. regardless of the correctness of the Message.4. TstDst shall accept incoming Messages without generating any error Messages.ind is called with the EOM flag set to FALSE. it shall perform the following actions in the given order: Copyright © 2007-2011 MIPI Alliance.1 Error Handling Procedure 2854 There are three sources of errors at TstDst as listed in Table 105. overwrite the Attribute value with the incoming Message length and follow the error handling procedure explained in Section 8. then TstDst shall consider this an error.

Copyright © 2007-2011 MIPI Alliance. All rights reserved. 2859 T_TstDstMessageCount shall reflect the index of the faulty Message within the Message stream since T_TstDstMessageCount is incremented on every incoming Message with.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2856 • 2857 • 2858 • The TstDst de-activates itself by setting T_TstDstOn to FALSE. T_TstDstErrorDetectionEnable is set to FALSE. i. Inc. error. or without.e. The TstDst sets the T_TstDstErrorCode with the error code that generated the error. Message analyzing is disabled.40. MIPI Alliance Member Confidential 270 .

15.8. a settable Attribute shall be reset to its corresponding static Attribute. Boolean Boolean Enumeration Integer Integer Integer Integer Integer Message Byte Byte Byte FALSE=0. All rights reserved. and to the Reset Value otherwise. TRUE=1 FALSE=0 FALSE FALSE Sawtooth 1 0 0 256 FALSE=0.5 Summary of TstDst Attributes Version 1.00 31-Jan-2011 2860 At reset. The actual duration of the timeout period shall be the value set in the Attribute ±10%. Table 106 Attribute Attribute ID TstDst (settable.req is skipped. MIPI Alliance Member Confidential 271 Description T_TstDstOn T_TstDstErrorDetectionEnabl e T_TstDstPattern T_TstDstIncrement T_TstDstMessageCount T_TstDstMessageOffset T_TstDstMessageSize T_TstDstFCCredits 0x40A1 0x40A2 0x40A3 0x40A4 0x40A5 0x40A6 0x40A7 0x40A8 The state of TstDst Enable analyzing incoming Messages The expected pattern in the incoming Messages The expected increment value between two consecutive bytes Number of received Messages Offset of error from start of Message The expected size of incoming Message The amount of credits passed to the flow control Service Primitive The interval in microseconds for which requesting T_CO_FLOWCONTROL. See Section 9 for more details. Inc.40. gettable) Attributes Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Copyright © 2007-2011 MIPI Alliance. if one exists.4. TRUE=1 Sawtooth=0 0 to 255 0 to 65535 0 to 65535 0 to 65535 1 to T_MaxE2EFCCredits MIPI Alliance Specification for UniPro 256 T_TstDstInterFCTokenGap 0x40A9 Integer µs 0 to 65535 0 .

All rights reserved. MIPI Alliance Member Confidential 272 T_TstDstErrorCode 0x40AB Enumeration NO_ERROR=0 FRAGMENT_CORRUPT=1 NO_ERROR INVALID_MSG_SIZE=2 UNEXPECTED_BYTE_VALUE=3 MIPI Alliance Specification for UniPro .req after enabling the TstDst Error code that generated the TstDst disconnection Integer Byte 1 to T_MaxE2EFCCredits 256 Copyright © 2007-2011 MIPI Alliance.Table 106 Attribute Attribute ID TstDst (settable. Inc.40. gettable) Attributes (continued) Description Type Unit Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1.00 31-Jan-2011 T_TstDstInitialFCCredits 0x40AA The initial number of credits passed by the TstDst to T_CO_FLOWCONTROL.

are left out.e. Copyright © 2007-2011 MIPI Alliance. DestDeviceID_Enc). i.40.16 Transport Layer and Network Layer Interaction 2861 The generation of a T_CO_DATA. the parameters are in the defined valid range 2864 The receipt of one or multiple Network Layer-specific N_DATA_SHDR.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8.ind Service Primitives associated with delivery of a data unit causes the Transport Layer to generate a T_CO_DATA. MIPI Alliance Member Confidential 273 . All rights reserved. in case: 2862 • 2863 • The Segment processing for transmission has been performed successfully The Service Primitives are called correctly. For simplicity. e. in case: 2865 • The Segment processing for reception has been performed successfully (even with a potentially incomplete Message) 2866 The Message Sequence Chart in Figure 89 illustrates a possible interaction scenario between a Transport Layer and a Network Layer. certain parameters.req Service Primitives by the Transport Layer.g.ind. When appropriate.Version 1. settings of header fields are embedded for a better understanding. Inc.req results in the generation of one or multiple Network Layer-specific N_DATA_SHDR.

req(T_PDU[FCT=1]) Copyright © 2007-2011 MIPI Alliance.Version 1.40.cnf_L(SUCCESS) DT SH N_PDU (N_SDU) N_DATA_SHDR.req(T_PDU[EOM=0]) DT SH N_PDU (N_SDU) N_DATA_SHDR.ind(T_PDU[FCT=1]) FCT Received T_CO_DATA.req(Message) N_DATA_SHDR.req(Credits=300) T_CO_FLOWCONTROL. FRAGMENT_CORRECT) Figure 89 MSC of Network Layer and Transport Layer Interaction MIPI Alliance Specification for UniPro . T_E2EFCEnabled=TRUE.ind(T_PDU[EOM=0]) N_DATA_SHDR.ind(T_PDU[EOM=1]) T_CO_DATA.cnf_L(300.ind(Message.00 31-Jan-2011 TS Provider A NS Provider A NS Provider B TS Provider B CONNECTED. All rights reserved.ind(T_PDU[EOM=0]) N_DATA_SHDR. T_E2EFCEnabled=TRUE. T_[Rx/Tx]TokenValue = 256 T_CO_FLOWCONTROL. Inc.req(T_PDU[EOM=0]) DT SH N_PDU (N_SDU) N_DATA_SHDR. T_[Rx/Tx]TokenValue = 256 IDLE IDLE CONNECTED. MIPI Alliance Member Confidential 274 DT SH N_PDU (N_SDU) N_DATA_SHDR.req(T_PDU[EOM=1]) T_CO_DATA. SUCCESS) N_DATA_SHDR.

a settable Attribute shall be reset to its corresponding static Attribute.00 31-Jan-2011 MIPI Alliance Specification for UniPro 8.Version 1. All rights reserved. and to the Reset Value otherwise. 2870 At reset. MIPI Alliance Member Confidential 275 . Inc.40.17 Management Information Base and Protocol Constants 2867 Table 107 and Table 109 show the Transport Layer Attributes. 2868 Table 108 lists the Protocol Constants used within the protocol specification and within the Configuration and Capability Attributes. 2869 All Transport Layer Attributes should be readable. if one exists. Copyright © 2007-2011 MIPI Alliance. See Section 9 for more details.

00 31-Jan-2011 Table 107 Attribute Attribute ID Transport Layer (gettable. it allows CPort Attributes to be set. Inc. CPortID of the peer CPort.Version 1. which determines the value of the TC field in the Data Link Layer Header. the connection is active. settable) Attributes Description Type Units Valid Attribute Value(s) Mandatory Value(s) Reset Value Needed per CPort (Connection Parameters) Copyright © 2007-2011 MIPI Alliance. When set to CONNECTED. which is used to compute the DestDeviceID_Enc field in the Network Layer Header. ProtocolID value of the current Connection CPort control register: b0: End-to-End Flow Control (E2EFC) b1: Controlled Segment Dropping (CSD_n) b2: CPort Safety Valve (CSV_n) Value of a E2E FC Token transmitted Value of a E2E FC Token received Integer 0 to N_MaxDeviceID Any T_PeerCPortID 0x4022 Integer 0 to T_MaxCPortID Any T_ConnectionState 0x4020 Enum IDLE=0. and CPort Attributes cannot be changed. MIPI Alliance Member Confidential 276 T_PeerDeviceID 0x4021 DeviceID of the peer CPort. Traffic Class of current Connection. which is used to compute the DestCPortID_Enc of the Transport Layer and the DestDeviceID_Enc field in the Network Layer Header. n=5 to 24 2n. n=5 to 24 25 25 . 1 Supported Traffic Class(es) 0 to 65535 Any MIPI Alliance Specification for UniPro 0x4024 Integer 0 T_CPortFlags 0x4025 3-bit word All 1 1 T_TxTokenValue T_RxTokenValue 0x4026 0x4027 Integer Integer Bytes Bytes 2n. All rights reserved.40. State of the Connection. When set to IDLE. CONNECTED=1 IDLE T_TrafficClass T_ProtocolID1 0x4023 Integer 0.

Integer Integer Bytes Bytes 0 to T_MaxE2EFCCredits 0 to T_MaxE2EFCCredits 0 0 Copyright © 2007-2011 MIPI Alliance.40. When set to CPORT_UNDER_TEST. The value of this Attribute is dynamic. the CPort is used by the Transport Layer Test Feature. 2. CPORT_UNDER_TEST = 2 CPORT_APPLI CATION 1. settable) Attributes (continued) Description Type Units Valid Attribute Value(s) Mandatory Value(s) Reset Value Version 1.00 31-Jan-2011 Needed per CPort (Connection Parameters) T_LocalBufferSpace2 T_PeerBufferSpace2 T_CreditsToSend2 0x4028 0x4029 Amount of local buffer space as tracked by the local CPort Conservative value of the amount of buffer space at the peer CPort Amount of space in the local buffer that has not been communicated to the remote destination port yet CPort Mode. All rights reserved. MIPI Alliance Specification for UniPro Table 108 Attribute Transport Layer Protocol Constants Type Units Value Description T_MaxSegmentSize T_MaxHdrSize T_MTU T_MaxCPortID T_MaxE2EFCCredits Maximum Segment Size (T_PDU size) Maximum L4 header size Transport Layer Maximum Transfer Unit Maximum value of CPortID Maximum number of E2E FC credits Integer Integer Integer Integer Integer Byte Byte Byte T_MTU + T_MaxHdrSize 1 272 2047 232 – 1 Byte . When set to CPORT_APPLICATION.Table 107 Attribute Attribute ID Transport Layer (gettable. Reserved for future use. Inc. the CPort is used by the application. MIPI Alliance Member Confidential 277 0x402A Integer Bytes 0 to T_MaxE2EFCCredits 0 T_CPortMode 0x402B Enum CPORT_APPLICATION = 1.

Version 1.00 31-Jan-2011 Table 109 Attribute Attribute ID Transport Layer (gettable. 3. MIPI Alliance Member Confidential 278 1. The value of the capability Attribute T_TC1TxMaxSDUSize should not exceed (N_TC1TxMaxSDUSize – T_MaxHdrSize). MIPI Alliance Specification for UniPro . 2. Inc.40. The starting value depends on T_NumCPorts (see Table 102). The value of the capability Attribute T_TC0TxMaxSDUSize should not exceed (N_TC0TxMaxSDUSize – T_MaxHdrSize). All rights reserved. static) Attributes Description Type Unit Valid Attribute Value(s) T_NumCPorts T_NumTestFeatures1 T_TC0TxMaxSDUSize2 T_TC1TxMaxSDUSize3 0x4000 0x4001 0x4060 0x4061 Number of available CPorts Number of available Test Feature instances Maximum transmit payload (SDU) size per Segment for TC0 Maximum transmit payload (SDU) size per Segment for TC1 Integer Integer Integer Integer CPorts Test Features Byte Byte 1 to T_MaxCPortID 1 or 2 to T_NumCPorts 1 to T_MTU 1 to T_MTU Copyright © 2007-2011 MIPI Alliance.

2872 The DME is the Service Provider with respect to Control (see Section 9.2) services described below.1) and Configuration (see Section 9. The DME service usage in relation to these layer services is explained in more detail in this section. Data Link and PHY Adapter Layers. All rights reserved. Inc. Application Layer (LA) DME SAP T_LM SAP Transport Layer (L4) Device Management Entity (DME) N_LM SAP Network Layer (L3) DL_LM SAP PA_LM SAP Data Link Layer (L2) PHY Adapter Layer (L1. It aims to provide as much implementation flexibility as possible given the restrictions needed to achieve a high degree of interoperability. in order to fulfill the service provision. the DME assumes certain services from the Transport. 2873 Figure 90 shows the SAP model used for the Device Management Entity.5) Figure 90 Device Management Entity SAP Model 2874 The functionality of the DME can be divided into two entities. MIPI Alliance Member Confidential 279 .40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9 Device Management Entity (DME) 2871 This section defines the services provided by the DME. Network. Control and Configuration. Copyright © 2007-2011 MIPI Alliance.Version 1. In turn.

Table 110 Destination Layer DME Attributes Routing Rules DME Action LayerID (Bits 14:12) PHY (L1) PA (L1. All rights reserved. a 3-bit layer identifier (see Table 110) and a 12-bit layer-specific AttributeID. EndPointReset and the hibernate entry and exit sequences for the lower UniPro stack layers. 9.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.5) DL (L2) N (L3) T (L4) DME 000 001 010 011 100 101 110 and 111 Route to PHY via PA (L1. see Table 113). the layer-specific AttributeID is implementation-specific. it shall respond with the INVALID_MIB_ATTRIBUTE error code (ConfigResultCode. UniPro Cold Reset. MIPI Alliance Member Confidential 280 .2. UniPro Warm Reset and EndPointReset. The provision of these resets is mandatory for a UniPro implementation.2 Attribute Routing 2878 The DME Configuration entity shall route requests based on the AttributeID to UniPro stack layers as shown in Table 110. Figure 91 provides the format of the Attribute address.40. If the destination layer does not have an Attribute corresponding to AttributeID.5) Route to PA (L1.5) Route to DL (L2) Route to N (L3) Route to T (L4) Access local DME Attributes DME shall respond with INVALID_MIB_ATTRIBUTE 9. power mode changes.2. When Bit 15 of the AttributeID is set to zero. 9. either this document or [MIPI05]. it manages the Link Startup Sequence. the layer-specific AttributeID is defined in the relevant section of the appropriate specification. Inc.2 DME Configuration 2876 The DME Configuration entity routes Get and Set requests to the appropriate layer.Version 1. The Attribute address is a 16-bit AttributeID that has two sub-fields. Copyright © 2007-2011 MIPI Alliance. In addition. power-off and reset for the entire UniPro stack.3 DME Service Functionality and Features 2879 Three types of reset are defined in this section. When bit 15 is set to one. Attribute ID 1 5 1 4 1 2 1 1 0 0 LayerID AtrributeID (layer) Attribute Address Format Figure 91 9.1 Attributes 2877 The DME Configuration uses Attributes to access configurable parameters in various UniPro protocol layers.1 DME Control 2875 The DME Control entity is responsible for power-on.

the UniPro Link is disabled and it can either be instructed to enter the Off State (DME_POWEROFF. All rights reserved. 2882 The different types of reset are summarized in Table 111.9). The assumed features of other layers are defined in Section 9. Application Application – – – TRG_EPR YES YES NO 2883 At the end of a UniPro Cold Reset or UniPro Warm Reset procedure.40.2 UniPro Warm Reset 2889 UniPro Warm Reset has a very similar effect as the Cold Reset. all Attributes including statistics. including Attributes UniPro Cold Reset UniPro Warm Reset EndPointReset UniPro Statistics Endpoint Applicatio n Local Trigger Remote Trigger YES YES NO YES NO NO NO NO YES POR. error counters and error flags shall be reset to their reset states and all data buffers shall be cleared.req from the DME User it shall reset the entire UniPro stack using the <layer-identifier>_LM_RESET. Transport Layer (L4) through PHY Adapter Layer (L1. and the respective Attributes.5).00 31-Jan-2011 MIPI Alliance Specification for UniPro 2880 Cold Reset and Warm Reset affect the entire UniPro stack. 2884 The three types of reset are described in Section 9.2. 2888 The Cold Reset is not intended to reset the local Application.3. if any. It may also be triggered by the DME User on reception of a DME_LINKLOST. A UniPro Warm Reset may be triggered by the local Endpoint Application when an unrecoverable UniPro stack failure was detected.1 UniPro Cold Reset 2885 UniPro Cold Reset is the fundamental UniPro reset. while Warm Reset does not. The effect of the EndPointReset trigger on the Application. on the local side of a Link. 2881 EndPointReset is a method to trigger a reset of the remote Application over the Link.5 to L4). MIPI Alliance Member Confidential 281 .11.7. is endpoint-specific and out of scope for this document. It cannot be directly triggered by a Link Startup sequence.req primitive (see Section 9. 2886 The Cold Reset shall return all layers to their initial condition. Section 9.req). At the end of the Reset procedure the Link reaches the Disabled state.req primitives.1.4. For further information see Figure 98 and Section 9. 9.3. Table 111 Reset Scope and Triggers Results in Boot Procedure Reset Scope UniPro Stack. 9. The difference between Warm Reset and Cold Reset is that Cold Reset clears statistics. but shall not be triggered by a POR event.11.2. or move to the Off State using the DME_POWEROFF.ind.3. It shall be triggered by any power-on reset (POR) event. In the Disabled state the DME User can invoke the Boot procedure using the DME_ENABLE. Copyright © 2007-2011 MIPI Alliance.2).req primitive.req). All protocol state machines.2 and Section 9. indicating that the peer Device has undergone a reset and has initiated the Link Startup sequence (see Section 5. The DME shall address the layers in bottom up order (L1.3.3. or a Boot process shall be initiated (DME_ENABLE. or by the local Endpoint Application.Version 1. timers. Inc. 2887 When the DME receives a DME_RESET.3.

error counters and error flags shall not be cleared.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2890 The Warm Reset shall return all layers to their initial condition. During hibernation. 2893 The remote UniPort shall indicate the reception of this trigger event to its Endpoint Application. The UniPro stack retains a minimal state as defined by each stack layer. Persistent values may be stored and provisioned in a form of NVM/eFuse storage. The default retention policy (required for Hibernate) for each Attribute in a UniPro layer is determined by the Application. and the UniPro stack keeps only a minimal set of features active. The resulting action performed by the remote Endpoint Application is optional. All protocol state machines. All rights reserved. If the Endpoint Application resets itself. Inc.4 Initializing UniPro Attributes after Reset 2895 All UniPro Attributes shall reset to a default value specified in the MIB Attribute tables of each layer section (L1. It may reset itself or may refuse to react to the trigger. 9. 2898 Hibernate is a UniPro state in which the PHY is in the HIBERNATE_STATE.5 to L4 and the DME). However.8. ‘TRG_EPR’ shall be sent only during SlowAuto_Mode. timers. it shall also apply a Warm Reset to its UniPort. and Attributes shall be reset to their reset states and all data buffers shall be cleared.Version 1. 2894 The PA Layer shall send the ‘TRG_EPR’ over logical PHY Data Lane #0. 9. 2899 Figure 92 describes Link hibernation where one Device. The retention polices for these Attributes are described in each Attribute section of the relevant layer section. T_CO_SAP. During hibernation. have undefined behavior. 2896 An Application may update or override the default or persistent value on-demand. the DME continues to be available for the DME User. UniPro shall mandate a subset of Attributes to be retained. 9.7. the UniPro stack is not available to carry Application-level data transfer/communication. Sending this trigger event may be requested by the local Endpoint Application using the DME_ENDPOINTRESET. typically a Host Device.6.3 EndPointReset 2892 The EndPointReset is a means for the local Application to request the remote Endpoint Application to reset itself. initiates Link hibernation with a remote Device. Therefore. the EndPointReset has no further effect on the UniPro stack. Some UniPro Attributes can load a persistent value instead.3. Attributes that can load a persistent value are described in each Attribute section of the relevant layer section.5 Hibernate (M-PHY only) 2897 Hibernate is a UniPro state. 2891 The Warm Reset is not intended to reset the local Application. If this action is not performed.The procedures for entering and exiting hibernate are only defined for M-PHY. It is essentially a remote trigger event (TRG_EPR) transferred across a UniPro Link. The difference from Cold Reset is that status fields including statistics. 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. MIPI Alliance Member Confidential 282 . Section 5. The mapping of ‘TRG_EPR’ to the PHY is defined in the PHY-specific sections.8 and Section 5. and the primitives of the Application-level interface. Copyright © 2007-2011 MIPI Alliance.40.req primitive.

PA Layer and DME.L4 exchange Figure 93 9. which describes the entry flow up until the Application is ready to start the enter hibernation procedure. (Remote) Application Layer exchanges messages to prepare for link hibernation PACP_PWR to Hibernate Hibernate L4 Hibernate L3 Hibernate L2 Application level exchange PA level exchange (PACP) DME->L2. Annex G. 9.1. A detailed flow showing SAP primitives is described in the following sections.L3.1 Hibernate High Level Entry Flow Hibernate Entry Phase 1 Flow for Peer-to-Peer (P2P) Devices 2905 Figure 94 depicts the Hibernate Entry Phase 1 MSC flow for peer Devices. The color coding in Figure 93 divides the hibernate entry flow down into steps that require exchanging data at the Application Layer.5.5 – L4) UniPro (L1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Device A (Local/Host) UniPort Peer-to-Peer Link Control Arrow Indicating Initiator of Hibernate / Un-hibernate Device B (Remote) Figure 92 Hibernating a Peer-to-Peer Link 2900 The following sections describe the hibernate entry and exit flow. provides an informative description of recommended Copyright © 2007-2011 MIPI Alliance. 2902 The Hibernate Entry Flow is explained in two key phases: 2903 • 2904 • Phase 1. All rights reserved.Version 1. MIPI Alliance Member Confidential 283 . which describes the entry flow after the Application has instructed the UniPro stack to enter hibernation. App (Local) DME UniPro (L1. Inc.5-L4) DME App. Phase 2.5. As described in the hibernate overview section. the Application shall exchange pre-conditions for hibernate entry at the Application level before a UniPro stack can enter hibernate.40.1 Entering Hibernate 2901 Figure 93 shows a high level MSC flow for entering hibernate.

req to the DME. the Application shall initiate phase 2 sending a DME_HIBERNATE_ENTER. reads versioning info. (Remote) App. App (Local) DME UniPro L4 UniPro L4 DME App. subsequent layers of the local or remote UniPro stack (L4 to L2) are hibernated by the DME by sending an xx_LM_HIBERNATE_ENTER. The DME in turn initiates UniPro stack hibernate by sending PA_LM_HIBERNATE_ENTER.7). Once the Application level pre-condition is completed. 2907 Once the PA Layer has successfully hibernated the M-PHY Link. the Application is ready to hibernate the UniPro stack.Version 1.40.2 Hibernate Entry Flow Phase 1 Hibernate Entry Phase 2 Flow 2906 Figure 95 depicts the Hibernate Entry Phase 2 flow in UniPro.req SAP primitive to the local PA Layer. These recommended pre-conditions guarantee that there is no outstanding data in the UniPro stack. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro pre-conditions that should be exchanged by an Application.5. All rights reserved. MIPI Alliance Member Confidential 284 . for link Application prepares link for hibernate at application level Application level exchange Figure 94 9. The local PA Layer receives this request and places the M-PHY Link into hibernate using the PACP protocol (detailed description of PACP protocol can be found in Section 5.1. Inc.8.req SAP primitive to the respective layer. Once the Application level pre-conditions successfully complete.

cnf_L N_LM_HIBERNATE_ENTER.L3.ind T_LM_HIBERNATE_ENTER. The DME in turn initiates UniPro stack un-hibernate by sending PA_LM_HIBERNATE_EXIT.cnf_L DME_HIBERNATE_ENTER.req N_LM_HIBERNATE_ENTER.cnf_L DL_LM_HIBERNATE_ENTER.ind PA level exchange (PACP) DME->L2.cnf_L PACP_PWR to Hibernate WaitInd PA_LM_HIBERNATE_ENTER.00 31-Jan-2011 MIPI Alliance Specification for UniPro App (Local) DME UniPro (L1. Copyright © 2007-2011 MIPI Alliance.ind T_LM_HIBERNATE_ENTER.req DL_LM_HIBERNATE_ENTER.cnf_L N_LM_HIBERNATE_ENTER.req PA_LM_HIBERNATE_ENTER.40.req DL_LM_HIBERNATE_ENTER. The local PA Layer receives this request and un-hibernates the M-PHY Link using the PACP protocol (detailed description of PACP protocol can be found in section 5).Version 1.req to the DME.req N_LM_HIBERNATE_ENTER.req T_LM_HIBERNATE_ENTER.req T_LM_HIBERNATE_ENTER. MIPI Alliance Member Confidential 285 .5-L4) DME App.cnf_L DME_HIBERNATE_ENTER.cnf_L DME_HIBERNATE_ENTER.req primitive to the respective layers.5-L4) UniPro (L1.req WaitCnf PA_LM_HIBERNATE_ENTER.req SAP primitive to the local PA Layer. (Remote) DME_HIBERNATE_ENTER.cnf_L DL_LM_HIBERNATE_ENTER. All rights reserved.5. 2910 Once the PA Layer has successfully un-hibernated the M-PHY Link.L4 exchange Figure 95 Hibernate Entry Flow Phase 2 9. subsequent layers of the local and remote UniPro stack (L4 to L2) are un-hibernated by the DME by sending an xx_LM_HIBERNATE_EXIT.2 Exiting Hibernate (Un-hibernate) 2908 Figure 96 shows the hibernate exit flow. 2909 The Application shall initiate hibernate exit by sending DME_HIBERNATE_EXIT. Inc. The Application shall be responsible for un-hibernating a UniPro Link.ind PA_LM_HIBERNATE_ENTER.

The Application is responsible for handling failures to hibernate or un-hibernate the Link.8.cnf_L DME_HIBERNATE_EXIT.5.ind PA_LM_HIBERNATE_EXIT.cnf_L DL_LM_HIBERNATE_EXIT.12.req PA_LM_HIBERNATE_EXIT.cnf_L N_LM_HIBERNATE_EXIT.40. power state M-PHY signaling WaitInd PA_LM_HIBERNATE_EXIT. 9.L3. The Application can also only perform a Link initialization.req DL_LM_HIBERNATE_EXIT.req N_LM_HIBERNATE_EXIT.req WaitCnf PA_LM_HIBERNATE_EXIT.3 Failing to Enter or Exit Hibernate 2911 The DME sends confirmation of a hibernate or un-hibernate request to the Application.req T_LM_HIBERNATE_EXIT.req T_LM_HIBERNATE_EXIT.req N_LM_HIBERNATE_EXIT.cnf_L DME_HIBERNATE_EXIT. Copyright © 2007-2011 MIPI Alliance.5-L4) UniPro (L1. Detailed description is specified in Section 5.ind T_LM_HIBERNATE_EXIT. the Application should retry the request.ind UniPro Application Layer exchanges messages to un-hibernate link Application level exchange PA level exchange (PACP) DME->L2. (Remote) DME_HIBERNATE_EXIT.ind T_LM_HIBERNATE_EXIT.cnf_L PA returns to prev.Version 1. the DME should report persistent failure to the Application.00 31-Jan-2011 MIPI Alliance Specification for UniPro App (Local) DME UniPro (L1. The power mode change from the DME perspective is provided in Figure 97. In all cases.L4 exchange Figure 96 Hibernate Exit Flow 9. Upon failure. Inc.req DL_LM_HIBERNATE_EXIT. or retry the request then perform a Link initialization.cnf_L N_LM_HIBERNATE_EXIT. MIPI Alliance Member Confidential 286 .cnf_L DME_HIBERNATE_EXIT.5-L4) DME App. All rights reserved.6 DME Power Mode Change 2912 The power mode change from the local PA Layer’s perspective is depicted in Figure 43.cnf_L DL_LM_HIBERNATE_EXIT.

The second phase is missing if the power mode change request fails. and PA_RxTermination • PA_HSSeries If the return value of any PA_LM_SET. the request has failed.ind DME_POWERMODE. 2919 The local PA Layer provides a method to transmit data between two peer DME entities.4. All rights reserved.req primitive as follows: • • for TX: PA_ActiveTxDataLanes.rsp_L PA_LM_PWR_MODE_CHANGED. 2921 The procedure in brief: 2922 • 2923 2924 2925 2926 • 2927 • 2928 • 2929 • Set the parameter values of the PA Layer Attributes using the PA_LM_SET.cnf_L PA_LM_SET.00 31-Jan-2011 MIPI Alliance Specification for UniPro Write PA_PWRModeUserData 0 to 11 DME USER DME_POWERMODE. which is done by setting PA_PWRMode.req DME PA_LM_SET.cnf_L(Success) PA_LM_PWR_MODE.ind Last cnf_L Primitive Figure 97 Power Mode Change (DME Perspective) 2913 The power mode change in the DME level may be split into the following three distinctive phases: 2914 • 2915 • 2916 • Issue a request to the local PA Layer Update the local L2 timer values 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.ind DL_LM_SET. All power mode related Attributes shall be set before activating the power mode change request.5) DL (L2) Last cnf_L Primitive Write timers in DL DME_POWERMODE.cnf_L PA_LM_PWR_MODE.g. due to capability mismatch Set the PA_PWRMode using the PA_LM_SET.1 Issuing the Request 2920 The power mode configuration shall be given to the local PA Layer via LM SAP. PA_RxGear.6.req DL_LM_SET. then the local PA Layer has accepted the request Wait for the PA_LM_PWR_MODE_CHANGED. PA_TxGear. 9.req primitive If the return values is SUCCESS.40. The local data is sent to the peer DME and the peer DME’s response is reported back.req PA_LM_SET.Version 1. and PA_TxTermination for RX: PA_ActiveRxDataLanes. The payload is twenty-four bytes of data (see Table 8) to fit all L2 timer values for all TCs. e.1.7) Copyright © 2007-2011 MIPI Alliance.cnf_L primitive was not SUCCESS.ind primitive (see Section 5. MIPI Alliance Member Confidential 287 .cnf_L(Success) PA (L1.req(PA_PWRMode) PA_LM_SET. Inc.

This indicates that the power mode change request was created by a remote DME. SET.req primitives.9 the local Network layer via the layer’s N_LM_SAP as defined in Section 7. and the LocalL2TimerData parameter of the DME_POWERMODE. which carries the P W R M o de U s e r D a t a in f o r m a t i o n t o t h e p e e r D M E . the local DME shall receive the primitive even though it did not issue the power mode change request. 2935 When the DME has finished updating the local L2 timer values. All rights reserved. ENABLE and HIBERNATE (ENTER. that is.4 the local PHY Adapter layer via the layer’s PA_LM_SAP as defined in Section 5. I n t h e c u r r e n t v e r s i o n o f U n i P r o .8 DME_SAP 2949 The primitives on this Service Access Point are intended to be used by an Application Layer.ind primitive when the timer values in the L2 Layer can be updated.40. 2931 There are two parameters in the PA_LM_PWR_MODE. the DME shall wait until the local PA Layer returns with the PA_LM_PWR_MODE_CHANGED. WARM). 2936 The local PA Layer informs the local L2 layer internally when the L2 timers can be re-started. In this case the second parameter.ind primitive. PAPowerModeUserData. PAResult is set to FALSE. 2938 The PA_LM_PWR_MODE_CHANGED. RESET (COLD.ind primitive. EXIT) primitives 2946 The DME further requires the PHY Adapter layer to support the following features: 2947 • 2948 • Methods to send and receive the Link Startup sequence Methods to send and receive the EndPointReset trigger 9. a component that is higher in the reset hierarchy than the UniPro stack. This indicated that the power mode change request was created by the local DME. In this case the second parameter is discarded. it informs the local PA Layer to resume using the PA_LM_PWR_MODE.4 2939 The DME is associated with: 2944 The DME requires each associated layer to support the following features: 2945 • The GET. 2934 The DME shall update the local L2 timer values using the DL_LM_SET.6. This primitive contains a parameter.7 2940 2941 2942 2943 • • • • Features Assumed from Other Layers the local Transport layer via the layer’s T_LM_SAP as defined in Section 8.rsp_L primitive shall be set to the reserved value. When the peer DME initiates the request.7 the local Data Link layer via the layer’s DL_LM_SAP as defined in Section 6. 9. Parameter values are defined in Table 9. Inc. the L2 timers are stopped due to a request by the local PA Layer.3 Completion 2937 If the power mode change request was accepted. t h e PAPowerModeUserData parameter in the PA_LM_PWR_MODE. At that point. Two scenarios are defined by the value of PAResult: 2932 • PAResult and 2933 • PAResult is set to TRUE.ind primitive has a parameter indicating the result of the power mode change operation.6.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.2 Updating L2 Timer Values 2930 The local PA Layer is informed with the PA_LM_PWR_MODE. contains the content of the remote DME’s PA_PWRModeUserData Attribute and shall be used to program the L2 timers.req primitive shall be used to program the L2 timers.Version 1.rsp_L primitive. MIPI Alliance Member Confidential 288 . Copyright © 2007-2011 MIPI Alliance. PA_PWRModeUserData. 9.

for CPort Integer 0 to T_NumTestFeatures – 1.4 9. a Host shall support the DME_PEER_GET.xxx and the DME_PEER_SET. These primitives are optional for a Peripheral. Table 113 Name Type DME_SAP Configuration Primitive Parameters Valid Range Value Description NORMAL AttrSetType Enum 0 STATIC 1 Select whether an Attribute value is set in runtime (Normal) or the Attribute’s non-volatile (Static) value is overwritten The address of the MIBattribute Indicates the targeted M-PHY data lane or CPort or Test Feature when relevant MIBattribute Integer 0x0000 to 0x7FFF 0 to 2*PA_MaxDataLanes – 1.8.2 9.Version 1. needs this capability. Both Host and Peripheral shall support DME_GET.2 9. of the DME provides the means to retrieve and store values.1.8.8.1.1 9.7 9.40. for M-PHY 0 to T_NumCPorts – 1. MIPI Alliance Member Confidential 289 . for Test Feature GenSelectorIndex Copyright © 2007-2011 MIPI Alliance. Hence. respectively.8. Inc. usually the Host.1.8.1.1.8. Table 112 Name DME_SAP Configuration Primitives Indication Local Response Response Local Confirm Confirm Request DME_GET DME_SET DME_PEER_GET DME_PEER_SET 9. primitives.xxx and DME_SET.1 Configuration Primitives 2950 The configuration primitives.8 2951 The DME shall have remote access to Attributes of the peer Device on the UniPro Link via the local PA Layer.1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.8. for the configuration Attributes found in the UniPro stack and in the underlying PHY Layer. at least one Device on each UniPro Link.1. All rights reserved. 2952 Even if the capability to request the access to remote Attributes is optional for a single Device.8.8. GET and SET.1.xxx primitives.6 9.xxx.5 9.

or otherwise the Attribute indicated by MIBattribute and SelectorIndex is not implemented.req SelectorIndex is outside of the range of available CPorts. All rights reserved. The Attribute indicated by MIBattribute and SelectorIndex exists. INVALID_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE READ_ONLY_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE BAD_INDEX The CPort indicated by T_LM_SET. the Attribute indicated by MIBattribute and SelectorIndex does not support setting its reset value. Table 114 ConfigResultCode ConfigResultCode Values Condition SUCCESS The request succeeds. or otherwise If AttrSetType is STATIC. the value or the reset value of the Attribute indicated by MIBattribute and SelectorIndex is set to the value of MIBvalue. or outside of the valid value range. This ConfigResultCode value shall only be used if AttrSetType is NORMAL. MIBvalue 2953 Table 114 provides further explanation to the various Return Codes. but is not settable.40. but the value of MIBvalue is outside of the implemented range.Version 1. Copyright © 2007-2011 MIPI Alliance. The MIBattribute value is invalid. for the Attribute. Inc. MIPI Alliance Member Confidential 290 . The Attribute indicated by MIBattribute and SelectorIndex exists and is settable (AttrSetType = NORMAL) or allows its reset value to be set (AttrSetType = STATIC).00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 113 Name DME_SAP Configuration Primitive Parameters (continued) Type Valid Range Value Description SUCCESS INVALID_MIB_ATTRIBUTE INVALID_MIB_ATTRIBUTE_VALUE READ_ONLY_MIB_ATTRIBUTE WRITE_ONLY_MIB_ATTRIBUTE ConfigResultCode Enum BAD_INDEX LOCKED_MIB_ATTRIBUTE BAD_TEST_FEATURE_INDEX PEER_COMMUNICATION_FAILURE BUSY DME_FAILURE Variable 0 1 2 3 4 5 6 7 8 9 10 The value of the MIB Attribute. i.e. The MIB value size cannot exceed thirty-two bits Indicates the result of the request (see further explanation in Table 114).

or equal to. Addressing is done based on the MIBattribute and the GenSelectorIndex if relevant.1. GenSelectorIndex ) 2958 When Generated 2959 This primitive is generated by the DME User to obtain information from a local Attribute of the UniPro stack. T_NumTestFeatures. i. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending on the Attribute.req SelectorIndex is greater than.8. This value shall be used if the DME fails to perform a GET or SET operation because the layer being addressed by the DME is in an inaccessible state. Only the UniPro stack may delay a primitive processing and cause a BUSY condition. This ConfigResultCode value shall only be used if AttrSetType is NORMAL.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 114 ConfigResultCode ConfigResultCode Values (continued) Condition LOCKED_MIB_ATTRIBUTE The Attribute indicated by MIBattribute and SelectorIndex exists and is settable. setting power mode or remote Attribute access. PACP remote configuration protocol has encountered error. 2960 Effect on Receipt 2961 The DME determines which layer should be accessed and forwards the GET request to that layer.40.req( MIBattribute.8. 2962 Behavioral Description 2963 The state diagram describing the behavior of the primitive is shown in Figure 422 of [MIPI02].1. 2965 The semantics of this primitive are: 2966 DME_GET. the GenSelectorIndex. 9.1 DME_GET.req 2955 This primitive shall be used to request information from a specific Attribute identified by MIBattribute and. but it belongs to a CPort that is in the CONNECTED state. The value of T_LM_GET. Previous operation related to setting Attribute has not been completed. MIPI Alliance Member Confidential 291 .e. For Attributes not associated with a GenSelectorIndex.cnf_L 2964 This primitive reports the results of a GET request. 2956 The semantics of this primitive are: 2957 DME_GET. The DME User shall not issue a new request primitive before the previous one has terminated. All rights reserved.2 DME_GET. Inc. if relevant. 9. MIBvalue ) Copyright © 2007-2011 MIPI Alliance.cnf_L( ConfigResultCode. BAD_TEST_FEATURE_INDEX PEER_COMMUNICATION_FAILURE BUSY DME_FAILURE 2954 The DME shall use a request/confirmation handshake for the GET and SET primitives.Version 1. the GenSelectorIndex shall be ignored.

req( AttrSetType.req primitive (see Section 9. GenSelectorIndex ) 2977 When Generated 2978 This primitive is generated by the DME User to set the value of a local Attribute of the UniPro stack or underlying PHY.1. 2988 The ConfigResultCode field includes a result code from the layer that was previously addressed using the DME_GET. If the ConfigResultCode is not SUCCESS. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute. the GenSelectorIndex. The corresponding. MIBvalue.40. the GenSelectorIndex shall be ignored. otherwise MIBvalue hold the value of the requested Attribute.2. Copyright © 2007-2011 MIPI Alliance. 2979 Effect on Receipt 2980 The DME determines which layer should be accessed and forwards the SET request to that layer. 2970 Effect on Receipt 2971 The DME User may generate a new DME_GET.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2967 When Generated 2968 This primitive is generated by the DME in response of the DME_GET. the MIBvalue shall be ignored.req or DME_SET. 2969 The ConfigResultCode field includes a result code from the layer that was previously addressed using the DME_GET. 9.2).req 2974 This primitive shall be used to set the value of a specific Attribute identified by MIBattribute and.cnf_L primitive serves to provide information on any errors that may have occurred.8. All rights reserved. 2972 Behavioral Description 2973 The state diagram describing the behavior of the primitive is shown in Figure 422 of [MIPI02].Version 1. if relevant.8.2. 2981 Behavioral Description 2982 The state diagram describing the behavior of the primitive is shown in Figure 421 of [MIPI02]. For Attributes not associated with a GenSelectorIndex.cnf_L 2983 This primitive shall be used to report the results of a SET request. and also serves as a synchronizing handshake. MIPI Alliance Member Confidential 292 .3 DME_SET. MIBattribute.cnf_L( ConfigResultCode ) 2986 When Generated 2987 This primitive is generated when the layer has finished processing the SET request.2). 2984 The semantics of this primitive are: 2985 DME_SET. 9. 2975 The semantics of this primitive are: 2976 DME_SET. Addressing is done based on the MIBattribute and GenSelectorIndex if relevant.req primitive when the GET request is completed.req primitive (see Section 9.1.req primitive.4 DME_SET. Inc.

it shall implement it as described in this section. MIBvalue ) 3007 When Generated 3008 This primitive is generated by the DME in response of the DME_PEER_GET. if an implementation supports this primitive. it shall also support the DME_PEER_GET. 2999 Effect on Receipt 3000 The DME will forward the request to the local PA Layer by generating the PA_LM_PEER_GET.6 DME_PEER_GET. 3009 Effect on Receipt 3010 The DME User may generate a new DME_PEER_GET.req or DME_SET. For Attributes not associated with a GenSelectorIndex. in the peer Device. Copyright © 2007-2011 MIPI Alliance. the MIBvalue shall be ignored. 9.cnf( ConfigResultCode. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute.req primitive.1. If the ConfigResultCode is not SUCCESS. GenSelectorIndex ) 2997 When Generated 2998 This primitive is generated by the DME User to obtain information from an Attribute located in the UniPro stack of the peer Device. identified by MIBattribute and. 2995 The semantics of this primitive are: 2996 DME_PEER_GET. All rights reserved. if relevant. MIPI Alliance Member Confidential 293 . However.req primitive.5 DME_PEER_GET. 3005 The semantics of this primitive are: 3006 DME_PEER_GET.req or DME_PEER_SET.00 31-Jan-2011 MIPI Alliance Specification for UniPro 2989 Effect on Receipt 2990 The DME User may generate a new DME_GET.req primitive when the GET request is completed.cnf 3003 This primitive shall be supported by a Host and is optional for a Peripheral. 3001 Behavioral Description 3002 The state diagram describing the behavior of the primitive is shown in Figure 427 of [MIPI02].req primitive.8. 9.Version 1. Inc.8.req primitive is supported by an implementation.cnf primitive as described in this section. the GenSelectorIndex shall be ignored.req 2993 This primitive shall be supported by a Host and is optional for a Peripheral. If the DME_PEER_GET. 2994 This primitive shall be used to request information from a specific Attribute. 2991 Behavioral Description 2992 The state diagram describing the behavior of the primitive is shown in Figure 421 of [MIPI02].req( MIBattribute. the GenSelectorIndex.40.1. otherwise the MIBvalue hold the value of the requested Attribute. 3004 This primitive reports the results of a GET request.

3015 The semantics of this primitive are: 3016 DME_PEER_SET. if an implementation supports this primitive. 9.req 3013 This primitive shall be supported by a Host and is optional for a Peripheral. Inc. MIBattribute. if relevant.1. Copyright © 2007-2011 MIPI Alliance. the GenSelectorIndex shall be ignored.cnf primitive.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3011 Behavioral Description 3012 The state diagram describing the behavior of the primitive is shown in Figure 427 of [MIPI02]. MIPI Alliance Member Confidential 294 . All rights reserved.req or DME_PERR_SET.cnf primitive as described in this section. However. of the peer Device.cnf( ConfigResultCode ) 3027 When Generated 3028 This primitive is generated after the reception of the PA_LM_PEER_SET.cnf 3023 This primitive shall be supported by a Host and is optional for a Peripheral. the GenSelectorIndex.req primitive is supported by an implementation.req primitive. 3031 Behavioral Description 3032 The state diagram describing the behavior of the primitive is shown in Figure 427 of [MIPI02]. MIBvalue.req( AttrSetType.8 DME_PEER_SET. If the DME_PEER_SET. 3021 Behavioral Description 3022 The state diagram describing the behavior of the primitive is shown in Figure 427 of [MIPI02]. 9. it shall implement it as described in this section. GenSelectorIndex ) 3017 When Generated 3018 This primitive is generated by the DME User to set the value of an Attribute located in the UniPro stack or underlying PHY of the peer Device.7 DME_PEER_SET. 3025 The semantics of this primitive are: 3026 DME_PEER_SET. identified by MIBattribute and. For Attributes not associated with a GenSelectorIndex.8. The GenSelectorIndex shall be interpreted either as a data PHY Lane index or CPort index or Test Feature index depending of the Attribute.req primitive. 3024 This primitive shall be used to report the results of a SET request.1. 3019 Effect on Receipt 3020 The DME will forward the request to the local PA Layer by generating the PA_LM_PEER_SET. 3029 Effect on Receipt 3030 The DME User may generate a new DME_PEER_GET. 3014 This primitive shall be used to set the MIBvalue value of a specific Attribute.40. it shall also support the DME_PEER_SET.8.Version 1.

26 M M M M D.2.8.2.M D.11 9.2.2.2.8.8.16 9.8.23 9. D-PHY(D) or both (D.M D 3035 Table 116 lists the parameters that appear in the DME_SAP control primitives.19 9.M).2.2.8.2.2.2.4 9.40.2. 3034 The primitives covered in this section are listed in Table 115.8 9.Version 1.8.2.8.28 9.11 9.8.8.8.25 9.29 9.27 9.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.8.8.M D.8.2.M D.13 9.8. Table 115 Name Request DME_SAP Control Primitives Indication Local Response Response Local Confirm Confirm PHY DME_POWERON DME_POWEROFF DME_ENABLE DME_RESET DME_ENDPOINTRESET DME_LINKSTARTUP DME_LINKLOST DME_HIBERNATE_ENTER DME_HIBERNATE_EXIT DME_POWERMODE DME_TEST_MODE DME_ERROR DME_RXPWRSTATE 9.24 9.7 9.2.8.17 9.2.1 9.2.M D.8.8.2.18 9.8.22 9.M D.5 9.2.8.12 9.8.8.2.2 9. PHY column in the table defines applicability of the primitives to M-PHY(M).15 9.13 D.M 9.8.20 9. All rights reserved.8.2. MIPI Alliance Member Confidential 295 .2. RxPowerMode Enum FastAuto SlowAuto Unchanged Specifies the requested power mode Copyright © 2007-2011 MIPI Alliance.2. Inc.8.M D.2. Table 116 Name Type DME_SAP Control Primitive Parameters Valid Range Value Description GenericErrorCode Enum Success Failure Cold Warm Fast Slow 0 1 0 1 1 2 4 5 7 Report the outcome of the operation as success or failure Select whether a warm or a cold reset should be performed ResetLevel Enum TxPowerMode.21 9.8.2.8.2.8.6 9.3 9.8.2.2.8.2.2 Control Primitives 3033 The Service Primitives in this section are provided for controlling the reset and run mode of the entire UniPro protocol stack.2.8.9 9.

40. Table 117 Order Name L2 Timer Data Structure Type1 Description 0 DL_FC0ProtectionTimeOutVal 1 DL_TC0ReplayTimeOutVal 2 DL_AFC0ReqTimeOutVal 3 DL_FC1ProtectionTimeOutVal 4 DL_TC1ReplayTimeOutVal 5 DL_AFC1ReqTimeOutVal 6 reserved for TC2 7 reserved for TC2 8 reserved for TC2 9 reserved for TC3 10 reserved for TC3 11 reserved for TC3 1. 16-bit integer Integer Integer integer Integer Integer integer Integer Integer integer Integer Integer integer Flow control protection time-out value for TC0 Replay time-out value for TC0 AFC request time-out value for TC0 Flow control protection time-out value for TC1 Replay time-out value for TC1 AFC request time-out value for TC1 3037 Table 118 provides further references to the specific definition of the LayerErrorCode (see Table 116) in each layer. MIPI Alliance Member Confidential 296 . Unused and reserved bits should be set to one (‘1’).Version 1. Inc. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 116 Name DME_SAP Control Primitive Parameters (continued) Valid Range Value Description Type LocalL2TimerData Struct N/A N/A Data structure containing required local timer values for power mode change (see Table 117) Data structure containing required remote timer values for power mode change (see Table 117) See Table 9 RemoteL2TimerData PowerChangeResultCo de Struct N/A N/A Enum DME T 0x5 0x4 0x3 0x2 0x1 LayerNumber Enum N DL PA (and PHY) The layer that reported the error indicated by LayerErrorCode LayerErrorCode Integer N/A A layer specific error code reported back to the DME (See relevant layer chapter for the list of error codes and also Table 118) 3036 Table 117 defines the LocalL2TimerData and RemoteL2TimerData structure and order. Copyright © 2007-2011 MIPI Alliance.

it shall also support the DME_POWERON.2. MIPI Alliance Member Confidential 297 . via DME.req 3038 Support for this primitive is optional. Inc.cnf_L 3048 Support for this primitive is optional.req primitive is used to power on the layers L1.5 through L4 connected to the DME. 3046 Behavioral Description 3047 The state diagram describing the behavior of the primitive is shown in Figure 429 of [MIPI02]. 3054 Effect on Receipt 3055 The DME User knows that the DME has powered on all the UniPro stack layers. 3056 Behavioral Description 3057 The state diagram describing the behavior of the primitive is shown in Figure 429 of [MIPI02]. 9.cnf_L( GenericErrorCode ) 3052 When Generated 3053 This primitive is generated when powering on all the UniPro stack layers has been completed. 3044 Effect on Receipt 3045 The UniPro stack layers are powered on by the DME. 3049 The DME_POWERON. 3050 The semantics of this primitive are: 3051 DME_POWERON.req primitive is supported by an implementation. However.cnf_L primitive is used as a local confirm for the DME_POWERON.5 2 3 4 PHYErrorCode DLErrroCode L3DiscardReasonCode L4DiscardReasonCode Table 13 and Table 20 Table50 Table 71 Table 91 9. if an implementation supports this primitive. If the DME_POWERON. even in the POWEREOFF state. shall be able to receive and respond to DME_POWERON. 3039 The DME_POWERON.req primitive.2.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 118 Layer Layer Indicator LayerCodeError Mapping Reference Layer Error Code PA DL N T 1. it shall implement it as described in this section.req.req( ) 3042 When Generated 3043 This primitive is generated when the DME User powers on the UniPro stack. All rights reserved.2 DME_POWERON.cnf_L primitive as described in this section.1 DME_POWERON.40. The UniPro stack. 3040 The semantics of this primitive are: 3041 DME_POWERON. Copyright © 2007-2011 MIPI Alliance.Version 1.8.8.

if an implementation supports this primitive.req( ) 3081 When Generated 3082 This primitive is generated when the DME User wants to enable the UniPro stack. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9. 3069 The DME_POWEROFF.cnf_L 3068 Support for this primitive is optional. MIPI Alliance Member Confidential 298 .2. Copyright © 2007-2011 MIPI Alliance. 3060 The semantics of this primitive are: 3061 DME_POWEROFF. 9. 3066 Behavioral Description 3067 The state diagram describing the behavior of the primitive is shown in Figure 429 of [MIPI02]. 3079 The semantics of this primitive are: 3080 DME_ENABLE.req primitive is used to power off the layers L1.5 through L4 connected to the DME.req primitive is supported by an implementation. 9.2. However.2.req primitive. If the DME_POWEROFF.Version 1.8.5 DME_ENABLE.40. 3059 The DME_POWEROFF.cnf_L primitive as described in this section. 3076 Behavioral Description 3077 The state diagram describing the behavior of the primitive is shown in Figure 429 of [MIPI02].req 3058 Support for this primitive is optional. 3064 Effect on Receipt 3065 The UniPro stack layers are powered off by the DME.8. it shall implement it as described in this section.req 3078 The DME User uses this primitive to enable the UniPro stack. 3074 Effect on Receipt 3075 The DME User knows that the DME has powered off the UniPro stack layers. 3070 The semantics of this primitive are: 3071 DME_POWEROFF.3 DME_POWEROFF.req( ) 3062 When Generated 3063 This primitive is generated when the DME User powers off the UniPro stack. it shall also support the DME_POWEROFF.8.cnf_L( GenericErrorCode ) 3072 When Generated 3073 This primitive is generated when the powering off all the UniPro stack layers has been completed. Inc.cnf_L primitive is used as a local confirm for the DME_POWEROFF.4 DME_POWEROFF.

8.cnf_L( ) 3108 When Generated 3109 This primitive is generated when reset process has been completed.8.req 3096 The DME_RESET. 3094 Behavioral Description 3095 The state diagram describing the behavior of the primitive is shown in Figure 431 of [MIPI02]. 9.req primitive shall be used to reset the DME and the UniPro stack layers L1.Version 1.7 DME_RESET. 3085 Behavioral Description 3086 The state diagram describing the behavior of the primitive is shown in Figure 431 of [MIPI02]. All rights reserved.req primitive. 3088 The semantics of this primitive are: 3089 DME_ENABLE. 3103 Behavioral Description 3104 The state diagram describing the behavior of the primitive is shown in Figure 430 of [MIPI02].cnf_L( GenericErrorCode ) 3090 When Generated 3091 This primitive is generated when the enable procedure has been completed. 3097 The semantics of this primitive are: 3098 DME_RESET.cnf_L primitive shall be used as a local confirm for the DME_RESET. 9.6 DME_ENABLE.2.5 through L4 connected to it.8.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3083 Effect on Receipt 3084 The layers are enabled in order from bottom to top by the DME.40.2. 9. 3101 Effect on Receipt 3102 The UniPro stack is reset and changes state to the LinkDown state. MIPI Alliance Member Confidential 299 .2. Copyright © 2007-2011 MIPI Alliance. 3106 The semantics of this primitive are: 3107 DME_RESET.cnf_L 3087 This primitive is generated when the enable procedure has been completed.cnf_L 3105 The DME_RESET.8 DME_RESET.req( ResetLevel ) 3099 When Generated 3100 This primitive is generated when the DME User resets the UniPro stack through the DME. 3092 Effect on Receipt 3093 The DME User knows that the DME has enabled all the layers. Inc.

3133 The semantics of this primitive are: 3134 DME_ENDPOINTRESET. 9. 3112 Behavioral Description 3113 The state diagram describing the behavior of the primitive is shown in Figure 430 of [MIPI02]. 9.ind( ) Copyright © 2007-2011 MIPI Alliance.8.10 DME_ENDPOINTRESET. All rights reserved.9 DME_ENDPOINTRESET.req primitive shall be used to send an EndPointReset request command to the Link Endpoint.ind primitive shall be used to indicate that the EndPointReset request has been received.8. 3119 Effect on Receipt 3120 The EndPointReset command is sent by the local PA Layer to the Link Endpoint.req primitive by the DME. MIPI Alliance Member Confidential 300 .11 DME_ENDPOINTRESET.2.ind 3132 The DME_ENDPOINTRESET. 3128 Effect on Receipt 3129 The DME User knows that the EndPointReset command has been sent by the local PA Layer. 3115 The semantics of this primitive are: 3116 DME_ENDPOINTRESET. 3121 Behavioral Description 3122 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02].2.req 3114 The DME_ENDPOINTRESET.8. 3124 The semantics of this primitive are: 3125 DME_ENDPOINTRESET. 9.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3110 Effect on Receipt 3111 The DME User knows that the DME has completed the reset process. Inc.req( ) 3117 When Generated 3118 This primitive is generated when the DME User request the DME to perform a reset of the Endpoint.cnf_L( GenericErrorCode ) 3126 When Generated 3127 This primitive is generated when EndPointReset command has been sent by the local PA Layer.40. 3130 Behavioral Description 3131 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02].cnf_L 3123 The DME_ENDPOINTRESET.cnf_L primitive shall be used as a local confirmation for the reception of the DME_ENDPOINTRESET.2.Version 1.

Otherwise the Link remains in the LinkDown state.2. Inc.cnf_L( GenericErrorCode ) 3153 When Generated 3154 This primitive is generated when the start-up process has been completed successfully or error is encountered.req primitive. The success or failure is reported in the primitive parameter. 3157 Behavioral Description 3158 The state diagram describing the behavior of the primitive is shown in Figure 432 of [MIPI02]. 3139 Behavioral Description 3140 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02].40.2. 9.req( ) 3144 When Generated 3145 This primitive is generated when the DME User requests the DME to start the UniPro Link up process. 3146 Effect on Receipt 3147 First the DME starts the local PA Layer and then the local DL Layer with dedicated primitives in the PA_LM and DL_LM SAPs.8. the DME passes this confirmation to the DME User.Version 1. 3137 Effect on Receipt 3138 No automatic reset shall be performed. but it is up to DME User to respond accordingly.req 3141 The DME_LINKSTARTUP. 3155 Effect on Receipt 3156 If the Link start-up process was successful.cnf_L shall be used as a local confirm for the 3150 The DME_LINKSTARTUP.12 DME_LINKSTARTUP. 9. All rights reserved. the DME User knows that the UniPro Link is in the LinkUp state. 3148 Behavioral Description 3149 The state diagram describing the behavior of the primitive is shown in Figure 432 of [MIPI02].8. MIPI Alliance Member Confidential 301 . 3151 The semantics of this primitive are: 3152 DME_LINKSTARTUP.13 DME_LINKSTARTUP.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3135 When Generated 3136 This primitive is generated to the DME User when the EndPointReset response is received by the local PA Layer.req primitive shall be used to start the UniPro Link up. Copyright © 2007-2011 MIPI Alliance. 3142 The semantics of this primitive are: 3143 DME_LINKSTARTUP.cnf_L primitive DME_LINKSTARTUP.

8. 3178 The semantics of this primitive are: 3179 DME_HIBERNATE_ENTER.15 DME_LINKLOST.req primitive to complete the Link start-up process.ind( ) 3162 When Generated 3163 This primitive is generated when the Link start-up process initiated by the remote end has been detected by the local end.req( ) 3180 When Generated 3181 This primitive is generated when the DME User requests the Link to move into the Hibernate state.8.40. 3169 The semantics of this primitive are: 3170 DME_LINKLOST. 3164 Effect on Receipt 3165 The local DME must respond with DME_LINKSTARTUP. 9.2.ind primitive from the local PA Layer. 9.14 DME_LINKSTARTUP. 3175 Behavioral Description 3176 The state diagram describing the behavior of the primitive is shown in Figure 432 of [MIPI02]. This indicates a condition where the remote end is trying to re-establish a Link and the Link is lost. Copyright © 2007-2011 MIPI Alliance.req 3177 The DME_HIBERNATE_ENTER. 3173 Effect on Receipt 3174 The Link is put in the LinkLost state and the DME User must apply a DME_RESET to redo the boot sequence and get to the LinkUp state.req primitive shall be used to put the Link and all the UniPro layers into the Hibernate state to save power.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.ind 3159 The DME_LINKSTARTUP.ind 3168 The DME_LINKLOST. The DME passes this indication to the DME User.ind primitive shall be used as an indication that Link start-up process has been initiated by the remote end of the Link.ind primitive shall be used as an indication that Link is lost.16 DME_HIBERNATE_ENTER.2. MIPI Alliance Member Confidential 302 . All rights reserved. Inc.Version 1.ind( ) 3171 When Generated 3172 This primitive is generated when the Link is in LinkUp state and the DME receives the PA_LM_LINKSTARTUP. 3166 Behavioral Description 3167 The state diagram describing the behavior of the primitive is shown in Figure 432 of [MIPI02].8. 3160 The semantics of this primitive are: 3161 DME_LINKSTARTUP.2.

cnf_L 3186 The DME_HIBERNATE_ENTER.req 3204 The DME_HIBERNATE_EXIT. The PowerChangeResultCode parameter shall indicate if the procedure has succeeded or not. 3200 Effect on Receipt 3201 The DME User knows that the DME has completed its part of the hibernate enter process successfully or if an error was encountered during the process. The procedure has succeeded if the returned PowerChangeResultCode value is either PWR_LOCAL or PWR_REMOTE.40.2. 3191 Effect on Receipt 3192 If no error is returned the process to go into hibernate state continues.ind primitive shall be used to indicate the completion of the Hibernate Enter sequence. Inc.2.cnf_L primitive shall be used as a local confirmation for the DME_HIBERNATE_ENTER. The local PA Layer takes of communicating the hibernate state change with the remote end. 3196 The semantics of this primitive are: 3197 DME_HIBERNATE_ENTER.17 DME_HIBERNATE_ENTER. 9. 3202 Behavioral Description 3203 The state diagram describing the behavior of the primitive is shown in Figure 433 of [MIPI02].Version 1.8. the Link is in the Hibernate state.ind 3195 The DME_HIBERNATE_ENTER.req primitive shall be used to get the Link out of the Hibernate state. All rights reserved. is started.req primitive. In this case.ind( PowerChangeResultCode ) 3198 When Generated 3199 This primitive is generated when the hibernate entering process has been completed and the Link state is changed to the Hibernate state if the process was successful.8. 3187 The semantics of this primitive are: 3188 DME_HIBERNATE_ENTER. which is carried out by the DME layer by layer. 3184 Behavioral Description 3185 The state diagram describing the behavior of the primitive is shown in Figure 433 of [MIPI02].2. The local PA Layer indicates the change of state (to the hibernate state) to the DME.19 DME_HIBERNATE_EXIT. Both ends of the Link receive this primitive. 9. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3182 Effect on Receipt 3183 The Hibernate state entering process. 3193 Behavioral Description 3194 The state diagram describing the behavior of the primitive is shown in Figure 433 of [MIPI02]. MIPI Alliance Member Confidential 303 .cnf_L( GenericErrorCode ) 3189 When Generated 3190 This primitive is generated as a local confirmation for the hibernate enter request.18 DME_HIBERNATE_ENTER. 9.8.

req( ) 3207 When Generated 3208 This primitive is generated when the DME User requests the DME to get the Link out of the Hibernate state. 3220 Behavioral Description 3221 The state diagram describing the behavior of the primitive is shown in Figure 434 of [MIPI02].cnf_L( GenericErrorCode ) 3216 When Generated 3217 This primitive is generated as a local confirmation for the hibernate exit request.2. In this case the Link has left the Hibernate state.21 DME_HIBERNATE_EXIT.ind primitive shall be used to indicate the completion of the Hibernate Exit sequence. Copyright © 2007-2011 MIPI Alliance. Both ends of the Link receive this primitive.Version 1. 3211 Behavioral Description 3212 The state diagram describing the behavior of the primitive is shown in Figure 434 of [MIPI02]. 9. is started.8. The local PA Layer indicates the change of state (out of the hibernate state) back to the DME. 3209 Effect on Receipt 3210 The Hibernate exit process. 3214 The semantics of this primitive are: 3215 DME_HIBERNATE_EXIT. 9.ind( PowerChangeResultCode ) 3225 When Generated 3226 This primitive is generated when the hibernate exit process has been completed successfully by the DME and the Link state is changed to the LinkUp or LinkDown state depending which was the Link state prior to Hibernation. The PowerChangeResultCode parameter shall indicate if the procedure has succeeded or not. 3223 The semantics of this primitive are: 3224 DME_HIBERNATE_EXIT.cnf_L primitive shall be used as a local confirmation for the DME_HIBERNATE_EXIT. The procedure has succeeded if the returned PowerChangeResultCode value is either PWR_LOCAL or PWR_REMOTE.cnf_L 3213 The DME_HIBERNATE_EXIT. MIPI Alliance Member Confidential 304 . Otherwise an error shall indicate failure of the exit process.2. All rights reserved. The local PA Layer takes of communicating the hibernate exit with the remote end. Inc.40.req primitive.ind 3222 The DME_HIBERNATE_EXIT. 3218 Effect on Receipt 3219 If no error is returned the process to exit the Hibernate state proceeds. which is carried out by the DME layer by layer.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3205 The semantics of this primitive are: 3206 DME_HIBERNATE_EXIT.8.20 DME_HIBERNATE_EXIT.

3234 When Generated 3235 This primitive is generated when the DME User wants the DME to change the power mode of the Link. 3245 Effect on Receipt 3246 The DME User knows that the power mode change process will take place. 3238 Behavioral Description 3239 The state diagram describing the behavior of the primitive is shown in Figure 435 of [MIPI02].req primitive including possible error code if the power mode change is impossible due to an invalid set of parameters provided or for any other reason.22 DME_POWERMODE. 3232 The semantics of this primitive are: 3233 DME_POWERMODE. 3229 Behavioral Description 3230 The state diagram describing the behavior of the primitive is shown in Figure 434 of [MIPI02].req( RemoteL2TimerData ) TxPowerMode.2.cnf_L primitive shall be used as a local confirmation for the DME_POWERMODE. Copyright © 2007-2011 MIPI Alliance.2. MIPI Alliance Member Confidential 305 .8.Version 1. 9. 3247 Behavioral Description 3248 The state diagram describing the behavior of the primitive is shown in Figure 435 of [MIPI02]. RxPowerMode. If the hibernate process has failed an error shall be reported.8.req primitive.req primitive. LocalL2TimerData. 9.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).cnf_L 3240 The DME_POWERMODE.cnf_L( GenericErrorCode ) 3243 When Generated 3244 This primitive is generated as a local confirmation for the DME_POWEMODE. 3241 The semantics of this primitive are: 3242 DME_POWERMODE. Attributes defining the PHY parameters for the new power mode change shall be configured by the DME User before issuing the DME_POWERMODE. The requested UniPro power mode and all the Data Link Layer timer required for the power mode change are provided as parameters.23 DME_POWERMODE.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3227 Effect on Receipt 3228 The DME User knows that the DME has completed its part of the hibernate exit process successfully and the Link is now in the LinkUp or the LinkDown state depending which was the Link state prior to entering Hibernation. Inc. All rights reserved. 3236 Effect on Receipt 3237 The DME completes the power mode change process.

8. MIPI Alliance Member Confidential 306 . it shall also support the DME_TEST_MODE.req 3258 This primitive shall be supported by a Host and is optional for a Peripheral.cnf_L( GenericErrorCode ) 3272 When Generated 3273 This primitive is generated after reception of the PA_LM_TEST_MODE. If the DME_TEST_MODE. Both ends receive this indication.24 DME_POWERMODE. All rights reserved.2.cnf_L primitive as described in this section.req primitive. 9. if an implementation supports this primitive.26 DME_TEST_MODE.req primitive is supported by an implementation. PA Layer. However.req( ) 3262 When Generated 3263 This primitive is generated by the DME User to set the peer Device to a given test mode. Inc. 9.40. 3256 Behavioral Description 3257 The state diagram describing the behavior of the primitive is shown in Figure 435 of [MIPI02].cnf_L primitive indicating that the request was sent to the peer Device. 3270 The semantics of this primitive are: 3271 DME_TEST_MODE. 3266 Behavioral Description 3267 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02].8.2. it shall implement it as described in this section.8. 3269 This primitive inform the DME User that the sequence to set the peer Device to a given test mode was sent.ind 3249 This indication shall be used to indicate that the DME. 3250 The semantics of this primitive are: 3251 DME_POWERMODE. 3264 Effect on Receipt 3265 The DME forwards the request to the local PA Layer by generating the PA_LM_TEST_MODE. Copyright © 2007-2011 MIPI Alliance.ind( PowerChangeResultCode ) 3252 When Generated 3253 This primitive is generated when the power mode has been changed.25 DME_TEST_MODE.cnf_L 3268 This primitive shall be supported by a Host and is optional for a Peripheral. 3260 The semantics of this primitive are: 3261 DME_TEST_MODE. 3259 This primitive is used to put the peer Device into test mode.2.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 9. or DL Layer part of the power mode change has been completed. 3254 Effect on Receipt 3255 The DME User knows that the power mode change has been completed.

All rights reserved. the T_LM_DISCARD. 3298 Behavioral Description 3299 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02].ind( LayerNumber.2. MIPI Alliance Member Confidential 307 . 3283 Effect on Receipt 3284 The DME User knows that the UniPro stack is not in a normal operation mode anymore.ind information is forwarded to the DME User.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3274 Effect on Receipt 3275 The DME User knows that peer Device is in the given test mode. 3276 Behavioral Description 3277 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02]. The information forwarded to the DME user differs by layer: 3288 3289 3290 3291 • • • • For the Transport layer (L4).2.ind information is forwarded to the DME User.ind( ) 3281 When Generated 3282 This primitive is generated when the DME receives the PA_LM_TEST_MODE. 3279 The semantics of this primitive are: 3280 DME_TEST_MODE.ind information is forwarded to the DME User. but in a given test mode. 3285 Behavioral Description 3286 The state diagram describing the behavior of the primitive is shown in Figure 436 of [MIPI02]. For the Network layer (L3).40. that a layer in the UniPro stack has encountered an error condition.8.ind primitive.27 DME_TEST_MODE. Copyright © 2007-2011 MIPI Alliance.28 DME_ERROR. 9. that the UniPro stack has been set to a certain test mode.ind information is forwarded to the DME User. LayerErrorCode ) 3294 When Generated 3295 This primitive is generated when the DME receives an error indication primitive from one of the UniPro layers. For the Data Link layer (L2).ind 3278 This primitive is used to indicate to the DME User.ind 3287 This primitive is used to indicate to the DME User. 9. the N_LM_DISCARD. the DL_LM_ERROR. the PA_LM_PHY_RESET.Version 1. Inc. 3296 Effect on Receipt 3297 The DME User knows that the UniPro stack has encountered an error condition and acts accordingly. 3292 The semantics of this primitive are: 3293 DME_ERROR.5).8. For the PA Layer (L1.

00 31-Jan-2011 MIPI Alliance Specification for UniPro 9.40. After Power On.2.cnf_L).ind primitive is directly mapped to the PA_LM_RXPWRSTATE. Copyright © 2007-2011 MIPI Alliance. All rights reserved.req primitive before the Link startup operation. If the LinkStartUp sequence is successful. It then moves to the LinkDown state and waits until it receives a confirmation of the LinkStartUp procedure (PA_LM_LINKSTARTUP.9 UniPro Versioning 3301 The DME shall keep the version information of the UniPro stack.00 Reserved value Config present Device type 8 [7:4] UniPro version [3:0] 1 0 9. Inc. The version information is passed to the local PA Layer version Attribute by the DME using the PA_LM_SET.3. MIPI Alliance Member Confidential 308 . The stack can enter hibernate mode from either LinkUp or LinkDown states upon receipt of a request from the DME.Version 1. the stack is in the Disabled state until it gets a local request to start-up the Link (DME_ENABLE.ind primitive.8.req.4. the stack moves to the LinkUp state and is ready to send and receive data.10 UniPro States 3302 Figure 98 shows an abstracted and simplified state diagram of the UniPro stack after power on and DME_RESET.ind 3300 The DME_RXPWRSTATE.00 UniPro version 1. During Link configuration (such as a power mode change) the stack enters the LinkCfg state temporarily.req).40.29 DME_RXPWRSTATE. during which time no data exchange is possible. See Section 5. or it fails.1 for a detailed description of this primitive. Table 119 Field UniPro Version Information Mapping Bits Values Description Unused CM Present [15:10] 9 0 1 0 1 0 0 2 to 15 N/A Connection management present No connection management present Config protocol present No config protocol present Endpoint Above v1. The version information mapping to a 16-bit Attribute field shall be as defined in Table 119. Once the change in configuration is successfully applied. the stack returns to the LinkUp state.40. 9.

40.Version 1.req / DME_RESET.cnf_L (SUCCESS) [pwrmode done] DME_POWERMODE.req DME_HIBERNATE_EXIT. LinkDown.req / DME_ENABLE.ind / DME_LINKLOST.cnf_L DME_HIBERNATE_ENTER. Table 120 Primitive DME_SAP Restrictions When Restricted (Ignored) DME_SET.cnf_L(SUCCESS) LinkUp DME_POWERMODE.8).req primitives (see Section 9. Disabled.ind] / DME_LINKSTARTUP.cnf_L PA_LM_LINKSTARTUP.req DME_ENDPOINTRESET.req DME_LINKSTARTUP. Copyright © 2007-2011 MIPI Alliance. some restrictions are enforced on all DME_xxx.cnf_L /Off(*) DME_ENABLE. These restrictions specify when a primitive is going to be executed or when it shall be ignored by an implementation (see Table 120). All rights reserved.cnf_L Off DME_POWERON.req / DME_HIBERNATE_ENTER.cnf_L Disabled Hibernate DME_RESET.req DME_POWER_ON.req In the OFF and Disabled states In the OFF.req [prev_state=LinkUp] / DME_HIBERNATE_EXIT.req DME_POWERMODE. the DME shall set the GenericErrorCode field in the local confirmation primitive to Failure.req [capability ok] / DME_POWERMODE. MIPI Alliance Member Confidential 309 .req DME_POWER_OFF.req / DME_POWEROFF.req [no peer detected] / DME_LINKSTARTUP.cnf_L(FAILURE) DME_LINKSTARTUP.cnf_L DME_HIBERNATE_ENTER.ind PA_LM_LINKSTARTUP.ind LinkDown DME_LINKSTARTUP.req DME_HIBERNATE_ENTER.req [peer detected] / PA_LM_LINKSTARTUP. Inc.ind(LOCAL) LinkCfg Figure 98 UniPro States 3303 Based on the UniPro state diagram shown in Figure 98.req DME_PEER_GET.00 31-Jan-2011 MIPI Alliance Specification for UniPro DME_POWEROFF. Hibernate and LinkLost states In all states except the OFF state In all states except the Disabled state In all states except the Disabled state In all states except the LinkUp state In all states except the LinkDown state In all states except the LinkDown and LinkUp states In all states except the Hibernate state In all states except the LinkUp state In all states except the LinkDown state 3304 If a DME_SAP control primitive is issued in a restricted power state.req DME_PEER_SET.cnf_L DME_HIBERNATE_EXIT.req DME_ENABLE.req / DME_HIBERNATE_ENTER.cnf_L LinkLost (*) Any state other than the Off state DME_HIBERNATE_EXIT.req DME_GET.req [prev_state=LinkDown] / DME_HIBERNATE_EXIT.req DME_TESTMODE.req / DME_POWERON.

3312 The DME User shall proceed with the boot sequence and instruct the DME to transition the Link to the LinkUp state using the DME_LINKSTARTUP. the DME enables a layer only after the layer below it has reported that it is enabled.cnf_L primitive. After being enabled.req primitive. beginning with L1.11.cnf_L and configuring the Network Layer and Transport Layer Attributes. These Attributes are either automatically set to the defined reset values. which ensures that the UniPro layers are initialized in order. N_DeviceID and N_DeviceID_valid need to be configured in the Network Layer.req primitive.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3305 If a DME_SAP configuration primitive is issued in a restricted power state.Version 1. and the Attributes for connection setup need to be set in the Transport Layer as described in Section 8. each layer shall perform its own initialization.40. 9. or a Warm Reset. The UniPro boot procedure ensures that L2 does not start its AFC exchange until the L1.5 exercises the Link Startup sequence and reports that the PHY is operational. Copyright © 2007-2011 MIPI Alliance.cnf_L.11 Reset and Boot Procedures 3306 This section describes the UniPro Reset and Boot procedures. or set by the Application before the Link is used. Each layer shall use the <layeridentifier>_LM_STARTUP.3.11.5 up to L4. 3309 The UniPro boot procedure is controlled by the DME. 3315 To be able to communicate through a UniPro stack. 9. the Link reaches the LinkUp state and the DME shall report this condition to the DME User using the DME_LINKSTARTUP. 3314 At the end of this phase. 3316 After receiving the DME_LINKSTARTUP.cnf_L primitive to indicate to the DME that the layer has completed initialization. The boot procedure is invoked by the DME User using the DME_ENABLE. the DME shall set the ConfigResultCode field in the confirmation primitive to DME_FAILURE. 3311 At the end of this phase the Link reached the LinkDown state and the DME shall report this condition to the DME User using the DME_ENABLE. In the latter case.req primitive. All rights reserved.req primitive. In particular.2 Boot Procedure 3308 The UniPro boot procedure follows a Cold Reset. MIPI Alliance Member Confidential 310 .5 followed by L2 using the <layer-identifier>_LM_LINKSTARTUP.req primitive.cnf_L primitive. Network and Transport Layers also need to be configured. Each layer shall use the <layer-identifier>_LM_ENABLE_LAYER.req primitive the DME shall startup L1. these Attributes should be set immediately after receiving the DME_LINKSTARTUP.1. which is shown in Figure 99.11. including a power-on reset.3 3318 • 3319 • Boot Procedure Example (informative) 3317 The following three types of boot sequence are provided for reference: Default. the boot process is complete and the Link is ready for data transfers. 9. the UniPro boot procedure ensures that L2 does not start its AFC exchange until the L1. 9. Thus.11.5 exercises the Link Startup sequence and reports that the PHY is operational. Peer initiated. 3310 Upon receiving the DME_ENABLE. each UniPro layer shall be enabled by the DME using the <layer-identifier>_LM_ENABLE_LAYER. Inc. For example. 3313 Upon receiving the DME_LINKSTARTUP.cnf_L primitive to indicate to the DME that the layer has completed the respective layer startup procedure.1 Reset Procedure 3307 The reset procedure is described in Section 9. which is shown in Figure 100.

cnf_L T_LM_ENABLE_LAYER.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3320 • Figure 101 describes a special case where a peer Device-initiated sequence resulted in a Link reaching LinkUp state.40.cnf_L PA (L1.req PA_LM_LINKSTARTUP.cnf_L LinkDown DME_LINKSTARTUP.cnf_L DME_LINKSTARTUP.cnf_L(Success) LinkUp T_LM_ENABLE_LAYER.ind primitive. All rights reserved. DME USER DME Disabled DME_ENABLE.cnf_L(Success) DL_LM_LINKSTARTUP. Inc.cnf_L DL_LM_ENABLE_LAYER.req PA_LM_LINKSTARTUP.Version 1.req PA_LM_ENABLE_LAYER.req N_LM_ENABLE_LAYER. MIPI Alliance Member Confidential 311 .req DME_ENABLE.req PA_LM_ENABLE_LAYER.5) DL (L2) N (L3) T (L4) Figure 99 Default Boot Procedure Copyright © 2007-2011 MIPI Alliance. while receiving a DME_LINKLOST.cnf_L N_LM_ENABLE_LAYER.req DL_LM_LINKSTARTUP.req DL_LM_ENABLE_LAYER.

cnf_L(Success) LinkUp Figure 100 Peer Initiated Boot Procedure Copyright © 2007-2011 MIPI Alliance.ind DME_LINKSTARTUP.ind DME_LINKSTARTUP. All rights reserved.cnf_L N_LM_ENABLE_LAYER.cnf_L(Failure) DME_LINKSTARTUP.40.cnf_L DME_ENABLE.req PA_LM_LINKSTARTUP.cnf_L DME_LINKSTARTUP.cnf_L T_LM_ENABLE_LAYER. MIPI Alliance Member Confidential 312 .req N_LM_ENABLE_LAYER.cnf_L(Failure) LinkDown PA_LM_LINKSTARTUP.req PA_LM_LINKSTARTUP.req PA_LM_ENABLE_LAYER.Version 1.req T_LM_ENABLE_LAYER.req PA_LM_LINKSTARTUP.cnf_L LinkDown DME_LINKSTARTUP.req PA_LM_ENABLE_LAYER.cnf_L(Success) DL_LM_LINKSTARTUP.5) DL (L2) N (L3) T (L4) DME_ENABLE.req PA_LM_LINKSTARTUP.cnf_L DL_LM_ENABLE_LAYER.req DL_LM_LINKSTARTUP.00 31-Jan-2011 MIPI Alliance Specification for UniPro DME USER DME Disabled PA (L1.req DL_LM_ENABLE_LAYER. Inc.

3322 All DME DDB L1 Attributes should be readable (settable is optional).Version 1.. each settable DME Attribute shall be reset to its corresponding static value. All rights reserved.req PA_LM_RESET.cnf_L LinkDown DME_LINKSTARTUP. Copyright © 2007-2011 MIPI Alliance.cnf_L T_LM_RESET. 3324 At reset.cnf_L PA (L1. all DME_DDBL1 Attributes are valid and read-only. MIPI Alliance Member Confidential 313 .cnf_L Disabled DME_ENABLE. If DME_DDBL1_Revision is set to a non-zero value.req PA_LM_ENABLE_LAYER.5) DL (L2) N (L3) T (L4) .req PA_LM_LINKSTARTUP. 3323 If DME_DDBL1_Revision is set to zero.cnf_L DME_LINKSTARTUP..00 31-Jan-2011 MIPI Alliance Specification for UniPro User may at this point read the CPort buffers etc.12 DME DDB L1 3321 Table 121 shows the DME DDB L1 Attributes.ind LinkLost DME_RESET.req PA_LM_RESET. See [MIPI04] for the definition of these parameters.ind DME_LINKLOST.40. which are copies of the DME User’s DDB L1 parameters. and then proceed with the normal bootup sequence.req T_LM_RESET. Parameters should be settable if functionality sharing is desired.req DL_LM_LINKSTARTUP.req PA_LM_LINKSTARTUP. DME USER DME LinkUp PA_LM_LINKSTARTUP.cnf_L T_LM_ENABLE_LAYER.. if one exists or to its Reset Value otherwise. all DME_DDBL1 Attributes are invalid. DME_ENABLE.req PA_LM_ENABLE_LAYER.cnf_L(Success) DL_LM_LINKSTARTUP. DME_RESET.cnf_L(Success) LinkUp Figure 101 Link Lost Triggered Boot Procedure 9.. Inc.req T_LM_ENABLE_LAYER.cnf_L .

3325 The DME Attributes listed in Table 121 should be retained during Hibernation.Version 1. Manufacturer ID of the DME User as specified by the MIPI Alliance. DME_DDBL1_DeviceClass 0x5002 Int The Device Class ID of the DME User as specified by the MIPI Alliance. b2: DDB Level 2 set support. DME_DDBL1_Length 0x5005 Int 1. b[7:3]: Reserved. All rights reserved.0) the value shall be 0x10.40. the value shall be zero. If b1 is set. N/A For Devices supporting only DDB Level 1. then b0 shall also be set. Those Attributes are simple and do not cause any implicit action when set. both b0 and b1 shall also be set. For this version (v1. See [MIPI04] The length of any DDB Level 2 data. If the N/A Device does not conform to a specified device class.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 121 Attribute Attribute Unit ID1 DDB L1 Attributes Description Reset Value DME_DDBL1_Revision 0x5000 Int See [MIPI04] The revision of the DDB specification supported by this Device encoded as major-version * 0x10 + minor-version. See [MIPI04] Eight bit field indicating the DDB support: b0: DDB Level 1 support. 0x00 DME_DDBL1_Level 0x5001 Int 0x1 (no support for DDB L2) Allow also the DDB L2 indications under the limitation that it is up to the function specific driver to fetch DDB L2. b1: DDB Level 2 get support. N/A DME_DDBL1_ManufacturerI D DME_DDBL1_ProductID 0x5003 0x5004 Int Int The Manufacturer's internal product ID N/A of the DME User. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 314 . Shall be 0b1 if and only if the SET-DDBLEVEL2 Service is supported. Attributes 0x5000 to 0x5005 correspond to the DDB Level 1 fields and their offsets defined in [MIPI04]. Inc. Shall be 0b1 if and only if the GET-DDBLEVEL2 Service is supported. If b2 is set. Shall be 0b1. the value shall be zero. Shall be 0b00000.

00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex A Test PHY Protocol Interface (T-PPI) 3326 The Test PHY Protocol Interface is essentially a sub-set of the logical PHY Protocol Interface (PPI) signal described in the [MIPI01].5) T-PPI PCB #2 Figure 102 Simplified View of UniPro Interoperability Setup 3328 The T-PPI provides the signal list for interfacing UniPro stacks at the bottom of L1. In addition to this. etc. A. 3331 The control group signals. T-PPI's Clock and Control groups shall be shared by all Data Lanes. In addition to this. at both the Transmitter and the Receiver. qualify the clock group and data group signals.g. Inc. 3330 The T-PPI consists of three groups of signals. Clock and Data. error signals. e. All rights reserved. The data group signals consist of a sub-set of D-PHY PPI's Transmit and Receive signals. which is mandated by the UniPro specification. 3332 In the case multiple Data Lanes are emulated.5) T-PPI PCB #1 C o n n e c t o r Cable C o n n e c t o r T-PPI FPGA with UniPro Stack (L4 to L1. 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. T-PPI FPGA with UniPro Stack (L4 to L1. MIPI Alliance Member Confidential 315 . are not included in the T-PPI signal list. Control. if T-PPI is supported it shall be implemented as described in this annex. signals for changing lane direction. and signals not needed for UniPro. Note that in the T-PPI's ESC mode. Copyright © 2007-2011 MIPI Alliance. 3327 Support for the T-PPI is optional.Version 1. To lower the T-PPI signal count. The signals on all the other Data Lanes shall be ignored. The clock group signals consist of a sub-set of the Clock Lane signals specified in the D-PHY PPI signal list. However. Figure 103 depicts the T-PPI signals per direction.5. only Data Lane 0 shall be used. e.g.40. T-PPI is intended for connecting UniPro stack PCBs as shown in Figure 102.1 T-PPI Signal List 3333 This section describes each of the signals groups in the T-PPI. 3329 The main requirement of T-PPI is to have a low signal count. Moreover low T-PPI signal count would allow multiple Data Lanes fit on a low number of connectors. some of the mutually exclusive signals on the logical PPI are multiplexed. PHY-specific signals. which are T-PPI-specific. Both these sets of signals can be included in the T-PPI if needed by extending T-PPI later. each lane shall use a separate T-PPI data group. It also includes signals from the extended PPI signal list that is needed for the DPHY with 8b9b line encoding. because the number of connector pins is limited.

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. Receive Mode (Receiver) RxMode indicates whether the Data group signals belong to the HighSpeed mode or Escape mode. • RxMode='1' indicates the High-Speed (HS) mode. and which of the two Clock signals is used. and which of the two Clock signals is used. the total number of signals per direction is (1+2+10*N). two signals in the Clock Group and ten signals in the Data Group. A. • RxMode='0' indicates the Escape (ESC) mode. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Transmitter Control Group Clock Group TxMode TxByteClkHS TxClkEsc 1 1 1 RxMode RxByteClkHS RxClkEsc Control Group Clock Group Receiver Data Group L=3 L=2 L=1 L=0 TxData_L[7:0] TxDataType_L TxValid_L 8*N 1*N 1*N RxData_L[7:0] RxDataType_L RxValid_L L=3 L=2 L=1 L=0 Data Group For multiple lane configuration.1 Control Group 3335 The T-PPI control group consists of the mode signal.2. for a single lane configuration.40.4} Figure 103 T-PPI Signal Groups with Their Respective Signals per Direction 3334 The T-PPI consists of thirteen signals per direction. • TxMode='1' indicates the High-Speed (HS) mode. respectively. where N = {1. MIPI Alliance Member Confidential 316 . The mode signal indicates the T-PPI operation mode: high-speed mode. 2 and 3) shall be ignored at the receiver. Table 122 Signal Name T-PPI Control Group Transmitter and Receiver Signal List Description Direction TxMode Output Transmit Mode (Transmitter) TxMode indicates whether the Data Group signals belong to the HighSpeed mode or Escape mode.2. For a multiple-lane configuration. each data lane shall use a separate T-PPI data group of signals. or escape mode emulating the D-PHY high-speed mode and the escape mode.1.3} N is Number of Lanes. where N is the number of lanes in that direction.Version 1. L is Data Lane. Note that when the TPPI is operating in ESC mode (Mode = ‘0’).3. where L = {0. one signal in the Control Group.1. 3336 Table 122 describes the control group signals at the transmitter and receiver. RxMode Input Copyright © 2007-2011 MIPI Alliance. Inc. • TxMode='0' indicates the Escape (ESC) mode.

which is an input.Version 1. DataType signal and Valid signal. MIPI Alliance Member Confidential 317 . Table 123 describes the clock group signals at the transmitter and receiver. RxClkEsc shall be ignored. The Valid signal shall indicate whether the values carried on the Data signals and DataType signal of the T-PPI are valid or not. Inc. The T-PPI Mode signal indicates which clock signal is used to synchronize the data group signals. Escape mode transmit clock. All rights reserved. the High-Speed byte clock and the Escape-Mode clock. TxByteClkHS is an output.40. T-PPI RxByteClkHS signal is equivalent to RxByteClkHS signal in the logical PPI. When the T-PPI is in ESC Mode (RxMode =’0’). The T-PPI TxByteClkHS signal is equivalent to TxByteClkHS signal in the logical PPI. Table 124 describes these signals at the transmitter and receiver. TxClkEsc is used to synchronize the T-PPI data group signals when T-PPI is in escape mode (TxMode =’0’).1. RxByteClkHS shall be ignored. The T-PPI Data signal carries the data belonging to transmitter (/receiver) or the miscellaneous (set of multiplexed transmit(/receiver) signals plus the control signals) signals. Table 123 Signal Name T-PPI Clock Group Transmitter and Receiver Signal List Description Direction TxByteClkHS Output High-Speed mode transmit clock. RxClkEsc is used to synchronize the T-PPI data group signals when T-PPI is in escape mode (RxMode =’0’). Note that in T-PPI. Copyright © 2007-2011 MIPI Alliance. TxByteClkHS may be driven ‘0’. T-PPI TxClkEsc signal is equivalent to TxClkEsc signal in the logical PPI. When the T-PPI is in ESC Mode (TxMode =’0’). Escape mode receive clock. TxClkEsc may be driven ‘0’. T-PPI RxClkEsc signal is equivalent to RxClkEsc signal in the logical PPI. When the T-PPI is in high-speed mode (TxMode =’1’). The DataType signal distinguishes between the data and miscellaneous signals is carried on the T-PPI data signals. High-Speed mode receive clock.1.00 31-Jan-2011 MIPI Alliance Specification for UniPro A. When the T-PPI is in high-speed mode (RxMode =’1’).3 Data Group 3338 The data group consists of three signals: Data signal. TxByteClkHS is used to synchronize the T-PPI data group signals when TPPI is in High-Speed mode (TxMode =’1’). TxClkEsc Output RxByteClkHS Input RxClkEsc Input A. RxByteClkHS is used to synchronize the T-PPI data group signals when TPPI is in High-speed mode (RxMode =’1’). as opposed to the PPI TxByteClkHS.2 Clock Group 3337 The T-PPI Clock group consists of two clock signals.

• When '0'. 2 or 3 corresponding to Data Lane 0. Data Lane 2 or Data Lane 3. • When '1'. Also the T-PPI TxMode signal indicates whether these signals correspond to high-speed mode or escape mode.2 on the T-PPI signal multiplexing to know the meaning of each bit. TxValid_L maps to TxValidHS or TxValidEsc in the PPI signal list depending on the value of T-PPI TxMode signal. L can take values 0. Data Lane 2 or Data Lane 3. 2 or 3 corresponding to Data Lane 0.Version 1. All rights reserved. the T-PPI RxMode signal indicates whether these signals correspond to high-speed mode or escape mode.2 on the T-PPI signal multiplexing to know the meaning of each bit. This 8-bit signal conveys the PPI receive data or PPI miscellaneous (receive /control) signals depending upon the value of the RxDataType_L T-PPI signal. Data Lane 1. 1. This 8-bit signal conveys the PPI Transmit data or PPI miscellaneous (transmit /control) signals depending upon the value of the TxDataType_L T-PPI signal. 2 or 3 corresponding to Data Lane 0. • When '0' the corresponding TxData_L [7:0] and TxDataType_L shall carry invalid information and shall be ignored at the receiver. TxDataType_L indicates that the corresponding data group signals TxData_L [7:0] carry miscellaneous signals (PPI transmit and control signals). Receive data/miscellaneous signals for Data Lane L. L can take values 0. Transmit valid for Data Lane L.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 124 Signal Name Direction T-PPI Data Group Transmit and Receive Signal List Description TxData_L [7:0] Output Transmit data/miscellaneous signals for Data Lane L. 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 TxValid_L Output RxData_L [7:0] Input Copyright © 2007-2011 MIPI Alliance. Type of Data on the TxData_L [7:0] L can take values 0. 1. 2 or 3 corresponding to Data Lane 0. MIPI Alliance Member Confidential 318 . Data Lane 1. See Section A. See Section A. 1. Data Lane 1. Inc. L can take values 0. Data Lane 2 or Data Lane 3.2 on the T-PPI signal multiplexing for more details. Data Lane 2 or Data Lane 3.40. 1. See Section A. Also. • When '1' the TxData_L [7:0] and TxDataType_L shall carry valid (data or miscellaneous) information. TxDataType_L indicates that the corresponding data group signals TxData_L [7:0] carry PPI transmit data signals. Data Lane 1.

2 or 3 corresponding to Data Lane 0. L can take values 0.40. Note that the T-PPI valid signal (not shown in Table 125) is asserted to indicate that Tx(Rx)Data_L[7:0] carries valid information (data or miscellaneous signals). Copyright © 2007-2011 MIPI Alliance.Version 1. 1. Data Lane 2 or Data Lane 3. RxValid_L Input A. All rights reserved. The miscellaneous signals on Tx(Rx)Data_L[7:0] (when DataType_L ='1') are mutually exclusive from each other and also with the data. • When '1'. At the transmit side signals will be a request (output) and at the receiver it will be an indication (input). Data Lane 2 or Data Lane 3.2 T-PPI Signal Multiplexing 3339 This section provides details on how to interpret the meaning of the each of the bits in the T-PPI Tx(Rx)Data[7:0] signal based on the Tx(Rx)Mode and Tx(Rx)DataType_L signals. RxDataType_L indicates that the corresponding data group signals RxData_L [7:0] carry miscellaneous signals (PPI receive and control signals). Data Lane 1. RxDataType_L indicates that the corresponding data group signals RxData_L [7:0] carry PPI receive data signals.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 124 Signal Name T-PPI Data Group Transmit and Receive Signal List (continued) Description Direction RxDataType_ L Input Type of Data on the RxData_L [7:0]. This signal indicates whether the RxData_L signals carry miscellaneous signals (receive and control signals in PPI) or data signals in PPI from the transmitter. For example. • When '1' the RxData_L [7:0] and RxDataType_L shall carry valid (data or miscellaneous) information. Hence. RxValid_L maps to RxValidHS or RxValidEsc in the PPI signal list depending on the value of T-PPI RxMode. • When '0' the corresponding RxData_L [7:0] and RxDataType_L shall carry invalid information and shall be ignored. 1. when a trigger-0 is asserted [Data_0[0]='1'] then all other signals are de-asserted (Data_0[7:1]=0x0). MIPI Alliance Member Confidential 319 . Data Lane 1. See Section A. • When '0'. L can take values 0. 2 or 3 corresponding to Data Lane 0. Inc.2 on the T-PPI signal multiplexing for more details. a miscellaneous signal shall be asserted with all other miscellaneous signals de-asserted. Receive valid for Data Lane L.

This signal is asserted (active high) for a single clock of Tx(Rx)Clk to transmit (indicate) a Protocol Marker.Version 1. Copyright © 2007-2011 MIPI Alliance. • When 10b indicates Data Link (DL) Layer Protocol Marker request/indication related to C417 (Table 17). When Data_0 [7:6] is 11b. • When 11b indicates Data Link (DL) Layer Protocol Marker request/indication related to C600 (Table 17). 10b or 01b.Adapter (PA) Layer Protocol Marker request/indication related to C400 (Table 17). • When 01b indicates PHY.00 31-Jan-2011 Table 125 Mode Data Type (DataType_L) Data Signal (Data_L [7:0]) T-PPI Signal Multiplexing on the Data [7:0] Signals Equivalent PPI Signal Description ‘0’ => Data Data_0[7:0] TxDataEsc[7:0] RxDataEsc[7:0] LPDT Data[7:0] Protocol Marker request/indication in ESC speed mode of T-PPI. Data_0 [5:0] shall be 0x00. MIPI Alliance Member Confidential 320 ‘0’ => ESC ‘1’ => Misc TxData_0[7:6] RxData_0[7:6] N/A1 MIPI Alliance Specification for UniPro . • When 00b implies that neither DL Layer nor PA Layer Protocol Marker request/indication.40. Inc. This single ESC clock duration pulse is equivalent to the bits [16:8] (control symbol indicator plus EscType field) in the Escaped Data PA_PDU (Figure 16). All rights reserved.

00 31-Jan-2011 Data Signal (Data_L [7:0]) TxData_0[5] RxData_0[5] TxUlpsEsc RxUlpsEsc Ultra Low Power State (ULPS) request/indication. When Data_0[4] is 1b. there is no need to assert this (RX) Stopstate signal. Inc. Note that in cases where there is no D-PHY interface to the UniPro Stack.Table 125 Mode Data Type (DataType_L) T-PPI Signal Multiplexing on the Data [7:0] Signals (continued) Equivalent PPI Signal Description Version 1. This active high signal is asserted to indicate that the Lane is in Ultra Low Power State (ULPS). All rights reserved. Data_0[7:3] and 0] Data_0[1:0] shall be 0x0. Escape mode Trigger 3-0 request/indication. de When de-asserted. Note that in cases where there is no D-PHY interface to the UniPro Stack. it indicates that the Lane exited Stop State. When Data_0[5] is 1b. it indicates an Escape mode Trigger-2. Data_0[7:5] and Data_0[3:0] shall be 0x0. RxTriggerEsc[3: When Data_0[2] is 1b. This active high signal is asserted to indicate that the protocol forced the Lane to a ForceTxStopMo Stop State. TxData_0[3:0] RxData_0[3:0] MIPI Alliance Specification for UniPro . TxTriggerEsc[3: When Data_0[3] is 1b it indicates a Escape mode Trigger-3. there is no need to assert this signal.40. Data_0[7:6] and Data_0[4:0] shall be 0x00. it indicates the Lane is no longer in ULPS. Data_0[7:4] and Data_0 0] [2:0] shall be 0x0. When de-asserted. MIPI Alliance Member Confidential 321 ‘0’ => ESC ‘1’ => Misc TxData_0[4] RxData_0[4] Stop State request/indication. Copyright © 2007-2011 MIPI Alliance.

MIPI Alliance Member Confidential 322 ‘1’ => HS ‘1’ => Misc TxData_L[7:6] RxData_L[7:6] N/A1 TxData_L[5:0] RxData_L[5:0] N/A MIPI Alliance Specification for UniPro 1.Adapter (PA) Layer Protocol Marker request/indication related to C400 (Table 17). A UniPro stack transmits the Type A comma code C600. Inc. which is not pointed by this marker signal. pointed to by this marker signal. . Tx(Rx)ProMarker. but transmits a regular escape code (C417). • When 10b indicates Data Link (DL) Layer Protocol Marker request/indication related to C417 (Table 17). When Data_L [7:6] is 11b. This signal is asserted high for a single clock of Tx(Rx)Clk to transmit (indicate) a Protocol Marker. All rights reserved. when PA_LegacyDPHYEscDL is FALSE. 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 PA_LegacyDPHYEscDL is TRUE. Reserved.00 31-Jan-2011 Data Signal (Data_L [7:0]) ‘0’ => Data TxData_L[7:0] RxData_L[7:0] TxDataHS[7:0] RxDataHS[7:0] High speed Data for Lane-L Protocol Marker request/indication in High-speed mode of T-PPI. • When 11b indicates Data Link (DL) Layer Protocol Marker request/indication related to C600 (Table 17). • When 00b implies that neither DL Layer nor PA Layer Protocol Marker request/indication. D-PHY Extended PPI (8b9b) allocates only one signal for Protocol Marker.Table 125 Mode Data Type (DataType_L) T-PPI Signal Multiplexing on the Data [7:0] Signals (continued) Equivalent PPI Signal Description Version 1. • When 01b indicates PHY. Data_L [5:0] shall be 0x00.40. Shall be set to 0x00. 10b or 01b. Copyright © 2007-2011 MIPI Alliance.

Version 1. Remote RX receives the Frame#0 and triggers remote TX to send AFC0#0 for Frame#0.1 Data Link Layer (informative) Reliability Scenarios Timeout Mechanism 3340 The TCx_REPLAY_TIMER operation is illustrated in Figure 104 for Traffic Class 0 without grouped acknowledgment. TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of Frame#2. Traffic Class 0 is used for illustration purposes though the same behavior is applicable to other Traffic Classes. Local TX SOF TC0 #0 EOF CRC SOF TC0 #0 EOF CRC AFC No unacknowledged frames in the TC0 TX buffer so the TC0_REPLAY_TIMER is stopped. Copyright © 2007-2011 MIPI Alliance.1 B. Local RX receives the AFC0#0 Frame. The successful reception of AFC0#0 Frame resets the TC0_REPLAY_TIMER. While Frame #2 is being transmitted. (DL_TC0OutAckThreshold set to zero). All rights reserved.1. TC0_REPLAY_TIMER is allowed to run. local TX uses Traffic Class 0 for transmitting a Frame with Frame Sequence Number 0 (Frame#0) to remote RX and TC0_REPLAY_TIMER is started after sending the last symbol of Frame#0 (CRC symbol). TC0_REPLAY_TIMER is allowed to run. TC0_REPLAY_TIMER is in running mode until the AFC0#0 is received (without an error). Then the timer is in not running state (stop state) as there are no pending acknowledgments. 3341 • Here. MIPI Alliance Member Confidential 323 . Inc. TC0 #0 CRC AFC TC0 #0 CRC 3342 • 3343 • 3344 • Remote RX Remote TX Local RX TC0_REPLAY_TIMER Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired 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. 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. TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of Frame#1. 3346 3347 3348 3349 3350 3351 • • • • • • TC0_REPLAY_TIMER is reset and started after sending the last symbol of Frame#0. While Frame #1 is being transmitted.00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex B B.40.

Local TX SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC SOF TC0 #2 EOF CRC SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC SOF TC0 #2 EOF CRC TC0_REPLAY_TIMER Remote RX Remote TX Local RX AFC TC0 #1 CRC AFC TC0 #1 CRC TC0_REPLAY_TIMER is reset with each received AFC0 as long as there are unacknowledged frames in the TC0 TX buffer AFC TC0 #2 CRC AFC TC0 #2 CRC No unacknowledged frames in the TC0 TX buffer so the TC0_REPLAY_TIMER is stopped. TC1_REPLAY_TIMER is stopped as there are no unacknowledged Frames for TC1. TC0_REPLAY_TIMER is reset and allowed to run after sending the last symbol of TC0 Frame#1. TC0_REPLAY_TIMER continues to run. While TC0 Frame #1 is being transmitted. MIPI Alliance Member Confidential 324 . TC0_REPLAY_TIMER is stopped as there are no unacknowledged Frames for TC0. All rights reserved. Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 105 TC0 Replay Timer Operation for Grouped ACK 3353 Figure 106 shows TCx_REPLAY_TIMER behavior in case of preemption (TC0 is preempted by TC1). After successful reception of AFC0#1 Frame by the local RX. After successful reception of AFC1#0 Frame by the local RX. 3354 3355 3356 3357 3358 3359 • • • • • • TC0_REPLAY_TIMER is reset and started after sending the last symbol of TC0 Frame#0. 3360 • 3361 • 3362 • Copyright © 2007-2011 MIPI Alliance. TC0_REPLAY_TIMER is allowed to run. Since TC0 Frame #1 has not been acknowledged.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3352 • Reception of AFC0#2 Frame by local RX resets and stops TC0_REPLAY_TIMER as there are no unacknowledged Frames. TC0 resumes transmitting TC0 Frame#1 from its preempted position. TC1 Frame #0. Since TC1 has no more Frames to send. Inc. TC1_REPLAY_TIMER is reset and allowed to run after sending the last symbol of TC1 Frame#0. The local TX preempts TC0 Frame #1 with a higher priority Frame.Version 1.

1. where TC0 and TC1 frames are depicted respectively in white and gray color. Frame#1. It discards the last Frame. which acknowledges correct reception of TC0 Frame#0. transmits AFC Frames for TC1 and TC0 and retransmits TC0 Frame#1.40. CRC AFC TC0 #1 CRC Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 106 TCx Replay Timer Behavior during Preemption B.e. and sends an acknowledgment for the Frame with AFC0#1 Frame.4. After reception of the AFC0 Frame by the local RX. TC0_REPLAY_TIMER is reset and started after sending the last symbol of Frame#1.5. Inc. AFC TC0 #1 No unacknowledged frames in the TC0 TX buffer so the TC0_REPLAY_TIMER is stopped. Remote RX receives TC0 Frame#1 in good condition. 3365 • 3366 • 3367 • 3368 • Copyright © 2007-2011 MIPI Alliance.2 Retransmission Mechanism 3363 Figure 107 illustrates retransmission due to the received NAC Frame by local RX. i. and a NAC Frame with the RReq bit not set (see Section 6.Version 1. the local RX resets and freezes the TC0_REPLAY_TIMER.2 for NAC Frame details).00 31-Jan-2011 MIPI Alliance Specification for UniPro Replay Timers TC0 TC1 Local TX SOF TC0 #0 EOF CRC SOF TC0 #1 SOF TC1 #0 EOF CRC COF TC0 #1 EOF CRC Remote RX Remote TX Local RX SOF TC0 #0 EOF CRC SOF TC0 #1 SOF TC1 #0 EOF CRC COF TC0 #1 EOF CRC AFC TC1 #0 CRC AFC TC1 #0 CRC No unacknowledged frames in the TC1 TX buffer so the TC1_REPLAY_TIMER is stopped. All rights reserved. MIPI Alliance Member Confidential 325 . 3364 • The local TX sends TC0 Frame#0 and Frame#1. The Forward Link carries no traffic from the local TX after sending TC0 Frame#1. and Frame#1 with an error (detected during CRC checking). After retransmitting TC0 Frame#1 it resets and starts TC0_REPLAY_TIMER. the local RX resets and starts the TC0_REPLAY_TIMER After reception of the NAC Frame by the local RX. The remote RX receives Frame#0 in good condition. this time. and schedules an AFC Frame to acknowledge TC0 Frame#0.

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. Inc. All rights reserved.Version 1. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3369 • The local RX detects AFC0#1 Frame and stops the TC0_REPLAY_TIMER as there are no pending acknowledgments. TC0 #1 CRC AFC TC0 #1 CRC TC0_REPLAY_TIMER is stopped on the receipt of the NAC frame. AFC transmission for prior TC0 transmission Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 107 Retransmission Triggered by NAC Frame 3370 Figure 108 shows a scenario with two Traffic Classes. Frame #1 is discarded TC0_REPLAY_TIMER Remote RX Remote TX Local RX AFC transmission for prior TC1 transmission AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #1 EOF CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #1 EOF CRC AFC No unacknowledged frames in the TC0 TX buffer so the TC0_REPLAY_TIMER is stopped. Local TX SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC AFC TC0 #0 CRC AFC TC0 #0 CRC NAC NAC CRC CRC Bit error.40. MIPI Alliance Member Confidential 326 .

Remote RX receives the AFC1 Frame in good condition and activates the NAC Frame generation. Copyright © 2007-2011 MIPI Alliance. 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. hence it starts sending TC0 Frames from the oldest unacknowledged Frame (TC0 Frame#1) to the latest Frame (TC0 Frame#3) available in buffer. Inc. MIPI Alliance Member Confidential 327 .Version 1. Remote RX receives TC0 Frame#2 and TC0 Frame#3 in good condition and sends an acknowledgment with AFC0#3 Frame. The reception of NAC Frame by the local RX stops the TC0 Frame #3 transmission (without concluding the current Frame).6.40. TC0_REPLAY_TIMER is reset and started after finalization of each Frame The remote RX receives Frame#0 in good condition. Local TX transmits AFC Frames for TC1 and TC0 and starts retransmission of all unacknowledged Data Frames in the priority order.11 for more details. In this illustration only TC0 traffic is depicted.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3371 • 3372 • 3373 • 3374 • 3375 • 3376 • 3377 • The local TX sends TC0 Frame#0. The local RX detects the AFC0#3 Frame and stops the TC0_REPLAY_TIMER as there are no pending acknowledgments. and Frame#1 with an error (detected during CRC checking). All rights reserved. Frame#1. See Section 6. Frame#2 and Frame#3.

AFC for TC1 and TC0 is transmitted. AFC TC0 #0 CRC NAC NAC CRC SOF AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #1 EOF CRC SOF TC0 #2 EOF CRC SOF TC0 #3 EOF CRC AFC No unacknowledged frames in the TC0 TX buffer so the TC0_REPLAY_TIMER is stopped. Frame #1 is discarded SOF TC0 #2 EOF CRC SOF TC0 #2 The current frame transmission is stopped. Inc. All rights reserved.Version 1.40. EOF CRC The Remote RX is expecting Frame #1 to be retransmitted so Frame #2 is discarded. MIPI Alliance Member Confidential 328 .00 31-Jan-2011 MIPI Alliance Specification for UniPro TC0_REPLAY_TIMER Local TX SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC Remote RX Remote TX Local RX SOF TC0 #0 EOF CRC SOF TC0 #1 EOF CRC Bit error. Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 108 Retransmission Triggered by NAC Frame while Stopping Current Frame Copyright © 2007-2011 MIPI Alliance. Any unacknowledged frames are retransmitted. TC0 #3 CRC AFC TC0 #3 CRC CRC AFC TC0 #0 CRC SOF AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #1 EOF CRC SOF TC0 #2 EOF CRC SOF TC0 #3 EOF CRC TC0_REPLAY_TIMER is stopped on the receipt of the NAC frame.

The remote TX transmits AFC Frames for TC1 and TC0. so it did not send an AFC0 Frame. 3385 • 3386 • 3387 • Copyright © 2007-2011 MIPI Alliance.Version 1. 3379 • 3380 • 3381 3382 3383 3384 • • • • 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.40. The remote RX receives Frame#16. The local TX transmits NAC Frame with the RReq bit set. MIPI Alliance Member Confidential 329 . The remote RX could not detect an EOF_EVEN or EOF_ODD symbol and CRC symbol. The local TX TC0_REPLAY_TIMER expires. Inc. The local TX triggers PHY initialization (not shown in the figure). 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. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3378 Figure 109 depicts the case where retransmission is triggered by expiration of TC0_REPLAY_TIMER. The remote TX triggers PHY initialization (not shown in the figure) after receiving NAC Frame with the RReq bit set. It has no unacknowledged Data Frames for TC1 and TC0 to send.

The remote RX detects Frame#16 and Frame#18 but could not detect Frame#17. The local RX receives the AFC0#16 and the NAC Frame. It recognizes the wrong Frame Sequence Number when it received Frame#18 (while Frame#17 was expected).Version 1. Inc. MIPI Alliance Member Confidential 330 3390 • 3391 • 3392 • . 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. 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).40. 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. All rights reserved. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro TC0_REPLAY_TIMER Local TX Remote RX Remote TX AFC TC0 #15 CRC Local RX AFC TC0 #15 CRC SOF TC0 #16 EOF CRC SOF TC0 #16 XXX CRC Frame end is not detected NAC RReq CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF Retransmission of all frames that have not been acknowledged TC0 #16 EOF CRC NAC RReq CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #16 EOF CRC AFC transmission due to NAC reception AFC TC1 #31 CRC AFC TC0 #15 CRC AFC TC1 #31 CRC AFC TC0 #15 CRC AFC transmission for prior TC1 transmission AFC transmission for prior TC0 transmission AFC transmission due to NAC reception Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 109 Retransmission Triggered by TC0_REPLAY_TIMER Expiration 3388 Figure 110 depicts the scenario where the retransmission is caused by a wrong Frame Sequence Number.

3394 • The local TX starts sending TC0 Frame#1. TC0 Frame#1 is preempted by TC1 Frame#0 while the former was in transmission.40. For indication to Local a NAC frame transmission is triggered. MIPI Alliance Member Confidential 331 . All rights reserved. AFC TC0 #16 CRC NAC AFC TC0 #16 CRC NAC CRC CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #17 EOF CRC AFC TC1 #31 CRC AFC TC0 #31 CRC SOF TC0 #17 EOF CRC Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 110 Retransmission Due to Wrong Frame Sequence Number 3393 Figure 111 depicts the scenario where NAC Frame transmission is triggered due to errors in AFC reception. Copyright © 2007-2011 MIPI Alliance.Version 1. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro TC0_REPLAY_TIMER Local TX Remote RX Remote TX AFC TC0 #15 CRC Local RX AFC TC0 #15 CRC SOF TC0 #16 EOF CRC SOF TC0 #17 EOF CRC SOF TC0 #18 EOF CRC SOF TC0 #19 EOF CRC SOF TC0 #16 EOF CRC XXX TC0 #XX XXX CRC SOF TC0 #18 EOF CRC SOF TC0 #19 EOF CRC SOF and/or EOF not detected Frame with unexpected frame number is received. This frame and all following frames are discarded until a frame with the expected frame number is received.

The illustration also shows resetting and running of TC0_REPLAY_TIMER after sending each TC0 Frame. With the reception of the AFC1#0 Frame. The reception of the AFC0#3 Frame (acknowledgment for TC0 Frame#3) stops the TC0_REPLAY_TIMER. After the NAC Frame is sent.Version 1. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3395 • 3396 • 3397 • 3398 • 3399 • After transmitting TC1 Frame#0 completely.40. the TC1_REPLAY_TIMER is stopped as there are no unacknowledged Frames in the buffer. Then the local TX sends a NAC Frame (RReq bit not set). There is no Data Frame retransmission from remote TX because there are no outstanding Frames at the remote TX. The remote RX detects the NAC Frame and remote TX transmits only the AFC1#0 and AFC0#1 Frames. Copyright © 2007-2011 MIPI Alliance. the remote RX receives TC1 Frame#0 and remote TX sends acknowledgment for it with the AFC1#0 Frame. The NAC Frame preempts TC0 Frame#2. 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. The local RX detects this AFC1#0 Frame in error. MIPI Alliance Member Confidential 332 . Meanwhile. All rights reserved. the transmission of TC0 Frame#2 is continued from its preempted position.

AFC1 Frame is discarded AFC TC1 #0 CRC CRC COF TC0 #2 EOF CRC SOF TC0 #3 EOF CRC CRC COF TC0 #2 EOF CRC SOF TC0 #3 EOF CRC No unacknowledged frames in the TC1 TX buffer so the TC1_REPLAY_TIMER is stopped.40.Version 1. All rights reserved. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro Replay Timers TC0 TC1 Local TX SOF TC0 #1 SOF TC1 #0 EOF CRC COF TC0 #1 EOF CRC SOF TC0 NAC Remote RX Remote TX Local RX SOF TC0 #1 SOF TC1 #0 EOF CRC COF TC0 #1 EOF CRC SOF TC0 NAC AFC TC1 #0 CRC Bit error. Legend Timer Stopped Timer Reset and Running Timer Running Timer Expired Figure 111 No Retransmission Due to Error in AFC Reception Copyright © 2007-2011 MIPI Alliance. AFC TC1 #0 CRC AFC TC0 #1 CRC AFC TC1 #0 CRC AFC TC0 #1 CRC AFC TC0 #3 CRC AFC TC0 #3 CRC TC0_REPLAY_TIMER is stopped on the receipt of the AFC frame. MIPI Alliance Member Confidential 333 .

Inc. The IRQ Message is delivered faster with preemption. The transmission of the IRQ Message is delayed until the TC0 Frame is finalized. 3401 Figure 113 shows the further behavior of the Link without preemption. Figure 114 shows that the IRQ Message preempts TC0 Frame transmission as it has a higher priority.1 Preemption Scenarios Forward Link 3400 Figure 112 explains the forward Link use case.e.00 31-Jan-2011 MIPI Alliance Specification for UniPro B.2.2 B. MIPI Alliance Member Confidential 334 . Upper Layer DL DL Upper Layer 10 Mbps Link TC0: Bulky Data Transfer – DL_MTU Size TC1: IRQ – Small Size Figure 112 Forward Link Use Case Upper Layer DL DL Upper Layer 10 Mbps Link TC0: Bulky Data Transfer – DL_MTU Size TC1: IRQ – Small Size Figure 113 Forward Link Use Case without Preemption Copyright © 2007-2011 MIPI Alliance. i. 3402 Figure 114 and Figure 115 show the behavior of the Link with preemption. is requested to send over TC1.40.Version 1. Just after the TC0 Frame started on the Link a small Message. After the IRQ Message is finalized the TC0 Frame transmission is finalized. high priority request like IRQ. The TC0 is requested to transmit a bulk of data. All rights reserved.

Inc.40. the reverse Link also benefits from the preemption.Version 1. 3404 With preemption the AFC Frame is transmitted immediately in consideration of the arbitration scheme and the IDLE time of the forward Link is reduced to a minimum if no higher priorities traffic is ongoing on the reverse Link.2. MIPI Alliance Member Confidential 335 .2 Reverse Link 3403 Besides the forward Link use case explained earlier. All rights reserved. Without preemption the reverse traffic can block the forward Link by a significant factor compared to preemption case. Copyright © 2007-2011 MIPI Alliance.00 31-Jan-2011 MIPI Alliance Specification for UniPro Upper Layer DL DL Upper Layer 10 Mbps Link TC0: Bulky Data Transfer – DL_MTU Size TC1: IRQ – Small Size Figure 114 Forward Link Use Case with Preemption – Start of Preemption Upper Layer DL DL Upper Layer 10 Mbps Link TC0: Bulky Data Transfer – DL_MTU Size TC1: IRQ – Small Size Figure 115 Forward Link Use Case with Preemption – End of Preemption B. Because an AFC Frame can only be sent after a current transmitted Frame is finalized and on the forward Link the Frame cannot be transmitted when the forward Link is waiting for an AFC Frame (no credits available or max outstanding acknowledgments (DL_TCxOutAckThreshold) are reached).

40. All rights reserved. Figure 117 shows that TC0 Frame is started on reverse Link just before the completion of the TC1 data on forward Link. In Figure 117 the TC1 buffer at the receiver is empty and it is not yet communicated to the sender side. the AFC1 Frame is transmitted on the reverse Link (see Figure 118). Ack and credits received Transmission blocked Figure 117 Reverse Link Use Case without Preemption – AFC1 is Blocked Copyright © 2007-2011 MIPI Alliance. Ack and credits received Transmission blocked Figure 116 Reverse Link Use Case 3405 The behavior of the use case is described here without preemption. MIPI Alliance Member Confidential 336 . Inc. AFC1 Frame cannot be sent immediately as TC0 occupies the reverse Link. After the reception of the flow control the forward Link is able to transmit new TCx Data Frame on the forward Link. The received TC1 data is consumed by the upper layer and the buffer is empty now. After completion of TC0. It cannot be sent due to the undelivered AFC1 Frame from receiver side.00 31-Jan-2011 MIPI Alliance Specification for UniPro Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send. The sender has new TC1 data to send. Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send.Version 1. This results in an IDLE state of the forward Link.

Inc. MIPI Alliance Member Confidential 337 . Ack and credits received 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. IDLE time of the forward Link is reduced to a minimum. All rights reserved. Copyright © 2007-2011 MIPI Alliance. the AFC1 preempts immediately the ongoing TC0 transmission (see Figure 120). The preempted Frame is continued after the AFC Frame transmission is finalized.Version 1. Ack and credits received Transmission blocked Figure 118 Reverse Link Use Case without Preemption – TC1 Data is Blocked Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send.00 31-Jan-2011 MIPI Alliance Specification for UniPro Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send.40. The sender can serve TC1 Data Frame transmission after the AFC1 is received (see Figure 121).

MIPI Alliance Member Confidential 338 . All rights reserved. Inc. Ack and credits received Transmission pre-empted Figure 121 Reverse Link Use Case with Preemption – AFC1 Reception Copyright © 2007-2011 MIPI Alliance.Version 1. Ack and credits received Transmission pre-empted Figure 120 Reverse Link Use Case with Preemption – AFC1 Transmission Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send.

The example shows a TC0 Frame with ASCII characters ‘1’ through ‘9’. X0) 16 1 0 0 0 0 0 0 0 1 0 15 L3s=1 14 13 12 11 10 ESC_DL 9 8 7 L4s=1 6 5 SOF 4 3 TC=TC0 2 1 0 Reserved FCT=0 ECM=0 HEX value 0xFFFF 0x4EF8 0x2D5E 0xA796 0xE93D 0x375D 0x05ED 0x5125 0x819B 0xB5DF Initial Value 0x10107 0x08284 0x03132 0x03334 0x03536 0x03738 0x03941 0x04243 0x1012A 0x04A20 DestDeviceID_Enc = 2 ‘1’ (0x31) ‘3’ (0x33) ‘5’ (0x35) ‘7’ (0x37) ‘9’ (0x39) ‘B’ (0x42) ESC_DL DestCPortID_Enc = 1 ‘2’ (0x32) ‘4’ (0x34) ‘6’ (0x36) ‘8’ (0x38) ‘A’ (0x41) ‘C’ (0x43) EOF_EVEN CCITT CRC-16 = 0x4A20 Frame Seq. CRC Register (X15 . Number=0x0A 1's Complement Figure 123 CCITT CRC Example Copyright © 2007-2011 MIPI Alliance. ‘B’ and ‘C’.3 CCITT CRC-16 Example 3407 An illustrative example of the CCITT CRC-16 is given in Figure 123. All rights reserved.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Upper Layer DL 1 Gbps Link Ack and Credits AFC FSM DL Upper Layer 10 Mbps Link TC0 TC1 AFC ready to send. MIPI Alliance Member Confidential 339 .40.. Inc. Ack and credits received Transmission pre-empted Figure 122 Reverse Link Use Case with Preemption – End of Preemption B. ‘A’.

cnf Figure 124 Common Usage of SAP Primitives C.4 provides an overview of the SAP concept used by the UniPro stack.req) Service Primitive is used by a Service User to request a Service Provider execute a particular action. The action may cause remote and local state changes.rsp) Service Primitive is used by a Service User to carry out an action in response to an Indication Service Primitive. However. However. a few additional concepts are needed to fully describe the UniPro stack and its behavior. The Indication (. A Response Service Primitive has the same ambiguity.00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex C SAP Primitive Formalism (informative) 3408 This specification uses the OSI protocol formalism developed in [ITUT01] and [ITUT02] to describe the UniPro protocol stack.ind . The Confirm (. there are situations where the relationship of a Response or Confirm Service Primitive to another Service Primitive or action is ambiguous as shown in Figure 125. Inc. MIPI Alliance Member Confidential 340 .rsp . The action may cause remote and local state changes. Device A Layer n+1 .req Layer n Layer n Device B Layer n+1 .cnf) Service Primitive is used by a Service Provider to signal that a particular action was executed or to provide a response to a request. these Service Primitives relate to each other as shown in Figure 124. 3414 In most cases.Version 1. In this example. Copyright © 2007-2011 MIPI Alliance. 3409 Section 4.40. The Response (.ind) Service Primitive is used by a Service Provider to indicate to a Service User that a particular action was executed. All rights reserved. it is not clear if a Confirm Service Primitive is the result of a local or remote action. The following summary of the four classical Service Primitives is provided for convenience: 3410 • 3411 • 3412 • 3413 • The Request (. The action may have been triggered remotely or locally. The action may have been triggered remotely or locally.1 Additional SAP Primitives 3415 The Message Sequence Chart shown in Figure 124 is typical for certain types of transactions.

cnf Figure 125 Ambiguous Usage of SAP Primitives 3416 The following additional Service Primitives are introduced to avoid this ambiguity: 3417 • The Local Confirm (.cnf) Service Primitives are now reserved for Messages that result in a Message sent to a peer Device. Copyright © 2007-2011 MIPI Alliance. 3418 • 3419 With the addition of these two new Service Primitives. the relationships between Service Primitives are modified as shown in Figure 126.Version 1.cnf .rsp) and Confirm (.rsp_L) Service Primitive is issued following an Indication Service Primitive that was directed at the local Device. Inc.rsp . The Local Response (.40.req Layer n Layer n Device B Layer n+1 . a new Indication Service Primitive cannot be issued before reception of a Local Response Service Primitive. a new Request Service Primitive cannot be issued before reception of a Local Confirm Service Primitive. All rights reserved.ind . Typically.rsp .00 31-Jan-2011 MIPI Alliance Specification for UniPro Device A Layer n+1 . thus regulating the rate of Messages sent between the Service User and local Service Provider. The Response (. thus regulating the rate of Messages sent between the Service User and local Service Provider. Typically.cnf_L) Service Primitive is issued following a Request Service Primitive directed at the local Device. MIPI Alliance Member Confidential 341 .

cnf Figure 126 Usage of the Local SAP Primitives Copyright © 2007-2011 MIPI Alliance.Version 1.rsp . MIPI Alliance Member Confidential 342 .cnf_L .00 31-Jan-2011 MIPI Alliance Specification for UniPro Device A Layer n+1 .req Layer n Layer n Device B Layer n+1 .rsp_L . Inc.40.ind . All rights reserved.

Conformance to the UniPro specification does not depend on any portion of the signal interface defined herein. which includes the clock T_CO_DATA. All rights reserved.ind T_CO_FLOWCONTROL. 3430 The T_CO_DATA.1 3424 3425 3426 3427 3428 • • • • • Signal Definition Global. As a result.req. D. which includes optional signals for external TX CPort arbitration 3423 The CPort signal interface. The CPort signal interface is the signal-interface equivalent of the T_CO_SAP.req reflect the UniPro T_CO_SAP. Copyright © 2007-2011 MIPI Alliance.req.ind and T_CO_FLOWCONTROL. T_CO_DATA. which includes the flow-control transmission signals TX status/arbitration. there is no attempt to minimize the number of signals.req T_CO_DATA.req Tx Status/Arbitration Figure 127 CPort Signal Interface 3429 The CPort signal interface is a synchronous interface. which includes the short-header data reception signals T_CO_FLOWCONTROL.req. depicted in Figure 127.ind. Inc. 3422 The CPort signal interface is optimized for a local on-chip interface. which includes the short-header data transmission signals T_CO_DATA.00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex D CPort Signal Interface (informative) 3420 The CPort signal interface defines a generic signal interface used to connect UniPro CPorts to their Applications. MIPI Alliance Member Confidential 343 .40. 3421 The CPort signal interface is informative only. All signals of the CPort signal interface are synchronous to the rising edge of t_clk.Version 1. consists of five signal groups: CPort Global t_clk t_tx_valid t_tx_accept t_tx_cportid t_tx_data t_tx_byte_en t_tx_eom t_rx_valid t_rx_accept t_rx_cportid t_rx_data t_rx_byte_en t_rx_eom t_rx_msg_status t_fc_valid t_fc_accept t_fc_cportid t_fc_credits t_fc_credits_accepted t_txsa_cport_status t_txsa_fc_for_maxsegment t_txsa_end_segment Application T_CO_DATA. This interface is meant as an example of how the more generic T_CO_SAP could be instantiated in an implementation.

and because data is serialized anyway by the UniPro stack. which lead to this particular CPort signal interface design. as the data is already serialized before being transferred over the UniPro Link. signals can be added or removed as needed. Moreover. 3433 A detailed description of all the CPort interface signals is shown in Table 126. This multiplexing requires the UniPro stack to assist the external TX CPort arbiter.40. There is no need for similar arbitration signals at the RX side. Other choices are obviously possible.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3431 The CPort signal interface multiplexes the CPort data transfers to prevent a signal explosion. These signals are grouped in the TX Status/Arbitration signal group. 3432 All of the previous options are particular design choices. MIPI Alliance Member Confidential 344 . Copyright © 2007-2011 MIPI Alliance.Version 1. All rights reserved. Inc.

00 31-Jan-2011 Table 126 Signal Name Driver CPort Interface Signal Definition Description Common Group t_clk Clock source Main clock. This signal indicates the CPort ID to which the data is destined. This signal is sampled when t_tx_valid is '1'.req Group Copyright © 2007-2011 MIPI Alliance. the permissible t_tx_byte_en values are b'1111'. b'1100' and b'1000'. this signal contains one bit per data byte. Changing the t_tx_cportid value creates a Message fragment boundary. Transmitter byte enable. For N=32. C=3 if 16 CPorts are implemented. and results in a new Packet being created by the UniPro stack. … t_tx_data[7:0] (LSB). t_tx_byte_en[N/8-1:0] Application . t_tx_data.g. t_tx_accept CPort t_tx_cportid[C:0] Application MIPI Alliance Specification for UniPro t_tx_data[N-1:0] Application Transmitter data. When '1'. In the case of a multiple byte data interface. Transmitter accept. The t_tx_byte_en[i] values of '1' and '0' indicate the presence and absence of valid data for the i-th byte (i. MIPI Alliance Member Confidential 345 t_tx_valid Application Transmitter valid.40. All the signals of the CPort signal interface are synchronous to the rising edge of t_clk.e. Transmitted CPort ID. Permissible values for t_tx_byte_en are only those with adjacent valid bytes starting from MSB. All rights reserved. and is driven with each data element. The byte transmission order is t_tx_data[N-1:N-8] (MSB). t_tx_byte_en and t_tx_eom are valid and will remain valid until they are accepted by the CPort by setting t_tx_accept to '1'. t_tx_data[N-9:N-16]. The data is transferred when t_tx_valid and t_tx_accept are both '1'. b'1110'. e. The CPort is allowed to set t_tx_accept to '1' before t_tx_valid is set '1'.Version 1. t_tx_data[i×8+7:i×8]). this signal indicates that the CPort is ready to accept data.. and is implementation-specific. respectively. this signal indicates that t_tx_cportid. The signal width depends on the number of CPorts in the UniPro stack. This signal width is a multiple of 8. When '1'. T_CO_DATA. Inc..

The Application is allowed to set t_rx_accept to '1' before t_rx_valid is set to '1'. Receiver byte enable. b'1100' and b'1000'. respectively. b'1110'. The last Message byte is the least significant enabled byte transferred by t_tx_data in the same clock cycle.ind Group Copyright © 2007-2011 MIPI Alliance. When '1'. For N=32. C=3 if 16 CPorts are implemented. which is the least significant enabled byte transferred by t_tx_data in the same clock cycle. t_rx_byte_en and t_rx_eom are valid and will remain valid until they are accepted by the Application by setting t_rx_accept to '1'. When '1'. e.. … t_rx_data[7:0] (LSB). T_CO_DATA. t_rx_accept Application t_rx_cportid[C:0] CPort t_rx_data[N-1:0] CPort MIPI Alliance Specification for UniPro t_rx_byte_en[N/8-1:0] CPort t_rx_eom CPort . The byte transmission order is t_rx_data[N-1:N-8] (MSB). Setting t_tx_eom to '1' results in the EOM flag being set to '1' for the Segment containing the last Message byte.e. this signal indicates the receipt of the last byte of the Message. Inc.Table 126 Signal Name Driver CPort Interface Signal Definition (continued) Description Version 1.00 31-Jan-2011 t_tx_eom Application Transmitter End Of Message. t_rx_data[N-9:N-16]. this signal indicates that the Application is ready to accept data. this signal indicates that t_rx_cportid. this signal indicates that the last byte of the Message is sent. Receiver accept. This signal is sampled when t_rx_valid is '1'. and is driven with each data element. Receiver data.g. Receiver End Of Message. and is implementation-specific. The data is transferred when t_rx_valid and t_rx_accept are both '1'. This signal width is a multiple of 8. MIPI Alliance Member Confidential 346 t_rx_valid CPort Receiver valid. Receiver CPort ID. t_rx_data. The signal width depends on the number of CPorts in the UniPro stack. t_rx_data[i×8+7:i×8]). When '1'. the permissible t_rx_byte_en values are b'1111'. In the case of a multiple byte data interface. The t_rx_byte_en[i] values of '1' and '0' indicate the presence and absence of valid data for the i-th byte (i. This signal indicates the CPort ID from which the data is sent.40. this signal contains one bit per data byte. Permissible values for t_rx_byte_en are only those with adjacent valid bytes starting from MSB.. All rights reserved. When '1'.

This signal indicates whether the currently received Message is valid or corrupt due to a fragment being dropped in the CPort (by the safety valve or the Controlled Segment Dropping). Flow-control credits. All rights reserved.00 31-Jan-2011 t_rx_msg_status CPort Receiver Message status. The width of the t_fc_credits_accepted signal is identical to the t_fc_credits signal width.g. Once set to '1'.. The credit transfer is erroneous when t_fc_credits_accepted is less than t_fc_credits from the last cycle (equivalent to the CREDITS_EXCEEDED value of L4CPortResultCode in the T_CO_FLOWCONTROL. T_CO_FLOWCONTROL. The signal stays set to '1' until t_rx_eom is set to '1'.cnf_L). This signal indicates the CPort ID to which the credits are destined. When more credits than the t_fc_credits capacity must be transferred. A value of '0' indicates that the Message has been correct so far.req Group Copyright © 2007-2011 MIPI Alliance. A value of '1' indicates that a fragment has been dropped. Flow-control accept.Table 126 Signal Name Driver CPort Interface Signal Definition (continued) Description Version 1. This signal is valid one cycle after t_fc_credits was transferred. The data is transferred when t_fc_valid and t_fc_accept are both '1'. 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. When '1'. MIPI Alliance Member Confidential 347 t_fc_valid Application Flow-control valid. this signal indicates that t_fc_cportid and t_fc_credits are valid and will remain valid until they are accepted by the CPort by setting t_fc_accept to '1'. the t_fc_credits signal must be asserted multiple times. Inc. Flow-control CPort ID. The signal width. and indicates the amount of credits accepted by the CPort. The credit transfer is correct when t_fc_credits_accepted is equal to the t_fc_credits from the last cycle (equivalent to the OK value of L4CPortResultCode in the T_CO_FLOWCONTROL. is implementation-specific and relates to the amount of credits that can be issued at once.40. Flow-control credits accepted. e. The CPort is allowed to set t_fc_accept to '1' before t_fc_valid is set '1'. When '1'. The signal width depends on the number of CPorts in the UniPro stack. t_fc_accept CPort t_fc_cportid[C:0] Application t_fc_credits[F:0] Application MIPI Alliance Specification for UniPro t_fc_credits_accepted[F:0] CPort . F+1.cnf_L). this signal indicates that the CPort is ready to accept credits. C=3 if 16 CPorts are implemented.

If the t_txsa_fc_for_maxsegment[i] signal is '1'. Copyright © 2007-2011 MIPI Alliance. End of Segment. Credits for maximum Segment. This signal reflects the status of each CPort. 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).Table 126 Signal Name Driver CPort Interface Signal Definition (continued) Description TX Status/Arbitration Group Version 1. The b'10' value is reserved. MIPI Alliance Member Confidential 348 t_txsa_fc_for_maxsegment[(P-1):0] CPort t_txsa_end_segment[(P-1):0] CPort MIPI Alliance Specification for UniPro .00 31-Jan-2011 t_txsa_cport_status[(2*P-1):0] CPort CPort status. the i-th CPort has enough end-to-end credits to send a maximum Segment. with t_txsa_cport_status[2*i+1:2*i] reflecting the status of the i-th CPort (P is the total number of CPorts). Inc. A value of b'01' indicates that the CPort is not connected (NO_CONNECTION). The t_txsa_end_segment[i] signal is set to '1' for a single cycle every time Layer 4 introduces an end of Segment.40. All rights reserved. A value of b'00' indicates that the CPort is configured and usable for data transmission and reception. otherwise the i-th CPort has less credits (P is the total number of CPorts).

MIPI Alliance Member Confidential 349 . Copyright © 2007-2011 MIPI Alliance. The data in this Message fragment is transferred to CPort 0 as indicated by t_tx_cport. which indicates that all four bytes of the interface contain valid data. In first cycle. the Application also sets t_tx_valid to ‘1’.40.2 Timing Diagrams 3434 This section illustrates the functionality of the CPort signal interface with timing diagrams. The t_tx_byte_enable is set to b’1111’. the transfer continues with a new Message fragment to CPort 1 as indicated by t_tx_cportid.Version 1. 3437 In cycle N+1. meaning that data is transferred to the UniPro stack. t_clk t_tx_valid t_tx_accept t_tx_cportid[C:0] h’0' h’0' h’0' h’0' h’0' h’1' h’1' t_tx_data[7:0] D3 D7 D11 Dn-3 X D3 D7 t_tx_data[15:8] D2 D6 D10 Dn-4 Dn D2 D6 t_tx_data[23:16] D1 D5 D9 Dn-5 Dn-1 D1 D5 t_tx_data[31:24] D0 D4 D8 Dn-6 Dn-2 D0 D4 t_tx_byte_en[3:0] t_tx_eom b’1111' b’1111' b’1111' b’1111' b’1110' b’1111' b’1111' cycle 1 cycle 2 cycle 3 cycle N-1 cycle N cycle N+1 cycle N+2 Figure 128 Transmitter Data Transfer Example 3438 In Figure 129. 3436 As t_tx_valid and t_tx_accept remain set to ‘1’. A transmitter transfer can be delayed in this way when e. Dn-1 and Dn) as indicated by the b’1110’ value of t_tx_byte_en. Inc. the Message fragment continues to be transferred until the t_tx_eom is set to ‘1’ in cycle N. an example of a Message fragment transfer from the Application to the UniPro stack is shown. The UniPro stack indicates that it is ready to accept data by setting the t_tx_accept to ‘1’.. 3435 In Figure 128.00 31-Jan-2011 MIPI Alliance Specification for UniPro D. All rights reserved.g. a second transmitter data transfer is shown. The data transfer in cycle N contains only three valid bytes (Dn-2. the UniPro stack uses t_tx_accept to stop the data transfer in cycle 3. In this case. These three bytes are transferred on the most significant byte lanes of t_tx_data. The rest of the transfer is similar to that in Figure 128. the core inserts a header symbol.

data is transferred in all cycles except cycle 2. first on CPort 0 (cycles 1 through N). The data is transferred when both t_tx_valid and t_tx_accept are ‘1’. as indicated by the t_rx_byte_en value of b’1100’. and end-of-message is indicated by setting t_rx_eom to ‘1’.Version 1. In cycle N. t_clk t_rx_valid t_rx_accept t_rx_cportid[C:0] t_rx_data[7:0] h’0' D3 h’0' D7 h’0' D7 h’0' D11 h’0' Dn-2 h’0' X h’1' D3 t_rx_data[15:8] D2 D6 D6 D10 Dn-3 X D2 t_rx_data[23:16] D1 D5 D5 D9 Dn-4 Dn D1 t_rx_data[31:24] D0 D4 D4 D8 Dn-5 Dn-1 D0 t_rx_byte_en[3:0] t_rx_eom t_rx_msg_status b’1111' b’1111' b’1111' b’1111' b’1111' b’1100' b’1111' cycle 1 cycle 2 cycle 3 cycle 4 cycle N-1 cycle N cycle N+1 Figure 130 Receiver Data Transfer Example Copyright © 2007-2011 MIPI Alliance. only the two most significant two bytes of t_rx_data are enabled. then CPort 1 (cycle N+1 onwards) as indicated by t_rx_cportid. MIPI Alliance Member Confidential 350 . a receiver data transfer is shown. The t_rx_msg_status value of ‘0’ indicates that the Message is correctly received. All rights reserved. Inc. Thus.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro t_clk t_tx_valid t_tx_accept t_tx_cportid[C:0] h’0' h’0' h’0' h’0' h’0' h’0' h’1' t_tx_data[7:0] D3 D7 D7 D11 Dn-1 X D3 t_tx_data[15:8] D2 D6 D6 D10 Dn-2 X D2 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_byte_en[3:0] b’1111' b’1111' b’1111' b’1111' b’1111' b’1000' b’1111' t_tx_eom cycle 1 cycle 2 cycle 3 cycle 4 cycle N-1 cycle N cycle N+1 Figure 129 Delayed Transmitter Data Transfer Example 3439 In Figure 130. In cycle N.

in the following cycle. 3442 In cycles 5 and 6.40. respectively. It is allowed to transfer credits on t_fc_credits. respectively. as shown in cycle 6. As shown in cycle 4. The credit is accepted in cycle 2 by setting t_fc_accept to ‘1’. in cycles 6 and 7. The credits are acknowledged by t_fc_credits _accepted on cycle after the credit transfer.Version 1. MIPI Alliance Member Confidential 351 . t_clk t_fc_valid t_fc_accept t_fc_cportid[C:0] h’0' h’0' h’0' h’0' h’1' h’2' X t_fc_credits[F:0] C0 C0 X X C1 C2 X t_fc_credits_accepted[F:0] X cycle 1 X cycle 2 C0 cycle 3 X cycle 4 X cycle 5 C1 cycle 6 C2 cycle 7 Figure 131 Flow Control Credit Transfer Example Copyright © 2007-2011 MIPI Alliance. new credit values C1 and C2 are transferred for CPorts 1 and 2. a flow control credit transfer is shown. the t_fc_valid is ‘0’.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3440 In Figure 131. 3441 In cycles 3 and 4. which means the t_fc_credits do not contain meaningful values. As a result. 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. Inc. 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’. All rights reserved. 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. while acknowledging credits from the previous cycle on t_fc_credits_accepted.

00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex E Test M-PHY Protocol Interface (T-MPI) (informative) 3443 The interface described in this annex is optional. All rights reserved. The M-PHY DATA SAP is sent over the T-MPI using the SERDES. The use cases described in this annex are not limiting. Copyright © 2007-2011 MIPI Alliance.40.RX Figure 132 T-MPI Protocol Testing Configuration E. This may be the case for a UniPro conformance tester that requires an FPGA implementation of the UniPro stack and third party M-PHY.RX Test Features Test Features CTRL . This is used for example for checking power mode.2 UniPort-M testing using an external third party M-PHY 3450 The T-MPI interface may be used to enable a UniPro Stack user to borrow a third party M-PHY. Therefore a maximum of 4 transceivers pairs may be used to test a UniPro implementation that supports up to four data lanes. This annex describes the mapping of the M-TX-DATA. MIPI Alliance Member Confidential 352 . it shall implement it as described in this annex.TX CTRL . 3449 One SERDES transceiver pair includes a transmitter and a receiver. E. However. Inc.TX T-MPI Dummy M-PHY DATA .5 to L4 CTRL . It essentially replaces the M-PHY by utilizing high-speed SERDES technology available on modern FPGAs. Figure 132 gives an example of T-MPI interface usage for UniPro protocol stack testing. 3446 Several essential features of the PA Layer are using services of the CTRL SAPs. Therefore. such as power mode related Attributes.1 Use Cases 3447 The T-MPI enables two main. The Test Features module controls and monitors the data stream on the SERDES. M-TX-CTRL and M-RX-CTRL SAPs to the T-MPI interface.RX SERDES T-MPI SERDES DATA .TX CTRL . while the M-PHY CTRL SAP is used to control the Test Features included in the “Dummy M-PHY”.1.1 UniPro Protocol Stack Testing 3448 UniPro Protocol Stack Testing may be used for interoperability testing between two UniPro stacks.Version 1. The T-MPI should use one SERDES transceiver per supported M-PHY data lane. 3444 The Test M-PHY Protocol Interface (T-MPI) is an optional interface that corresponds to the M-PHY SAP interface. if a UniPro implementation chooses to support TMPI. E. 3445 The PHY_SAP consists of separate set of DATA and CTRL SAPs for both the RX and TX direction. the T-MPI mandates a minimum amount of M-PHY features. The T-MPI can be seen as a “Dummy M-PHY” implementation. This annex refers extensively to Annex A in [MIPI05].TX UniPro Stack L1.5 to L4 DATA . use cases for the test of a UniPro implementation. This interface may be used to test the UniPro protocol stack on an FPGA implementation and may be used for interoperability testing of an early UniPro stack prototype.RX UniPro Stack L1.1. to be supported. Dummy M-PHY DATA . M-RX-DATA.

TX T-MPI Dummy M-PHY M-TX DATA .6. All rights reserved. An implementation may extend the feature-set described in this annex. Power Mode test feature as described in Section E. while the M-PHY CTRL SAPs are mapped to the serial interface. Access to T-MPI Attributes as described in Section E.8.2.8. The UniPro stack and the T-MPI interface are implemented onto the FPGA of the UniPro stack PCB. In this configuration the M-PHY DATA SAPs are mapped to the T-MPI interface. 3465 • 3466 When used in external M-PHY case.8.2 T-MPI Features 3454 The T-MPI described in this annex contains a number of features that may or may not be supported by a particular implementation depending on the use case and the purpose of such implementation. Dummy M-PHY DATA . Physical Lanes renumbering as described in Section E. There should be a single SERDES transceiver pair per supported data lane.5.4.RX Control I/F Serial I/F Control I/F M-RX FPGA UniPro Stack PCB FPGA PHY PCB Figure 133 External M-PHY Configuration 3452 Such a configuration enables usage of M-PHY from several sources with different proprietary interfaces. Access to M-PHY MODULE Attributes and support for M-PHY MODULE effective and shadow configuration register banks as described in Section E.3. E. The SERDES transceivers data format is described in Section E.8.4. Inc.8.8. Copyright © 2007-2011 MIPI Alliance. 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. the T-MPI should support the following features: 3467 • Conversion of M-PHY CTRL SAPs to a Serial Interface as described in Section E.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3451 Figure 133 gives an example of a external M-PHY configuration using the T-MPI interface. The FPGA of the PHY PCB implements the T-MPI interface to the UniPro stack PCB and a proprietary interface to the M-PHY. Features are categorized as mandatory features and optional features.7.RX UniPro Stack L1.Version 1. MIPI Alliance Member Confidential 353 .8. FSM Emulation test feature as described in Section E. 3459 When used in protocol testing case the T-MPI shall support the following features: 3460 3461 3462 3463 3464 • • • • • Four SERDES instances. 3456 When used in protocol testing case the T-MPI should support the following features: 3457 • 3458 • Error Control test feature as described in Section E.40. OMC Emulation test feature as described in Section E.5 to L4 SERDES T-MPI SERDES Proprietary I/F CTRL . The SERDES Transceivers should run at a fixed data rate. 3455 The T-MPI shall support SERDES Transceivers for all use cases. The PHY PCB has an MPHY device and an FPGA.1.TX M-PHY CTRL .9.

3471 M-TX-DATA SAP and M-RX-DATA SAP are transferred directly to and from the SERDES transceivers respectively.2. 3472 The DM Register bank refers to Dummy M-PHY Register bank. control and status Attributes including effective and shadow registers. Copyright © 2007-2011 MIPI Alliance. It contains all M-PHY related capability. MIPI Alliance Member Confidential 354 . The physical lane renumbering module just multiplexes logical lanes on protocol side to physical lanes on T-MPI side. Depending on the status of various test features additional control and status information are sent and received by the SERDES. All rights reserved. 3473 Since the SERDES operates at a fixed data rate. This is necessary for the verification of the PACP protocol in the PA Layer. 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. This is necessary for the verification of correct usage of the M-TX-CTRL and M-RX-CTRL SAPs.Version 1. Each data lane of the protocol shall be connected to the T-MPI lane through a physical lane renumbering module. Lane0 DATA-TX Lane0 DATA-RX 1 Lane T-MPI LaneX DATA-TX Lane0 Control TTXP0 TTXN0 TRXP0 TRXN0 TTXP1 TTXN1 TRXP1 TRXN1 Power Mode SerDes Transceivers TTXP2 TTXN2 TRXP2 TRXN2 TTXP3 TTXN3 TRXP3 TRXN3 LaneX DATA-RX Lane1 DATA-TX Lane1 DATA-RX Shadow ERROR Control Lane1 Control Protocol Lane2 DATA-TX Physical lane renumbering LaneX Control Lane2 DATA-RX Effective DM Register bank Capability Status OMC Emulation Lane2 Control FSM Emulation Lane3 DATA-TX T-MPI Control Lane3 DATA-RX Lane3 Control Dummy M-PHY Figure 134 Protocol Testing Block Diagram 3470 Four instance of the T-MPI lane shall be used regardless on the number of supported data lanes by the protocol.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3468 • Support for simultaneous multi-lanes M-PHY configuration.40. the Power Mode parameters are extracted and checked against the expected power mode setting of the effective configuration registers of the M-RX. Inc.1 Functional Block Diagram (Protocol Testing) 3469 Figure 134 illustrates the block diagram for the Protocol Testing use case. 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. a Power Mode test feature is introduced in the T-MPI. The control for the lane multiplexing is provided by T-MPI control Attributes. E. On the SERDESRX side.

E. E. the Dummy M-PHY shall have one instance of a T-MPI lane. The OMC emulation module controls sending of LCC commands over the SERDES-TX side and detects LCC commands on the SERDESRX side. 3476 The T-MPI control block contains all T-MPI related Attributes and controls the SERDES operations. The M-TX-DATA and M-RX-DATA SAPs are directly mapped to the SERDES transceivers.Version 1. 3479 The T-MPI control block contains all necessary T-MPI-related Attributes and controls the SERDES operations.3 T-MPI Signal List 3480 This section describes the T-MPI signal list. It may be used to track the Dummy M-TX and M-RX state machines.2. MIPI Alliance Member Confidential 355 . The M-TX-CTRL and M-RX-CTRL SAPs should be mapped to a single instance of a Serial interface.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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. Inc.40. A T-MPI lane should have a single SERDES transceivers instance. All rights reserved. Copyright © 2007-2011 MIPI Alliance.2 Functional Block Diagram (External M-PHY) 3477 The block diagram of T-MPI for the external M-PHY use case is depicted in Figure 135. 3475 FSM Emulation test feature is optional. Lane0 DATA-TX Lane0 DATA-RX 1 Lane T-MPI LaneX DATA-TX Lane0 Control TTXP0 TTXN0 TRXP0 TRXN0 SerDes Transceivers TTXP1 TTXN1 TRXP1 TRXN1 TTXP2 TTXN2 TRXP2 TRXN2 TTXP3 TTXN3 TRXP3 TRXN3 LaneX DATA-RX Lane1 DATA-TX Lane1 DATA-RX LaneX Control T-MPI Control Lane1 Control Protocol Lane2 DATA-TX Lane2 DATA-RX Lane2 Control Lane3 DATA-TX SCL Serial I/F Dummy M-PHY SDA Lane3 DATA-RX Lane3 Control Figure 135 T-MPI Block Diagram for External M-PHY Case 3478 For each supported data lane.

Inc. The method to put the SERDES in the required BURST mode is outside the scope of this specification. the T-MPI defines additional control symbols which are reserved control symbols for the M-PHY. E. E. direction from UniPro stack PCB to PHY PCB Bi-directional serial data. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 127 Group Signal name T-MPI Signals description Description Direction T-MPI TX Lane 0 TTXP0 TTXN0 TRXP0 TRXN0 TTXP1 TTXN1 TRXP1 TRXN1 TTXP2 TTXN2 TRXP2 TRXN2 TTXP3 TTXN3 TRXP3 TRXN3 SCL SDA Out Out In In Out Out In In Out Out In In Out Out In In Out In/Out SERDES TX Lane 0 P SERDES TX Lane 0 N SERDES RX Lane 0 P SERDES RX Lane 0 N SERDES TX Lane 1 P SERDES TX Lane 1 N SERDES RX Lane 1 P SERDES RX Lane 1 N SERDES TX Lane 2 P SERDES TX Lane 2 N SERDES RX Lane 2 P SERDES RX Lane 2 N SERDES TX Lane 3 P SERDES TX Lane 3 N SERDES RX Lane 3 P SERDES RX Lane 3 N Serial Clock.4 SERDES Data Format 3483 After reset. Data are sampled on the rising edge of SCL. All information communicated over the SERDES shall use 8b10b encoding and RD (Running Disparity) as in the M-PHY specification [MIPI05].40. four T-MPI data lanes shall be supported and the TMPI 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. T-MPI RX Lane 0 T-MPI TX Lane 1 T-MPI RX Lane 1 T-MPI TX Lane 2 T-MPI RX Lane 2 T-MPI TX Lane 3 T-MPI RX Lane 3 T-MPI Serial Interface 3481 When using the T-MPI in case of protocol testing only. The T-MPI receiver Copyright © 2007-2011 MIPI Alliance. The T-MPI shall transmit only control symbols that are supported by the M-PHY and control symbols defined for the T-MPI.1 T-MPI Control Symbols 3484 In order to distinguish between M-PHY control symbols and T-MPI control symbols.Version 1. 3485 The additional T-MPI Control symbols are given in Table 128.4. MIPI Alliance Member Confidential 356 . the T-MPI shall initialize the SERDES transceivers and put them into BURST mode.

Version 1. In case of protocol testing the T-MPI receiver shall check the following data symbol and compare it to the expected power mode as described in Section E. EoB shall be generated by the T-MPI TX on burst completion from the PA Layer (falling edge of TX_Burst). 3492 On a detection of HoB control symbol by the T-MPI receiver. since there is no checking on MK0/MK1/MK2 control symbols requested by the PA Layer. 3487 The usage of the NFLR control symbol enables keeping the SERDES transceivers running at a fixed predefined data rate. HoB shall not be followed by PwrMode data symbol in case of borrowed M-PHY.2 Head Of Burst Control Symbol 3488 Any burst initiated by the protocol shall be encapsulated between HoB and EoB control symbols.40.23. The list of T-MPI control symbols given in Table 128 may be extended.1 New Filler Control Symbol 3486 T-MPI defines the NFLR control symbol as a new filler control symbol.4.8.7 K. E. Inc. 3490 • 3491 The HoB control symbol defined by the T-MPI is different than the MK0 defined by the M-PHY. it shall generate a M-LANE-PREPARE.3 End Of Burst Control Symbol 3493 The EoB control symbol defined by T-MPI is different than the MK2 control symbol defined by M-PHY.29. E. The HoB control symbol is used to indicate a start of burst sequence initiated by the protocol.7 K. On the receiver side NFLR symbols shall not be transferred to the protocol side.00 31-Jan-2011 MIPI Alliance Specification for UniPro does not check for undefined control symbols. HoB shall be generated on a M-LANE-PREPARE.27. T-MPI just transmit/receives the symbols as they come without the need to interpret them.7 K.ind primitive (or a falling edge of RX_Burst).4 K.28.30. Upon detection of EoB control symbol by the T-MPI RX it shall generate a M-LANE-BurstEnd. MIPI Alliance Member Confidential 357 . HoB shall be followed by a PwrMode data symbol in case of protocol testing.3.4. The EoB control symbol indicates an end of burst. NFLR is the default symbol that shall be transmitted by the SERDES when no other active data transfer is requested by the protocol.4.1. It enables verification of proper sequencing of M-PHY control symbols.req primitive (or on the rising edge of TX_Burst signal) as soon as the SERDES is able to accept a new active burst.0 K.1. All rights reserved.7 000 11100 100 11100 111 11101 111 11011 111 10111 111 11110 001111 0100 001111 0010 101110 1000 110110 1000 111010 1000 011110 1000 110000 1011 110000 1101 010001 0111 001001 0111 000101 0111 100001 0111 NFLR HoB EoB LCFG LRST ERR New Filler Head of Burst End of Burst Line Config Line Reset Error E. Table 128 Input Symbol HGF EDCBA T-MPI Control Symbols RD = +1 Name Function abcdei fghj RD = -1 abcdei fghj K.ind primitive (or a rising edge of RX_Burst). Copyright © 2007-2011 MIPI Alliance. while having the protocol running eventually at a lower speed.28. This has several advantages: 3489 • Implementation is simplified.1.

3502 The format of the PwrMode data symbol is given in Table 129 Table 129 Bit 7 6 Power Mode Symbol Encoding 5 4 3 2 1 0 PwrMode MODE SERIE GEAR Terminatio Reserved n Hibernate _control 3503 Table 130 gives the bit field description for the PwrMode data symbol. 3498 The insertion of the ERR control symbols is controlled by the ERROR Control test feature. When an ERR control symbol is received the M-LANE-SYMBOL.4.4 Line Config Control Symbol 3494 The LCFG control symbol is used for OMC emulation support.2.2 T-MPI Data Symbols 3499 T-MPI shall support all data symbols supported by the M-PHY. T-MPI TX shall initiate a LCFG control symbol transmission when a BURST from the PA Layer is completed and if the corresponding TX_LCC_Enable Attribute is set to YES and if any of bits of TX_LCC_Sequencer are set. 3496 The T-MPI TX shall initiate a LRST control symbol transmission when a BURST from the PA Layer is completed upon a reception of an M-CTRL-LINERESET.6 Error Control Symbol 3497 The ERR control symbol is used to deliberately replace a valid transmitted PHY-symbol from the PA Layer by an invalid PHY-symbol to support checking of PHY symbol errors.5 Line Reset Control Symbol 3495 The LRST control symbol is used to signal a LINE-RESET over the T-MPI Link. The PwrMode data symbol gives the power mode setting of the transmitter side.Version 1. 3500 Some data symbols have specific meaning when they are following specific Control Symbols. E. The ERR symbol may be placed anywhere between HoB control symbol followed by PwrMode data symbol and EoB control symbol. In case of borrowed M-PHY the symbol following the HoB has no particular meaning. All rights reserved. E. Inc. MIPI Alliance Member Confidential 358 . Table 130 Name Encoding PwrMode Bit Field Descriptions Description Values TX Power mode setting MODE LS_MODE HS_MODE 1 0 Shall be set to LS_MODE when TX_MODE=LS_MODE Shall be set to HS_MODE when TX_MODE=HS_MODE Copyright © 2007-2011 MIPI Alliance.1 Power Mode Data Symbol 3501 The PwrMode data symbol is a data symbol that is immediately following HoB in case of protocol testing only.4.40.4. A LCFG control symbol shall be followed by an LCC-Cmd data symbol and 4 payload data symbols.1.00 31-Jan-2011 MIPI Alliance Specification for UniPro E.4.1. E.req primitive (assertion of the TX_LineReset signal).1.4.ind with Res_Error shall be generated (assertion of the RX_SymbolErr). E.

SERIE SERIE_A SERIE_B 1 0 Shall be set to SERIE_A when TX_HSRATE_Series = A Shall be set to SERIE_B when TX_HSRATE_Series = B TX PWM GEAR when in LS_MODE.4. Inc. Implementation may extend the definition of LCC-Cmd data symbol. TX HS GEAR when in HS_MODE. All rights reserved. Reserved G1 0 1 Shall not be set to this value Shall be set when TX_MODE=HS_MODE and TX_HSGEAR=HS_G1 or when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G1 Shall be set when TX_MODE=HS_MODE and TX_HSGEAR=HS_G2 or when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G2 Shall be set when TX_MODE=HS_MODE and TX_HSGEAR=HS_G3 or when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G3 Shall be set when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G4 Shall be set when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G5 Shall be set when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G6 Shall be set when TX_MODE=LS_MODE and TX_PWMGEAR=PWM_G7 TX Termination settings Termination DISABLED ENABLED Hibernate_Contr ol Reserved EXIT ENTER 0 1 0 1 1 Fixed to 1 G2 2 GEAR G3 3 G4 G5 G6 G7 4 5 6 7 E.2 LCC Command Data Symbol 3504 The LCC Command Data symbol (LCC-Cmd) is the first data symbol that is following an LCFG control symbol. Valid only in HS_MODE.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 130 Name Encoding PwrMode Bit Field Descriptions (continued) Values Description TX HS mode Series. Table 131 LCC Command LCC-Cmd Data Symbol Encoding LCC-Cmd Data Symbol Encoding Value LCC-READ-CAPABILITY LCC-WRITE-ATTRIBUTE LCC-READ-MFG-INFO 0x02 0x16 0x1A Copyright © 2007-2011 MIPI Alliance. Table 131 gives the encoding of the LCC-Cmd data symbol.40.Version 1. MIPI Alliance Member Confidential 359 .2.

All rights reserved.3 Bit Ordering and Binary Value 3506 The notation of binary data values is MSB to LSB when reading from left to right. Those data symbols are always followed by four payload data symbols.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 131 LCC-Cmd Data Symbol Encoding (continued) LCC-Cmd Data Symbol Encoding Value LCC Command LCC-READ-VEND-INFO 0x06 3505 The LCC-Cmd given in Table 131 shall be supported for protocol testing use-case. Data bytes are therefore indicated by “HGFEDCBA” where “H” is the MSB and “A” the LSB. Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 360 . E.40. DATA Byte H G F E D C B A 8B/10B j h g f i e d c b a Transmitted Last Figure 136 Bit Ordering Transmitted First E. This notation is used for payload data bytes as well as for configuration parameter values. Inc.4.5 SERDES State Machines 3508 State machines for the SERDES-TX (S-TX) and SERDES-RX (S-RX) are shown in Figure 137 and Figure 138 respectively and explained in the sections that follow.Version 1. 3507 Transmission order is illustrated in Figure 136.

Copyright © 2007-2011 MIPI Alliance.req LINE-RESET M-LANE-PREPARE.Version 1.40.req BURST State State with Sub-FSM Implementation dependent state Figure 137 State Diagram for S-TX RESET OMC LCFG IDLE LRST LINE-RESET EoB HoB BURST State State with Sub-FSM Implementation dependent state Figure 138 State Diagram for S-RX E. MIPI Alliance Member Confidential 361 . All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro RESET OMC TX_LCC_Sequencer != 0 IDLE M-CTRL-LINE-RESET. Inc.5.1 FSM State Descriptions 3509 This section specifies the purpose and operation for each of the FSM states.

All rights reserved.1. During the IDLE state the S-TX shall transmit NFLR control symbols. 3518 The S-RX shall exit the IDLE state and transit to the OMC state upon reception of an LCFG control symbol.2 IDLE State 3511 The IDLE state is reached when the S-TX is operating at a fixed transmission rate and is in burst mode.5.req primitive. E. 3512 The S-TX shall exit the IDLE state and transit to the BURST state upon reception of an M-LANEPREPARE.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro E. RX_Enter_HIBERN8 shall be set to NO when HoB control symbol is received. 3514 The S-TX shall exit the IDLE state and transit to the OMC state when the corresponding TX_LCC_Sequencer Attribute has any of its bit set to ‘1’. Copyright © 2007-2011 MIPI Alliance.1.5.req primitive.5. Inc. 3516 The S-RX shall exit the IDLE state and transit to the BURST state upon reception of symbol HoB control symbol. 3515 The S-RX leaves the RESET state and transit to the IDLE state once it could synchronize its receiver and detects NFLR control symbols. The status of the T-MPI interface on the lines is undefined during the RESET state. MIPI Alliance Member Confidential 362 . The IDLE state is equivalent to any of the SAVE states in the M-PHY specification. The control to enter and exit the RESET state is implementation dependent. The S-RX shall stay is the IDLE state as long NFLR control symbols are detected.1 RESET State 3510 The RESET state is the initial state after applying reset or power-on reset to the T-MPI interface. 3517 The S-RX shall exit the IDLE state and transit to the LINE-RESET state upon reception of an LRST control symbol.3 BURST State 3519 The BURST state is used to transfer data as requested by the M-TX-DATA and M-RX-DATA SAPs. 3513 The S-TX shall exit the IDLE state and transit to the LINE-RESET state upon reception of an M-CTRLLINE-RESET.Version 1. The BURST state contains a sub-FSM which specifies the sequence of events during a BURST and is depicted in Figure 139. E.1.

Received symbol errors are one of the following: 3526 • 3527 • 3528 • 3b4b sub-block coding error 5b6b sub-block coding error Reserved symbol error Copyright © 2007-2011 MIPI Alliance. 3524 The S-RX shall generate an M-LANE-PREPARE. 3521 The S-TX shall transmit a HoB control symbol upon reception of an M-LANE-PREPARE.ind primitive upon reception of HoB control symbol. If within a BURST the PA Layer has no M-PHY symbol to transmit. Each T-MPI BURST sequence corresponds to a single MPHY BURST.00 31-Jan-2011 MIPI Alliance Specification for UniPro DATA IDLE HoB PwrMode NFLR EoB IDLE ERR BURST State M-PHY Payload symbols to/from PA Figure 139 BURST Sub-FSM 3520 The BURST state is entered from the IDLE state.ind primitive upon reception of each symbol received between the PwrMode data symbol and the EoB control symbol. 3525 The S-RX shall generate an M-LANE-SYMBOL. Each M-PHY payload symbols may contain data or control symbols as defined by the M-PHY specification.req primitive. The S-RX shall report any detected symbol errors using the M-LANE-SYMBOL.req primitive. the HoB control symbol shall be followed by either symbols coming from the protocol or by NFLR control symbols. 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. The PwrMode data symbol is followed by a sequence of M-PHY payload symbols. 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. the S-TX shall insert an NFLR control symbol. 3522 The S-TX shall transmit a data or a control symbol for each occurrence of the M-LANE-SYMBOL. Inc. In the case of protocol testing the HoB control symbol shall be followed by a PwrMode data symbol.40. The EoB control symbol is used to detect end of BURST sequence. 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. The S-RX shall not generate M-LANESYMBOL.ind primitive when receiving an NFLR control symbol. For the external M-PHY use case. In case of protocol testing the HoB control symbol is followed by the PwrMode data symbol. MIPI Alliance Member Confidential 363 . A BURST sequence shall start with the HoB control symbol. All rights reserved.ind primitive with the RX_SymbolError signal set.Version 1.

40. In the LINE-RESET state the S-TX shall transmit the LRST control symbol. the M-TX Attributes are reset to their default values and the S-TX returns to the IDLE state. E.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3529 • 3530 • Running Disparity error ERR control symbol is received 3531 The S-RX shall generate an M-LANE-BurstEnd. 3533 The S-TX shall enter the LINE-RESET state upon reception of an M-CTRL-LINERESET. DATA3 DATA2 IDLE LCFG LCC-Cmd DATA1 IDLE DATA0 OMC State LCC payload data Figure 140 OMC Sub-FSM Copyright © 2007-2011 MIPI Alliance.ind primitive upon reception of the EoB control symbol and return to the IDLE state.req primitive. Inc. In the LINE-RESET state the OMC Write-only Attributes shall not be reset. All rights reserved. The S-RX shall return to the IDLE state after the PA Layer has accepted the M-CTRLLINERESET. MIPI Alliance Member Confidential 364 .Version 1. 3534 The S-RX shall enter the LINE-RESET state upon reception of a LRST control symbol. Once the LRST control symbol is transmitted. The OMC state contains a sub-FSM which specifies the sequence of events during OMC emulation operations.ind primitive.4 LINE-RESET State 3532 The LINE-RESET state is used for signaling a LINE-RESET over the T-MPI interface similarly to the LINERESET signaling used on the M-PHY interface. The S-RX shall issue an M-CTRL-LINERESET. E. The OMC Sub-FSM is depicted in Figure 140.ind primitive in the LINE-RESET state and shall reset the M-RX Attributes to their default values. OMC operations such as.5 OMC State 3535 The OMC State is used for OMC emulation support.1.1.5. LCC-WRITE and LCC-READS operations are initiated when any bit of TX_LCC_Sequencer is set.5.

DATA2. then LCC-Cmd shall be LCC-READ-MFG-INFO If LCC-READ-VEND-INFO is set. then LCC-Cmd shall be LCC-READ-CAPABILITY. Table 132 and Table 133 specify how to set the DATA3. 3548 The LCC payload data symbols to be sent by the S-TX are depending on the LCC-Cmd.req primitive set and when TX_LCC_Enable is set to TRUE and when any bit of TX_LCC_Sequencer is set. then LCC-Cmd shall be LCC-WRITE-ATTRIBUTE If LCC-READ-MFG-INFO is set.40. 3537 Once the S-TX has entered the OMC state it shall execute the following sequence: 3538 3539 3540 3541 3542 • • • • • Transmit a LCFG control symbol Transmit an LCC-Cmd data symbol Transmit an LCC payload of four data symbols (DATA3. DATA2. Inc. Table 132 LCC-Cmd LCC Payload for LCC-WRITE-ATTRIBUTE in S-TX DATA3 DATA2 DATA1 DATA0 Bit0: TX_Amplitude bit 0 Bit1: MC_Output_Amplitude Bit2: MC_HS_Unterminated_Enable Bit3: MC_LS_Terminated_Enable LCC-WRITE-ATTRIBUTE Bit4: MC_HS_Unterminated_LINE_Drive_E nable Bit5: MC_LS_Terminated_LINE_Drive_Ena ble Bit6: 0b1 Bit7: 0b1 0xFF 0xFF 0xFF Copyright © 2007-2011 MIPI Alliance.Version 1. DATA1 and DATA0 LCC payload data depending on the current active LCC-Cmd.req primitive set and when there is no M-CTRL-LINERESET. then LCC-Cmd shall be LCC-READ-VEND-INFO If LCC-READ-CAPABILITY is set. All rights reserved. DATA1 and DATA0) Clear the corresponding set bit in TX_LCC_Sequencer 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 3545 3546 3547 • • • • If LCC-WRITE-ATTRIBUTE is set. MIPI Alliance Member Confidential 365 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 3536 The S-TX shall transit from the IDLE state to the OMC state when there is no M-LANE-PREAPRE.

DATA1 and DATA0) Store the received LCC payload into the appropriate OMC Status Attribute or to Lx_OMC_WO. MIPI Alliance Member Confidential 366 . Table 134 specifies the assignment of LCC Payload data to the T-MPI Attributes. DATA2. DATA1 and DATA0 values may be ignored.ind primitive after receiving LCC-READ-MFG-INFO.Version 1.40. For example. the DATA3 payload shall be stored in Lx_OMC_WO and DATA2. Copyright © 2007-2011 MIPI Alliance. 3550 The S-RX shall transit from the IDLE state to the OMC state on detection of a LCFG control symbol. LCC-READVEND-INFO and LCC-READ-CAPABILITY Return to the IDLE state 3555 • 3556 • 3557 On a LCC-WRITE-ATTRIBUTE command. depending on the LCC-Cmd Generate an LCCReadStatus. Once the S-RX has entered the OMC state it shall execute the following sequence: 3551 3552 3553 3554 • • • • Reception of the LCFG control symbol Reception of the LCC-Cmd data symbol Reception of the LCC payload consisting of four data bytes (DATA3. Table 134 LCC Payload for LCC-WRITE-ATTRIBUTE in S-RX DATA3 DATA2 DATA1 DATA0 LCC-Cmd LCC-WRITE-ATTRIBUTE Lx_OMC_WO - - - 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.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 133 LCC-Cmd DATA3 LCC Payload for LCC-READ-X in S-TX DATA2 DATA1 DATA0 LCC-READ-MFGINFO LCC-READ-VENDINFO LCC-READCAPABILITY Lx_OMC_READ_D ATA3 Lx_OMC_READ_D ATA2 Lx_OMC_READ_D ATA1 Lx_OMC_READ_D ATA0 3549 Note that “x” in Table 133 relates to the Lane number. Table 135 LCC-Cmd LCC Payload for LCC-READ-MFG-INFO and READ-VEND-INFO in S-RX DATA3 DATA2 DATA1 DATA0 LCC-READ-MFGINFO MC_PHY_MajorMin MC_PHY_Editorial_ MC_MFG_ID_Part1 MC_MFG_ID_Part2 or_Release_Capabi Release_Capability lity LCC-READ-VEND. L1_OMC_READ_DATA3 is the OMC_READ_DATA3 Attribute for Logical Lane 1. All rights reserved. Inc.MC_Ext_Vendor_In MC_Ext_Vendor_In MC_Ext_Vendor_In MC_Ext_Vendor_In INFO fo_Part1 fo_Part2 fo_Part3 fo_Part4 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.

All rights reserved.Version 1.40. MIPI Alliance Member Confidential 367 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 136 Payload DATA Bit LCC Payload assignment for LCC-READ-CAPABILITY in S-RX Attribute 0 1 2 DATA3 3 4 5 6 7 0 1 2 DATA2 3 4 5 6 7 0 1 2 DATA1 3 4 5 6 7 0 1 2 DATA0 3 4 5 6 7 MC_HSMODE_Capability MC_HSGEAR_Capability – bit 0 (LSB) MC_HSGEAR_Capability – bit 1 MC_HS_START_TIME_Var_Capability – bit 0 (LSB) MC_HS_START_TIME_Var_Capability – bit 1 MC_HS_START_TIME_Var_Capability – bit 2 MC_HS_START_TIME_Var_Capability – bit 3 MC_HS_START_TIME_Range_Capability MC_RX_SA_Capability MC_RX_LA_Capability MC_LS_PREPARE_LENGTH – bit 0 (LSB) MC_LS_PREPARE_LENGTH – bit 1 MC_LS_PREPARE_LENGTH – bit 2 MC_LS_PREPARE_LENGTH – bit 3 MC_PWMG0_Capability MC_PWM_GEAR_Capability – bit 0 (LSB) MC_PWM_GEAR_Capability – bit 1 MC_PWM_GEAR_Capability – bit 2 MC_HS_Unterminated_Capability MC_LS_Terminated_Capability MC_HS_Unterminated_LINE_Drive_Capabality MC_LS_Terminated_LINE_Drive_Capability OMC_TYPE_Capability - Copyright © 2007-2011 MIPI Alliance. Inc.

The T-MPI does not check the MK2 symbol to detecting end of burst.cnf_L primitive.6 Timing Diagrams 3560 This section gives examples of timing diagram for a T-MPI TX burst and RX burst. 3566 At T4 the S-TX starts to transmit exactly the same symbol sequence as would the M-PHY transmit in a BURST. T1 M-PHY TXDP/TXDN TX_SymbolClk TX_ProtDORDY[1:0] TX_DataNCtrl[1:0] TX_Symbol[15:8] TX_Symbol[7:0] TX_PhyDIRDY TX_Burst T-MPI TXDP/TXDN NFLR HoB PwrM MK0 MK1 B3 7F A5 5A A9 82 MK2 FLR EoB NFLR NFLR T2 PREPARE T3 SYNC T4 Data MK0 MK1 B3 7F A5 T5 5A A9 T6 82 MK2 FLR T7 EoB 11 00 02 01 7F B3 11 5A A5 82 A9 00 80 04 00 00 00 00 Figure 141 TX-Burst Timing Diagram Example 3562 In this example. All rights reserved. The T-MPI just passes the symbols provided by the PA Layer without interpreting them. Then at T6 the PA Layer de-asserts the TX_Burst signal to indicate end of burst. which indicates that the S-TX is in the IDLE state. Copyright © 2007-2011 MIPI Alliance. 3564 At T2 an M-PHY would transit to the PREPARE state. Inc. The assertion of TX_PhyDIRDY corresponds to the M-LANE-SYMBOL. At T3 the S-TX transit into the BURST state and start to transmit the HoB control symbol followed by the PwrMode data symbol.6.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. 3568 At T7 the TX_Burst signal is sampled as inactive. 3567 At T5 the PA Layer requests the transmission of a MK2 symbol followed by a FLR symbol to indicate end of burst.Version 1. The EoB control symbol is followed by an NFLR control symbol. 3563 At T1 the PA Layer asserts the TX_Burst signal to indicate beginning of a TX burst. 3565 At T3 an M-PHY would transit to the SYNC state. At the same time the TX_PhyDIRDY signal is asserted to indicate that the S-TX has accepted the MK0. the PA Layer interface to the M-PHY is two M-PHY symbols wide. MK1 control symbols.00 31-Jan-2011 MIPI Alliance Specification for UniPro E. therefore the T-MPI issue an EoB control symbol to terminate the S-TX BURST state. Therefore on each TX_SymbolClk two M-PHY symbols are transmitted. These timing diagrams are based on signals defined in Annex A of [MIPI05].1 T-MPI TX Burst Diagram 3561 An example of a T-MPI TX burst timing diagram is given in Figure 141. E. but is rather checking the status of the TX_Burst signal. This corresponds to the M-LANE-PREAPRE.40. MIPI Alliance Member Confidential 368 .

Version 1. E.7 SERDES Configuration 3576 The SERDES transceivers configuration is implementation dependent therefore this annex gives only recommendations which are related to transceivers available in two commonly used FPGA families: Xilinx and Altera.00 31-Jan-2011 MIPI Alliance Specification for UniPro E. 3572 At T2 the S-RX has detected the reception of the HoB control symbol followed by a PwrMode data symbol.2 T-MPI RX Burst Diagram 3569 An example of a T-MPI RX Burst diagram is given in Figure 142. therefore the corresponding RX_SymbolErr is set.7. FLR A9 82 T5 E4 MK2 T6 T7 NFLR HoB PwrM EoB NFLR 00 00 00 00 00 11 11 02 01 00 11 00 7F B3 00 11 10 80 C4 00 11 00 82 A9 10 11 10 04 E4 00 00 00 00 00 00 Figure 142 RX Burst Timing Diagram Example 3570 Also in this example the interface between the PA Layer and the PHY is two PHY symbols wide. 3571 At T1 the S-RX FSM is still in the IDLE state receiving NFLR control symbols.E.1 Transceivers 3577 Recommended transceivers from Xilinx are GTX transceivers. The detection of the HoB control symbol causes the transition to the BURST state and the T-MPI asserts the RX_Burst signal. = Disparity Error NFLR T2 T3 Data MK0 MK1 B3 7F C4 T4 D. 3574 At T5 the S-RX detects a running disparity error for symbol 0x82. 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. The assertion of the RX_Burst signal corresponds to the M-LANE-PREPARE.E. MIPI Alliance Member Confidential 369 . All rights reserved. Therefore at each RX_SymbolClk two PHY symbols are received. 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. T1 T-MPI RXDP/RXDN RX_SymbolClk RX_PhyDORDY[1:0] RX_DataNCtrl[1:0] RX_Symbol[15:8] RX_Symbol[7:0] RX_SymbolErr[1:0] RX_Burst D. Inc. Copyright © 2007-2011 MIPI Alliance. E.40.6. Those transceivers are also called CML transceivers.ind primitive.ind primitive.

The bit rate should be fixed at 1. Those transceivers are also called PCML transceivers. Copyright © 2007-2011 MIPI Alliance. Transmitter Single ended output termination 50 ohm + 50 ohm ~100 nF 7 pF 50 ohm Board ~100 nF Bypass internal AC-coupling Receiver 7 pF 50 ohm + - Differential input termination Figure 143 Transceivers Configuration E. E.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3578 Recommended transceivers from Altera are GX transceivers. The fixed frequency rate should be defined the M-PHY supplier and should be fixed according to the highest supported gear of the M-PHY. 3580 Altera GX transceivers have also a programmable driver swing between 400 and 1200 mVPPD.4 Symbol Encoding 3588 The transceivers shall enable 8b/10b encoding and enable running disparity encoding.7. 3590 For External M-PHY use case the transceivers should run at a fixed bit rate. 3586 The NFLR control symbol should be used for synchronizing the receiver and used for comma alignment. 3584 The receiver should have a 100 Ω differential input termination as depicted in Figure 143. 3587 The receiver should enable use of an elastic buffer to synchronize receiver clock domain to the FPGA core interface clock domain.25 Gbps.40.5 Transceivers Frequency 3589 For protocol test case the transceivers shall run at a fix bit rate. For example.2 Driver Configuration 3579 Xilinx's GTX transceivers have a programmable driver swing between 500 and 1070mVPPD.7. 3582 The driver output should be terminated with 50 Ω output resistance as depicted in Figure 143. Inc. 3581 Recommended T-MPI transceiver swing should be in the range of 500 and 900 mVPPD.125 Gbps. then a possible fixed rate for the transceivers can be set to 3.Version 1.7. MIPI Alliance Member Confidential 370 . E.3 Receiver Configuration 3583 The receiver should have its voltage termination set to floating as depicted in Figure 143. if an M-PHY supports HG-G2 series B as a maximum gear.7. All rights reserved. E. 3585 Internal AC coupling of the receiver should be bypassed as depicted in Figure 143.

cnf_L • No corresponding signal. There are four kinds of M-PHY Attributes to be considered by the Dummy M-PHY: Capability Attributes. Status Attributes and OMC Write-only Attributes.1 Access to M-PHY Attributes 3592 In order to verify some of the M-PHY CTRL SAP primitives. A T-MPI implementation may have additional testing features. In order to check correct access to the M-PHY Capability Attributes. some critical Attributes are controlled commonly. E. E.req • • Activation of configuration Attributes and transfer from the shadow register bank to the effective register bank. so that the Attributes are assigned the same values over all lanes. 3593 Each lane has its own independent set of Attributes. It is mapped to the RX_AttrID signal when accessing M-RX and to the TX_AttrID signal when accessing the M-TX.cnf_L( MIBvalue ) Returns the value of the requested read Attribute on the RX_AttrRdVal bus or on the TX_AttrRdVal bus depending on access to M-RX or M-TX. MIPI Alliance Member Confidential 371 .1.req( MIBattribute. RX_AttrWRn=0b1.1 Used Primitives 3595 Access and control of the M-PHY Attribute is provided by the following primitives: 3596 • 3597 3598 3599 3600 3601 • 3602 3603 • 3604 3605 3606 3607 • 3608 3609 • 3610 3611 3612 • 3613 M-CTRL-CFGGET. TX_AttrID=MIBattribute M-CTRL-CFGSET. TX_AttrWRn=0b0. TX_AttrID=MIBattribute M-CTRL-CFGGET. Description for each Attribute is given in [MIPI05].8. TX_AttrWrVal=MIBvalue. Corresponds to the RX_CfgUpdt and TX_CfgUpdat according to access to M-RX or M-TX respectively. 3594 This section describes only the M-PHY Attributes that are supported by the Dummy M-PHY MODULEs.8 Testing Features 3591 This section describes the testing features of the T-MPI interface. MIBvalue ) • • • • Request to set an Attribute (MIBattribute) to a specific value (MIBvalue) Access to M-RX: RX_CfgEnbl=0b1. Being able to Copyright © 2007-2011 MIPI Alliance. the T-MPI defines control Attributes that can be set by the protocol. RX_AttrWrVal=MIBvalue. TX_AttrWRn=0b1.8. RX_AttrWRn=0b0. However.cnf_L • No corresponding signal. Configuration Attributes. Those T-MPI Attributes are used to configure the values of the M-PHY Capability Attributes. RX_AttrID=MIBattribute Access to M-TX: TX_CfgEnbl=0b1.00 31-Jan-2011 MIPI Alliance Specification for UniPro E.Version 1. All rights reserved. Inc. Capability Attributes E.8.1. M-CTRL-CFGSET. M-CTRL-CFGREADY. Access to M-RX: RX_CfgEnbl=0b1.40. access to the M-PHY Attributes is necessary.req( MIBattribute ) • • • Request to read the Attribute value. M-CTRL-CFGREADY. RX_AttrID=MIBattribute • Access to M-TX: TX_CfgEnbl=0b1. MIBattribute is the Attribute ID given in the following tables.2 3614 Capability Attributes are read-only Attributes for both the M-TX and M-RX.

N: support for this Attribute is optional. N: Does not require a shadow register Table 137 Attribute ID Attribute Name 3621 • 3622 • M-TX Capability Attributes Default Value Mandato ry Control Shadow Required Access 0x0001 0x0002 0x0003 0x0004 0x0005 0x0006 0x0007 0x0008 0x0009 0x000A 0x000B 0x000C TX_HSMODE_Capability TX_HSGEAR_Capability TX_PWMG0_Capability TX_PWMGEAR_Capability TX_Amplitude_Capability TX_ExternalSYNC_Capabil ity TX_HS_Unterminated_LIN E_Drive_Capability TX_LS_Terminated_LINE_ Drive_Capability TX_Min_SLEEP_NoConfig _Time_Capability TX_Min_STALL_NoConfig_ Time_Capability TX_Min_SAVE_Config_Tim e_Capability TX_REF_CLOCK_SHARE D_Capability R R R R R R R R R R R R 0x01 0x03 0x00 0x07 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y Y N Y N N Y Y N N N N TX_Capability TX_Capability TX_OptCapability1 TX_Capability TX_OptCapability1 TX_OptCapability1 TX_Capability TX_Capability TX_OptCapability2 TX_OptCapability2 TX_OptCapability3 TX_OptCapability1 N N N N N N N N N N N N 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.Version 1. W: Write Only. All rights reserved. Default Value: value of the Attribute at reset. RW: Read/Write. Shadow Required: Y: Requires a shadow register. Mandatory: Y: This Attribute shall be implemented in the Dummy M-PHY MODULE. Table 138 Attribute ID Attribute Name M-RX Capability Attributes Default Value Mandato ry Control Shadow Required Access 0x0081 RX_HSMODE_Capability R 0x01 Y RX_Capability N Copyright © 2007-2011 MIPI Alliance. MIPI Alliance Member Confidential 372 .00 31-Jan-2011 MIPI Alliance Specification for UniPro configure the Capability Attributes of the M-PHY is essential for testing downgrading features of the PA Layer. Inc. Attribute Name: Symbolic Attribute name (as defined in [MIPI05]). 3615 Table 137 gives the list of the M-TX Capability Attributes and defines for each Attribute: 3616 3617 3618 3619 3620 • • • • • Attribute ID: Attribute Address used in Get and Set commands. Control: Specifies the T-MPI Attribute that is used to control this M-PHY Attribute. R: Read Only.40. Access: access method to the Attribute.

3 Configuration Attributes 3625 Configuration Attributes are Read/Write Attributes of the M-RX and M-TX.8.1.req(MIBattribute. 3628 When the M-CTRL-CFGREADY. E. Inc.req is issued. Copyright © 2007-2011 MIPI Alliance.req(MIBvalue) primitive is issued. MIPI Alliance Member Confidential 373 . All rights reserved. 3627 When the M-CTRL-CFGSET. 3626 When the M-CTRL-CFGSET. the Dummy M-PHY shall update all effective registers with their corresponding shadow registers values.req is issued to a Configuration Attribute that requires a shadow register. the Configuration Attribute value with the MIBvalue=Attribute ID from the effective register bank shall be returned by the Dummy M-PHY using the M-CTRL-CFGGET.cnf_L primitive.Version 1.cnf_L(MIBvalue) primitive. 3629 When the M-CTRL-CFGGET. Some configuration Attributes (critical configuration Attributes) require shadow registers for writing the Attributes.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 138 Attribute ID Attribute Name M-RX Capability Attributes (continued) Access Default Value Mandato ry Control Shadow Required 0x0082 0x0083 0x0084 0x0085 0x0086 0x0087 0x0088 0x0089 0x008A 0x008B 0x008C 0x008D RX_HSGEAR_Capability RX_PWMG0_Capability RX_PWMGEAR_Capability RX_HS_Unterminated_Cap ability RX_LS_Terminated_Capab ility RX_Min_SLEEP_NoConfig _Time_Capability RX_Min_STALL_NoConfig _Time_Capability RX_Min_SAVE_Config_Tim e_Capability RX_REF_CLOCK_SHARE D_Capability RX_HS_SYNC_LENGTH_ Capability RX_HS_PREPARE_LENG TH_Capability RX_LS_PREPARE_LENGT H_Capability R R R R R R R R R R R R 0x03 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y N Y Y Y N N N N N N N RX_Capability RX_OptCapability1 RX_Capability RX_Capability RX_Capability RX_OptCapability2 RX_OptCapability2 RX_OptCapability3 RX_OptCapability1 RX_OptCapability4 RX_OptCapability5 RX_OptCapability5 N N N N N N N N N N N N 3624 When the M-CTRL-CFGGET.req(MIBvalue) primitive is issued. MIBvalue).req(MIBattribute.40. the Capability Attribute value with the MIBvalue=Attribute ID shall be returned by the Dummy M-PHY MODULE using the M-CTRLCFGGET. the Dummy M-PHY MODULE shall set the effective register with MIBattribute=AttributeID to the value specified by MIBvalue. the Dummy M-PHY shall set the shadow register with MIBattribute=AttributeID to the value specified by MIBvalue. MIBvalue).req is issued to a Configuration Attribute that does not require a shadow register.

it specifies for each Attribute if it shall support a shadow register. Furthermore. All rights reserved. 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.40. The Control column gives indication about which feature of the M-PHY is used to control the Attribute or is controlled by the Attribute. Table 139 Attribute ID Attribute Name M-TX Configuration Attributes Access Default Value Mandatory Control Shadow Required 0x0021 0x0022 0x0023 0x0024 0x0025 0x0026 0x0027 0x0028 0x0029 0x002A 0x002B 0x002C 0x002D 0x002E 0x002F 0x0030 0x0031 0x0032 TX_MODE TX_HSRATE_Series TX_HSGEAR TX_PWMGEAR TX_Amplitude TX_HS_SlewRate TX_SYNC_Source TX_HS_SYNC_LENGTH TX_HS_PREPARE_LENG TH TX_LS_PREPARE_LENGT H TX_HIBERN8_Control TX_LCC_Enable TX_PWM_BURST_Closure _Extension TX_BYPASS_8B10B_Enab le TX_DRIVER_POLARITY TX_HS_Unterminated_LIN E_Drive_Enable TX_LS_Terminated_LINE_ Drive_Enable TX_LCC_Sequencer RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW RW 0x01 0x01 0x01 0x01 0x02 0x00 0x00 0x4F 0x0F 0x0F 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Y Y Y Y Y N N N N N Y Y N N N Y Y Y Power Mode Power Mode Power Mode Power Mode OMC_WO Y Y Y Y Y Y Y Y Y Y Power Mode <LCFG> symbol Y N Y Y Y Power Mode Power Mode <LCFG> symbol Y Y N 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. Inc. Copyright © 2007-2011 MIPI Alliance. Furthermore. or is controlled by the Attribute. MIPI Alliance Member Confidential 374 .Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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.

M-RX and OMC Status Attributes Access Default Value Mandatory Control Shadow Required 0x0041 0x00C1 0x00D1 0x00D2 0x00D3 0x00D4 TX_FSM_State RX_FSM_State OMC_TYPE_Capability MC_HSMODE_Capability MC_HSBURST_Capability MC_HS_START_TIME_Var _Capability R R R R R R 0x00 0x00 0x00 0x00 0x00 0x00 Y Y Y Y Y Y FSM Emulation FSM Emulation <LCFG> READ DATA0 <LCFG> READ DATA3 <LCFG> READ DATA3 <LCFG> READ DATA3 N N N N N N Copyright © 2007-2011 MIPI Alliance.8. 3633 Since the Dummy M-PHY has a different FSM than the FSM from the M-PHY. OMC_READ_DATA2 and OMC_READ_DATA3 Attributes.6. 3634 OMC Status Attributes are set during the reception sequence in the OMC state of the S-RX according to Section E.1. Table 141 Attribute ID Attribute Name M-TX.5 and are controlled by the remote S-TX OMC_READ_DATA0. All rights reserved.8. the TX_FSM_State and RX_FSM_State shall reflect the FSM status of the Dummy M-PHY S-TX and S-RX FSMs according to Section E.40.4 Status Attributes 3632 Status Attributes in the M-PHY MODULEs are read-only Attributes that reflect the current status of the MRX.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 140 Attribute ID Attribute Name M-RX Configuration Attributes Access Default Value Mandatory Control Shadow Required 0x00A1 0x00A2 0x00A3 0x00A4 0x00A5 0x00A6 0x00A7 0x00A8 RX_MODE RX_HSRATE_Series RX_HSGEAR RX_PWMGEAR RX_LS_Terminated_Enable RX_HS_Unterminated_Ena ble RX_Enter_HIBERN8 RX_BYPASS_8B10B_Enab le RW RW RW RW RW RW RW RW 0x01 0x01 0x01 0x01 0x00 0x00 0x01 0x00 Y Y Y Y Y Y Y N Power Mode Power Mode Power Mode Power Mode Power Mode Power Mode Power Mode Y Y Y Y Y Y Y Y E. Inc. M-TX FSMs or the status of OMC. M-TX and OMC Status Attributes that shall be supported by the Dummy M-PHY.Version 1. 3635 Table 141 gives the list of the M-RX. OMC_READ_DATA1.8. MIPI Alliance Member Confidential 375 .

M-RX and OMC Status Attributes (continued) Access Default Value Mandatory Control Shadow Required Attribute Name 0x00D5 0x00D6 0x00D7 0x00D8 0x00D9 0x00DA 0x00DB 0x00DC 0x00DD 0x00DE 0x00DF 0x00E0 0x00E1 0x00E2 0x00E3 0x00E4 0x00E5 0x00E6 MC_HS_START_TIME_Ra nge_Capability MC_RX_SA_Capability MC_RX_LA_Capability MC_LS_PREPARE_LENG TH MC_PWMG0_Capability MC_PWMGEAR_Capability MC_LS_Terminated_Capab ility MC_HS_Unterminated_Ca pability MC_LS_Terminated_LINE_ Drive_Capability MC_HS_Unterminated_LIN E_Drive_Capability MC_MFG_ID_Part1 MC_MFG_ID_Part2 MC_PHY_MajorMinor_Rele ase_Capability MC_PHY_Editorial_Releas e_Capability MC_Ext_Vendor_Info_Part 1 MC_Ext_Vendor_Info_Part 2 MC_Ext_Vendor_Info_Part 3 MC_Ext_Vendor_Info_Part 4 R R R R R R R R R R R R R R R R R R 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y <LCFG> READ DATA3 <LCFG> READ DATA2 <LCFG> READ DATA2 <LCFG> READ DATA2 <LCFG> READ DATA1 <LCFG> READ DATA1 <LCFG> READ DATA1 <LCFG> READ DATA1 <LCFG> READ DATA1 <LCFG> READ DATA1 <LCFG> READ DATA3 <LCFG> READ DATA2 <LCFG> READ DATA1 <LCFG> READ DATA0 <LCFG> READ DATA3 <LCFG> READ DATA2 <LCFG> READ DATA1 <LCFG> READ DATA0 N N N N N N N N N N N N N N N N N N E. Copyright © 2007-2011 MIPI Alliance. All rights reserved.Version 1. Inc. Those Attributes are described in detail in Section E. Since those Attributes are write-only in an M-PHY MODULE. MIPI Alliance Member Confidential 376 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 141 Attribute ID M-TX.8.8.1.40.2. the Dummy M-PHY MODULE specifies a set of read-only registers from which it is possible to read the values of those write-only Attributes.5 OMC Write-only Attributes 3636 Support for write-only OMC Attributes in the Dummy M-PHY MODULE is optional.

it is possible to change capability Attributes and apply LINE-RESET for testing non default capability configuration. Inc. T-MPI AttributeID values are in the range of 0x0100 to 0x0FFF.8. 3639 T-MPI Attributes shall be reset after Power-On. L1. The M-PHY uses only AttributeID values from 0x0000 to 0x00FF. The Control column entry specifies the Attribute that is used for reading the write-only OMC Attribute. All rights reserved. 3641 Table 143 gives the T-MPI Attributes list for Lane 0. In that way.Version 1. Table 143 Attribute ID Attribute Name T-MPI Lane0 Attributes Default Value Mandatory Control Access 0x0101 0x0102 0x0103 0x0104 0x0105 L0_TX_Capability L0_TX_OptCapability1 L0_TX_OptCapability2 L0_TX_OptCapability3 L0_OMC_WO W W W W R 0x1F 0x06 0x00 0x00 0x02 Y N N N Y OMC Write-only Attributes M-TX Capability Attributes Copyright © 2007-2011 MIPI Alliance. Table 142 Attribute ID Attribute Name OMC Write Only Attributes Default Value Mandatory Control Shadow Required Access 0x0061 0x0062 0x0063 0x0064 0x0065 MC_Output_Amplitude MC_HS_Unterminated_En able MC_LS_Terminated_Enabl e MC_HS_Unterminated_LIN E_Drive_Enable MC_LS_Terminated_LINE_ Drive_Enable W W W W W 0x01 0x00 0x00 0x00 0x00 N N N N N OMC_WO OMC_WO OMC_WO OMC_WO OMC_WO N N N N N E.2 Access to T-MPI Attributes 3638 T-MPI-specific Attributes are necessary to control and monitor the Dummy M-PHY test features. T-MPI Attributes described in this section do not require shadow registers.2. T-MPI Attributes shall not be reset by LINE-RESET.8. The T-MPI Attributes are using the M-PHY namespace.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3637 Table 142 gives the list of write-only OMC Attributes supported by the Dummy M-PHY MODULE. L2 and L3 to indicate to which T-MPI lane those Attributes are belonging. The M-PHY Attributes uses only Attribute ID values from 0x0000 to 0x00FF. T-MPI Attributes uses the same address space as for the M-PHY Attributes. E.40. MIPI Alliance Member Confidential 377 .1 T-MPI Attributes Overview 3640 Each T-MPI lane has a full set of Attributes that are common and prefixed with L0.

All rights reserved. Copyright © 2007-2011 MIPI Alliance. Read Data pushed out from OMC to the remote M-RX. Read Data pushed out from OMC to the remote M-RX.40.Version 1. MIPI Alliance Member Confidential 378 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 143 Attribute ID Attribute Name T-MPI Lane0 Attributes (continued) Access Default Value Mandatory Control 0x0106 0x0107 0x0108 0x0109 0x010A 0x010B 0x010C 0x010D 0x010E 0x010F L0_RX_Capability L0_RX_OptCapability1 L0_RX_OptCapability2 L0_RX_OptCapability3 L0_RX_OptCapability4 L0_RX_OptCapability5 L0_OMC_READ_DATA0 L0_OMC_READ_DATA1 L0_OMC_READ_DATA2 L0_OMC_READ_DATA3 W W W W W W W W W W 0x1F 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y N N N N N Y Y Y Y OMC Emulation. M-RX Capability Attributes OMC Write-only Attributes M-TX Capability Attributes 3643 Table 145 gives the T-MPI Attributes list for Lane 2. Inc. Table 144 Attribute ID Attribute Name T-MPI Lane1 Attributes Default Value Mandatory Control Access 0x0111 0x0112 0x0113 0x0114 0x0115 0x0116 0x0117 0x0118 0x0119 0x011A 0x011B 0x011C 0x011D 0x011E 0x011F L1_TX_Capability L1_TX_OptCapability1 L1_TX_OptCapability2 L1_TX_OptCapability3 L1_OMC_WO L1_RX_Capability L1_RX_OptCapability1 L1_RX_OptCapability2 L1_RX_OptCapability3 L1_RX_OptCapability4 L1_RX_OptCapability5 L1_OMC_READ_DATA0 L1_OMC_READ_DATA1 L1_OMC_READ_DATA2 L1_OMC_READ_DATA3 W W W W R W W W W W W W W W W 0x1F 0x06 0x00 0x00 0x02 0x1F 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y N N N Y Y N N N N N Y Y Y Y OMC Emulation. M-RX Capability Attributes 3642 Table 144 gives the T-MPI Attributes list for Lane 1.

40. MIPI Alliance Member Confidential 379 . Inc. Read Data pushed out from OMC to the remote M-RX. M-RX Capability Attributes OMC Write-only Attributes M-TX Capability Attributes 3644 Table 146 gives the T-MPI Attributes list for Lane 3. Table 146 Attribute ID Attribute Name T-MPI Lane3 Attributes Default Value Mandatory Control Access 0x0131 0x0132 0x0133 0x0134 0x0135 0x0136 0x0137 0x0138 0x0139 0x013A 0x013B L3_TX_Capability L3_TX_OptCapability1 L3_TX_OptCapability2 L3_TX_OptCapability3 L3_OMC_WO L3_RX_Capability L3_RX_OptCapability1 L3_RX_OptCapability2 L3_RX_OptCapability3 L3_RX_OptCapability4 L3_RX_OptCapability5 W W W W R W W W W W W 0x1F 0x06 0x00 0x00 0x02 0x1F 0x00 0x00 0x00 0x00 0x00 Y N N N Y Y N N N N N M-RX Capability Attributes OMC Write-only Attributes M-TX Capability Attributes Copyright © 2007-2011 MIPI Alliance.Version 1. All rights reserved.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 145 Attribute ID Attribute Name T-MPI Lane2 Attributes Default Value Mandatory Control Access 0x0121 0x0122 0x0123 0x0124 0x0125 0x0126 0x0127 0x0128 0x0129 0x012A 0x012B 0x012C 0x012D 0x012E 0x012F L2_TX_Capability L2_TX_OptCapability1 L2_TX_OptCapability2 L2_TX_OptCapability3 L2_OMC_WO L2_RX_Capability L2_RX_OptCapability1 L2_RX_OptCapability2 L2_RX_OptCapability3 L2_RX_OptCapability4 L2_RX_OptCapability5 L2_OMC_READ_DATA0 L2_OMC_READ_DATA1 L2_OMC_READ_DATA2 L2_OMC_READ_DATA3 W W W W R W W W W W W W W W W 0x1F 0x06 0x00 0x00 0x02 0x1F 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Y N N N Y Y N N N N N Y Y Y Y OMC Emulation.

MIPI Alliance Member Confidential 380 .00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 146 Attribute ID Attribute Name T-MPI Lane3 Attributes (continued) Access Default Value Mandatory Control 0x013C 0x013D 0x013E 0x013F L3_OMC_READ_DATA0 L3_OMC_READ_DATA1 L3_OMC_READ_DATA2 L3_OMC_READ_DATA3 W W W W 0x00 0x00 0x00 0x00 Y Y Y Y OMC Emulation. All rights reserved.40. In case of protocol testing those Attributes are not mandatory. 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. Copyright © 2007-2011 MIPI Alliance. Inc. Table 147 Attribute ID Attribute Name T-MPI Serial Interface Control Attributes Access Default Value Mandatory Control 0x0160 Selector RW 0x10 Y* Serial Interface Table 148 Attribute ID T-MPI Physical Lanes Renumbering Attributes Access Default Value Mandatory Control Attribute Name 0x0170 0x0171 0x0172 0x0173 0x0174 0x0175 0x0176 0x0177 MAP_RX_LANE0 MAP_RX_LANE1 MAP_RX_LANE2 MAP_RX_LANE3 MAP_TX_LANE0 MAP_TX_LANE1 MAP_TX_LANE2 MAP_TX_LANE3 RW RW RW RW RW RW RW RW 0x04 0x05 0x06 0x07 0x04 0x05 0x06 0x07 Y Y Y Y Y Y Y Y Physical Lanes renumbering 3646 Table 149 gives the list of the T-MPI Power Mode Error Control and Status Attributes.Version 1. Read Data pushed out from OMC to the remote M-RX.

2 M-TX Capability Control Attributes 3647 This section gives detailed description for the handling of M-TX Capability Attributes per Lane.8. All rights reserved. M-TX Attributes are read-only Attributes. The prefix used to indicate Lane number is omitted in this description.2. 3648 Table 150 gives the detailed description or TX_Capability .Version 1. Inc.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 149 Attribute ID T-MPI Power Mode Error Control and Status Attributes Access Default Value Mandatory Control Attribute Name 0x0180 0x0181 0x0182 0x0183 0x0184 0x0185 PWRMODE_MODE_ERR PWRMODE_SERIE_ERR PWRMODE_GEAR_ERR PWRMODE_HIBERNATE_ ERR PWRMODE_TERMINATIO N_ERR PWRMODE_CTRL R R R R R W 0x00 0x00 0x00 0x00 0x00 0x00 Y Y Y Y Y Y Power Mode Test Feature E. The TX_OptCapability1. Copyright © 2007-2011 MIPI Alliance. TX_OptCapability2 and TX_OptCapability3 are used to set values of the optional capability Attributes of the Dummy M-PHY MODULEs.40. the T-MPI uses TX_Capability to set values of the mandatory capability Attributes required by the Dummy M-PHY MODULEs. Table 150 Name TX_Capability Attribute Description Bits Value Description 0 HS_Capability 1:0 1 2 3 0 1 2 PWM_Capability 4:2 3 4 5 6 7 TX_HS_Unterminated_LINE_Drive_Capability TX_LS_Terminated_LINE_Drive_Capability 5 6 HS Capability is not supported HS-G1 only is supported HS-G1 to HS-G2 are supported HS-G1 to HS-G3 are supported Reserved PWM-G1 only is supported PWM-G1 to PWM-G2 are supported PWM-G1 to PWM-G3 are supported PWM-G1 to PWM-G4 are supported PWM-G1 to PWM-G5 are supported PWM-G1 to PWM-G6 are supported PWM-G1 to PWM-G7 are supported As in M-PHY specification 3649 Table 151 gives the detailed description of TX_OptCapability1 mapping to M-PHY Attributes. MIPI Alliance Member Confidential 381 . Therefore.

00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 151 Name TX_OptCapability1 Attribute Description Bits Value Description TX_PWMG0_Capability TX_Amplitude TX_ExternalSYNC TX_REF_CLOCK_SHARED_Capability 0 2:1 3 4 As in [MIPI05]. MIPI Alliance Member Confidential 382 . 3650 Table 152 gives the detailed description of TX_OptCapability2 mapping to M-PHY Attributes. Inc. Copyright © 2007-2011 MIPI Alliance. Table 154 Name OMC WO Attribute Description Bits Value Description M_TX_Amplitude MC_Output_Amplitude MC_HS_Unterminated_Enable MC_LS_Terminated_Enable MC_HS_Unterminated_LINE_Drive_Enable MC_LS_Terminated_LINE_Drive_Enable 0 1 2 3 4 5 Bit 0 of TX_Amplitude Attribute in M-PHY specification As in M-PHY specification As in M-PHY specification As in M-PHY specification As in M-PHY specification As in M-PHY specification 3653 Table 155 gives the detailed description of RX_Capability. Table 152 Name TX_OptCapability2 Attribute Description Bits Value Description TX_Min_SLEEP_NoConfig_Time_Capability TX_Min_STALL_NoConfig_Time_Capability 3:0 7:4 As in [MIPI05].40.Version 1. All rights reserved. 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. Table 153 Name TX_OptCapability3 Attribute Description Bits Value Description TX_Min_SAVE_Config_Time_Capability 7:0 As in [MIPI05].

All rights reserved.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro Table 155 Name RX_Capability Attribute Description Bits Value Description 0 HS_Capability 1:0 1 2 3 0 1 2 PWM_Capability 4:2 3 4 5 6 7 RX_HS_Unterminated_Capability RX_LS_Terminated_Capability 5 6 HS Capability is not supported HS-G1 only is supported HS-G1 to HS-G2 are supported HS-G1 to HS-G3 are supported Reserved PWM-G1 only is supported PWM-G1 to PWM-G2 are supported PWM-G1 to PWM-G3 are supported PWM-G1 to PWM-G4 are supported PWM-G1 to PWM-G5 are supported PWM-G1 to PWM-G6 are supported PWM-G1 to PWM-G7 are supported As in M-PHY specification 3654 Table 156 gives the detailed description of RX_OptCapability1 mapping to M-PHY Attributes. 3656 Table 158 gives the detailed description of RX_OptCapability3 mapping to M-PHY Attributes Table 158 NAME RX_OptCapability3 Attribute Description Bits Value Description RX_Min_SAVE_Config_Time_Capability 7:0 As in [MIPI05]. Table 156 Name RX_OptCapability1 Attribute Description Bits Value Description RX_PWMG0_Capability RX_REF_CLOCK_SHARED_Capability 0 1 As in [MIPI05]. MIPI Alliance Member Confidential 383 . Copyright © 2007-2011 MIPI Alliance. Inc.40. 3655 Table 157 gives the detailed description of RX_OptCapability2 mapping to M-PHY Attributes. Table 157 NAME RX_OptCapability2 Attribute Description Bits Value Description RX_Min_SLEEP_NoConfig_Time_Capability RX_Min_STALL_NoConfig_Time_Capability 3:0 7:4 As in [MIPI05].

3664 Five error counters are defined and they are mapped to the PWRMODE_MODE_ERR. OMC_READ_DATA1. Table 159 NAME RX_OptCapability4 Attribute Description Bits Value Description RX_HS_SYNC_LENGTH_Capability 7:0 As in [MIPI05]. MAP_TX_LANE1. Counter size is implementation dependent and can have a maximum of 8 bits. All rights reserved.40. PWRMODE_SERIE_ERR. the relevant error counter is incremented. In case of mismatch. 3658 Table 160 gives the detailed description of RX_OptCapability5 mapping to M-PHY Attributes.8. 3659 OMC_READ_DATA0. PWRMODE_HIBERNATE_ERR and the PWRMODE_TERMINATION_ERR Attributes. MIPI Alliance Member Confidential 384 . the PWRMODE_MODE_ERR counter shall be incremented. MAP_TX_LANE0. then according to the mismatch type. MAP_TX_LANE2 and MAP_TX_LANE3 are given in Section E. Inc. Copyright © 2007-2011 MIPI Alliance.1. MAP_RX_LANE3. PWRMODE_GEAR_ERR.3. 3666 The receiver shall compare the value of MODE field in the PwrMode Data symbol to RX_MODE. The Power Mode Test Feature is a mandatory feature for protocol testing. E. Counters shall not wrap. 3665 Writing any value to the PWRMODE_CTRL register shall result in resetting all the Power Mode Test features related counters.2. Table 160 NAME RX_OptCapability5 Attribute Description Bits Value Description RX_HS_PREPARE_LENGTH_Capability RX_LS_PREPARE_LENGTH_Capability 3:0 7:0 As in [MIPI05]. PWRMODE_GEAR_ERR. 3661 Detailed descriptions of PWRMODE_MODE_ERR. 3667 The receiver shall compare the value of the SERIE field in the PwrMode Data symbol to RX_HSRATE_Series. MAP_RX_LANE1. If a mismatch is detected between the setting in the received PwrMode data symbol and the setting of the corresponding M-RX Attributes. In case of mismatch.4. OMC_READ_DATA2 and OMC_READ_DATA3 are used for LCC_READ operations and have detailed descriptions in Table 133. MAP_RX_LANE2.7.8. PWRMODE_SERIE_ERR. 3660 Detailed descriptions of MAP_RX_LANE0. 3663 On the receiver side of the T-MPI. the received PwrMode data symbol is compared with the status of the MRX Attributes. PWRMODE_TERMINATION_ERR and PWRMODE_CTRL are given in Section E. the PWRMODE_SERIE_ERR counter shall be incremented. A test application may read the status of those counters to determine if there were any errors related to the power mode setting.3 Power Mode Test Feature 3662 The Power Mode Test Feature is used to insert PwrMode data symbols between the HoB control symbol and the actual data payload from the protocol as described in Section E. PWRMODE_HIBERNATE_ERR.8.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3657 Table 159 gives the detailed description of RX_OptCapability4 mapping to M-PHY Attributes.

Inc. The updated M-RX Attributes can be then checked by a test application to determine if LCC read operations were performed correctly. OMC_READ_DATA1 and OMC_READ_DATA0. the payload for the LCC-READ command is contained in OMC_READ_DATA3. E. the T-MPI shall start LCC operations.5. the received data are captured in the OMC_WO register. In case of mismatch. OMC_READ_DATA2.5 3674 3675 3676 3677 • • • • OMC Emulation Test Feature 3673 OMC emulation test feature provides support for the following LCC commands: LCC-READ-CAPABILITY LCC-WRITE-ATTRIBUTE LCC-READ-MFG-INFO LCC-READ-VEND-INFO 3678 LCC commands operations and related state machine is described in Section E. when an LCC-WRITE command is detected. 3681 On the receiver side.8. However. In that case. 3670 The receiver shall compare the value of the Hibernate_Control field in the PwrMode Data symbol to RX_Enter_HIBERN8. 3672 The description of the Error Control Test Feature will be part of a later release of this specifications. respectively. When LCC-READ-CAPABILITY. Once TX_LCC_Enable is set.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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. the M-PHY Attributes described in Table 134 are used as payload. In case of mismatch the PWRMODE_GEAR_ERR counter shall be incremented. LCC emulation is not required for external M-PHY use case. depending on which LCC-READ command was received. then depending on the bits set in TX_LCC_Sequencer.1. LCC-WRITE and LCC-READ. When several bits of the TX_LCC_Sequencer are set. LCC-READ-MFG-INFO or LCC-READVEND-INFO are set. When an LCC-READ command is detected. 3682 LCC-Emulation shall not be reset by LINE-RESET. the OMC Emulation module shall prioritize LCC operations such that LCC-WRITE is executed first. a LCC-READ operation is invoked. the PWRMODE_HIBERNATE_ERR counter shall be incremented. the PWRMODE_TERMINATION_ERR counter shall be incremented. This feature is not mandatory for a DUT device (in protocol testing use case). Copyright © 2007-2011 MIPI Alliance.Version 1. This register can be later read by a test application for checking correct LCC operations. 3680 The OMC Emulation Test Feature module takes care for preparing data to be transmitted.4 Error Control Test Feature 3671 The Error Control Test Feature is used to insert errors on both sides of the Link. E.40.5. MIPI Alliance Member Confidential 385 . the M-RX Attributes are updated as described in Table 135 and Table 136. LCC-WRITE is invoked when LCC-WRITE-ATTRIBUTE in TX_LCC_Enable is set. 3679 LCC emulation shall be supported for protocol testing. There are two types of LCC operations. In that case. All rights reserved. In case of mismatch. 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. such a feature is required for a UniPro conformance tester for generating and checking error injection and handling.8.

40. MIPI Alliance Member Confidential 386 . FSM emulation shall be supported for protocol testing. All rights reserved. The FSM emulation is used to set the returned values of the TX_FSM_State and RX_FSM_State Attributes of the M-PHY. When a lane is disabled all control and data interface signals shall be set to inactive state.Version 1.00 31-Jan-2011 MIPI Alliance Specification for UniPro E. Table 162 RX_FSM_State RX_FSM_State Attribute Setting RX_MODE RX_Enter_HIBERN8 S-RX FSM State HIBERN8 SLEEP STALL LS-BURST HS-BURST LINE-CFG RESET IDLE IDLE IDLE BURST BURST OMC LS_MODE HS_MODE LS_MODE HS_MODE YES E. 3687 The Physical lane re-numbering test feature is mandatory for protocol testing use case. Table 161 TX_FSM_State TX_FSM_State Attribute Setting TX_MODE TX_HIBERN8_Control S-TX FSM State HIBERN8 SLEEP STALL LS-BURST HS-BURST LINE-CFG RESET IDLE IDLE IDLE BURST BURST OMC LS_MODE HS_MODE LS_MODE HS_MODE ENTER 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.7 Physical Lanes Renumbering Test Feature 3686 Physical lanes renumbering is required for checking the lane-renumbering feature of the PA Layer which occurs during the Link startup procedure. Copyright © 2007-2011 MIPI Alliance. 3684 Table 161 gives the setting of TX_FSM_State depending on the SERDES TX FSM State and the M-RX TX_MODE and TX_HIBERN8_Control Attributes. When line re-numbering is applied all control and data interface signals from the PA Layer to the Dummy M-PHY shall be multiplexed according to the renumbering setting. The returned values are depending on the current power mode and SERDES FSM State.8.6 FSM Emulation Test Feature 3683 FSM Emulation Test Feature is required for checking the state of the T-MPI transceivers and being able to distinguish Active state from Hibernate State. Furthermore the line re-numbering feature enables disabling of individual lanes in either direction. FSM emulation is not required for external M-PHY use case. Lane renumbering is controlled individually for both RX and TX direction and for each lane.8. Inc.

Inc. MIPI Alliance Member Confidential 387 . 3690 The description of the serial control interface will be part of a later version of this specification.9 Serial Control Interface 3689 The Serial Control interface is used to control access to the Attributes of an external M-PHY.00 31-Jan-2011 MIPI Alliance Specification for UniPro 3688 Lane re-numbering is controlled by the MAP_x Attributes of the T-MPI as described in Table 163. Map PA Logical Lane to SERDES lane 3. MAP_RX_LANE1. MAP_RX_LANE2. Disable Lane. This description applies to MAP_RX_LANE0.Version 1. All rights reserved. MAP_RX_LANE3. E. Enable Lane. Table 163 NAME MAP_x Attribute Description Bits Value Description 0 Map 1:0 1 2 3 Enable 2 0 1 Map PA Logical Lane to SERDES lane 0. This feature is not required for protocol testing use case. Map PA Logical Lane to SERDES lane 1.40. MAP_TX_LANE_LANE1. MAP_TX_LANE0. Copyright © 2007-2011 MIPI Alliance. Map PA Logical Lane to SERDES lane 2. MAP_TX_LANE2 and MAP_TX_LANE3.

Thus. suppliers or users.00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex F Options and Tunable Parameters (informative) 3691 This annex collects the most significant “design time” options and parameters. the PA Layer can instruct the peer Device to be in a given test mode. the DME can access. If this Attribute has a value of zero. Attributes of the peer Device.1 3699 With the PACP protocol.1. The intent of this annex is to make it easier for users of the UniPro specification to verify that no major decision point was overlooked when defining a specification on top of UniPro.1.1. use or re-use of IPs. usually the Host.1 Specification Point of View 3693 Note that only options or tunable parameters found in the UniPro specification are covered in this section since the targeted audience is writers of specifications defined on top of UniPro. that can be used. the Traffic Class is TC0.Version 1. F. and a second section targeted to IP vendors.5) 3694 For the PHY Adapter Layer. and which.1.2 3702 3703 3704 3705 • • • • Data Link Layer (L2) 3701 For the Data Link Layer. needs this capability. process the request and return a result. defined by PA_AvailTxDataLanes and PA_AvailRxDataLanes.1.1. 3692 This annex is divided in two sections. Copyright © 2007-2011 MIPI Alliance. one section targeted to writers of a specification using UniPro. F. or that no essential point was overlooked when considering the design. The value of DL_TC1RxInitCreditVal defines if TC1 is implemented. the following options and tunable parameters are defined: The PHY Type. Inc. via the local PHY Adapter Layer. Traffic Classes are supported Size of TX and RX buffers The maximum supported Frame size Support for preemption Supported Traffic Classes F. Those options and parameters are constant for a given UniPro implementation and cannot be changed at run-time. the following options and tunable parameters are defined: Number of. F.1 3706 UniPro leaves the choice to Applications to use one or two Traffic Classes. at least one Device on each UniPro Link. Nothing new is added by this annex to the UniPro behavior since it merely list points already presented in other sections of this document. F.1. respectively Access to Attributes of the peer Device PHY Layer test mode Access to Attributes of a Peer Device F. however the capability of receiving such a request from the peer Device is mandatory. tuned or restricted by a specification using UniPro. The capability to send this request to the peer Device is optional. a Device is always capable of receiving a request from a peer Device to access local Attributes.2. defined by PA_PHY_Type Number of supported Lanes for TX and RX. if an Application implements only one Traffic Class. but also gives guidelines for IP suppliers or users. Even if the capability to request access of remote Attributes is optional for a single Device. MIPI Alliance Member Confidential 388 . TC1 is not implemented.1 3695 • 3696 • 3697 • 3698 • PHY Adapter Layer (L1.2 PHY Test Mode 3700 With the PACP protocol.40. However. All rights reserved.

1. Therefore.2. but there might be a non-negligible impact on performance at high bandwidth.40.1.1.4 3716 3717 3718 3719 3720 • • • • • Transport Layer (L4) 3715 For the Transport Layer. respectively.Version 1.2.4 Support for Preemption 3711 An implementation can choose to support preemption in the TX side. Those values do not impact the protocol behavior of UniPro.1. Inc. respectively. respectively. etc. Note there does not seem to be any practical reason to mandate a smaller Frame size.2 TX and RX Buffer Sizes 3708 The size of the RX buffer is defined by DL_TC0RxInitCreditVal and DL_TC1RxInitCreditVal for TC0 and TC1. Application behavior. A specification using UniPro could be more restrictive in what values are expected from a UniPro implementation it uses. depending on hardware and software partitioning.3 3713 • Network Layer (L3) 3712 For the Network Layer the following options and tunable parameters are defined: Maximum supported Packet size Maximum Supported Packet Size F. This could be restricted and enforced by Switches to use. to ensure compatibility with future networks. F. F.1. Note that reducing the RX buffer size might reduce cost. 3709 The size of the TX buffer is defined by DL_TC0TxBufferSize and DL_TC1TxBufferSize for TC0 and TC1. the following options and tunable parameters are defined: Number of CPorts Number of Test Features CPort arbitration algorithm Maximum supported Segment size Static Connections Copyright © 2007-2011 MIPI Alliance. Applications needing high bandwidth for certain traffic are advised to use TC0 for such traffic. respectively. but might have an impact on the performance. low-bandwidth traffic. The Packet size is indicated by N_TC0TxMaxSDUSize and N_TC1TxMaxSDUSize for TC0 and TC1. a certain percentage of a UniPro Link. F. All rights reserved. An Application can mandate a specific value of this Attribute.1 3714 A UniPro implementation can choose to support a smaller Packet size than the maximum allowed Packet size.3 Maximum Supported Frame Size 3710 A UniPro implementation can choose to support a smaller Frame size than the maximum allowed Frame size. F. The Frame size is indicated by DL_TC0TxMaxSDUSize and DL_TC0TxMaxSDUSize for TC0 and TC1. Support for preemption is indicated by DL_TxPreemptionCap.3. but a specification could mandate support for at least a specific size Frame or support for the full Frame size indicated by DL_MTU. Note there does not seem to be any practical reason to mandate a smaller Packet size. MIPI Alliance Member Confidential 389 .00 31-Jan-2011 MIPI Alliance Specification for UniPro 3707 Note that TC1 is intended for low-latency.1. at maximum. The percentage could be a system level configurable parameter.2. but a specification could mandate support for at least a specific Packet size or support for the full Packet size indicated by N_MTU. F. especially if the average Frame size is small.

The Segment size is indicated by T_TC0TxMaxSDUSize and T_TC1TxMaxSDUSize for TC0 and TC1. since it defines the limits of concurrent L4 Connections possible at any given time. F.1.5 Static Connections 3726 The static configuration of a UniPro Device (see Section F. Note that the same condition as stated in Section F.1.1.cnf_L are used to power on the UniPro stack. since it artificially limits the possible reuse of such a specification for building multiple Function Devices.1.40.00 31-Jan-2011 MIPI Alliance Specification for UniPro F. F.1. DME_POWERON.6) can be used to define static L4 Connections. F.2 Access to Attributes of a Peer Device 3729 DME_PEER_GET and DME_PEER_SET Service Primitives are optional. respectively. without violating the UniPro specification. Note that as for the maximum Packet and Frame size.2 Number of Test Features 3723 The number of Test Features present in an implementation is given by the value of T_NumTestFeatures.1. All rights reserved.4 Maximum Supported Segment Size 3725 A UniPro implementation can choose to support a smaller Segment size than the maximum allowed Segment size. but a specification could mandate support for at least a specific Segment size or support the full Segment size indicated by T_MTU. as long as Round Robin arbitration is also provided.5 Device Management Entity 3727 The Device Management Entity has optional Service Primitives to power on and power off the UniPro stack and access Attributes of a peer Device. An Application on top of a UniPro stack could mandate the addition of another scheme. This is one of the critical parameters that any Application designed on top of UniPro should define clearly. but there is the option to add any other arbitration algorithm of the CPorts. This value is not critical for the protocol behavior of an Application on top of a UniPro stack.1 Powering On or Off the UniPro Stack 3728 DME_POWERON and DME_POWEROFF Service Primitives are optional.4. 3722 To allow UniPro Devices with multiple Functions. MIPI Alliance Member Confidential 390 . Conformance tests defined for UniPro rely heavily on the availability of Test Features.4.1.5. but is a very important parameter impacting the level of testability of a UniPro implementation.1 Number of CPorts 3721 The number of CPorts present in an implementation is given by the value of T_NumCPorts.1 applies here as well. F.4. F.req and DME_POWEROFF. F.1. F. a specification should not mandate a maximum number of CPorts allowed for a given UniPro implementation.cnf_L are used to power off the UniPro stack. there does not seem to be any practical reason to mandate a smaller Segment size.4. However.4.5.1.1. while DME_POWEROFF.3 CPort Arbitration Algorithm 3724 Round Robin arbitration is mandated by the UniPro specification. a specification using UniPro should define the minimum number of CPorts expected from a UniPro implementation. Copyright © 2007-2011 MIPI Alliance.1. Inc.req and DME_POWERON.Version 1.

F.6 Static Configuration of a UniPro Device 3731 A UniPro Device can be statically configured.2 IP Point of View 3733 In a future version of this document. Inc. Copyright © 2007-2011 MIPI Alliance. All rights reserved. For those gettable and settable Attributes that this specification defines a nonvolatile reset value.g. This means that after reset the value of these Attributes is automatically set. which can be different from their corresponding default value defined for the Attribute. e.00 31-Jan-2011 MIPI Alliance Specification for UniPro F. this section will provide guidelines for IP suppliers on which options to implement for a given context. MIPI Alliance Member Confidential 391 .5.req primitives. without requiring any action from an Application on top of the UniPro stack.ind are specifically used in testing mode and are not intended for normal Application use. F. 3732 Note that UniPro provides a standard method to write a non-volatile reset value through the DME_SET.40. to their corresponding reset value.Version 1.1.1.3 Testing Mode 3730 DME_TEST_MODE. an Application on top of a UniPro stack can set and change these reset values as desired by the Application.req and DME_TEST_MODE..req and DME_PEER_SET. to configure a static L4 Connection. utilizing the non-volatile reset values defined in this specification for certain Attributes..

For example. Copyright © 2007-2011 MIPI Alliance. 3735 There are two types of pre-condition Messages initiated by an Application. The initial value of an inactivity timer might be restored once an Application exits hibernate. The protocol for detecting inactivity or idleness should be defined by the Application. 3736 Inactivity precondition Messages allow Applications to exchange inactivity states of the local and remote Applications. The protocol for sharing Link information should be defined by the Application. Packets or Frames are outstanding in the UniPro stack. When the inactivity timer expires. The inactivity precondition Message can read this Attribute and use it to detect inactivity in the Application.Version 1. Inc.5 sent a precondition Message commanding Device A to initiate hibernate between Device A and Device B. inactivity Messages and Link information Messages.40. an Application Attribute is set to TRUE indicating that the Application is in an idle state. Once inactivity of a Link is detected. The pre-condition Messages ensure that no additional Messages are transmitted and received by the UniPro stack and all potential Links are identified to hibernate between the two UniPro Devices. All rights reserved. the Application strengthens its confidence that no additional Segments. MIPI Alliance Member Confidential 392 . This Message might be detected by using an inactivity timer to detect idleness of the Application. 3737 Link information-related precondition Messages might be used to communicate which Links need to be hibernated for hibernate Links between two Devices.00 31-Jan-2011 MIPI Alliance Specification for UniPro Annex G Recommended Pre-conditions for Hibernate Entry and Exit (informative) 3734 This annex provides an informative description of the pre-condition Messages that are exchanged at the Application level during Hibernate Entry Phase 1 flow. An inactivity precondition Message is intended to allow easier entry into hibernate. Device B in Section 9.

Nokia Corporation Andreas Gstoettner. Petersburg State University of Aerospace Instrumentation Andrei Radulescu. Inc. Micron Technology. Nokia Corporation Copyright © 2007-2011 MIPI Alliance. Inc. St. All rights reserved.Version 1. Texas Instruments Incorporated Valentin Olenev. Inc. Nokia Corporation Ariel Lasry. MIPI Alliance Member Confidential . Intel Corporation Pekka Korpinen.00 31-Jan-2011 MIPI Alliance Specification for UniPro 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. Toshiba Corporation Serge Lasserre. Petersburg State University of Aerospace Instrumentation Jason Oliver. Testronic Laboratories Michel Gillet. Nokia Corporation Yoram Rimoni. Miika Rummukainen. MCCI Corporation Todor Popovic. Texas Instruments Incorporated Alexey Rabin.40. STMicroelectronics Robert C Johnson. STMicroelectronics Juha Rakkola. Intel Corporation Glen Hambro. STMicroelectronics Krish Datla. Alberto García Zapata. St. IEEE-ISTO (staff) Peter van den Hamer. Bipin Balakrishnan. STMicroelectronics Hicham Bouzekri. IEEE-ISTO (staff) Taeho Kgil. Qualcomm.