Mipi M-PHY Specification V4-1-Er01

Errata 01 Errata for MIPI M-PHY Specification v4.
1
14-May-2018
Errata 01 for
MIPI M-PHY Specification
Specification Version 4.1

Specification Dated 01 December 2016
Specification MIPI Board Adopted 28 Mar 2017
Errata 01 Dated 14 May 2018

Errata MIPI Board Approved 17 May 2018
* IMPORTANT NOTE TO IMPLEMENTERS *

• The issue(s) listed in this Errata document will be corrected in the next edition of this MIPI Specification.
• Implementations should observe all Corrections listed here.
• The location of each Correction is also marked in the attached copy of the MIPI Specification. To reduce the
risk of incorrect implementations, we suggest you consider discarding any previous copies of this MIPI
Specification not so marked.
• This MIPI Specification as modified by the corrections listed in this Errata document is also a MIPI
Specification, as the MIPI Bylaws defines the term.
• MIPI member companies’ rights and obligations apply to the modified MIPI Specification as defined in
the MIPI Membership Agreement and MIPI Bylaws.
Copyright © 2018 MIPI Alliance, Inc.

All rights reserved.
Confidential
Errata for MIPI M-PHY Specification v4.1 Errata 01
14-May-2018
1 The PHY Working Group would like to ensure a unique understanding of the ADAPT sequence.
Spec PDF
Item Page Page Correction
Number Number
1 203 221 Editorial or Technical: Editorial
Location: After line 1130
Correction: Insert Section F.4 as shown on the following page.
Reason: Clarifies the definition of the ADAPT sequence. This is not
considered a technical change.
Technical Impact: None.
2 Copyright © 2018 MIPI Alliance, Inc.

Confidential
Errata 01 Errata for MIPI M-PHY Specification v4.1
14-May-2018
F.4 ADAPT Sequence

This section provides additional guidance for the ADAPT sequence specified in Section 4.7.2.3. The ADAPT
sequence is defined as an 8b10b encoded pattern of MK0, followed by a PRBS9 sequence 511 bits in length,
beginning with 9 b1 bits and ending with a single b0 bit. This is shown in Figure 79.
Figure 79 One ADAPT Sequence before 8b10b Encoding
The line coding is defined in Section 4.5, which also specifies that the LSb of an 8b10b encoded symbol is
transmitted first. The ADAPT sequence before and after 8b10b encoding is shown in Figure 80, based on the
definitions in Section 4.5.
Figure 80 Symbol Encoding within ADAPT Sequence (before Encoding -> Data Byte)
The start and end fragments of the serialized 8b10b encoded ADAPT sequence are shown in Figure 81.
Figure 81 Start and End of Serialized 8b10b Encoded ADAPT Sequence
Copyright © 2018 MIPI Alliance, Inc. 3

Confidential
Errata for MIPI M-PHY Specification v4.1 Errata 01
14-May-2018
This page intentionally left blank.
4 Copyright © 2018 MIPI Alliance, Inc.

Confidential
01-Dec-2016
Specification for
M-PHY®
Version 4.1 – 01 December 2016

MIPI Board Adopted 28-Mar-2016
CAUTION TO IMPLEMENTERS
This document is a Specification. MIPI member companies’ rights and obligations apply to this Specification as
defined in the MIPI Membership Agreement and MIPI Bylaws.
This release represents the fourth in a series of major releases of the Specification for M-PHY, each supporting
additional high speed GEARs.
All GEAR names and related parameters are reserved for exclusive use by the PHY WG. Implementers should
provide support, such as allowing software to select different GEARs, in their designs.
Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
Specification for M-PHY Version 4.1
01-Dec-2016

Confidential
1 Introduction 1
2 Terminology 3 Specification for
3 References 7 M-PHY®
4 Architecture and Operation 9
5 Electrical Characteristics 51
6 Electrical Interconnect
(informative) 95
7 Optical Media Converter (OMC)
99
8 The Protocol Interface 115 Version 4.1
A Signaling Interface Description
(normative) 163
01 December 2016
B Recommended Test
Functionality (informative) 188 MIPI Board Adopted 28-Mar-2016
C SI Dithering (informative) 193

D Setting of Attributes Values
(informative) 195
E Guidance for Protocols on
Managing LANE-to-LANE
Skew (informative) 198
F Guidance for Protocols on
Managing ADAPT Sub-State
and RX Equalization
(informative) 203
Further technical changes to this document are expected as work continues in the
PHY Working Group.

Confidential
01-Dec-2016
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
ii Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
Version 4.1 Specification for M-PHY
01-Dec-2016
Contents
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Release History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Architecture and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 PIN, LINE, LANE, SUB-LINK, LINK, and M-PORT. . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 LINE States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Termination Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 Signal Amplitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Signaling Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 Non-Return-to-Zero (NRZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2 Pulse Width Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Overview of Concept, Features, and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Line Coding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1 Data Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.2 Control Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5.3 Running Disparity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5.4 Bit Order and Binary Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6 State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.1 State Machine for a Type-I MODULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.2 State Machine for a Type-II MODULE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.3 State Machine Structure and State Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 FSM State Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7.1 SAVE States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7.2 BURST States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7.3 BURST MODEs and GEARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7.4 BREAK States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8.1 Conceptual Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8.2 Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9 Multiple LANE Provisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10 Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.10.1 LOOPBACK Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Electrical Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1 M-TX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Copyright © 2008-2017 MIPI Alliance, Inc. iii

Confidential
01-Dec-2016
5.1.1 Common M-TX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.2 HS-TX Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.3 PWM-TX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.4 SYS-TX Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 M-RX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.1 Common M-RX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2 HS-RX Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.3 PWM-RX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.4 SYS-RX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.5 SQ-RX Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3 PIN Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.1 PIN Capacitance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.2 PIN Signal Voltage Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.3 PIN Leakage Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.4 Ground Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.5 PIN Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6 Electrical Interconnect (informative). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.1 Line Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3 Methodology Guidance for Validating a LANE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.1 Interconnect S-parameters Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.2 Simulation Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7 Optical Media Converter (OMC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.1 Application Benefits of the OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2 Types of OMCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.3 Internal and External OMCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.4 OMC – Architecture and Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.4.1 OMC – Data Transmission BURST Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.4.2 OMC – HS-BURST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.4.3 OMC – DISABLED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.4.4 OMC – Transitional States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.5 OMC – Electrical and Interconnect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.5.1 OMC – Galvanic Connection Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.2 OMC – Signal Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.3 OMC – HS-BURST Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.6 OMC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.6.1 OMC Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.6.2 OMC – Configuration LCCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.7 OMC – M-PHY Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.8 OMC – Test Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8 The Protocol Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1 Service Primitive Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.2 M-TX-DATA and M-RX-DATA SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.2.1 M-LANE-SYMBOL.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.2.2 M-LANE-SYMBOL.indication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2.3 M-LANE-SYMBOL.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.2.4 M-LANE-PREPARE.request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
iv Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
8.2.5 M-LANE-PREPARE.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.2.6 M-LANE-PREPARE.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2.7 M-LANE-SYNC.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.2.8 M-LANE-SYNC.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.9 M-LANE-BurstEnd.request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.10 M-LANE-BurstEnd.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.2.11 M-LANE-BurstEnd.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2.12 M-LANE-HIBERN8Exit.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2.13 M-LANE-SaveState.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.2.14 M-LANE-MRXSaveState.indication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.2.15 M-LANE-AdaptStart.request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.2.16 M-LANE-AdaptStart.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.2.17 M-LANE-AdaptComplete.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.2.18 Sequence of Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
8.3 M-TX-CTRL SAP and M-RX-CTRL SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.3.1 M-CTRL-CFGGET.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.3.2 M-CTRL-CFGGET.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.3.3 M-CTRL-CFGSET.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.3.4 M-CTRL-CFGSET.confirm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.3.5 M-CTRL-CFGREADY.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.3.6 M-CTRL-CFGREADY.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.3.7 M-CTRL-RESET.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.3.8 M-CTRL-RESET.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.3.9 M-CTRL-LINERESET.request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.3.10 M-CTRL-LINERESET.indication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
8.3.11 M-CTRL-LINERESET.confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.12 M-CTRL-LCCReadStatus.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.13 Sequence of Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
8.4 M-TX and M-RX Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Annex A Signaling Interface Description (normative) . . . . . . . . . . . . . . . . . . . . . . 163
A.1 One-Hot Coding of Control Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.2 The M-RX Signaling Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.2.1 M-RX Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.3 The M-TX Signaling Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A.3.1 M-TX Signal Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A.4 Interface Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.4.1 Attribute Read from Effective Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.4.2 Attribute Write to Shadow Memory and Effective Configuration . . . . . . . . . . . . . 180
A.4.3 Effective Configuration Single-step Update and Local RESET . . . . . . . . . . . . . . . 180
A.4.4 Received LCC and LINE-RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
A.4.5 HS Data Reception with 20-bit RX_Symbol Bus . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A.4.6 TX_LineReset Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
A.4.7 HS Transmission on 20-bit TX_Symbol Bus with Data Throttled
by Protocol Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.4.8 HS Transmission on 20-bit TX_Symbol Bus with Data Throttled by M-TX . . . . . 186
Copyright © 2008-2017 MIPI Alliance, Inc. v

Confidential
01-Dec-2016
Annex B Recommended Test Functionality (informative) . . . . . . . . . . . . . . . . . . . 188

B.1 Test Pattern Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
B.1.1 General Transmitter Test Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
B.1.2 Test Patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
B.1.3 Signaling Type and Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
B.1.4 Continuous vs. Burst Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
B.1.5 Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.1.6 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.2 Test Pattern Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.2.1 General Receiver Test Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.2.2 Loopback Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.2.3 Receiver Pattern Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.2.4 Receiver Configuration – Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
B.3 Interoperability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Annex C SI Dithering (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
C.1 Dither Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
C.1.1 Dither Magnitude. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Annex D Setting of Attributes Values (informative) . . . . . . . . . . . . . . . . . . . . . . . . 195
D.1 Attribute Pair Matching for MODULEs of a LANE. . . . . . . . . . . . . . . . . . . . . . . . . . 195
D.2 Attribute Values Changed with LANE Speed Setting . . . . . . . . . . . . . . . . . . . . . . . . 196
D.2.1 Intra-MODE GEAR Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.2.2 Inter-MODE Gear Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.3 Interpretation of Certain Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.3.1 TX_LCC_Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
D.3.2 TX_PWM_BURST_Closure_Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
D.3.3 M-TX and M-RX Polarity Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Annex E Guidance for Protocols on Managing
LANE-to-LANE Skew (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Annex F Guidance for Protocols on Managing ADAPT Sub-State and RX
Equalization (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.1 When to Use ADAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.2 Detecting the Need for ADAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.3 ADAPT Sequences in Lower HS-GEARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
vi Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
Figures
Figure 1 M-PHY Lane Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 2 Example LANE Configuration with Media Converter . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 3 Example I/O Termination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 4 PWM Bit Waveforms and Bit Stream Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 5 Functional Options for MODULEs in Type-I and Type-II M-PORTs . . . . . . . . . . . 14
Figure 6 Running Disparity (RD) State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 7 State Diagram for Type-I M-TX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 8 State Diagram for Type-I M-RX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 9 State Diagram for Type-II M-TX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 10 State Diagram for Type-II M-RX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 11 Entry and Exit of HIBERN8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 12 LANE Power-up Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 13 LINK Power-up Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 14 BURST-SAVE: Detailed Sub-FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 15 ADAPT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 16 HS-BURST Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 17 Bidirectional SYS-BURST Clocking Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 18 LINE-RESET Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 19 Sub-state Machine of M-TX for LINE-CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 20 Sub-state Machine of the M-RX for LINE-CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 21 Format of Different LCC Frames on the LINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 22 Configuration Steps for LANE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 23 Configuration Steps for LANE including Media Converters. . . . . . . . . . . . . . . . . . . 48
Figure 24 LOOPBACK Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 25 M-TX PIN Voltages, PIN Currents, and Reference Loads . . . . . . . . . . . . . . . . . . . . 52
Figure 26 HS-G3 and HS-G4 Reference Channel Insertion Loss SDDIL_REF_CH Templates 52
Figure 27 Template for Reference Return Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 28 M-TX Signal Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 29 Ideal Single-ended and Differential Signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 30 Measurement Setup for Single-ended Output Resistance . . . . . . . . . . . . . . . . . . . . . 56
Figure 31 Measurement Setup for M-TX Return Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figure 32 Template for Differential Transmitter Return Loss SDDTX . . . . . . . . . . . . . . . . . . . . . . . . . 58
Copyright © 2008-2017 MIPI Alliance, Inc. vii

Confidential
01-Dec-2016
Figure 33 Impact of Signal Skew on Common-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 34 Impact of Output Signal Mismatch on Common-mode Voltage . . . . . . . . . . . . . . . . 62
Figure 35 Clock and Data Recovery Transfer Function and Jitter Transfer Function . . . . . . . . 64
Figure 36 Example Transmit Waveform with De-emphasis . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 37 HS-G1 and HS-G2 Differential Transmit Eye Diagram . . . . . . . . . . . . . . . . . . . . . . 66
Figure 38 HS-G3 and HS-G4 Differential Transmitter Eye Diagram . . . . . . . . . . . . . . . . . . . . 67
Figure 39 Common-mode Power Spectral Magnitude Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 40 TX Minor and Major Duration in a PWM Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 41 PIN Voltages and PIN Currents of an M-RX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 42 M-RX Implementation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 43 Examples of CTLE Frequency Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 44 Reference DFE Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 45 Measurement Setup for M-RX Return Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 46 Template for Differential Receiver Return Loss SDDRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 47 Sinusoidal Jitter Tolerance Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 48 HS-G1 and HS-G2 Differential Receiver Eye Diagram. . . . . . . . . . . . . . . . . . . . . . . 84
Figure 49 HS-G3 and HS-G4 Differential Receiver Eye Diagram. . . . . . . . . . . . . . . . . . . . . . . 85
Figure 50 Receiver Pulse Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 51 RX Minor and Major Duration in a PWM Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 52 Pulse Rejection and Non-squelch State Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 53 Point-to-Point Interconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 54 Single LANE Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figure 55 Multiple LANE Simulation Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 56 LANE with an OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 57 OMC State Diagram (based on Type-I M-RX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 58 DIF-Z OMC Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 59 Electrical Specification Test Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 60 HS-BURST Entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 61 OMC WRITE Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 62 OMC READ Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 63 M-PORT Protocol Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Figure 64 Sequence of Primitives at M-TX-DATA SAP and M-RX-DATA SAP . . . . . . . . . 129
Figure 65 Sequence of Service Primitives at M-TX-CTRL SAP and M-RX-CTRL SAP. . . . 136
viii Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
Figure 66 M-RX Signal Interfaces Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Figure 67 M-TX Signal Interfaces Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 68 Interface Behavior for Attribute Read Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Figure 69 Interface Behavior for Attribute Write Operations . . . . . . . . . . . . . . . . . . . . . . . . . 180
Figure 70 Interface Behavior for RX_CfgUpdt and RX_Reset . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 71 Interface Behavior for LCC Command and LINE-RESET . . . . . . . . . . . . . . . . . . . 182
Figure 72 Example 20-bit Interface Behavior for HS Data Reception. . . . . . . . . . . . . . . . . . . 183
Figure 73 Interface Behavior for a TX_LineReset Command . . . . . . . . . . . . . . . . . . . . . . . . . 184
Figure 74 Interface Behavior for HS Transmission with Protocol Layer Throttling Data . . . . 185
Figure 75 Interface Behavior for HS Transmission with M-TX Throttling Data. . . . . . . . . . . 186
Figure 76 Transmitter Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figure 77 Dithering Circuit Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 78 Measurement Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Copyright © 2008-2017 MIPI Alliance, Inc. ix

Confidential
01-Dec-2016
Tables
Table 1 LINE Conditions and Resulting LINE States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 2 5b6b Sub-Block Data Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 3 3b4b Sub-Block Data Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 4 Control Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Table 5 THIBERN8 and TACTIVATE Capabilities and Parameters . . . . . . . . . . . . . . . . . . . . . . . 25
Table 6 Valid Data Symbols for SYNC Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 7 PREPARE, SYNC, and ADAPT Attribute and Dependent Parameter Values . . . . . 33
Table 8 Summary of BURST Closure Conditions (TAIL-OF-BURST). . . . . . . . . . . . . . . . . 36
Table 9 HS-BURST: RATE Series and GEARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Table 10 PWM-BURST GEARs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 11 LINE-RESET and HIBERN8 Timer Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 12 LCC Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 13 FUNCTIONs and their Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 14 M-TX and HS-TX Reference Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 15 Common M-TX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 16 HS-TX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 17 PWM-TX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Table 18 SYS-TX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 19 M-RX Reference Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Table 20 Common M-RX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 21 HS-RX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Table 22 PWM-RX Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 23 SQ-RX Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Table 24 PIN Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Table 25 Interconnect Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Table 26 POR Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Table 27 Galvanic Connection Specification (informative) . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 28 Signaling Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Table 29 OMC HS-BURST Entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Table 30 Optical Media Converter (OMC) Jitter Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table 31 Optical Media Converter (OMC) Transmit Ratio Budget . . . . . . . . . . . . . . . . . . . . 106
Table 32 OMC Line Control Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Table 33 LCC-WRITE-ATTRIBUTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 34 LCC-READ-CAPABILITY Supported Capabilities Bit Definitions. . . . . . . . . . . . 111
Table 35 LCC-READ-MFG-INFO and LCC-READ-VEND-INFO Byte Map . . . . . . . . . . . 113
x Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
Table 36 OMC M-PHY Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Table 37 M-TX-DATA SAP Service Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Table 38 M-RX-DATA SAP Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Table 39 Parameters of M-TX-DATA SAP and M-RX-DATA Service Primitives. . . . . . . . 117
Table 40 Parameters for the M-LANE-SYMBOL.request Primitive . . . . . . . . . . . . . . . . . . . 118
Table 41 Parameters for the M-LANE-SYMBOL.indication Primitive . . . . . . . . . . . . . . . . . 119
Table 42 Parameters for the M-LANE-SYMBOL.confirm Primitive. . . . . . . . . . . . . . . . . . . 121
Table 43 Parameters for M-LANE-SYNC.request Primitive . . . . . . . . . . . . . . . . . . . . . . . . . 123
Table 44 Parameters for M-LANE-BurstEnd.confirm Primitive . . . . . . . . . . . . . . . . . . . . . . 125
Table 45 Parameters for M-LANE-SaveState.indication Primitive . . . . . . . . . . . . . . . . . . . . 126
Table 46 Parameters for M-LANE-MRXSaveState.indication Primitive . . . . . . . . . . . . . . . . 126
Table 47 M-TX-CTRL SAP Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Table 48 M-RX-CTRL SAP Service Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Table 49 Parameters of M-TX-CTRL SAP and M-RX-CTRL SAP Service Primitives . . . . 130
Table 50 M-TX Capability Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Table 51 M-TX Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 52 M-TX Status Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Table 53 OMC Write-only Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Table 54 M-RX Capability Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Table 55 M-RX Configuration Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Table 56 M-RX Status Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Table 57 OMC Status Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Table 58 One-Hot Coding of Control Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Table 59 M-RX-CTRL Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Table 60 M-RX-DATA Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Table 61 M-RX Test Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Table 62 M-TX-CTRL Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Table 63 M-TX-DATA Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Table 64 M-TX Test Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Table 65 Dithering Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Table 66 Attribute Pairs of a LANE to be Matched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Table 67 Relationship between M-TX Configuration and M-RX Capability Attributes . . . . 195
Table 68 Recommended Settings of OMC Write-only Attributes . . . . . . . . . . . . . . . . . . . . . 196
Table 69 LANE-to-LANE Skew Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Table 70 L2L Skew Parameters for Tightly Coupled Use-case . . . . . . . . . . . . . . . . . . . . . . . 200
Table 71 L2L Skew Parameters for Nominally Coupled Use-case. . . . . . . . . . . . . . . . . . . . . 200
Table 72 L2L Skew Parameters Optical Media Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Copyright © 2008-2017 MIPI Alliance, Inc. xi

Confidential
01-Dec-2016
Release History
Date Release Description
2008-08-29 v0.10.00 Initial release
2010-08-13 v0.80.00 Board approved release.
2011-05-03 v1.00.00 Board-approved release.
2012-07-09 v2.0 Board-approved release.
xii Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
1 Introduction
1 This document describes a serial interface technology with high bandwidth capabilities, which is particularly
developed for mobile applications to obtain low pin count combined with very good power efficiency. It is
targeted to be suitable for multiple protocols, including UniProSM and DigRFSM v4, and for a wide range of
applications.
2 The M-PHY Specification features the following aspects:
3 • BURST mode operation for improved power efficiency
4 • Multiple transmission modes with different bit-signaling and clocking schemes intended for
different bandwidth ranges to enable better power efficiency over a huge range of data rates
5 • Multiple transmission speed ranges and rates per BURST mode to further scale bandwidth to
application needs, and for mitigation of interference problems. Rates for high-speed mode are
fixed, for low-speed modes they are flexible within ranges
6 • Multiple power saving modes, where power consumption can be traded-off against recovery time
7 • Symbol coding (8b10b) for spectral conditioning, clock recovery, and in-band control options for
both PHY and Protocol Layer.
8 • Clocking flexibility: designed to be able to operate with independent local reference clocks at
each side, but suitable to exploit the benefits of a shared reference clock
9 • Optical friendly: enables low-complexity electro-optical signal conversion and optical data
transport inside the interconnect between MODULEs
10 • Distance: optimized for short interconnect (<10 cm) but extendable to a meter with good quality
interconnect or even further with optical converters and optical waveguides.
11 • Configurability: differences in supported functionality (to reduce cost) and tune for best
performance (implementation) without hampering interoperability
1.1 Scope
12 This document specifies unidirectional LANEs and its individual parts, as building blocks for composition of
a dual-simplex LINK by application protocols. An M-PHY implementation allows one or more LANEs in
each direction, allows differences in optional funtionality between LANEs, allows different momentary
operating modes between LANEs, and allows asymmetry in amount of LANEs and LANE properties for the
two directions of the dual-simplex LINK. Protocols applying M-PHY technology may have different LANE
constraints, and choose different operation control, or data striping and merging solutions. Therefore, this
document provides the features to enable LINK composition, but does not specify how multiple transmitters
and receivers are combined into a PHY-unit for a certain LINK composition. Each LANE has its own
interface to the Protocol Layer.
13 A MODULE can disclose its capabilities, and contains several configurable parameters in order to allow
differentiation on supported functionality and tune for best performance without hampering interoperability.
Therefore, protocols need to support some configuration mechanism to determine and define the operational
settings. Most flexible is an auto-discovery negotiation protocol to determine the commonly-supported
settings of the Physical Layer which are most desirable for running the application. M-PHY supports this, but
does not include the configuration protocol itself. Alternatively, the protocol may directly program the
required settings if there is predetermined higher system knowledge about which MODULEs are present at
both ends of that LINK.
14 The M-PHY specification shall always be used in combination with a higher layer MIPI specification that
references this specification. Any other use of the M-PHY specification is strictly prohibited, unless
approved in advance by the MIPI Board of Directors.
Copyright © 2008-2017 MIPI Alliance, Inc. 1

Confidential
01-Dec-2016
1.2 Purpose
15 Mobile devices face increasing bandwidth demands for each of its functions as well as an increase of the
number of functions integrated into the system. This requires wide bandwidth, low-pin count (serial) and
highly power-efficient (network) interfaces that provides sufficient flexibility to be attractive for multiple
applications, but which can also be covered with one physical layer technology. M-PHY is the successor of
D-PHY, requiring less pins and providing more bandwidth per pin (pair) with improved power efficiency.
2 Copyright © 2008-2017 MIPI Alliance, Inc.

Confidential
01-Dec-2016
2 Terminology
16 The MIPI Alliance has adopted Section 13.1 of the IEEE Specifications Style Manual, which dictates use of
the words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:
17 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).
18 The use of the word must is deprecated and shall not be used when stating mandatory
requirements; must is used only to describe unavoidable situations.
19 The use of the word will is deprecated and shall not be used when stating mandatory
requirements; will is only used in statements of fact.
20 The word should is used to indicate that among several possibilities one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of
action is preferred but not necessarily required; or that (in the negative form) a certain
course of action is deprecated but not prohibited (should equals is recommended that).
21 The word may is used to indicate a course of action permissible within the limits of the
Specification (may equals is permitted).
22 The word can is used for statements of possibility and capability, whether material,
physical, or causal (can equals is able to).
23 All sections are normative, unless they are explicitly indicated to be informative.
2.1 Definitions
24 ACTIVATED The combined states within HS-MODE or LS-MODE.
25 BURST Sequence of 8b10b encoded data transmission delimited by and including a HEAD-OF-BURST
and TAIL-OF-BURST.
26 COMMA Non-data symbol which can not be found at any bit position within any combination of other
valid symbols.
27 CRPAT Compliant Random Pattern, see [CTS01].
28 CJTPAT Compliant Jitter Tolerance Pattern, see [CTS01].
29 DIF-N Logical LINE state, driven by the M-TX, corresponding with a negative differential LINE
voltage. Voltage levels and signal transition timing specifications for the M-TX as well as
detection requirements for the M-RX are defined in Section 5.
30 DIF-P Logical LINE state, driven by the M-TX, corresponding with a positive differential LINE
voltage. Voltage levels and signal transition timing specifications for the M-TX as well as
detection requirement for the M-RX are defined in Section 5.
31 DIF-Q LINE state when the M-RX can be high-impedance resulting in undriven lines with an
undefined LINE state.
32 DIF-X Indication that LINE state can be either DIF-P or DIF-N, but nothing else.
33 DIF-Z Logical LINE state, driven by the M-RX, corresponding with almost zero differential LINE
voltage. Voltage levels and signal transition timing specifications for M-TX and M-RX are
defined in Section 5.
34 DISABLED MODULE state when the MODULE is powered, but not enabled.
35 FILLER Non-data symbol(s) inserted when no data is provided by the protocol during a BURST.

Confidential
01-Dec-2016
36 FLAG Control signal that indicates the occurrence of a certain event.

37 FRAME Series of symbols separated by MARKERs.
38 GEAR Speed range (PWM) or fixed RATEs (HS) of communication in LS or HS mode. Each HS
GEAR includes two RATEs which differ about 15% for mitigation of EMI.
39 HEAD-OF-BURST Period between exiting STALL state or SLEEP state and the first MARKER0 in a
BURST, indicating start of PAYLOAD data.
40 HIBERN8 Deepest low-power state without loss of configuration information.
41 HS-BURST High speed state including PREPARE, SYNC, MARKERs, and data.
42 HS-GEAR GEAR in HS-MODE.
43 HS-MODE High-Speed operation loop consisting of STALL and HS-BURST.
44 LANE A LANE is a unidirectional, point-to-point, differential serial connection, consisting of an
M-PHY transmit MODULE (M-TX), an M-PHY receive MODULE (M-RX), and a LINE.
45 LINE Differential point-to-point interconnect between the PINs of M-TX and M-RX. The
interconnect may include optical media converters and optical waveguide.
46 LINE-CFG Sub-state machine to exchange configuration parameters with Media Converters
47 LINE-INIT LINE-CFG sub-state before transmission of an LCC.
48 LINE-RESET Reset via the LINE by means of the exceptional signal condition of a long DIF-P.
49 LINK One or more PHY LANEs in each direction plus an additional LANE management layer that
provides a bidirectional data transport means, agnostic to the actual LANE composition.
50 LS-BURST Low speed state including PREPARE, MARKERs, and data.
51 LS-MODE Type-I: Combination of SLEEP, PWM-BURST, INIT, and LINE-CFG states.
Type-II: Combination of SLEEP and SYS-BURST states.
52 MARKER Non-data symbol, used for protocol related control purposes.
53 MODE Indicates either HS-MODE or LS-MODE.
54 MODULE Indication for either an M-TX or M-RX.
55 M-PORT Combination of MODULEs at one side of a LINK.
56 PAYLOAD BURST without HOB and TOB. PAYLOAD may consist of multiple FRAMEs.
57 PIN A point of external physical electrical connection for a component. Examples of a “PIN” may
include (but are not limited to) a BGA ball, QFP lead, or solder pad.
58 POWERED Any LANE or MODULE state when power supply is available.
59 PREPARE First part of the HOB after exiting STALL or SLEEP up to but not including the SYNC
sequence.
60 PWM Bit modulation scheme carrying the data information in the duty-cycle, and explicit clock
information in the period.
61 PWM-BURST Transmission of an LS-BURST in pulse-width modulated bit format and using 8b10b coding.
62 RATE Exact speed of communication in a certain mode in kbps, Mbps, or Gbps.
63 SAVE Set of power saving states STALL, SLEEP, HIBERN8, DISABLED, and UNPOWERED.
64 SLEEP Power saving state used between LS-BURSTs.

Confidential
01-Dec-2016
65 STALL Power saving state between HS-BURSTs with fast recovery time.
66 SUB-LINK All LANEs in the same direction as a fraction of a LINK.
67 SYMBOL-INTERVAL 10-bit period for the transmission of one symbol. SYMBOL-INTERVAL scales with
data rate.
68 SYNC An 8b10b symbol sequence with high edge-density intended for fast phase alignment.
69 SYS-BURST Transmission of an LS-BURST synchronous at the SysClk rate. Only possible for shared
SysClk applications.
70 TAIL-OF-BURST Run-length violating constant bit sequence used to return a MODULE to a SAVE state, or
a LINE-CFG state when applicable.
71 UNIT-INTERVAL Nominal length of one bit.
72 UNPOWERED MODULE state when the power supply is removed.
2.2 Abbreviations
73 e.g. For example (Latin: exempli gratia)
74 i.e. That is (Latin: id est)
2.3 Acronyms
75 b0, b1 Bit with logical value “0” or “1”, respectively. The signaling format depends on operating
MODE. A prefix indicating the MODE is occasionally used for clarification, e.g. PWM-b0.
76 CFG Configuration
77 EMI Electromagnetic Interference
78 FLR FILLER symbol
79 FSM Finite State Machine
80 HOB HEAD-OF-BURST
81 HS High-Speed
82 LCC LINE Control Command
83 LS Low-Speed
84 LSb Least Significant bit
85 MC Media Converter
86 MC-RX Media Converter Receiver
87 MC-TX Media Converter Transmitter
88 MIB Management Information Base
89 MK# Short indicator for MARKER symbols
90 MSb Most Significant bit
91 M-RX M-PHY electrical Receiver
92 M-TX M-PHY electrical Transmitter
93 NRZ Non-Return-to-Zero

Confidential
01-Dec-2016
94 O-RX Optical Receiver

95 O-TX Optical Transmitter
96 PIF Protocol InterFace
97 PWM Pulse-Width-Modulation
98 RCT Re-Configuration Trigger
99 RD Running Disparity
100 RMMI Reference M-PHY MODULE Interface
101 SAP Service Access Point (defining interactions with Protocol Layer)
102 SECDED Single Error Correction, Double Error Detection
103 SI Symbol Interval
104 SYS System-clock Synchronous
105 TOB TAIL-OF-BURST
106 UI Unit Interval

Confidential
01-Dec-2016
3 References
107 [IBM01] Widmer, A. X.; Franaszek, P. A., “A DC-Balanced, Partitioned-Block, 8B/ 10B
Transmission Code”, IBM Journal of Research. Development, VOL. 27, NO. 5,
September 1983.
108 [INC01] INCITS/TR-35:2004, Fibre Channel – Methodologies for Jitter and Signal Quality
Specification – MJSQ, Working Draft, T11.2/ Project 1316-DT/ Rev 14.1,
<http://www.t11.org>, InterNational Committee for Information Technology Standards,
5 June 2005.
109 [ITUT01] ITU-T Recommendation O.150, Specifications of measuring equipment - Equipment for
the measurement of digital and analogue/digital parameters - General requirements for
instrumentation for performance measurements on digital transmission equipment,
<http://www.itu.int/rec/T-REC-O/en>, International Telecommunication Union, 5 October
1992.
110 [MIPI01] MIPI Alliance Specification for Device Descriptor Block (DDB), version 1.0, MIPI
Alliance, Inc., 30 October 2008.
111 [CTS01] M-PHY Physical Layer Conformance Test Suite, Version 1.00, MIPI Alliance, Inc.,
14 May 2013.

Confidential
01-Dec-2016

Confidential
01-Dec-2016
4 Architecture and Operation

112 This section specifies the concept, communication principles, signaling schemes, interface structure and
operation of M-PHY interfaces.
4.1 PIN, LINE, LANE, SUB-LINK, LINK, and M-PORT

113 A LANE is a unidirectional, single-signal, physical transmission channel used to transport information from
point A to point B. A LANE consists of an M-PHY transmit MODULE (M-TX), an M-PHY receive
MODULE (M-RX), and a LINE, which is the point-to-point interconnect between the M-TX and M-RX. An
M-TX or M-RX has only one differential electrical output or input LINE interface, respectively, which
corresponds with two signaling PINs for each MODULE. The PINs are individually denoted as DP and DN,
where DP is defined as the positive node of the differential signal. An optional prefix, TX or RX, can be used
to indicate the M-TX or M-RX PINs, respectively. Specifications in this document are defined at the PINs of
the M-TX and M-RX, and PINs-to-PINs through the LINE. Figure 1 illustrates the relationship between
different parts of an M-PHY LINK.
LINK
SUB-LINK
M-PORT
LANE
PINs
TXDP LINE RXDP
M-TX PIF M-TX M-RX M-RX PIF
TXDN RXDN
PINs
LANE MANAGEMENT
LANE MANAGEMENT
PINs
TXDP LINE RXDP
M-TX PIF M-TX M-RX M-RX PIF
TXDN RXDN
PINs
PINs
RXDP LINE TXDP
M-RX PIF M-RX M-TX M-TX PIF
RXDN TXDN
PINs
LANE
M-PORT
SUB-LINK
LINK
Figure 1 M-PHY Lane Example
114 In the case of a galvanic interconnect, the LINE consists of two differentially-routed wires connecting the
LINE interface PINs of the M-TX and M-RX. Typically, these wires are transmission lines. Guidelines for
LINE characteristics are described in Section 6. A LINE may contain converters to other transmission media,
such as optical fiber. For data transfer purposes, such a LINE might be considered as a black box with
end-to-end signal transfer requirements defined at the PINs. Additionally, for advanced configuration
functions interaction between MODULEs and Media Converters is supported. Figure 2 shows the setup of a
LANE with Media-Converters (MC-TX and MC-RX) in the LINE.

Confidential
01-Dec-2016
LANE
LINE (blackbox)
transport media
M-TX MC-TX MC-RX M-RX
PINs PINs
Figure 2 Example LANE Configuration with Media Converter
115 An interface based on M-PHY technology shall contain at least one LANE in each direction. There are no
symmetry requirements from an M-PHY perspective for the number of LANEs in each direction.
116 All LANEs in the same direction within a LINK are denoted as a SUB-LINK. Two SUB-LINKs with
opposite directions plus additional LANE management, which provides bidirectional data transport
functionality agnostic to the actual LANE composition, is called a LINK. A set of M-TXs and M-RXs in a
device that compose one interface port is denoted as an M-PORT.
117 This document specifies LANEs and their individual parts including M-TX, M-RX, interconnect, and
optionally Media Converters. Furthermore, this specification sets some boundary conditions for M-TX and
M-RX inside a single M-PORT, which puts some constraints for the usage of LANEs within SUB-LINKs.
This document does not specify the LANE management function in order to allow maximum flexibility of
LANE exploitation by protocols. Therefore, the composition of LANEs in the two SUB-LINKs and the
specification of LANE management, which completes the LINK, is left to protocols applying M-PHY
technology.
4.2 LINE States

118 M-PHY technology exploits only differential signaling. a LINE can show the following states:
119 • A positive differential voltage, driven by the M-TX, which is denoted by LINE state DIF-P
120 • A negative differential voltage, driven by the M-TX, which is denoted by LINE state DIF-N
121 • A weak zero differential voltage, maintained by M-RX, which is denoted by LINE state DIF-Z
122 • An unknown, floating LINE voltage, or no LINE drive, which is denoted by LINE state DIF-Q
123 Table 1 list all possible LINE conditions with the resulting LINE state
Table 1 LINE Conditions and Resulting LINE States

Differential LINE M-TX Output M-RX Input LINE State
LINE State Name
Voltage Impedance Impedance Set by
Positive Low Any M-TX DIF-P
Negative Low Any M-TX DIF-N
Zero High Medium M-RX DIF-Z
Unknown or floating High High None DIF-Q
124 For data transmission, only DIF-P and DIF-N are exploited. DIF-Z can only occur during power-up and
power-saving states.
125 The transition point between DIF-Z and DIF-N is defined by the squelch threshold level, which is positioned
between the DIF-N and DIF-Z electrical LINE levels (Section 5.2.5).The transition point between DIF-P and
DIF-N is defined at the zero crossing of the differential signal.

Confidential
01-Dec-2016
4.2.1 Termination Scheme

126 An M-TX shall terminate both wires in the LINE with a characteristic impedance RSE_TX during any DIF-P
or DIF-N state, both differentially as well as common-mode with respect to ground. The M-TX can have a
larger resistance during SLEEP and STALL as described in Section 5.1.1.3 as RSE_PO_TX.
127 An M-RX does not always terminate the LINE, but certain options such as HS-MODE require support for
terminated operation. Therefore, an M-RX including these options shall include a switchable differential
LINE termination.
128 The M-RX termination condition are optionally indicated in the electrical parameter and LINE state name by
a subscript RT (Resistively Terminated) or NT (Not Terminated). For example, DIF-PRT is a DIF-P state with
receiver termination enabled.
129 Figure 3 shows an example of a LINE termination scheme. The electrical characteristics of LINE states and
terminations are specified in Section 5.
RSE_TX
Amplifier
VLD Line
RSE_TX
Detector
RHOLD RDIFF_RX/2 RDIFF_RX/2 RHOLD
Figure 3 Example I/O Termination
4.2.2 Signal Amplitudes

130 All communication is based on low-swing, DC-coupled, differential signaling. The LINE driver in an M-TX
may support two drive strengths, Large Amplitude (LA) and Small Amplitude (SA), resulting in different
signal amplitudes. Detailed electrical level specifications are provided in Section 5. Drivers can support
either one of these two, or both, amplitudes. If both amplitudes are supported, Large Amplitude shall be the
default configuration setting. An M-RX is able to receive both amplitudes if an appropriate interconnect is
used according to the guidelines in Section 6. Signal amplitudes are optionally indicated in parameter names
by an “LA” or an “SA” subscript.
4.3 Signaling Schemes

131 M-PHY technology exploits two different signaling schemes for transmission of bits, which are conceptually
described in the following sections. Detailed parameter value specifications are provided in Section 5.

Confidential
01-Dec-2016
4.3.1 Non-Return-to-Zero (NRZ)

132 For NRZ, each bit is represented by a period of either DIF-P or DIF-N, corresponding to a binary one or a
binary zero, respectively. All bits are directly concatenated and have equal length.
4.3.2 Pulse Width Modulation

133 The Pulse Width Modulation (PWM) scheme has self-clocking properties. Each bit consists of a combination
of two sub-phases, a DIF-N followed by a DIF-P. One of the two sub-phases is longer than the other:
TPWM_MAJOR > TPWM_MINOR, depending upon whether a binary one, or binary zero is being sent. The binary
information is in the ratio of the duration of the DIF-N and DIF-P states. If the LINE state is DIF-P for the
majority of the bit period, the bit is a binary one (PWM-b1). If the LINE state is DIF-N for the majority of the
bit period, the bit is a binary zero (PWM-b0).
134 Each bit period contains two edges, where the falling edge is at a fixed position and the rising edge position is
modulated. This means that the PWM bit stream explicitly contains a bit clock with period TPWM, which
equals the duration of one bit. TPWM may vary from bit to bit during a transmission within the limits specified
in Section 5. The bit waveforms for this signaling technique are shown in Figure 4.
,
TPWM_MINOR TPWM_MAJOR
(DIF-N) (DIF-P)
PWM-b1
TDIF-P > TDIF-N
PWM-b0
TDIF-P < TDIF-N
TPWM_MAJOR TPWM_MINOR
(DIF-N) (DIF-P)
1 0 0 1 1 1 0 1 1 0
Figure 4 PWM Bit Waveforms and Bit Stream Example
135 M-PHY technology utilizes PWM signaling with FIXED-RATIO and FIXED-MINOR format. For the
FIXED-RATIO format, the durations of TPWM_MAJOR and TPWM_MINOR are ideally two-thirds and one-third
of the bit period, respectively. For the FIXED-MINOR format, the duration of TPWM_MINOR is specified as
an absolute time duration, while TPWM_MAJOR scales with the bit period. The latter format is utilized for very
low data rates (PWM-G0).
4.4 Overview of Concept, Features, and Options

136 This document encompasses the full specification of LANEs, including transmitters (M-TX) and receivers
(M-RX), and interconnect (LINE), to support the required set of data transmission, power saving, and control
states. Furthermore, this document defines some constraints on options and operation between transmitter
and receiver MODULEs within a single M-PORT.

Confidential
01-Dec-2016
137 A MODULE is specified by the characteristics that can be observed on its PINs. Therefore, M-TX and M-RX
operation is fully characterized by the sequence of LINE states. All allowed sequences of LINE states are
structured into MODULE states and modes, which are specified by means of state machines in subsequent
sections. Detailed electrical characteristics of a MODULE are covered in Section 5.
138 Data transfer occurs in BURSTs, which can be either in High-Speed mode (HS-MODE) or Low-Speed mode
(LS-MODE).
139 There are two fundamentally different types of MODULEs, denoted as Type-I and Type-II, depending on the
signaling scheme used in LS-MODE. A Type-I MODULE employs PWM signaling, while a Type-II
MODULE uses system-clock synchronous, NRZ signaling (denoted by “SYS”). This implies differences in
the sequence of LINE states and state machines for an M-TX and an M-RX, as well as in the LINE
performance constraints. Therefore, PWM and SYS signaling are mutually exclusive, and only one of the two
signaling schemes shall be selected for an application. Note that a Type-II MODULE requires a shared
reference clock between the two ends of the LINE. A Type-I MODULE shall be able to operate with
independent local clock references on each side of the LINK (plesiochronous operation). Although a Type-I
MODULE does not require a shared clock reference, it may exploit the benefits of a shared reference clock if
available. A LANE with Type-I MODULEs allows for media converters in the LINE. Note that Type-I and
Type-II MODULEs are not interoperable. However, implementations may support both types of MODULEs
in order to enable hardware reuse.
140 All MODULEs in an M-PORT shall support LS-MODE, utilizing either the PWM or SYS signaling scheme
depending on the M-PORT type. For PWM signaling (Type-I), there are multiple GEARs to cover different
speed ranges. The default (mandatory) GEAR for Type-I is PWM-G1, ranging from 3 to 9 Mbps. There are
six GEARs with incremental 2x higher speed ranges (PWM-G2 to G7), and one GEAR below the default
speed range (PWM-G0).
141 MODULE functionality can be optionally expanded with HS-MODE. HS-MODE includes a default GEAR
(HS-G1) and three optional GEARs (HS-G2, HS-G3 and HS-G4) at incremental 2x higher rates. Each GEAR
includes two data rates for EMI mitigation reasons, e.g. HS-G1 supports 1.25 Gbps and 1.45 Gbps. For the
two M-PORT types, HS-MODEs are functionally equal, and very similar regarding signal specifications.
However, they might need to operate with different reference clock conditions (shared-clock versus
plesiochronous).
1
142 The HS unit interval is defined as UI HS = --------------- , where UIHS is the HS unit interval and DRHS is the high
DR HS
speed data rate.
143 Support for an optional GEAR in either HS-MODE or LS-MODE requires support for all GEARs below it,
down to the default GEAR of that mode. PWM-G0 is independently optional for a Type-I MODULE.
144 In the default configuration, M-RX shall terminate the LINE in HS-BURST and in all other states shall leave
the LINE unterminated. Optionally, HS-BURST may be operated without termination for selected GEARs,
while LS-BURST may be operated with termination for selected GEARs. Capabilities and settings for each
GEAR are handled by configuration, which is specified in Section 4.8. During power-saving states the M-RX
shall leave the LINE unterminated.
145 An M-TX can have two different drive strengths, which implies a large amplitude or a small amplitude on the
PINs. An M-TX shall support at least one of the two possible drive strengths. The drive strength setting holds
for all operating states simultaneously, so changing it adapts the signaling levels of all LINE states. An M-TX
that supports both drive strengths shall use Large Amplitude as the default setting.
146 The different options are depicted in Figure 5, where the selected set of options of every M-TX and M-RX
shall map onto a contingent part of the figure. The different types result in two option diagrams (and two state
machines) intended for different applications.
147 The functional options like supported modes, GEARs, and I/O settings shall be available for read-out in a
capability registry for configuration purposes. In combination with a configuration protocol of a higher level
specification, this enables interoperability between M-PORTs of the same type, while allowing operation up

Confidential
01-Dec-2016
to the highest commonly supported GEAR and the most optimal commonly supported settings. This
configuration process is conceptually specified in Section 4.8.1.
148 Besides functional options, there are also a number of programmable parameters. These parameters shall not
be mandated or defined at a fixed value by the protocol or application specifications. They are meant only for
design and performance optimizations. Examples of this are programmable Slew-Rate-Control for
HS-MODE and programmable timer intervals to optimize timing for actual LINE length, Media Converters,
and PHY hardware capabilities. The complete list of options and programmable parameters can be found in
Section 8.4.
M-PHY Type-I MODULE M-PHY Type-II MODULE
HS-4a/b (RT) HS-4a/b (RT)
HS-3a/b (RT) NT HS-3a/b (RT) NT
SYS (NT) RT
Type-I
Type-II
Baseline
Baseline
MODULE
PWM-0 (NT) RT MODULE
(NT)
(NT)
PWM-1 (NT) RT
PWM-2 (NT) RT
PWM-3 (NT) RT
PWM-4 (NT) RT
PWM-5 (NT) RT
NT = Not Terminated
PWM-6 (NT) RT RT = Resistively Terminated
PWM-7 (NT) RT
Figure 5 Functional Options for MODULEs in Type-I and Type-II M-PORTs
4.5 Line Coding

149 All information communicated inside BURST states shall be 8b10b encoded [IBM01] according to the data
and control symbols assignments prescribed in this section.
4.5.1 Data Symbols

150 The coding of each byte consist of a 5b6b and a 3b4b sub-block encoding. The bits in a data byte are indicated
by the capital letters HGFEDCBA. The five data bits “EDCBA” shall encode into a 6-bit sub-block “abcdei”,
according to Table 2. The three data bits “HGF” shall encode into the 4-bit sub-block “fghj”, according to
Table 3. For D.x.7 there is a Primary (D.x.P7) and an Alternate (D.x.A7) coding as shown in the table. The
Alternate encoding shall be selected if the Primary coding combined with the preceding 5b/6b code results in
five or more consecutive zeroes or ones. This implies that D.x.A7 shall only be used for x=17, x=18, and

Confidential
01-Dec-2016
x=20 when RD=-1 and for x=11, x=13, and x=14 when RD=+1. With x=23, x=27, x=29, and x=30, the
Alternate code represents the control symbol K.x.7. Any other x.A7 code cannot be used as it would result in
chances for misaligned comma sequences.
151 Several 5b and 3b sub-blocks have two complimentary encoded representations with opposite disparity. The
representation with the disparity sign opposite to the running disparity shall be applied for DC balance. For
more information on disparity control, see Section 4.5.3.1. For selection of the correct 3b4b sub-block
representation, the RD shall be evaluated including the preceding 5b6b sub-block, which is part of the same
symbol.
Table 2 5b6b Sub-Block Data Encoding

Input Data RD = -1 RD = +1 Input Data RD = -1 RD = +1
Symbol EDCBA abcdei Symbol EDCBA abcdei
D.00 00000 100111 011000 D.16 10000 011011 100100
D.01 00001 011101 100010 D.17 10001 100011
D.02 00010 101101 010010 D.18 10010 010011
D.03 00011 110001 D.19 10011 110010
D.04 00100 110101 001010 D.20 10100 001011
D.05 00101 101001 D.21 10101 101010
D.06 00110 011001 D.22 10110 011010
D.07 00111 111000 000111 D/K.23 10111 111010 000101
D.08 01000 111001 000110 D.24 11000 110011 001100
D.09 01001 100101 D.25 11001 100110
D.10 01010 010101 D.26 11010 010110
D.11 01011 110100 D/K.27 11011 110110 001001
D.12 01100 001101 D.28 11100 001110
D.13 01101 101100 K.28 11100 001111 110000
D.14 01110 011100 D/K.29 11101 101110 010001
D.15 01111 010111 101000 D/K.30 11110 011110 100001
D.31 11111 101011 010100
Table 3 3b4b Sub-Block Data Encoding

Input RD = -1 RD = +1 Input RD = -1 RD = +1
Symbol HGF fghj Symbol HGF fghj
D.x.0 000 1011 0100 K.x.0 000 1011 0100
1
D.x.1 001 1001 K.x.1 001 0110 1001
1
D.x.2 010 0101 K.x.2 010 1010 0101
D.x.3 011 1100 0011 K.x.3 011 1100 0011
D.x.4 100 1101 0010 K.x.4 100 1101 0010

Confidential
01-Dec-2016
Table 3 3b4b Sub-Block Data Encoding (continued)

Input RD = -1 RD = +1 Input RD = -1 RD = +1
Symbol HGF fghj Symbol HGF fghj
1
D.x.5 101 1010 K.x.5 101 0101 1010
1
D.x.6 110 0110 K.x.6 110 1001 0110
D.x.P7 111 1110 0001
D.x.A7 111 0111 1000 K.x.71 111 0111 1000
1. The alternate encoding for the K.x.y codes with disparity 0 allow for K.28.1, K.28.5, and K.28.7 to
be “comma” codes that contain a bit sequence that can't be found elsewhere in the data stream.
4.5.2 Control Symbols

152 Control symbols are special symbols that do not occur in the data symbol set, that can be used for embedded
control features during BURSTs. Table 4 lists all control symbols of the 8b10b code set. M-PHY technology
exploits four control symbols, namely K28.1, K28.3, K28.5, and K28.6. Their functions are briefly
mentioned in the table. Symbol K28.5 has comma properties, and shall be detected anywhere in the bitstream
for symbol alignment. Details on usage of symbols can be found in Section 4.7. An M-PORT shall not use a
reserved control symbol.
Table 4 Control Symbols

Input RD = -1 RD = +1
Name Function
Symbol HGF EDCBA abcdei fghj abcdei fghj
K.28.0 000 11100 001111 0100 110000 1011 Reserved
1
K.28.1 001 11100 001111 1001 110000 0110 FILLER NOP
K.28.2 010 11100 001111 0101 110000 1010 Reserved
Protocol
K.28.3 011 11100 001111 0011 110000 1100 MARKER1
Separator
K.28.4 100 11100 001111 0010 110000 1101 Reserved
HEAD-OF-BURST;
K.28.51 101 11100 001111 1010 110000 0101 MARKER0 Start-of-FRAME;
Symbol Alignment
K.28.6 110 11100 001111 0110 110000 1001 MARKER2 Protocol Separator
K.28.72 111 11100 001111 1000 110000 0111 Reserved
Defined in protocol
K.23.7 111 10111 111010 1000 000101 0111 MARKER3
specification
Defined in protocol
K.27.7 111 11011 110110 1000 001001 0111 MARKER4
specification
Defined in protocol
K.29.7 111 11101 101110 1000 010001 0111 MARKER5
specification
Defined in protocol
K.30.7 111 11110 011110 1000 100001 0111 MARKER6
specification

Confidential
01-Dec-2016
1. Within the control symbols, K.28.1, K.28.5 are comma symbols. Comma symbols are used for
synchronization (finding the alignment of the 8b and 10b codes within a bit-stream). K28.7 has also
comma properties, but sets constraints on the symbols around it. Because K.28.7 is not used, the
unique comma sequences 0011111 or 1100000 cannot be found at any bit position within any
combination of normal codes.
2. See note 1 for Table 3.
4.5.3 Running Disparity

153 The applied 8b10b transmission coding is a DC-balanced coding scheme. The Running-Disparity (RD) is the
disparity between the number of ones and zeroes in the proceeding part of the BURST, where each one is
counted as +1 and each zero is counted as -1. RD tracking is necessary for correct encoding in the M-TX and
error checking in the M-RX.
4.5.3.1 RD Characteristics and M-TX Coding Rules

154 In the absence of transmission errors, the RD stays within -3 and +3, while it always equals -1 or +1 at any of
the 6b and 4b sub-block boundaries. All sub-blocks have a disparity of 0, -2, or +2. Sub-blocks with non-zero
disparity have complementary representations with positive and negative disparity. In these cases, the
representation with the disparity polarity opposite to the RD shall be used such that RD changes from -1 to +1
or vice versa at sub-block boundaries, and accumulation of disparity cannot occur. The starting value of the
RD may be +1 or -1 for any BURST. The M-TX shall follow the RD rules for a BURST, from the first SYNC
symbol up to, and including, the last 8b10b symbol preceding TAIL-OF-BURST.
4.5.3.2 M-RX Disparity Handling

155 Although decoding 8b10b does not require RD information, it is useful for error checking purposes.
Therefore, the M-RX shall track the RD and flag per symbol to the protocol if an |RD|>1 condition is
observed at any sub-block boundary. An erroneous RD shall be clipped immediately to +1 or -1, which in
most cases corresponds to the correct value, such that the RD tracking is immediately capable of detecting
further RD errors in subsequent symbols (see Figure 6).
156 Normally, bit errors occur during bit synchronization, and the M-RX is not symbol synchronized until the
first MARKER0. Therefore, the M-RX shall not report RD errors during the HEAD-OF-BURST to the
protocol. The M-RX shall begin a new RD tracking sequence after receipt of a MARKER0 inside a BURST
D >= +2 (error)
D=0 D=0
D = +2 D > +2 (error)
RD = ? RD = +1
D = +2
D < -2 (error) D = -2
D = -2 RD = -1
RD = Running Disparity
D = Sub-Symbol Disparity D=0
D <= -2 (error)
Figure 6 Running Disparity (RD) State Diagram
4.5.4 Bit Order and Binary Value

157 Throughout this document, the chronology for serial binary sequences and timing diagrams is from left (first
in time) to right (last in time). Therefore, the notation for 8b10b symbols is “abcdeifghj”, where the “a” bit is
transmitted first. When 8b10b encoding is bypassed, the “j” bit is transmitted first.

Confidential
01-Dec-2016
158 The notation of binary data values is MSb to LSb when reading from left to right. Data bytes are therefore
indicated by “HGFEDCBA” where “H” is the MSb and “A” is the LSb. This notation is used for PAYLOAD
data bytes as well as for configuration parameter values. When 8b10b encoding is bypassed, LSb of
DataValue in M-LANE-SYMBOL.request is transmitted first.
159 Protocol shall enable 8b10b encoding/decoding for normal protocol operation. The protocol may bypass
8b10b encoding/decoding for testing purposes. The behavior of a MODULE whether to include PREPARE,
SYNC, TOB, or PIF is implementation specific when 8b10b encoding/decoding is bypassed.
4.6 State Machines

160 The two types of MODULEs result in two alternate state machines intended for different applications with
different application boundary conditions. M-PORTs of different type are not interoperable.
161 Both state machines allow for LS-MODE and HS-MODE operation, each including a BURST data
transmission and power saving state. Performance scalability can be achieved by use of these modes
combined with GEARs within modes.
162 The main differences between the two state machines are the following:
163 • Signaling scheme for LS-BURST (PWM versus SYS)
164 • Support for Media Converters (MC) in the LINE
165 • Assumptions about availability of auxiliary signals (e.g. reference clock, reset)
166 High level commonalities between the two state-machines are the following:
167 • LS-MODE for transmission in the Mbps speed range
168 • HS-MODE for transmission at Gbps rates
169 • Individual power saving states SLEEP and STALL in LS-MODE and HS-MODE, respectively
170 • Ultra-low power state HIBERN8
171 • LINE controlled state switching between BURSTs and its power saving state
172 • Protocol assisted configuration mechanism
173 Despite the high-level commonalities these aspects are not identical for the two MODULE types, and
sometimes not even similar, e.g. LS-MODE with PWM (Type-I) versus SYS (Type-II) signaling.
174 The state-machines in a LANE are similar for M-TX and M-RX, however the state transition conditions are
different from both perspectives. Therefore, separate state machines are provided for M-TX and M-RX.
4.6.1 State Machine for a Type-I MODULE

175 Specific features of a Type-I MODULE include the following:
176 • PWM self-clocked LS signaling
177 • Operation with independent local reference clocks; might benefit from shared reference clock if
available
178 • Fully embedded control within the LANE (additional auxiliary signals are not required)
179 • Support for Media Converters in the LINE
180 State machines for Type-I M-TX and M-RX are shown in Figure 7 and Figure 8, respectively, and explained
in the sections that follow.

Confidential
01-Dec-2016
DIF-P for  20 UIHS + TPWM_PREPARE (for configured PWM-GEAR and PREPARE_LENGTH)
HS-MODE DIF-N
DIF-P for
THS-PREPARE
STALL HS-BURST
RCT
DIF-N for 20 UIHS
RCT
9 PWM-b1
DIF-P to DIF-N
Transition at DIF-N for DIF-N
Completion of TACTIVATE DIF-P for
MODE-LCC RCT TPWM_PREPARE
LINE-CFG SLEEP PWM-BURST
(9 +10*N) PWM-b0 + PWM-b1

LS-MODE RCT
= State
Update of INLINE configuration
DIF-P = State with sub-FSM
settings during SLEEP or STALL HIBERN8
to DIF-N = Global State
after Re-Configuration Trigger (RCT)
transition = Power Saving (SAVE) State
after
DIF-Z = HS-MODE State
TLINE-RESET
= LS-MODE State (PWM)
RESET A = Special State
Completion = NRZ-LINE Condition
DISABLED LINE-RESET
= PWM-LINE Condition
= CONFIG Condition
Power RESET SAP DIF-P = Extra CONFIG Option

(without MC)
Supply Power Remote RESET
On Supply Command
Off
UNPOWERED POWERED ACTIVATED
Figure 7 State Diagram for Type-I M-TX

Confidential
01-Dec-2016
DIF-P for 9 to 20 UIHS + TPWM_PREPARE. Ready for LINE-CFG within that period (with respect to maximum allowed data rate in configured PWM -GEAR)
HS-MODE DIF-N
DIF-N to DIF-P
Transition
STALL HS-BURST
RCT
DIF-N for 9 to 20 UIHS
RCT
9 PWM-b1
DIF-P to DIF-N DIF-Z
Transition at DIF-N
to DIF-N DIF-N to DIF-P
Completion of Transition
MODE-LCC RCT Transition
(> 9 PWM-b0) + PWM-b1

LS-MODE RCT
= State
= State with sub-FSM
after Re-Configuration Trigger (RCT) DIF-P to DIF-N = Global State
Transition = Power Saving (SAVE) State
DIF-Z = HS-MODE State
= LS-MODE State (PWM)
RESET A = Special State
Completion = NRZ-LINE Condition
DISABLED LINE-RESET
= PWM-LINE Condition
= CONFIG Condition
Power RESET DIF-P = Extra CONFIG Option

(without MC)
Supply Power
On Supply DIF-P for TLINE-RESET-DETECT
Off
Figure 8 State Diagram for Type-I M-RX
4.6.2 State Machine for a Type-II MODULE

181 Specific features of a Type-II MODULE include the following:
182 • System-Clock-Synchronous LS signaling (SYS)
183 • Requires availability of a shared reference clock
184 • Partially embedded control within the LANE (some state transitions require additional auxiliary
control signals)
185 State machines for Type-II M-TX and M-RX are shown in Figure 9 and Figure 10, respectively, and
explained in the sections that follow.

Confidential
01-Dec-2016
HS-MODE DIF-N
DIF-P for
RCT THS_PREPARE
STALL HS-BURST
DIF-N for 20 UIHS
DIF-N for TACTIVATE RCT

(or) AUX
DIF-N LS-MODE
DIF-P for
TSYS_PREPARE
SLEEP SYS-BURST
RCT
DIF-N for > 10 UISYS
= State
settings during SLEEP or STALL HIBERN8 DIF-P to DIF-N
after Re-Configuration Trigger (RCT) Transition = Global State
after = Power Saving (SAVE) State
TLINE-RESET = HS-MODE State
= LS-MODE State (SYS)
Local RESET A = Special State
De-assertion
= LINE Condition
DISABLED LINE-RESET
= CONFIG / PIF Condition
Power Local RESET Assertion SAP DIF-P

Supply Power Remote RESET
On Supply Command
Off
Figure 9 State Diagram for Type-II M-TX

Confidential
01-Dec-2016
HS-MODE DIF-N
DIF-N to DIF-P
RCT Transition
STALL HS-BURST
DIF-N for 9 to 20 UIHS
DIF-Z to DIF-N RCT

Transition (or) AUX
DIF-N LS-MODE
DIF-N to DIF-P
Transition
SLEEP SYS-BURST
RCT
DIF-N for 10 UISYS
= State
after Re-Configuration Trigger (RCT) DIF-P to DIF-N = Global State
Transition = Power Saving (SAVE) State
= HS-MODE State
= LS-MODE State (SYS)
Local RESET A = Special State
De-assertion
= LINE Condition
DISABLED LINE-RESET
= CONFIG / PIF Condition
Power Local RESET Assertion DIF-P

Supply Power
On DIF-P for TLINE-RESET-DETECT
Supply
Off
Figure 10 State Diagram for Type-II M-RX
4.6.3 State Machine Structure and State Categories

186 Each state machine encompasses two operating modes, HS-MODE and LS-MODE, that include a data
transmission (BURST) state and a MODE-specific power saving (SAVE) state.
187 STALL is the SAVE state of HS-MODE, and SLEEP of LS-MODE. The BURST state of LS-MODE is
denoted as PWM-BURST for a Type-I MODULE, and SYS-BURST for a Type-II MODULE, in alignment
with the signaling scheme. LINE-CFG is an LS-MODE state for a Type-I MODULE only. Each mode has the
following states:
188 • HS-MODE: STALL, HS-BURST
189 • LS-MODE (Type-I MODULE): SLEEP, PWM-BURST, LINE-CFG
190 • LS-MODE (Type-II MODULE): SLEEP, SYS-BURST
191 Therefore, each state machine includes only two BURST states. A MODULE may support LS-MODE only.
BURST states for each MODULE type are as follows:
192 • PWM-BURST (Type-I MODULE only)
193 • SYS-BURST (Type-II MODULE only)
194 • HS-BURST (Type-I and Type-II MODULEs, optional)
195 BURST states and LINE-CFG contain sub-FSMs, which are specified in Section 4.7.2 and Section 4.7.4.2,
respectively.

Confidential
01-Dec-2016
196 Each state machine contains five SAVE states with a stationary LINE state. There is a specific SAVE state for
each operating MODE, an ultra-low power state (HIBERN8), and two system-controlled power saving states
for which the interface is no longer functional.
197 • STALL(HS-MODE)
198 • SLEEP(LS-MODE)
199 • HIBERN8(Ultra-low power state where configuration is retained)
200 • DISABLED(POWERED, but not enabled due to a Power-on Reset, or a local RESET via the
Protocol Interface (Type-II MODULE only))
201 • UNPOWERED(No power supply)
202 Furthermore, the following states are special purposes BREAK states:
203 • LINE-RESET(Embedded remote reset via the LINE)
204 • LINE-CFG(Configuration for Media Converters; Type-I MODULE only)
205 Finally, there are some global state names that are not additional unique states, but are aliases for a subset of
the states according to common characteristics.
206 The following names are global state names:
207 • POWERED (any state in the state machine, except UNPOWERED)
208 • ACTIVATED (all states within HS-MODE or LS-MODE taken together)
209 An M-RX state transition is triggered by either a LINE or Protocol Interface (PIF) event. A LINE event is
either a LINE state transition, LINE state sequence or a bit sequence in the applied signaling format. Some
trigger events are also conditional on configuration settings.
4.7 FSM State Descriptions

210 This section specifies the purpose and operation for each of the SAVE, BURST, and BREAK states.
4.7.1 SAVE States

211 This section specifies the five power-saving states, STALL, SLEEP, HIBERN8, DISABLED, and
UNPOWERED.
4.7.1.1 STALL
212 STALL is the power saving state in HS-MODE. STALL is mandatory for a MODULE that supports
HS-MODE. In this state, the M-RX shall not be terminated, while the M-TX shall drive DIF-N. This
ACTIVATED state is intended for power savings without a severe penalty on HS-BURST start-up time, in
order to enable fast and efficient BURST cycles. This state is exited to HS-BURST by a LINE transition to
DIF-P. Entering STALL can occur from HIBERN8, LINE-CFG, or SLEEP. The latter can only occur with an
RCT in the absence of Media Converters. See Section 4.7.1.3, Section 4.7.4.2, and Section 4.7.1.2,
respectively. A MODULE shall disclose, via a capability attribute, the minimum time it requires in STALL
prior to starting a new BURST. See Section 8.4.
213 The output resistance of the M-TX shall be RSE_TX until the end of the M-RX termination disable time.
Afterwards, the M-TX output resistance can be switched from RSE_TX to RSE_PO_TX. Leaving STALL state,
the M-TX output resistance shall be RSE_TX before the transition to DIF-P. See Section 5.1.1.3.
4.7.1.2 SLEEP
214 SLEEP is the power saving state of LS-MODE. SLEEP is mandatory for a MODULE. The M-RX shall not be
terminated, and the M-TX shall drive DIF-N. This state allows the lowest power consumption of all
ACTIVATED states. This state is exited to LS-BURST by a LINE transition to DIF-P. Entering SLEEP can
occur from HIBERN8, LINE-CFG, LINE-RESET, or STALL. The latter can only occur with an RCT in the
absence of Media Converters. See Section 4.7.1.3, Section 4.7.4.2, Section 4.7.4.1, and Section 4.7.1.1,

Confidential
01-Dec-2016
respectively. A MODULE shall disclose to the protocol, via a capability attribute, the minimum time it
requires in SLEEP prior to starting a new BURST. See Section 8.4.
215 The output resistance of the M-TX shall be RSE_TX until the end of the M-RX termination disable time.
Afterwards, the M-TX output resistance can be switched from RSE_TX to RSE_PO_TX by evaluation of the
optional TX_Min_SLEEP_NoConfig_Time or TX_Min_STALL_NoConfig_Time configuration attributes.
Leaving SLEEP state, the M-TX output resistance shall be RSE_TX before the transition to DIF-P. See
Section 5.1.1.3.
4.7.1.3 HIBERN8
216 HIBERN8 state enables ultra-low power consumption, while maintaining the configuration settings. A
MODULE shall support HIBERN8. The M-TX shall be high-impedance in HIBERN8, while the M-RX shall
hold the LINE at DIF-Z. Under these conditions, the M-RX is considered to be in squelch. When entering
HIBERN8 from LS-MODE or HS-MODE, the Protocol Layer shall not request a MODULE exit HIBERN8
before a minimum period in HIBERN8 of T H I B E R N 8 , which is defined as the larger of local
TX_Hibern8Time_Capability and remote RX_Hibern8Time_Capability. If the local M-TX supports the
Advanced Granularity Capability, then THIBERN8 shall be calculated as described in Table 5. If the remote M-
RX supports for the Advanced Granularity Capability and the RX_Advanced_Hibern8Time_Capability is
smaller than the RX_Hibern8Time Capability, it shall be used for the calculation of THIBERN8 as shown in
Table 5.
217 Upon state transition from SLEEP/STALL to HIBERN8, the LINE state(s) before observing DIF-Z shall not
be interpreted as a HIBERN8 exit condition. For each LANE entering HIBERN8 from ACTIVATED, the
protocol shall ensure M-RX enters HIBERN8 before M-TX.
218 The local M-TX shall drive DIF-N for a period of TACTIVATE on exit of HIBERN8 with de-emphasis
disabled. The output resistance of the M-TX shall be RSE_TX during this period. TACTIVATE shall conform to
RX_Min_ActivateTime_Capability of the remote M-RX, if the Advanced Granularity Capability is not
supported. If the remote M-RX supports for the Advanced Granularity Capability and the
RX_Advanced_Min_ActivateTime_Capability is smaller than the RX_Min_ActivateTime_Capability, it
shall be used for the calculation of TACTIVATEas shown in Table 5. For embedded HIBERN8 exit control, the
M-RX needs to detect a non-squelch state for a LINE transition to DIF-N. A Type-I MODULE shall use
embedded HIBERN8 exit control. For a Type-II MODULE, HIBERN8 exit control can be embedded or,
alternatively, by use of auxiliary control signals. Note that squelch detection is only utilized in HIBERN8, so
this function can be disabled for all other states. A LANE MODULE becomes ACTIVATED on exit of
HIBERN8, and shall return to the power saving state of the configured operating mode and be ready for a
BURST within TACTIVATE.
THIBERN8 TACTIVATE
LINE
DIF-Z Ready for
DIF-N BURST
LINE-CFG End
SLEEP SLEEP or LS-BURST
FSM DISABLED
HIBERN8
State SLEEP
STALL STALL or HS-BURST
STALL
Entry to HIBERN8 from SLEEP or STALL only with RCT for Type-II, or Type-I in absence of a Media Converter
Figure 11 Entry and Exit of HIBERN8

Confidential
01-Dec-2016
219 Entering HIBERN8 can occur from LINE-CFG, STALL, SLEEP, and DISABLED states. Entry of HIBERN8
from LINE-CFG, STALL or SLEEP state is controlled via configuration (see Table 51). The mechanism is
specified in Section 4.7.4.2.4. Note that when requesting HIBERN8 from LINE-CFG, the LINE signal first
switches from DIF-P to DIF-N, which ends LINE-CFG and causes a Re-Configuration Trigger (RCT). An
RCT is an internally driven event that occurs after the end of LINE-CFG and initiates a transition to
HIBERN8 due to a previous configuration within the same BURST causing the LINE signal to switch from
DIF-N to DIF-Z. Therefore, HIBERN8 is always entered from a DIF-N LINE state. Entering HIBERN8 from
DISABLED does not typically happen simultaneously for the M-TX and the M-RX in a LANE because it
depends on independent timings of RESET signals on each side of the LANE. Signals and states before,
during, and after HIBERN8 state are illustrated in Figure 11.
220 When entering HIBERN8 is requested by an RCT immediately following a transition from a BURST state to
a SAVE state, additional timings apply. After issuing TOB, the M-TX shall drive the LINE with DIF-N for
THIBERN8_ENTER_TX. The M-RX shall begin driving the LINE to DIF-Z within THIBERN8_ENTER_RX after
detection of TOB.
Table 5 THIBERN8 and TACTIVATE Capabilities and Parameters

Attribute or Parameter Value Units
RX_Advanced_Granularity_Capability 4, 8, 16, 32 s
RX_Advanced_Hibern8Time_Capability 1 to 128 n/a
RX_Advanced_Min_ActivateTime_Cap
1 to 14 n/a
ability
RX_Min_ActivateTime_Capability 1 to 9 100 s
TX_Advanced_Granularity 1 to 15 n/a
TX_Advanced_Granularity_Capability 4, 8, 16, 32 s
TX_Advanced_Hibern8Time_Capability 1 to 128 n/a
TX_Min_ActivateTime 1 to 15 100 s

Confidential
01-Dec-2016
Table 5 THIBERN8 and TACTIVATE Capabilities and Parameters

IF (RX_Advanced_Granularity_Capability[0] = 1)
TACTIVATE_RX =
MIN(RX_Min_ActivateTime_Capability * 100,
RX_Advanced_Min_ActivateTime_Capability *
2(2'b10 + RX_Advanced_Granularity_Capability[2:1]))
ELSE
TACTIVATE_RX =
RX_Min_ActivateTime_Capability * 100
END
IF (OMC is not present)
TACTIVATE >= TACTIVATE_RX
TACTIVATE ELSE s
TACTIVATE >= TACTIVATE_RX + 100
END
Set TX_Min_ActivateTime or
TX_Advanced_Granularity such that TACTIVATE
condition holds true:
IF (TX_Advanced_Granularity_Step[0] = 1)
TACTIVATE = TX_Advanced_Granularity *
2(2'b10 + TX_Advanced_Granularity_Step[2:1])
ELSE
TACTIVATE = TX_Min_ActivateTime * 100
END
IF (RX_Advanced_Granularity_Capability[0] = 1)
THIBERN8_RX =
MIN(RX_Hibern8Time_Capability * 100,
RX_Advanced_Hibern8Time_Capability *
2(2'b10 + RX_Advanced_Granularity_Capability[2:1]))
ELSE
THIBERN8_RX = RX_Hibern8Time_Capability * 100
END
THIBERN8 IF (TX_Advanced_Granularity_Capability[0] = 1) s
THIBERN8_TX =
MIN(TX_Hibern8Time_Capability * 100,
TX_Advanced_Hibern8Time_Capability *
2(2'b10 + TX_Advanced_Granularity_Capability[2:1]))
ELSE
THIBERN8_TX = TX_Hibern8Time_Capability * 100
END
THIBERN8 >= MAX(THIBERN8_RX, THIBERN8_TX)
4.7.1.4 DISABLED
221 DISABLED is a POWERED state, while MODULE operation is disabled by a RESET signal. When
DISABLED, an M-TX shall be high impedance, and an M-RX shall keep the LINE at DIF-Z. All
configuration settings shall be reset to default values. LANE operation cannot be (re-)established via LINE
signaling. For a Type I state machine, entry into and exit from DISABLED state occurs with RESET, which is
typically a Power-on Reset (POR). For a Type II MODULE, entry and exit of DISABLED state are controlled
by asserting or de-asserting the local RESET with a POR signal or through the Protocol Interface.

Confidential
01-Dec-2016
4.7.1.5 UNPOWERED
222 UNPOWERED is the state of a MODULE when the power supply is withdrawn. Both M-TX and M-RX shall
be high-impedance while UNPOWERED. During UNPOWERED state the LINE level is undefined, except
that the LINE voltages shall not exceed the safe operation voltage window, VPIN. All configuration settings
are lost. During powering-up, a MODULE shall exit into DISABLED state on the assertion of a RESET
signal. This is typically a Power-on Reset signal.
4.7.1.5.1 Power-Up Cycle

223 When the power supply comes up on a MODULE, the RESET signal shall drive the MODULE into
DISABLED. This RESET is typically derived from the system POR. During power-up, until shortly after the
assertion of RESET, an M-TX may temporarily expose a lower impedance. However, a Type-I M-TX shall
not cause a differential level exceeding the squelch threshold until it drives a DIF-N to signal exit of
HIBERN8.
224 The LINE state becomes defined when the M-RX is POWERED and enters DISABLED state. In
DISABLED state the M-TX is high-impedance, while the M-RX pulls the LINE state to DIF-Z. A MODULE
remains DISABLED while the RESET signal is asserted. When the RESET signal is de-asserted following
power-up, the MODULE shall enter HIBERN8.
225 After Power On Reset, the M-TX enters HIBERN8. When the protocol changes the TX_HIBERN8_Control
value to “EXIT” and issues a M-CTRL-CFGREADY.request to validate the newly set value of
TX_HIBERN8_Control, the M-TX exits HIBERN8.
226 For a Type II MODULE, using a local RESET through the Protocol InterFace, the local RESET shall not be
de-asserted before the complementary LANE MODULE at the other side of the LINE has been DISABLED.
227 The procedure for a Type I MODULE to exit from HIBERN8 following power-up is illustrated in Figure 12
and Figure 13. Before starting a data BURST, the M-TX initiating exit from HIBERN8 drives a DIF-N, and
continues to drive DIF-N, until an M-RX of the same M-PORT detects DIF-N. Exit of HIBERN8 on the
remote side remains a decision of the remote Protocol Layer, but is triggered by detection of HIBERN8 exit
on the remote side M-RX. The remote M-RX in the initiating LANE shall not exit HIBERN8 until local
RESET is de-asserted, and the M-RX has transitioned from DISABLED to HIBERN8. Note that the
minimum THIBERN8 time does not apply for an M-RX following power-up. Detecting DIF-N on the local
M-RX indicates that both ends of the LINK are operational, and have exited HIBERN8. Boundary conditions
for multi-LANE behavior are provided in Section 4.9.

Confidential
01-Dec-2016
UNPOWERED DISABLED HIBERN8 SLEEP
M-TX
Local Power -on-Reset period
DIF-Q: High impedance output Drive DIF-N
M-RX:
case I
DIF-Q Local Power-on-Reset period Drive DIF-Z, sense for DIF -N Detect DIF-N
Ignore any input signal
M-RX:
case II
Drive DIF-Z,
DIF-Q Local Power-on-Reset period Detect DIF-N
sense for DIF-N

M-RX:
case III
‫ ﺫ‬/and
Ignore any input signal immediately
detect DIF-N
Local Power-on-Reset period
Drive DIF-Z
sense for DIF-N
UNPOWERED
DISABLED HIBERN8 SLEEP
M-RX:
case IV
‫ ﺫ‬/and
detect DIF-N
Drive DIF-Z
sense for DIF-N
Figure 12 LANE Power-up Cycle

Confidential
01-Dec-2016

LANE-A
M-TX1 M-RX2
M-TX1
M-RX1 M-TX2
DIF-Q High impedance output Drive DIF-N LANE-B
LANE-A
M-RX2
‫ ﺫ‬.and
detect DIF-N
Drive DIF-Z
sense for DIF-N

M-TX2
DIF-Q High impedance output Drive DIF-N

LANE-B
M-RX1
DIF-Q Local Power-on-Reset period Drive DIF-Z, sense for DIF-N Detect DIF-N
Figure 13 LINK Power-up Cycle
4.7.2 BURST States

228 Data transmission occurs in BURSTs with power saving states between BURSTs. BURSTs can be transferred
in HS-MODE or LS-MODE, HS-BURST in HS-MODE, and LS-BURST in LS-MODE. There are two
variants of LS-BURSTs depending on the applied signaling scheme, PWM-BURST for a Type-I MODULE,
and SYS-BURST for a Type-II MODULE. This section specifies the sequence of events during BURST
states.
229 The Min_SAVE_Config_Time_Capability attribute includes all implementation specific timings required to
prepare for the reception of the next BURST after configuration during SAVE. Each BURST starts from the
SAVE state for that operating mode, with a transition from DIF-N to DIF-P. After a period of DIF-P called
PREPARE, a sequence of 8b10b encoded symbols follows as specified in Section 4.7.2.1. After the last
8b10b SYMBOL of the BURST either a series of b0s or a series of b1s (TAIL-OF-BURST) is transmitted. A
series of equal bits violate 8b10b code characteristics, and indicates whether the M-RX returns to the SAVE
state of the current operating mode or enters LINE-CFG. In the case of PWM signaling, the last bit of the
sequence is inverted to indicate the end of LINE activity.
230 Each BURST state contains a sub-state machine that specifies the sequence of events during a BURST, which
is shown in Figure 14. There is much similarity between individual BURST states, but there are also distinct
differences due to the exploited signaling schemes, which are explained in the following sections.
231 The following sections specify the details of the BURST sub-state machine.

Confidential
01-Dec-2016
.
SAVE state: PREPARE SYNC First MARKER0 for PAYLOAD symbols: TAIL-OF-BURST
STALL or SLEEP LINE state: DIF-P; Any 8b10b data symbols with symbol synchronization, DATA & MK0, MKn; Function: Run length
LINE state: DIF-N; Function: request for BURST 7/10 edge density . Optional for RD initialization, FLR for Idling if no violation indicating a
Unconstrained length PWM-G6 and PWM-G7. and start of PAYLOAD TX data available change of state
Function: clock/bit
synchronization
Duration: 0 to 15 SI or 24+P SI
By default extended until MK0
ADAPT
Function: HS-RX equalizer
adaptation and clock /bit
synchronization
Duration: 650*(n+1) or 650*2n bits
HS-BURST
ADAPT
STALL PREPARE SYNC MK0

DIF-N DIF-P FLR
8b10b Encoded
DATA
MK0 TAIL-OF-BURST
PWM/SYS-BURST
MKn
SLEEP PREPARE
DIF-N DIF-P
= SAVE State xxx = 8b10b Encoded Symbol

= BURST (sub-)State xxx = Symbol for M-RX
= Optional State Transition xxx = Symbol for M-RX
xxx = Symbol for M-RX xxx = Symbol for Protocol
Figure 14 BURST-SAVE: Detailed Sub-FSM
4.7.2.1 PREPARE for BURST

232 PREPARE is the initial sub-state of BURST which allows settling of LINE levels and transceiver settings
before the bitstream is started. LINE state during PREPARE is DIF-P. If an M-RX is configured to terminate
the LINE during the BURST, the termination shall be enabled during PREPARE. Signal integrity shall be
maintained during any change of termination status. At the end of PREPARE, the LINE signals shall be
settled. The length of PREPARE is configurable and specified in Table 7. The length of PREPARE in the
local M-TX shall be greater than, or equal to the corresponding value of the remote M-RX parameters in the
appropriate MODE, i.e., THS_PREPARE in HS-MODE, TPWM_PREPARE in PWM-MODE and TSYS_PREPARE
in SYS-MODE. T P W M _ P R E PA R E of the local M-TX shall not exceed the minimum value of
TLINE-RESET-DETECT.
233 The PREPARE capabilities of the remote M-RX and the OMC in the LINE are used to configure the
PREPARE duration of the local M-TX using the following method:
234 IF (OMC is present)
235 M-TX LS_PREPARE_LENGTH >= MAX(RX_LS_PREPARE_LENGTH_capability,
236 MC_LS_PREPARE_LENGTH)
237 ELSE
238 M-TX LS_PREPARE_LENGTH >= RX_LS_PREPARE_LENGTH_capability
4.7.2.2 SYNC
239 For HS-MODE, the PREPARE sub-state period shall be followed by a SYNC sequence. For PWM-G6 and
PWM-G7 in LS-MODE, the PREPARE sub-state period may be followed by a SYNC sequence. The SYNC
sequence is intended for bit synchronization of the M-RX to the embedded clock data stream. The SYNC

Confidential
01-Dec-2016
sequence shall be a serialized subset of 8b10b data symbols with a high edge density for fast synchronization.
Therefore, only symbols with at least seven transitions inside the symbol (out of nine possible transitions)
shall be used for the SYNC sequence. Data symbols fulfilling this condition are listed in Table 6.
240 The SYNC sequence shall, by default, be generated by M-TX (TX_SYNC_Source = INTERNAL_SYNC),
but can be optionally configured to be provided by the protocol
(TX_SYNC_Source = EXTERNAL_SYNC). The default SYNC sequence shall be an alternating D10.5 and
D26.5 pattern that may start with either of the two symbols. A SYNC pattern provided by the protocol shall
only contain data symbols listed in Table 6. The SYNC sequence may start with RD of +1 or -1. However, for
DC-balance, the SYNC sequence shall be encoded according to Running Disparity rules.
Table 6 Valid Data Symbols for SYNC Sequence

RD = +1 RD = -1 Number of
Symbol Name HGFEDCBA
abcdeifghj abcdeifghj Transitions
D10.2 01001010 0101010101 0101010101 9

D21.5 10110101 1010101010 1010101010 9
D2.2 01000010 0100100101 1011010101 8
D4.2 01000100 0010100101 1101010101 8
D21.0 00010101 1010100100 1010101011 8
D21.4 10010101 1010100010 1010101101 8
D31.2 01011111 0101000101 1010110101 8
D5.2 01000101 1010010101 1010010101 8
D9.2 01001001 1001010101 1001010101 8
D10.5 10101010 0101011010 0101011010 8
D10.6 11001010 0101010110 0101010110 8
D21.1 00110101 1010101001 1010101001 8
D21.2 01010101 1010100101 1010100101 8
D22.5 10110110 0110101010 0110101010 8
D26.5 10111010 0101101010 0101101010 8
D1.2 01000001 1000100101 0111010101 7
D2.5 10100010 0100101010 1011011010 7
D2.6 11000010 0100100110 1011010110 7
D4.5 10100100 0010101010 1101011010 7
D4.6 11000100 0010100110 1101010110 7
D10.0 00001010 0101010100 0101011011 7
D10.4 10001010 0101010010 0101011101 7
D15.2 01001111 1010000101 0101110101 7
D16.2 01010000 1001000101 0110110101 7
D21.7 11110101 1010100001 1010101110 7
D22.0 00010110 0110100100 0110101011 7

Confidential
01-Dec-2016
Table 6 Valid Data Symbols for SYNC Sequence (continued)

RD = +1 RD = -1 Number of
Symbol Name HGFEDCBA
abcdeifghj abcdeifghj Transitions
D22.4 10010110 0110100010 0110101101 7

D23.5 10110111 0001011010 1110101010 7
D26.0 00011010 0101100100 0101101011 7
D26.4 10011010 0101100010 0101101101 7
D27.5 10111011 0010011010 1101101010 7
D29.5 10111101 0100011010 1011101010 7
D31.5 10111111 0101001010 1010111010 7
D31.6 11011111 0101000110 1010110110 7
D2.0 00000010 0100101011 1011010100 7
D2.4 10000010 0100101101 1011010010 7
D4.0 00000100 0010101011 1101010100 7
D4.4 10000100 0010101101 1101010010 7
D5.5 10100101 1010011010 1010011010 7
D5.6 11000101 1010010110 1010010110 7
D6.2 01000110 0110010101 0110010101 7
D9.5 10101001 1001011010 1001011010 7
D9.6 11001001 1001010110 1001010110 7
D10.1 00101010 0101011001 0101011001 7
D11.5 10101011 1101001010 1101001010 7
D12.2 01001100 0011010101 0011010101 7
D13.5 10101101 1011001010 1011001010 7
D18.2 01010010 0100110101 0100110101 7
D19.5 10110011 1100101010 1100101010 7
D20.2 01010100 0010110101 0010110101 7
D21.3 01110101 1010100011 1010101100 7
D21.6 11010101 1010100110 1010100110 7
D22.1 00110110 0110101001 0110101001 7
D22.2 01010110 0110100101 0110100101 7
D25.5 10111001 1001101010 1001101010 7
D26.1 00111010 0101101001 0101101001 7
D26.2 01011010 0101100101 0101100101 7
D31.0 00011111 0101001011 1010110100 7
D31.4 10011111 0101001101 1010110010 7

Confidential
01-Dec-2016
241 The SYNC sequence has a minimum duration, TSYNC, that is configurable in order to accommodate different
application conditions as shown in Table 7.
242 The TSYNC attributes of the remote M-RX and OMC are added to configure the SYNC duration of the local
M-TX using the following method:
243 IF (OMC is present)
244 Calculate TSYNC for M-RX (called TSYNC_M-RX) as shown in Table 7 by replacing SYNC_range with
245 M-RX SYNC_range, and SYNC_length with M-RX SYNC_length. Also calculate TMC_HS_START_TIME
246 as shown in Table 7.
247 TSYNC_M-TX = TSYNC_M-RX + TMC_HS_START_TIME
248 IF TSYNC_M-TX < 16
249 M-TX SYNC_range = 0 (Fine)
250 M-TX SYNC_length = TSYNC_M-TX
251 ELSE
252 M-TX SYNC_range = 1 (Coarse)
253 M-TX SYNC_length = CEILING(LOG2(TSYNC_M-TX))
254 END
255 ELSE (If no OMC is present)
256 M-TX SYNC_range = M-RX SYNC_range
257 M-TX SYNC_length = M-RX SYNC_length
258 END
Table 7 PREPARE, SYNC, and ADAPT Attribute and Dependent Parameter Values
HS_PREPARE_LENGTH 0 to 15 n/a
THS_PREPARE HS_PREPARE_LENGTH*2(GEAR – 1) SI
LS_PREPARE_LENGTH 0 to 15 n/a
TPWM_PREPARE_calc = MAX(
2(M-TX LS_PREPARE_LENGTH + GEAR – 7),1)
TPWM_PREPARE SI
TPWM_PREPARE = MIN(TPWM_PREPARE_calc, MIN(TLINE-RESET-
DETECT))
TSYS_PREPARE LS_PREPARE_LENGTH SI
SYNC_length 0 to 15 n/a
SYNC_range 0 to 1 n/a
IF (SYNC_range = FINE)
TSYNC = SYNC_length
ELSE (IF SYNC_range = COARSE)
IF(M-RX OR OMC)
TSYNC TSYNC = MIN(2SYNC_length, 214) SI
ELSE
TSYNC = 2SYNC_length
END
END
ADAPT_length 0 to 127 n/a
ADAPT_type 0 to 1 n/a

Confidential
01-Dec-2016
Table 7 PREPARE, SYNC, and ADAPT Attribute and Dependent Parameter Values
IF (ADAPT_type = FINE)
TADAPT = 650 * (ADAPT_length + 1)
ELSE (IF ADAPT_type = COARSE)
TADAPT bit
TADAPT = 650 * 2ADAPT_length,
where ADAPT_length < 18
END
IF (MC_HS_START_TIME_Range_Capability = FINE)
TMC_HS_START_TIME = MC_HS_START_TIME_Var_Capability
TMC_HS_START_TIME ELSE (IF MC_HS_START_TIME_Range_Capability = COARSE) SI
TMC_HS_START_TIME = MIN(2MC_HS_START_TIME_Var_Capability, 214)
END
259 In HS-BURST or PWM-BURST for PWM-G6 and PWM-G7, the SYNC sequence is followed by
PAYLOAD that shall start with a MARKER0 (MK0). The Protocol Layer can request transmission of
MARKER0 if 8b10b encoding is enabled. If transmission of MARKER0 is not requested before the
configured SYNC length expires, and 8b10b encoding is enabled, the SYNC sequence shall be extended until
the Protocol Layer requests transmission of MARKER0. SYS-BURST, and PWM-BURST for PWM-G0
through PWM-G5, do not include SYNC.
4.7.2.3 ADAPT
260 If an M-RX supports ADAPT, the PREPARE sub-state may be followed by the ADAPT sub-state for HS-G4.
The ADAPT sub-state is intended for the M-RX equalizer training to adapt to the channel characteristic,
when receiving an HS data stream. The ADAPT sequence shall start with an MK0 followed by an 8b10b
encoded PRBS9 pattern completed by one b0 bit. Adding this bit enables complete encoding of the ADAPT
sequence. The PRBS9 pattern is generated in the M-TX by a linear feedback shift register with feedback on
the 5th and 9th taps as described by [ITUT01]. The 8b10b encoded ADAPT sequence repeats every 650 bits.
The ADAPT sub-state ends with the transmission of a TAIL-OF-BURST, upon which the M-RX and M-TX
shall return to the STALL state.
261 The ADAPT sequence has a duration, TADAPT, that is configurable to accommodate different application
conditions, as shown in Table 7. The ADAPT duration of an M-TX TADAPT is set according to the remote M-
RX capabilities RX_HS_ADAPT_INITIAL_Capability and RX_HS_ADAPT_REFRESH_Capability.
These capabilities describe the length for an Initial ADAPT after power-up and for a shorter Refresh ADAPT
sequence during LINK operation, respectively. An M-RX shall store the equalizer settings in HIBERN8 and
during Line Reset. A protocol can initiate ADAPT upon HIBERN8 exit or after Line Reset.
262 An M-RX shall complete its training in the ADAPT sub-state within an ADAPT duration of TADAPT
signalled from the M-TX. An M-RX shall be able to detect the TOB at the end of ADAPT, but shall not
interpret any part of the ADAPT sequence as TOB. The protocol shall set TADAPT of an M-TX to fulfil the
remote M-RX requirements. A protocol should be able to set TADAPT of an M-TX also to larger values. The
beginning of the M-TX and remote M-RX ADAPT sub-states can be misaligned. The M-TX and remote M-
RX FSMs are aligned at STALL entry through TOB detection.
263 The ADAPT sub-state ends by returning to the STALL state. The remote M-RX can track RD but it shall not
propagate errors during ADAPT. MODULEs can use TADAPT timers to time the end of ADAPT. When
exiting the ADAPT sub-state to the STALL state, the TOB may be followed by an RCT1.
264 Figure 15 shows an example of an ADAPT operation. The duration of TADAPT is defined to start from the
first MK0 up to the beginning of the TOB.
1. A configuration change affecting the signalling may need to be followed by another ADAPT sequence.

Confidential
01-Dec-2016
TLINE is the flight time

TADAPT
through the interconnect
DIF-P
M M M
LINE at M-TX PINs PRBS9 sequence PRBS9 sequence
K K K TOB
+ b0 bit + b0 bit
0 0 0
DIF-N DIF-N
TX-FSM
STALL HS-PREPARE ADAPT STALL
State
TLINE TLINE TLINE TLINE TLINE
DIF-P
LINE at M-RX PINs TOB
DIF-N DIF-N
RX-FSM
STALL HS-PREPARE ADAPT STALL
State
Figure 15 ADAPT Operation
265 During initial discovery, the local protocol requests and reads capabilities of MODULEs on both sides of the
LINK. If HS-G4 equalizer capability is detected on both sides, the protocol transfers remote M-RX ADAPT
length capability into local M-TX ADAPT length configuration. The local protocol shall configure the
following setting for an Initial ADAPT:
266 • TX_HS_ADAPT_Length >= RX_HS_ADAPT_INITIAL_Capability
267 The local protocol shall configure the following setting for a Refresh ADAPT:
268 • TX_HS_ADAPT_Length >= RX_HS_ADAPT_REFRESH_Capability
269 When a HS-G4 BURST is initiated (through MLANE-AdaptStart.request) and ADAPT has been configured
(through RX_ADAPT_Control), the M-TX transitions from PREPARE to the ADAPT sub-state instead of
SYNC. The M-TX transitions from DIF-P to transmitting the ADAPT sequence. Both M-TX and M-RX
remain in the ADAPT sub-state for the equalizer training for a duration of TADAPT, as configured in the local
ADAPT length configuration (see Table 7). The M-RX signals exit from the ADAPT sub-state by flipping
the ADAPT_Control field of RX_ADAPT_Control from ADAPT to SYNC and returning to STALL.
270 The M-TX ADAPT length TADAPT can be calculated according to Table 7 for configured
TX_HS_ADAPT_LENGTH.
271 The protocol can initiate subsequent retrainings through an M-LANE-AdaptStart.request service primitive,
synchronously staging an RCT at both ends of the LINK, reconfiguring TADAPT at the M-TX, and writing the
ADAPT_control field of RX_ADAPT_Control from SYNC to ADAPT and setting the ADAPT_type field of
RX_ADAPT_Control to either INITIAL or REFRESH. During the execution of ADAPT, starting from M-
LANE-AdaptStart to M-LANE-AdaptComplete, the protocol shall not issue an
M-LANE-PREPARE.request.
4.7.2.4 PAYLOAD of BURST

272 After SYNC or PREPARE period, PAYLOAD shall be transferred on request of the protocol. PAYLOAD
starts with a MARKER0 and ends with the symbol before a TAIL-OF-BURST. Between the HEAD and TAIL
symbols, any number of DATA0 to DATA255 or MARKER symbols can be transported in any order under
protocol control via the PIF.
273 Note that the MARKER0 symbol has comma properties. This shall be utilized in the M-RX, to acquire, check
and regain symbol alignment on any occurrence of MARKER0. If during a BURST at any time after the first
MARKER0 the protocol does not provide the next symbol request on time, the M-TX will insert FILLER
symbols (FLR) in order to prevent failure and corruption of the serial stream. The protocol layer may
periodically provide MARKER0 for the purposes of self-healing or re-synchronization. For EMI reasons,
protocols are strongly encouraged to limit consecutive repetitions of FILLER or any symbol.

Confidential
01-Dec-2016
4.7.2.5 Closure of BURST

274 With the transmission of TAIL-OF-BURST, the BURST ends and the M-RX and M-TX shall return to the
appropriate SAVE state, or enter LINE-CFG state depending on the polarity of the TOB constant bit
sequence; this constant bit sequence violates the 8b10b coding rules. The M-RX shall exit BURST mode on
detection of the constant bit sequence.
4.7.2.5.1 Closure and Return to SAVE

275 If the BURST closure condition for exit to SAVE state is transmitted (see Table 8), the M-RX shall become
unterminated. The termination shall be disabled and the LINE state settled within the time defined by either
R X _ M i n _ S TA L L _ N o C o n f i g _ Ti m e _ C a p a b i l i t y (exit to S TA L L ) or
RX_Min_SLEEP_NoConfig_Time_Capability (exit to SLEEP). As shown in Table 8, the number and format
of bits differ for different BURST states depending on the signaling scheme. In the table, N is an integer
number of symbols represented by TX_PWM_BURST_Closure_Extension of the local M-TX, and shall be
greater than, or equal to, the value of RX_PWM_Burst_Closure_Length_Capability of the remote M-RX.
4.7.2.5.2 Closure and Return to LINE-CFG

276 In HS-MODE or LS-MODE, if the BURST closure condition for exit to LINE-CFG is transmitted, both
M-RX and M-TX shall return to LINE-CFG state in LS-MODE. As shown in Table 8, the number and format
of bits differ for different BURST states depending on the signaling scheme. This state transition does not
exist in the Type-II state machine. During exit from BURST to LINE-CFG, DIF-P for greater than or equal to
20 UIHS plus TPWM_PREPARE (for configured PWM-GEAR and PREPARE_LENGTH) of the local M-TX
shall not exceed the minimum value of TLINE-RESET-DETECT.
277 When the Protocol Layer issues M-CTRL-CFGREADY.request and LCC_Enable is TRUE, M-TX shall pass
through LINE-CFG after TAIL-OF-BURST. M-TX shall remain in LINE-INIT state, when exited from
PWM-BURST, for a number of SI equal to TX_PWM_BURST_Closure_Extension.
Table 8 Summary of BURST Closure Conditions (TAIL-OF-BURST)

Return to SAVE Return to LINE-CFG
MODE MODULE
LINE Condition State LINE Condition
HS M-TX DIF-N for 20 UIHS STALL DIF-P for  20 UIHS + TPWM_PREPARE

HS M-RX DIF-N for 9 to 20 UIHS STALL DIF-P for 9 to 20 UIHS + TPWM_PREPARE
PWM M-TX (9 + 10*N) PWM-b0 + PWM-b1 SLEEP 9 PWM-b1
PWM M-RX ( 9 PWM-b0) + PWM-b1 SLEEP 9 PWM-b1
SYS M-TX DIF-N for  10 UISYS SLEEP n/a
SYS M-RX DIF-N for 10 UISYS SLEEP n/a
4.7.2.6 Example of an HS-BURST

278 A time domain illustration of HS-BURST operation is shown in Figure 16. In this example the M-RX is
(default) configured to provide LINE termination during HS-BURST, which can be noticed by the signal
level changes during PREPARE and (exit-to-)STALL.

Confidential
01-Dec-2016
Version 4.1
Configured PREPARE Period Configured SYNC Length PAYLOAD
TLINE is the flight time
BURST through the interconnect
DIF-P
Loop
M
LINE at M-TX PINs SYNC K Data, MKn
0 DIF-N
DIF-N
TX-FSM
State
STALL HS-PREPARE 8b10b SYMBOLs STALL
BURST
to DIF-P
LINE-CFG M DIF-P
LINE at M-TX PINs SYNC K Data, MKn
0
DIF-N
TX-FSM
STALL HS-PREPARE 8b10b SYMBOLs Exit to LINE-CFG
Confidential
State
TLINE TTERM_ON_HS_RX TLINE TLINE TLINE TTERM_OFF_HS_RX TLINE
BURST
DIF-P
Loop
M
LINE at M-RX PINs SYNC K Data, MKn
0
DIF-N DIF-N
RX-FSM
State
STALL HS-PREPARE 8b10b SYMBOLs Exit to STALL STALL
BURST
Specification for M-PHY

to DIF-P DIF-P
LINE-CFG M
LINE at M-RX PINs SYNC K Data, MKn
0
DIF-N
RX-FSM
State
STALL HS-PREPARE 8b10b SYMBOLs Exit to LINE-CFG
Figure 16 HS-BURST Operation

37
01-Dec-2016
4.7.3 BURST MODEs and GEARs
4.7.3.1 HS-BURST
279 HS-BURST is the data transmission state of HS-MODE. HS-BURST starts from STALL on a transition to
DIF-P. Data shall be 8b10b encoded in this mode and transmitted using NRZ signaling. After the last symbol
of the BURST, a MODULE enters STALL state, or in the case of a Type-I MODULE, enters LINE-CFG
state, depending on the exit condition on the LINE.
4.7.3.1.1 HS-GEARs
280 A MODULE in HS-BURST shall only operate at the defined data rate, DRHS. There are two RATE series, A
and B, where each step in the series scales by a factor of two, while the speed rate difference between the two
RATE series is about 15%, as listed in Table 9. If the data rates of the two RATE series are pair-wise coupled
for closest rates (~15%), these individual couples are denoted as GEARs. A MODULE that includes
HS-MODE shall support both RATEs of a GEAR. A MODULE supporting HS-MODE shall support HS-G1.
If a higher GEAR is supported all lower GEARs shall be supported as well.
Table 9 HS-BURST: RATE Series and GEARs

RATE A-series (Mbps) RATE B-series1 (Mbps) High-Speed GEARs
1248 1457.6 HS-G1 (A/B)
2496 2915.2 HS-G2 (A/B)
4992 5830.4 HS-G3 (A/B)
9984 11660.8 HS-G4 (A/B)
1. The B-series rates shown are not integer multiples of common reference frequencies 19.20 MHz or
26.00 MHz, but are within the tolerance range of 2000 ppm.
4.7.3.2 PWM-BURST
281 PWM-BURST is the data transmission state of LS-MODE of Type-I LINKs. PWM-BURST starts from
SLEEP on the transition to DIF-P. Data shall be 8b10b encoded in this mode and transmitted using PWM
signaling. After the last symbol of the BURST, a sequence of same-value PWM bits is added, which creates
an 8b10b run-length violation on the LINE. For a sequence of PWM-b0 with a trailing PWM-b1, both M-RX
and M-TX shall return to SLEEP state. For a sequence of PWM-b1, both M-RX and M-TX shall go to
LINE-CFG state. See Table 8 for more details.
4.7.3.2.1 PWM-GEARs
282 PWM-BURST has multiple GEARs, each with a limited speed range. Table 10 lists all the PWM-GEARs.
PWM-G1 is the default GEAR at start-up and after reset. Only PWM-G1 is mandatory. Except for PWM-G0,
each GEAR spans a speed range of a factor of three, while subsequent PWM-GEARs scale with factors of
two. This allows a continuum of possible rates. If a higher PWM-GEAR is supported all lower GEARs down
to default GEAR shall be supported as well. PWM-G0 is optional independently. For PWM-G1 and all higher
PWM-GEARs, FIXED-RATIO signaling shall be applied. The FIXED-MINOR signaling format shall be
used for PWM-G0.

Confidential
01-Dec-2016
Table 10 PWM-BURST GEARs

PWM-GEARs Min. (Mbps) Max. (Mbps)
PWM-G0 0.01 3
PWM-G1 3 9
PWM-G2 6 18
PWM-G3 12 36
PWM-G4 24 72
PWM-G5 48 144
PWM-G6 96 288
PWM-G7 192 576
4.7.3.3 System-clock Synchronous BURST (SYS-BURST)

283 SYS-BURST is the data transmission state of LS-MODE of Type-II LINKs. SYS-BURST starts from SLEEP
on the transition to DIF-P. Data shall be 8b10b encoded in this mode and transmitted using reference-clock
synchronous NRZ signaling. After the last symbol of the BURST, the LINE is driven to DIF-N state. The
long DIF-N creates an 8b10b run-length violation which ends SYS-BURST and moves both M-RX and
M-TX to SLEEP state.
284 In this mode, MODULEs depend on a shared reference clock for transmission. The transmission rate in this
mode shall be an integer division of the shared reference clock frequency, fSYS_REF. The reference clock may
originate from an independent system clock or from one of the two devices in the LINK. An example of the
latter case is shown in Figure 17, where the device providing the clock is located on the left hand side of the
figure.
285 This document only partially specifies this mode, as it also relies on the specifications of the reference clock,
the timing relationship between the clock pin on the devices and the reference clock input of the MODULEs
(PIF), and the timing between reference clock input of the MODULEs and the LINE signals. Section 5
contains an informative guideline for timing between reference clock and LINE signals. The overall timing
specifications for this signaling scheme shall be covered by the protocol specification utilizing this mode.

Confidential
01-Dec-2016
M-TX M-RX
SysClk
Buffer Buffer
M-RX M-TX
Figure 17 Bidirectional SYS-BURST Clocking Example
4.7.4 BREAK States

286 BREAK states have special functions, which are entered by exceptional LINE sequences that do not occur
during normal operating modes.
4.7.4.1 LINE-RESET
287 This is the lowest level reset mechanism in order to reset the M-RX via the LINE during operation in case of
malfunction. The LINE-RESET condition is a long DIF-P period, which can never occur during normal
operation. LINE-RESET can be initiated by the Protocol Layer on the M-TX side of a LINK using the
M-CTRL-LINERESET.request primitive (see Section 8.3.9). A MODULE shall support LINE-RESET in all
ACTIVATED states.
288 Before issuing M-CTRL-LINERESET.request with TActivateControl set to “ProtocolControlled”, the
Protocol Layer issues M-LANE-BurstEnd.request and waits for TACTIVATE after the M-TX has generated
M-LANE-SaveState.indication. This condition ensures the M-TX drives DIF-N for at least TACTIVATE so that
an M-RX, which might be in HIBERN8, is ACTIVATED before the LINE-RESET condition is driven. For
LINE-RESET, the M-TX shall drive DIF-P for TLINE-RESET.
289 After the Protocol Layer issues M-CTRL-LINERESET.request with TActivateControl set to
“PhyControlled”, the M-TX drives DIF-N for TACTIVATE before driving the LINE-RESET condition.
TACTIVATE is calculated as described in Table 5.
290 An M-RX shall be reset when DIF-P is observed on the LINE for TLINE-RESET-DETECT. The LINE-RESET
timer shall not rely on correct protocol operation. LINE-RESET exits to SLEEP on a transition to DIF-N.
LINE-RESET shall reset all configuration settings to their respective default values as specified in
Section 8.4.

Confidential
01-Dec-2016
T ACTIVATE T LINE-RESET
DIF-P,
LINE DIF-Z or DIF-N DIF-P DIF-N
DIF-N
Figure 18 LINE-RESET Timing
Table 11 LINE-RESET and HIBERN8 Timer Values

Parameter Min. Max. Unit Descriptions and Notes
A maximum value of 20ms may be set at the option
TLINE-RESET 3.1 ms
of the protocol. (Informative)
TLINE-RESET-DETECT 1 3 ms
THIBERN8_ENTER_TX 50 1000 ns
THIBERN8_ENTER_RX 25 ns
Minimum duration in SAVE states following
TRCT_SAVE 40 ns
configuration.
4.7.4.2 LINE-CFG (Type-I MODULE Only)

291 LINE-CFG state enables low-level configuration features. This functionality shall be supported by a
MODULE used for a LANE that may contain a Media Converter, as a Media Converter is configured by this
mechanism. In the absence of a Media Converter, M-RX and M-TX are not obliged to support LINE-CFG.
For backward compatibility with earlier versions of M-PHY, an M-RX not implementing LINE-CFG shall be
able to absorb a LINE-CFG sequence, when transmitted by an M-TX, without processing it. Starting from
TOB and ending with the last bit of the LCC-MODE, an M-RX shall ignore the LINE states and re-
synchronize its state machine upon transition from LINE-CFG to DIF-N. LINE-CFG enables a MODULE to
write and read configuration attributes to and from a Media Converter. A Media Converter typically contains
only a subset of the physical layer functionality and no protocol stack and therefore cannot be directly
accessed by the protocol.
292 The sub-state machines of the LINE-CFG state are shown in Figure 19 and Figure 20 for the M-TX and
M-RX, respectively. These state machines consists of LINE Control Commands (LCC) with their
corresponding parameter field, interleaved by LINE-INIT states. LINE-INIT state means nine or more b1 bits
in a row, generated in case of M-TX or received in case of M-RX. This exception condition does not occur
during any other state.
293 The M-TX state machine shall sequence the requested commands in a specified order, starting with WRITE-
ATTRIBUTE, followed by READ-MFG-INFO, then READ-VEND-INFO, then READ-CAPABILITY, and
ending with MODE. Note that during LINE-CFG sub-states, only commands that are requested shall be
transmitted, not requested commands shall be skipped. The requested commands are controlled by protocols
via the SAP.
294 The M-RX shall not be sensitive to the order of LCCs, except that the LCC-MODE command is always the
last one. However, the M-RX will logically receive commands in the order as specified for the M-TX. M-RX
may drive DIF-Z when LCC-MODE is detected. When RCT is triggered, if transition is not to HIBERN8,
then M-RX should disable DIF-Z. Detailed specifications of these states are provided in the following
sections. TX_LCC_Sequencer (see Table 51) shall automatically be reset after LCC operation.

Confidential
01-Dec-2016
295 After leaving LINE-CFG, MODULEs and Media Converters conduct an RCT synchronizing their operation.
The protocol shall ensure all attributes associated with LINE-CFG are set consistently at the end of the
BURST that contains the reconfiguration trigger request. Note that these setting do not become effective for
the MODULEs themselves until the RCT arrives. After the RCT request, the protocol shall not change
attributes until entering SAVE state, see Section 8.2.11.3. The end of LINE-CFG drives a DIF-N indicating a
transition via RCT to the configured SAVE state, see Section 4.7.4.2.4.
296 Application may confirm setting of TX_LCC_Sequencer and TX_LCC_Enable via M-CTRL-
CFGREADY.request during BURST or SAVE state. In both cases, these M-TX settings shall become
immediately effective upon receipt of M-CTRL-CFGREADY.request and affect the state transitions that
follow the next M-LANE-BurstEnd.request after M-CTRL-CFGREADY.confirm. If the application opts to
issue M-CTRL-CFGREADY.request during BURST state, it should keep the BURST open until the M-TX
has processed effectuation of M-CTRL-CFGREADY.request.
b1
LINE-INIT
From TOB as defined in Table 8 Automatic at
completion
b0 (last bit of symbol)
LINE-WRITE FRAME
If WRITE_enable TRUE LCC-WRITE-
40b-WRITE DATA
AND not sent ATTRIBUTES
FALSE
LINE-READ FRAME
If READ-
TRUE LCC-READ-
MFG-INFO_enable 40b-READ DATA
MFG-INFO
AND not sent
FALSE
LINE-READ FRAME
If READ-
TRUE LCC-READ-VEND-
VEND-INFO_enable 40b-READ DATA
INFO
AND not sent
FALSE
LINE-READ FRAME
If READ-
TRUE LCC-READ-
CAPABILITY_enable 40b-READ DATA
CAPABILITIES
AND not sent
FALSE
LINE-MODE FRAME
Exit by DIF-P to DIF-N transition
LCC-MODE
after last LCC-MODE bit
Figure 19 Sub-state Machine of M-TX for LINE-CFG

Confidential
01-Dec-2016
b1
From TOB as defined in Table 8
LINE-INIT
Automatic at
b0 (last bit of symbol)
completion
OR >= 9x b1
TRUE
IF LCC_WRITE? 40b-WRITE DATA
FALSE
TRUE
IF LCC_READ? 40b-READ DATA
FALSE
Exit by DIF-P to DIF-N transition

LCC-MODE
after last LCC-MODE bit
Figure 20 Sub-state Machine of the M-RX for LINE-CFG
4.7.4.2.1 LINE-INIT
297 LINE-CFG is entered in LINE-INIT. This can occur either from HS-BURST or from PWM-BURST if
directed by a TOB as defined in Table 8. Both M-RX and M-TX stay in LINE-INIT as long as PWM-b1 are
transferred, which, when exited from PWM-BURST, shall be greater than, or equal to, a number of SI equal
to the remote M-RX RX_PWM_Burst_Closure_Length_Capability attribute. LINE-INIT ends with a
PWM-b0, immediately followed by a 10-bit LINE-Control-Command (LCC) which contains the requested
action. LINE-INIT state between two commands shall be exactly ten bits long, consisting of nine b1 bits and
one b0 bit. Possible b1 bits belonging to the preceding command shall not be counted, so precisely ten bits are
inserted. TPWM_PREPARE is always calculated in LS-MODE SI.
4.7.4.2.2 LINE Control Command (LCC)

298 LCCs are 10-bit long and are always preceded by a PWM-b0, being part of, and completing, LINE-INIT.
LCCs are not 8b10b encoded. Table 12 lists the functions of the bits in the LCCs, which can be divided into
four categories. MODE-LCCs (16; including MISC, PWM-MODE, and HS-MODE), WRITE-LCCs (1),
READ-LCCs (3; which are READ-CAPABILITY, READ-MFG-INFO, and READ-VEND-INFO), and
RESERVED-LCCs (12) for future usage. MODE-LCCs have no additional data field and are therefore just
ten bits long and exit into DIF-N LINE state. The resulting Re-Configuration Trigger will move the state to
STALL, SLEEP, or HIBERN8. See Section 4.7.4.2.4 for more details. LCCs shall only be issued starting
from LINE-INIT state.
299 LCCs contain five information bits (d[4:0]) which encode the requested action and are transmitted first. The
remaining five bits are used to increase robustness. LCCs are protected against bit-errors by a SECDED
Hamming code scheme with five parity bits (p1 to p5 = d5 to d9).

Confidential
01-Dec-2016
Table 12 LCC Definition1

d5 d6 d7 d8 d9
d0 d1 LCC-Category d2 d3 d4 Command
p1 p2 p3 p4 p5
0 0 0 RESERVED 1 1 1 1 1
0 0 1 RESERVED 0 1 1 0 0
0 1 0 RESERVED 0 0 0 1 1
0 1 1 HIBERN8-SLEEP 1 0 0 0 0
0 0 MISC
1 0 0 RESERVED 1 0 0 1 0
1 0 1 RESERVED 0 0 0 0 1
1 1 0 RESERVED 0 1 1 1 0
1 1 1 HIBERN8-STALL 1 1 1 0 1
0 0 0 READ-CAPABILITY 0 1 0 1 0
0 0 1 RESERVED 1 1 0 0 1
0 1 0 RESERVED 1 0 1 1 0
READ/ 0 1 1 READ-MFG-INFO 0 0 1 0 1
0 1
WRITE 1 0 0 READ-VEND-INFO 0 0 1 1 1
1 0 1 WRITE-ATTRIBUTE 1 0 1 0 0
1 1 0 RESERVED 1 1 0 1 1
1 1 1 RESERVED 0 1 0 0 0
0 0 0 PWM-G0 0 0 1 1 0
0 0 1 PWM-G1 1 0 1 0 1
0 1 0 PWM-G2 1 1 0 1 0
0 1 1 PWM-G3 0 1 0 0 1
1 0 PWM-MODE
1 0 0 PWM-G4 0 1 0 1 1
1 0 1 PWM-G5 1 1 0 0 0
1 1 0 PWM-G6 1 0 1 1 1
1 1 1 PWM-G7 0 0 1 0 0
0 0 0 HS-G1A 1 0 0 1 1
0 0 1 HS-G2A 0 0 0 0 0
0 1 0 HS-G3A 0 1 1 1 1
0 1 1 HS-G4A 1 1 1 0 0
1 1 HS-MODE
1 0 0 HS-G1B 1 1 1 1 0
1 0 1 HS-G2B 0 1 1 0 1
1 1 0 HS-G3B 0 0 0 1 0
1 1 1 HS-G4B 1 0 0 0 1

Confidential
01-Dec-2016
1. Columns for LCC data bits in this table are not intended to convey any information on bit-order
transmission. Transmission of a 10-bit LCC should always begin with b0.
4.7.4.2.3 LINE-READ and LINE-WRITE Frames

300 LINE-READ and LINE-WRITE frames contain four byte data fields (thirty-two bits) after the LCC. These
four bytes are transmitted in a 4x10-bit format across the LINE. Each 10-bit block contains one byte of
information in the center, which is sandwiched between two b0s. The data bits d[7:0] of each byte shall
therefore be located in the second bit through the second-to-last bit of each ten bit block as illustrated in
Figure 21. The first and last bit of each 10-bit block shall be b0.
301 The transmitted bytes of a LINE-READ frame shall be all b1 (0xFF), while the data of a LINE-READ at the
M-RX side contain the information, which is read from the Media Converter. There are two READ
commands, READ-MFG-INFO and READ-VEND-INFO, with the same format, enabling more bits to read
if necessary. The M-RX shall store the READ bytes as Media Converter attributes in the configuration
registry. The WRITE bytes consists of a selection of bits, which are derived from attributes in the M-TX
configuration registry.
302 The exact contents and meaning of the WRITE and READ bytes are specified in Section 7.
303 LINE-READ shall be performed only in PWM-G1. The protocol has to ensure that a LINE-CFG containing
an LCC-READ is performed in PWM-G1.
10 bits 10 bits 10 bits 10 bits 10 bits
b b b b b b b b b
LINE-INIT 0 LCC-WRITE 0
WRITE1 0 0
WRITE2 0 0
WRITE3 0 0
WRITE4 0
LINE-INIT
b b b b b b b b b
LINE-INIT 0 LCC-READ 0
0xFF 0 0
0xFF 0 0
0xFF 0 0
0xFF 0
LINE-INIT
PWM Encoded
b
LINE-INIT 0 LCC-MODE DIF-N
Figure 21 Format of Different LCC Frames on the LINE
4.7.4.2.4 Re-Configuration Trigger (RCT)

304 A re-configuration trigger (RCT) is intended to provide a synchronous event upon which INLINE
configuration attributes can be updated, ensuring MODULE attributes on both sides of a LANE remain
consistent and interoperable. Both MODULEs and inline Media Convertors shall detect an RCT.
305 The Protocol Layer shall provide sufficient time to the LANE following an RCT to complete re-configuration
before requesting a new BURST as defined in Section 8.4.
306 All of the following conditions shall be fulfilled before a Re-Configuration Trigger is executed by a
MODULE, or inline Media Converter:
307 • A CFG-READY indication via the Protocol Interface (M-CTRL-CFGREADY.request)
308 • Entering or being in a SAVE state
309 • Completion of LINE-CFG (only for a Type-I MODULE with a Media Converter)
310 As described in Section 4.7.4.2, a Media Converter is configured by the attached MODULE through
LINE-CFG, making completion of LINE-CFG necessary in cases where Media Converters are present.
Completing LINE-CFG ensures that re-configuration of all MODULEs and inline Media Converters within a
LANE remain synchronized.

Confidential
01-Dec-2016
311 Note that when requesting HIBERN8 from LINE-CFG, the LINE signal first switches from DIF-P to DIF-N,
which ends LINE-CFG and causes an RCT. This RCT effectuates the request to go to HIBERN8, which
causes the LINE signal to switch from DIF-N to DIF-Z. After the last bit of LINE-CFG, the M-TX shall drive
the LINE with DIF-N for THIBERN8_ENTER_TX. The M-RX shall begin driving the LINE to DIF-Z within
THIBERN8_ENTER_RX after detection of the last transition to DIF-N.
4.8 Configuration
312 M-PHY provides significant flexibility advantages over other serial PHYs offering multiple optional MODEs
and configurable Attributes. To support this level of flexibility, interoperability is managed in two ways,
default parameter settings provide a minimum level of interoperation between MODULEs of the same type,
while a robust configuration mechanism supports optimization of the PHY through the protocol for specific
use-cases. Central to the configuration process is self-discovery where each MODULE contains a set of
Attributes containing its capabilities. This information can be interrogated by the protocol using a CONFIG
interface in the PIF. When coupled with the minimum dual-simplex LINK, this arrangement allows, through
implementation in the protocol, a complete capability discovery and negotiation process avoiding the
requirement of detailed knowledge of the LINK components at a system level.
4.8.1 Conceptual Configuration Process

313 Following an OFF state, or a LINE-RESET, a MODULE operates with default configuration settings. Under
default operation the Protocol can retrieve MODULE capabilities, arbitrate more optimal configuration
settings, then directly change OFFLINE settings, or make a change request for INLINE settings. This process
consists of the following steps:
314 • DISCOVERY
315 • Read MODULE capabilities, and determine desired, commonly supported configuration
settings.
316 • PHY CONFIG
317 • Request to change MODULE configuration settings.
318 • EFFECTUATE
319 • Update the MODULE configuration settings.
320 To support the configuration process, the following four registries are anticipated:
321 • CAPABILITY registry; contains the capability information for a given MODULE.
322 • STATUS (also known as INLINE-SET) registry; contains effectuated INLINE configuration
settings. These configuration settings are updated from the INLINE-CR registry by the MODULE
upon an RCT.
323 • INLINE-CR registry, (shadow registry for the INLINE-SET registry); logs change requests for
configuration settings of INLINE parameters, that is, settings that immediately impact actual
signaling.
324 • OFFLINE-SET registry; contains configuration settings that do not directly impact signaling, and
are therefore immediately effectuated with issuing of M-CTRL-CFGREADY.request. An RCT
for effectuating these attributes is not required.
325 The nature of a configuration setting, whether it is INLINE or OFFLINE, depends on the mode of operation.
326 Each MODULE within a SUB-LINK may have its own set of registries, or an M-PORT implementation may
combine common configuration settings, depending on the specific LINK composition. The implementation
of the anticipated registries is outside the scope of this document.
327 A Media Converter is not required to interpret PAYLOAD data, and therefore MODULEs support a
supplementary, low-level configuration mechanism. This supplementary mechanism, based on LCCs and
used in the LINE-CFG state, is intended to enhance, but not replace, the main configuration mechanism. A
MODULE is not reconfigured via LINE-CONFIG.

Confidential
01-Dec-2016
328 The configuration process is detailed in the following sections for LANEs without, and with, Media
Converters.
4.8.1.1 Configuration without Media Converters

329 Figure 22 illustrates the information flow for a dual-simplex LINK without Media Converters in the LINEs,
and the steps of the configuration process for that LINK. There might be invisible, non-constraining Media
Converters in a LINE, but these are, in this case, not part of the configuration process.
Configuration Process Information Flow
LANEs in BURST-MODE
DISCOVERY
CAPABILITY M-TX M-RX CAPABILITY

The local protocol requests and reads Local Remote
capabilities of MODULES on both sides of the Protocol Protocol
LINK and arbitrates the best set of
configuration settings for the MODULE.
CAPABILITY M-RX M-TX CAPABILITY
INLINE-CR INLINE-CR
PHY CONFIG
LANEs in BURST-MODE
OFFLINE-SET M-TX M-RX OFFLINE-SET
Local Remote
The protocol writes the newly arbitrated
Protocol Protocol
settings to the INLINE-CR and OFFLINE-SET INLINE-CR INLINE-CR
registries.
OFFLINE-SET M-RX M-TX OFFLINE-SET
INLINE-CR INLINE-SET INLINE-SET INLINE-CR

EFFECTUATE
All LANEs to SAVE state

Local M-TX M-RX Remote
Once the MODULE enters a SAVE state; the
Protocol Protocol
MODULE updates the INLINE-SET from the INLINE-CR INLINE-SET INLINE-SET INLINE-CR
INLINE-CR registry.
M-RX M-TX
= Information Flow
Figure 22 Configuration Steps for LANE
4.8.1.2 Configuration with Media Converters in the LINE

330 Figure 23 illustrates the information flow for a dual-simplex LINK with configurable Media Converters in
the LINEs, and the steps of the configuration process for that LINK. The configuration process in this case
includes several additional steps for configuring the Media Converters as shown in the figure.

Confidential
01-Dec-2016
Configuration Process Information Flow
LANEs in PWM-BURST (PWM-G1 default)

POWER-UP
From power-up, the MODULE operates under MC MC

default BURST settings (PWM-G1). For Local M-TX M-RX Remote
implementations with MCs, LCC_Enable Protocol Protocol
defaults to TRUE. During the first burst the
protocol issues a M -CTRL-
CFGREADY.request to exit into LINE-CFG MC MC
M-RX M-TX
LANEs in LINE-CFG
MC MC
MC READ
Upon entering LINE-CFG the MODULE

M-TX M-RX CAPABILITY
executes the operations stored under Local Remote
TX_LCC_Sequencer : if B[0] = 1, LCC-READ- Protocol Protocol
CAPABILITY is requested, which triggers the
inline media converter to write its capabilities
to the CAPABILITY registry in the M-RX. MC MC
CAPABILITY M-RX M-TX
LANEs in BURST mode

DISCOVERY
MC MC
Following the MC capability read, the local CAPABILITY M-TX M-RX CAPABILITY
Local Remote
protocol requests and reads capabilities of
MODULEs on both sides of the LINK , and Protocol Protocol
arbitrates the best set of configuration
settings for the MODULE.
MC MC
CAPABILITY M-RX M-TX CAPABILITY
INLINE-CR INLINE-CR
LANEs in BURST mode
PHY CONFIG
MC MC
The protocol writes the newly arbitrated Local OFFLINE-SET M-TX M-RX OFFLINE-SET Remote
settings to the INLINE-CR and OFFLINE-SET
registries. During this burst the protocol Protocol Protocol
INLINE-CR INLINE-CR
issues a M-CTRL-CFGREADY.request to exit
into LINE-CFG.
MC MC
OFFLINE-SET M-RX M-TX OFFLINE-SET
LANEs in LINE-CFG
MC CONFIG
Upon entering LINE-CFG, the MODULE MC MC

executes the functions asserted through Local M-TX M-RX Remote
TX_LCC_Sequencer ; if B[7] = 1, LCC- Protocol Protocol
WRITE-ATTRIBUTE is requested, at which
time the M-TX updates the MC with new
configuration settings . MC MC
M-RX M-TX

All LANEs to SAVE state
EFFECTUATE
MC MC
Upon exit from LINE-CFG, the MODULE Local M-TX M-RX Remote
enters a SAVE state; the MODULE updates Protocol Protocol
the INLINE-SET from the INLINE-CR registry,
the MC effectuates all new settings .
MC MC
M-RX M-TX
= READ from MC = WRITE to MC = MC to effectuate new CONFIG settings

= Information Flow
Figure 23 Configuration Steps for LANE including Media Converters
4.8.2 Configuration Parameters

331 Configuration attributes for MODULEs are listed in Section 8.4.

Confidential
01-Dec-2016
4.9 Multiple LANE Provisions

332 This document governs individual LANEs for a LINK. However, the LANE composition of a LINK is not
specified by this document. This section specifies the provisions and constraints for multi-LANE SUB-LINK
operation. This enables a multitude of possible LANE compositions for LINKs. The fine selection of allowed
LANE combinations is left to the protocols on top of the Physical Layer.
333 There shall be no (tight) PHY-level requirements on timing alignment between SUB-LINKs.
334 The LANEs of a SUB-LINK consisting of multiple LANEs may each individually be in ACTIVATED,
DISABLED or HIBERN8.
335 Independent activation of multiple LANEs in a SUB-LINK is optional. If independent activation of multiple
LANEs in a SUB-LINK is supported, each MODULE shall satisfy all signaling requirements across multiple
LANEs used for a SUB-LINK. If independent activation of multiple LANEs in a SUB-LINK is not
supported, the number of LANEs in BURST in a SUB-LINK shall only be changed while all LANEs are
either in a SAVE state or DISABLED.
336 Individual LANEs of a SUB-LINK should only be DISABLED during initialization after power-up. When
ACTIVATED, LANEs of a SUB-LINK shall be in the same MODE at the same RATE. In HS-MODE, both
SUB-LINKs shall use the same HS RATE series (A or B). SUB-LINKs may be operated in different GEARs.
SUB-LINKs can be operated in different modes. SUB-LINKs may contain different numbers of LANEs.
Entry and exit of HIBERN8 of a SUB-LINK is correlated with the state of the SUB-LINK in the opposite
direction. A SUB-LINK is considered to be in HIBERN8 when all its LANES are in HIBERN8 or
DISABLED. LANE exit and entry of HIBERN8 are initiated from the M-TX side and controlled by the local
protocols. The protocols on both sides control LANEs such that both SUB-LINKs enter and exit HIBERN8
more, or less, simultaneously or shortly after each other. The detection means of the M-RX are just triggers
for the further protocol action. At least one LANE of a TYPE-I SUB-LINK needs to remain enabled after
power up.
337 This document does not require functional symmetry of M-TXs and M-RXs for the SUB-LINKs of a LINK.
338 The allocation of PAYLOAD data over multiple LANEs is left to the protocol specifications.
4.10 Test Modes

339 Test modes are special modes of operation which shall not happen during normal operation of a MODULE,
which are intended to facilitate electrical, functional and protocol related tests. However, most tests can and
should be executed using the normal operating modes. Protocols shall support generation of both burst and
continuous mode signaling for the purposes of conformance testing. This may be accomplished via loopback,
or dedicated test modes, depending on the application. See Annex B for further information.
4.10.1 LOOPBACK Mode

340 LOOPBACK mode provides a transparent bit-by-bit path from an M-RX input to an M-TX output. This can
be done only for commonly supported MODE and GEAR settings for the involved M-RX and M-TX. If
multiple M-RXs or M-TXs are present in a complete LINK, the mapping of which M-RX is looped via which
M-TX is either specified by the applicable protocol specification or is otherwise left to the implementor. The
Physical Layer is set into LOOPBACK mode via configuration.
341 LOOPBACK retransmits via the M-TX the encoded LINE data as recovered by the M-RX without decoding
(and re-encoding) the 8b10b symbols. The configured setup in the mode is illustrated in Figure 24.
Bypassing the coders avoids bit error multiplication. For any mandatory test condition, the input data
provided to the M-RX shall be 8b10b encoded. Furthermore, an implementation should use symbol streams
with characteristics similar to what happens in the real application. LOOPBACK mode can for example be
used for BER testing.
342 Although this mode allows a test setup to inject a non-8b10b encoded bit stream for experimental purposes,
there shall not be mandatory requirements on the functionality or performance of the Physical Layer in this

Confidential
01-Dec-2016
case. Because HS-MODE utilizes embedded-clock data recovery, it is essential that any input bit stream in
HS-LOOPBACK contains sufficient edge density.
343 For LOOPBACK the RATEs of M-RX and M-TX shall be identical, even though the MODULEs might be
able to operate plesiochronously during normal operation. Note that this test mode is suitable to monitor the
internal recovered bitstream of the M-RX on the outside via the M-TX, but not to characterize the M-TX
performance.
.
Protocol Interface in Protocol Interface in

normal operation normal operation
Mode- Control & Protocol Mode- Control & Protocol

Interface Logic Interface Logic
decoded
raw output
input
data & ctrl
data & ctrl
8b10b decoder 8b10b encoder
encoded
recovered Protocol Level Switch MUX data & ctrl
encoded bits
Receiver Transmitter
Shared reference clock
Front-End Front-End
LINE Interface LINE Interface
Figure 24 LOOPBACK Configuration

Confidential
01-Dec-2016
5 Electrical Characteristics
344 This section defines the electrical and low-level timing characteristics of M-TXs and M-RXs. The definitions
of the common MODULE characteristics are followed by specific characteristics for HS-MODE,
PWM-MODE, and SYS-MODE operation. Finally, this section specifies the general PIN characteristics for a
MODULE.
345 The definitions within this section refer to a MODULE in certain MODEs, which are referred to as
FUNCTIONs. The FUNCTIONs are listed with their abbreviations in Table 13.
Table 13 FUNCTIONs and their Abbreviations

Abbreviation FUNCTION
HS-TX M-TX in HS-MODE
PWM-TX M-TX in PWM-MODE
SYS-TX M-TX in SYS-MODE
HS-RX M-RX in HS-MODE
PWM-RX M-RX in PWM-MODE
SYS-RX M-RX in SYS-MODE
SQ-RX M-RX in squelch
346 The names of the FUNCTIONs correspond with the operational states of the M-TXs and M-RXs as specified
in Section 4.6.3. A MODULE does not need to support all FUNCTIONs, only those required for the intended
application. FUNCTIONs required for an M-TX or an M-RX implementation are defined in Section 4.4,
Section 4.6, Section 4.7 and higher level protocol standards. Also, the high level timing of the FUNCTIONs
and their operation are defined in Section 4.
347 The electrical and timing characteristics of the M-TX and the M-RX are defined at the PINs of an IC. Only
MODULE characteristics that are observable at the PINs are subject to specification. These characteristics
shall meet their specifications for any supported FUNCTION.
348 This specification is intended to be implementation agnostic. The section structure, which is based on
FUNCTIONs, does not preclude integrated driver or receiver implementations. Although some figures in this
section may suggest a certain driver or receiver implementation, they are used only for illustration purposes.
5.1 M-TX Characteristics

349 This document distinguishes three different operating modes and corresponding FUNCTIONs. Following the
definition of the common M-TX electrical and timing characteristics, additional characteristics specific to
HS-TX, PWM-TX, and SYS-TX are defined in this section.
5.1.1 Common M-TX Characteristics

350 The common electrical and timing characteristics of an M-TX are defined in this section, which also contains
the PIN and signal definitions. The common M-TX characteristics apply to the HS-TX, PWM-TX, and
SYS-TX FUNCTIONs.
5.1.1.1 PIN, Signal, and Reference Characteristic Definitions

351 An M-TX drives a low-voltage differential output signal at the PINs TXDP and TXDN either into a
terminated, or an unterminated, load. TXDP and TXDN are defined as the positive and negative output PINs,
respectively.

Confidential
01-Dec-2016
352 The PIN voltages and currents, as well as the reference load RREF are shown in Figure 25. RREF_RT and
RREF_NT are defined as reference loads for when the M-TX is terminated and not terminated, respectively.
ITXDP(t)
TXDP
+
0/1 M-TX VDIF_TX(t) ZREF RREF
-
TXDN
ITXDN(t)
VTXDN(t) VTXDP(t) CPAR CPAR
Figure 25 M-TX PIN Voltages, PIN Currents, and Reference Loads
353 Reference Channels CH1 and CH2 are defined for operation in HS-G3 and HS-G4. The reference channels
are defined by the channel insertion loss SDDIL_REF_CH, the return loss SDDRL_REF_CH, and the channel
differential impedance R DIF_REF_CH when terminated with R REF_RT. The maximum single-ended DC
channel resistance is RDC_REF_CH. The SDDIL_REF_CH templates are shown in Figure 26. An M-PHY
operating in HS-G3 and HS-G4 shall demonstrate TX eye opening conformance with Reference Channels
CH1 or CH2. The reference channels do not represent an actual LINK channel. The reference channel
insertion loss template does not scale for HS-G4. The reference channel definition is independent of HS-
Gear.
354 A reference package model is defined for operation in HS-G4 to represent an interconnect extension that
affects the signal quality beyond the reference channels. The reference package model, with the addition of
pad capacitance, shall conform to the HS-TX and HS-RX return loss defined in Section 5.1.1.4 and
Section 5.2.1.5.
Figure 26 HS-G3 and HS-G4 Reference Channel Insertion Loss SDDIL_REF_CH Templates
355 VTXDP(t) and VTXDN(t) are defined as the signal voltages at TXDP and TXDN with respect to ground. VTXDP
and VTXDN are defined as the voltage amplitudes of the VTXDP(t) and VTXDN(t) signals, respectively.

Confidential
01-Dec-2016
356 ITXDP(t) and ITXDN(t) are defined as the output currents flowing out of TXDP and TXDN, respectively.
ITXDP and ITXDN are defined as the current amplitudes of the ITXDP(t) and ITXDN(t) signals, respectively.
357 ZREF is the impedance of the reference load RREF. which is bounded by the return loss SRLREF. CPAR
illustrates parasitic capacitance that contributes to ZREF; CPAR is not specified. ZREF_RT is defined as the
complex impedance of R REF_RT and represents the AC reference load limit in the terminated state.
SRLREF_RT is defined as the return loss of ZREF_RT and can be calculated using Equation 1.
Z REF_RT + Z R
SRL REF_RT = – 20 log --------------------------------
- (Equation 1)
Z REF_RT – Z R
358 where ZR is a defined reference impedance. SRLREF_RT is defined having a minimum value greater than
SRLREF_RT[MIN] for all frequencies from 0 Hz up to fHS_MAX (see Figure 27).
log f
1 kHz fHS_MAX
0
See Table
Below
SRLREF
[dB]
Frequency 1 kHz fHS_MAX

SRLREF for Gears 1, 2, and 3 (dB) -40 -20
SRLREF for Gear 4 (dB) -40 -17
-40 dB
Figure 27 Template for Reference Return Loss
359 The HS frequency, fHS, is half the HS data rate, DRHS. Other characteristic frequencies during operation in
HS-MODE are the maximum and minimum frequencies, fHS_MAX and fHS_MIN, respectively. fHS_MAX and
fHS_MIN are used in the S-parameter templates. All these frequencies are defined as fractions of DRHS as
shown by the following equations:
DR HS
f HS = --------------- (Equation 2)
2
3  D R HS
f HS_MAX = ------------------------ (Equation 3)
4
DR HS
f HS_MIN = --------------- (Equation 4)
10
360 An M-TX drives a differential low-swing signal with either Large Amplitude or Small Amplitude. The
amplitude of the differential output signal is doubled when the M-TX drives an unterminated load compared

Confidential
01-Dec-2016
to when it drives a terminated load. Differential output signals with large and small amplitudes for the
terminated and unterminated states are shown in Figure 28. All single-ended voltage levels are relative to the
ground voltage at the M-TX side.
361 The jitter of an HS-TX in HS-MODE is specified by means of a jitter transfer function with a corner
frequency fC_HS_TX. Jitter is integrated up to the upper transmitter cut-off frequency fU_TX. An additional
lower cut-off frequency fSTJ_TX is defined for the short term jitter of an HS-TX.
362 The jitter is defined for a BER of 10-12 according to [INC01]1. The mean () of the distribution function is
located at 0.
VDIF_LA_NT_TX
VCM_LA_TX
VDIF_LA_RT_TX
VDIF_SA_RT_TX
VDIF_SA_NT_TX VCM_SA_TX
GND
Small Amplitude Large Amplitude
Figure 28 M-TX Signal Levels
363 The reference parameters for the M-TX are summarized in Table 14.
Table 14 M-TX and HS-TX Reference Parameters

Values
Symbol Unit Description
Min. Nom. Max.
Reference Load
Reference load for when the M-TX is
RREF_RT 100 
terminated.
Reference load for when the M-TX is not
RREF_NT 10 k
terminated.
ZR 100  Reference impedance.
Reference Channel
Reference channel single-ended DC
RDC_REF_CH 4 
resistance.
Reference channel return loss limit from
SDDRL_REF_CH -15 dB
DC up to 6 GHz.
RDIF_REF_CH 100  Reference channel differential impedance.
1. The BER is changed from 10-10 to 10-12 in M-PHY v4.1. Other jitter definitions remain unchanged. The
change in BER is tightening the M-TX jitter requirements.

Confidential
01-Dec-2016
Table 14 M-TX and HS-TX Reference Parameters (continued)

Values
Min. Nom. Max.
Frequency
Corner frequency of clock and data recovery
fC_HS_G1_TX 2.0 MHz
transfer function in HS-G1.
fC_HS_G2_TX 4.0 MHz
fC_HS_G3_TX 8.0 MHz
fC_HS_G4_TX 8.0 MHz
1 -
---------------
fU_TX Hz Upper frequency of jitter transfer function.
2 UI HS
1 -
------------------
fSTJ_TX Hz Lower bound of short term jitter.
30UI HS
 0.707 N.A. Damping ratio of jitter transfer function.
Limit for BER
QBER 7.0345 Q-factor for a BER of 10-12
BER 10-12 Target BER
5.1.1.2 Differential and Common-mode Voltage

364 An M-TX drives a differential signal on the TXDP and TXDN PINs. The differential output voltage signal
VDIF_TX(t) is defined as the difference of the voltage signals VTXDP(t) and VTXDN(t). VDIF_TX is defined as
the amplitude of VDIF_TX(t). VDIF_TX(t) can be calculated from the following equation:
V DIF_TX  t  = V TXDP(t) – V TXDN  t  (Equation 5)
365 Separate AC and DC parameters are defined for VDIF_TX. The DC parameter VDIF_DC_TX is defined for an
M-TX which drives a steady DIF-N or a steady DIF-P LINE state into a reference load RREF_RT or RREF_NT.
An M-TX shall drive a differential DC output voltage amplitude which meets the specified limits of
VDIF_DC_TX. When the differential DC output voltage amplitude remains within the specified limits of
VDIF_DC_TX, the LINE has settled.
366 The AC parameter VDIF_AC_TX is defined for an M-TX which drives a test pattern into a reference load
RREF_RT or RREF_NT. For an HS-TX the lower limit of VDIF_AC_TX is defined over the eye opening TEYE_TX
as defined in Section 5.1.2.9. The upper limit of VDIF_AC_TX is defined as the maximum differential output
voltage, when the M-TX drives a test pattern into a reference load RREF_RT or RREF_NT. An M-TX shall drive
a differential AC output voltage signal which meets the specified limits of VDIF_AC_TX.
367 There is no definition for how long the lower limit of VDIF_AC_TX has to be met for a PWM-TX or a SYS-TX.
368 The common-mode output voltage signal VCM_TX(t) is defined as the arithmetic mean value of the signal
voltages VTXDP(t) and VTXDN(t) when the M-TX drives a test pattern into a reference load RREF_RT or
RREF_NT. VCM_TX is defined as the amplitude of VCM_TX(t). VCM_TX(t) can be calculated from the following
equation:
V TXDP(t) + V TXDN(t)
V CM_TX(t) = -------------------------------------------------- (Equation 6)
2

Confidential
01-Dec-2016
369 An M-TX shall drive a common-mode output voltage signal which meets the specified limits of VCM_TX.
370 VDIF_TX(t) and VCM_TX(t) for ideal single-ended output signals VTXDP(t) and VTXDN(t) are shown in
Figure 29.
Ideal Single-ended Signals
VTXDP(t)
VCM_TX (t) = (VTXDP(t) + VTXDN(t))/2

+VDIF_TX -VDIF_TX
VTXDN(t)
Ideal Differential Signal
VDIF_TX (t) = VTXDP (t) – VTXDN(t)

+VDIF_TX
0 V (differential)
-VDIF_TX
Figure 29 Ideal Single-ended and Differential Signals
5.1.1.3 Single-ended Output Resistance

371 The resistance RSE_TX is defined as the single-ended output resistance of an M-TX at both its TXDP and
TXDN PINs. RSE_TX is defined for the case of a terminated M-TX that drives either a DIF-P or DIF-N LINE
state with a reference load RREF_RT and a current source I connected between TXDP and TXDN as shown in
Figure 30. A change of the current I results in a change of the PIN signal voltages VTXDP and VTXDN.
372 IREF is defined as the value of the current source I that causes a variation of VTXDP and VTXDN by ±25 mV.
373 The single-ended output resistance shall conform with the specification limits of RSE_TX for both the DIF-N
and DIF-P state. An implementation should keep the output resistance during state transitions close to the
steady state output resistance.
TXDP RREF_RT/2
+
0/1 M-TX IREF
-
TXDN RREF_RT/2 VCM_TX

VTXDP VTXDN
Figure 30 Measurement Setup for Single-ended Output Resistance

Confidential
01-Dec-2016
374 In Equation 7 through Equation 10, VTXDP, VTXDN and VCM_TX are defined as the voltages of the
signals at the test points shown in Figure 30 at two distinct times, t 1 and t 2 , where t 2 > t 1 , such that
V = V(t1) – V(t2). The current source I sources IREF and -IREF. at t1 and t2, respectively.
375 The single-ended output resistance RSE_TX at TXDP can be calculated using the following equation:
 V TXDP
R SE_TX  TXDP  = --------------------------------------------------------------------------- (Equation 7)
 V TXDP –  V CM_TX
– 2I REF – -------------------------------------------------
R REF_RT  2
376 Similarly, the single-ended output resistance RSE_TX at TXDN can be calculated using the following
equation:
 V TXDN
R SE_TX  TXDN  = ----------------------------------------------------------------------- (Equation 8)
 V TXDN –  V CM_TX
2I REF – --------------------------------------------------
R REF_RT  2
377 RSE_PO_TX is defined as the single-ended output resistance of an M-TX in a STALL or SLEEP state at both
the TXDP and TXDN PINs. RSE_PO_TX is defined for a terminated M-TX, which drives either a DIF-N or a
DIF-P LINE state, when a reference load RREF_RT is connected between TXDP and TXDN. If the optional
RSE_PO_TX is utilized, the single-ended output resistance of an M-TX in the STALL or SLEEP states shall
conform with the specified limit of RSE_PO_TX.
378 VCM_TX and VDIF_TX shall stay in their specified limits during switching between RSE_TX and RSE_PO_TX.
RSE_PO_TX is an optional feature of an M-TX, which is defined to allow for power optimization in the STALL
and SLEEP states.
379 RSE_PO_TX is defined according to RSE_TX. Using the parameters of the RSE_TX definition, the single-ended
output resistance RSE_PO_TX at TXDP can be calculated using the following equation:
 V TXDP
R SE_PO_TX  TXDP  = --------------------------------------------------------------------------- (Equation 9)
 V TXDP –  V CM_TX
– 2I REF – -------------------------------------------------
R REF_RT  2
380 Similarly, the single-ended output resistance RSE_PO_TX at TXDN can be calculated from the following
equation:
 V TXDN
R SE_PO_TX  TXDN  = ----------------------------------------------------------------------- (Equation 10)
 V TXDN –  V CM_TX
2I REF – --------------------------------------------------
R REF_RT  2
5.1.1.4 Return Loss

381 The M-TX return loss parameters are based on a mixed-mode S-parameter matrix. The single ended
S-parameters are characterized using the reference impedance RREF_RT/2.
382 The characterization can be done with a setup as illustrated in Figure 31. In the figure, VC denotes the
common-mode voltage and VD denotes the differential voltage.

Confidential
01-Dec-2016
RREF_RT/2
M-TX
RREF_RT/2
VC – VD/2 VC + VD/2
Figure 31 Measurement Setup for M-TX Return Loss
383 The common-mode transmitter return loss, SCCTX, and the differential transmitter return loss, SDDTX, are
defined for an M-TX transmitting a repetitive CRPAT into a reference load RREF_RT/4 for SCCTX, and
RREF_RT for SDD TX. SDD TX and SCC TX parameters are considered to be informative.When an M-TX
supports Large Amplitude and Small Amplitude its SCC TX and SDD TX should conform with the
specification limits for both amplitudes. SCCTX and SDDTX are defined at the PINs such that they include
contributions from the on-chip circuitry as well as from the package.
384 The SDDTX template is shown in Figure 32 along with the return loss at corner frequencies fHS_MIN, fHS and
fHS_MAX. SCCTX is defined for frequencies up to fHS_MAX. An M-TX should fulfill both the common-mode
transmitter return loss SCCTX and the differential transmitter return loss SDDTX specification limits.
log f
0 fHS_MIN f HS fHS_MAX
0
SDD TX
[dB]
Frequency f HS_MIN fHS fHS_MAX

HS-G1 -17 -10 -7
HS-G2 -17 -4.8 -3
HS-G3 -13 -3.8 -2
HS-G4 -11 -2.2 -1
Figure 32 Template for Differential Transmitter Return Loss SDDTX
5.1.1.5 LINE Disturbance during M-TX Power-up

385 An M-TX in a Type-I LINK shall not cause a LINE condition upon the transition from the UNPOWERED to
a POWERED state which can be detected as a non-squelch state by the SQ-RX of the LANE. The allowed
LINE disturbance upon such a transition of an M-TX is hence restricted by the squelch pulse rejection as
defined in Section 5.2.5.

Confidential
01-Dec-2016
386 Squelch detection is not used in a Type-II LINK. Hence, there is no restriction of the LINE disturbance
caused by an M-TX upon the transition from the UNPOWERED state to a POWERED state in such a LINK.
5.1.1.6 Common M-TX Parameters

387 The common electrical and timing parameters of an M-TX are listed in Table 15.
Table 15 Common M-TX Parameters

Values
Min. Max.
M-TX Electrical
Large Amplitude differential TX DC voltage when the
VDIF_DC_LA_RT_TX 160 300 mV M-TX is terminated. Defined for RREF_RT1 and test
pattern2. See Section 5.1.1.2.
Large Amplitude differential TX AC voltage when the
VDIF_AC_LA_RT_TX3 140 310 mV M-TX is terminated. Defined for RREF_RT1 and
CRPAT4. See Section 5.1.1.2.
Large Amplitude differential TX DC voltage when the
VDIF_DC_LA_NT_TX 320 600 mV M-TX is not terminated. Defined for RREF_NT5 and test
Large Amplitude differential TX AC voltage when the
VDIF_AC_LA_NT_TX3 280 620 mV M-TX is not terminated. Defined for RREF_NT5 and
Small Amplitude differential TX DC voltage when the
VDIF_DC_SA_RT_TX 100 190 mV M-TX is terminated. Defined for RREF_RT1 and test
Small Amplitude differential TX AC voltage when the
VDIF_AC_SA_RT_TX3 80 200 mV M-TX is terminated. Defined for RREF_RT1 and
Small Amplitude differential TX DC voltage when the
VDIF_DC_SA_NT_TX 200 380 mV M-TX is not terminated. Defined for RREF_NT5 and test
Small Amplitude differential TX AC voltage when the
VDIF_AC_SA_NT_TX3 160 400 mV M-TX is not terminated. Defined for RREF_NT5 and
Large Amplitude common-mode TX voltage. Defined
VCM_LA_TX 160 310 mV for RREF_RT1 or RREF_NT5 and CRPAT6.
See Section 5.1.1.2.
Small Amplitude common-mode TX voltage. Defined
VCM_SA_TX 80 240 mV for RREF_RT1 or RREF_NT5 and CRPAT6.
M-TX Resistance
Single-ended output resistance. Defined for RREF_RT1.
RSE_TX 40 60 
Single-ended output resistance in STALL or SLEEP
RSE_PO_TX 10 k
states. Defined for RREF_RT1. See Section 5.1.1.3.

Confidential
01-Dec-2016
Table 15 Common M-TX Parameters (continued)

Values
Min. Max.
M-TX Return Loss
Common-mode transmitter return loss. Defined for
SCCHS_G1_TX -6.0 dB (RREF_RT/4)1 up to fHS_MAX and test pattern6. See
Section 5.1.1.4.
Section 5.1.1.4.
Section 5.1.1.4.
1. External reference load RREF_RT and a reference impedance ZREF_RT that conform to SRLREF_RT.
2. Defined when driving both a DIF-N and a DIF-P LINE state.
3. The M-TX HS-G3 and HS-G4 AC differential amplitude voltages are validated through eye-mask
conformance at the end of a reference channel, CH1 or CH2, using a CRPAT test pattern. See
Section 5.1.2.9.
4. Measurement based on accumulative eye diagram. Measurements are accomplished using the
Compliant Random Pattern (CRPAT).
5. External reference load RREF_NT and capacitances at TXDP and at TXDN within the limit of
CPIN_RX.
6. Defined for a repetitive CRPAT.
7. The listed parameters should be measured with de-emphasis turned off.
5.1.2 HS-TX Characteristics

388 This section contains the electrical and timing characteristics specific to an HS-TX which are not covered by
the common M-TX parameters in Section 5.1.1.
5.1.2.1 Rise and Fall Times

389 The HS-TX rise and fall times, TR_HS_TX and TF_HS_TX, respectively, are defined as transition times between
the 20% and 80% signal levels of the differential HS-TX output signal with an amplitude of VDIF_DC_TX,
when driving a pattern into a reference load, R REF_RT or R REF_NT. The HS-TX rise and fall times are
considered to be informative. The pattern used for measurement is a minimum of two UI HS of DIF-P
followed by a minimum of two UI HS of DIF-N for TF_HS_TX , and a minimum of two UI HS of DIF-N,
followed by a minimum of two UIHS of DIF-P for TR_HS_TX.
5.1.2.2 Slew Rate

390 The slew rate SRDIF_TX is defined as the ratio V/T, where V is the absolute value of the voltage difference
of the differential HS-TX output signal voltage measured at the 20% and 80% levels of VDIF_DC_SA_RT_TX
and T is the corresponding time difference when the HS-TX drives a reference load RREF_RT with Small
Amplitude. The specification limits of SRDIF_TX shall be met by an HS-TX that supports slew rate control
and which is operated in HS-G1.
391 The slew rate of the HS-TX should be controllable to allow for N different slew rate states. SRDIF_TX[1] and
SRDIF_TX[N] denominate the slew rate for the fastest and for the slowest slew rate states, respectively. The
number N is implementation-specific and is out of scope for this document. The slew rate states should cover
a range defined by the maximum slew rate SRDIF_TX[MAX] and the minimum slew rate SRDIF_TX[MIN]. For

Confidential
01-Dec-2016
at least one state the slew rate should be larger than SRDIF_TX[MAX]. For at least one state it should be
smaller than SRDIF_TX[MIN].
392 The slew rate shall be monotonically decreasing when stepping from faster to slower slew rate states, i.e.,
SRDIF_TX[i] is larger than SRDIF_TX[i+1], where i is in the range of 1 to N-1. It shall be monotonically
increasing when stepping from slower to faster slew rate states. A given slew rate correspondence between
setting and value is not intended to be specified, rather range and granularity are provided. The range of slew
rate settings is intended to exceed the range of conformant slew rate values to allow control over common
mode noise and EMI (see Section 5.1.2.10.1).
393 The resolution of the slew rate states SRDIF_TX is defined as the difference of the slew rates of two adjacent
slew rate states divided by the slew rate of the slower state.
394 SRDIF_TX can be calculated using the following equation:
DIF_TX SR  i  – SR DIF_TXi + 1
 SR DIF_TX = --------------------------------------------------------------------------- (Equation 11)
SR DIF_TX  i + 1 
395 where SRDIF_TX[i+1] is the slew rate of the slower slew rate state and SRDIF_TX[i] is the slew rate of the
adjacent faster slew rate state.  SR DIF_TX shall be met between SR DIF_TX [1] and SR DIF_TX [N] (see
Table 16).
5.1.2.3 Intra-LANE Output Skew

396 The transmitter intra-LANE output skew, TINTRA_SKEW_TX, is defined as the time between the intersections
of the single-ended output signals VTXDP(t) and VTXDN(t) with the averaged common-mode voltage VCM_TX,
when the HS-TX drives a test pattern into a reference load RREF_RT or RREF_NT. The transmitter intra-lane
output skew shall be in the specification limits of TINTRA_SKEW_TX. A skew of the single-ended output
signals results in a common-mode voltage ripple as illustrated in Figure 33.
Real Single-Ended Signals Ideal Single-Ended Signals
VTXDP(t)
VCM_TX(t)
+VDIF_TX -VDIF_TX
VTXDN(t)
TINTRA_SKEW_TX TINTRA_SKEW_TX
Figure 33 Impact of Signal Skew on Common-mode
5.1.2.4 LANE-to-LANE Skew

397 The HS-TX LANE-to-LANE skew TL2L_SKEW_HS_TX is defined as the time between the zero crossings of
the differential output signals VDIF_TX(t) of any two HS-TXs in one SUB-LINK, when both HS-TX drive a
test pattern into identical reference loads RREF_RT or RREF_NT. The value of TL2L_SKEW_HS_TX is outside the
scope of this document. If required, it shall be defined in the protocol specification.
5.1.2.5 Output Resistance Mismatch

398 The HS-TX output resistance mismatch, RSE_TX, is defined as the difference of the single-ended output
resistances, R SE_TX , at the TXDP and TXDN PINs, when the HS-TX drives CRPAT test pattern into a
reference load, RREF_RT or RREF_NT. RSE_TX is defined in Section 5.1.1.3.

Confidential
01-Dec-2016
399 RSE_TX can be calculated from the following equation:
 R SE_TX = R SE_TX  TXDP  – R SE_TX  TXDN  (Equation 12)
400 where RSE_TX(TXDP) is the output resistance driving either a DIF-N or a DIF-P and RSE_TX(TXDN) is the
output resistance driving either a DIF-N or a DIF-P such that Equation 12 has to be evaluated for four cases.
The HS-TX output resistance mismatch shall be in the limits of RSE_TX for all four cases.
401 Transmitter output signal mismatch, as well as the transmitter output gain mismatch, originates from
RSE_TX. The transmitter output gain mismatch definition is out of scope for this document. A transmitter
output signal mismatch results in different signal transition times as well as in different differential DC output
voltages VDIF_DC_TX when driving a DIF-P or a DIF-N LINE state. Both effects cause a ripple of VCM_TX.
An example of a VCM_TX ripple is illustrated in Figure 34.
VTXDP(t)
VCM_TX(t)
+VDIF_TX
-VDIF_TX
VTXDN(t)
Figure 34 Impact of Output Signal Mismatch on Common-mode Voltage
5.1.2.6 Transmitter Pulse Width

402 The transmitter pulse width TPULSE_TX of an HS-TX differential output signal is defined as the time between
the zero crossings of a single bit of the differential output signal VDIF_TX(t) when driving a test pattern into a
reference load RREF_RT or RREF_NT. The transmitter pulse width of an HS-TX output signal should conform
with the lower limit of TPULSE_TX.
5.1.2.7 Transmitter Jitter

403 To ensure interoperability among the components that comprise an end-to-end LANE, the jitter budget must
be adhered to by the HS-TX and the HS-RX. The LINE characteristics are indirectly defined by the HS-TX
jitter characteristics and by the HS-RX jitter tolerance. While the jitter budgets for reference clock and PLLs
are not explicitly defined, the impact of these circuits is included in the jitter budget.
404 The transmitter total jitter TJTX is a convolution of the deterministic jitter DJTX and the random jitter RJTX of
the differential output signal V DIF_TX (t) of the HS-TX. TJ TX is the sum of the arithmetic sum of the
deterministic jitter contributions DJTX[j], where DJTX[j] are peak-to-peak values, and the square root of the
sum of squared random jitter contributions RJTX[i] multiplied by two times the Q-factor QBER, which is a
constant depending on the BER.
405 TJTX can be calculated using following equation:
2
TJTX =  DJTX  j  + 2QBER  RJTX  i  (Equation 13)
j i
406 Using the dual-Dirac model, TJTX can be expressed by the following equation:
TJ TX = DJ TX    + 2Q BER  (Equation 14)
407 where DJTX() is the time between two Dirac pulses and  is the standard deviation of the Gaussian random
jitter of the HS-TX. DJTX() is the dual-Dirac model for the deterministic jitter of the HS-TX and  is the

Confidential
01-Dec-2016
model for the random jitter of the HS-TX. Further details of the dual-Dirac jitter model are described in
[INC01].
408 This specification defines the TJTX and the DJTX(). In addition, the short term total jitter, STTJTX, and the
short term deterministic jitter, STDJTX( ), which limit the jitter within a 30UI HS signal sequence, are
specified. The short term jitter corresponds to a high frequency jitter in the frequency domain.
409 The HS-TX jitter spectrum spans from very low frequencies up to high frequencies. In the low frequency
range, HS-TX jitter can be significant down to a few kHz. An HS-RX at the other end of the LANE tracks the
low frequency jitter components and behaves as a high pass jitter filter. Therefore the HS-TX jitter is filtered
with a high-pass jitter transfer function HJTF(s), which is defined in the following equation:
2
s
H JTF  s  = ----------------------------------------------
2
-
2
(Equation 15)
s + 2 m s +  m
C_HS_TX f
410 where  m = 2f m and fm = -------------------------------------------------------------------
- . The clock and data recovery transfer function can
2 2 2
1 + 2 + 1 +  1 + 2 
be expressed by the following equation:
2
2 m s +  m -
H CDR  s  = ----------------------------------------------
2 2
(Equation 16)
s + 2 m s +  m
411 After HJTF(s) is applied to the jitter, TJTX is determined by integrating over the frequency range from larger
than 0 Hz up to fU_TX. Figure 35 shows a plot of HJTF(s) and HCDR(s).
412 A 1st order high-pass filter with the pole at fSTJ_TX is applied to the transmit jitter to determine STTJTX.
413 The transmitter total jitter TJTX and deterministic jitter DJTX() are defined for the differential output signal
VDIF_TX(t) at the zero crossings when the HS-TX is driving a CRPAT test pattern into a reference load
RREF_RT or RREF_NT . The transmitter total jitter and deterministic jitter of an HS-TX shall conform with the
limits of TJTX and DJTX(),respectively.
414 The transmitter short term total jitter STTJTX and short term deterministic jitter STDJTX() are defined for
the differential output signal VDIF_TX(t) at the zero crossings when the HS-TX is driving a CRPAT test pattern
into a reference load RREF_RT or RREF_NT. The transmitter short term total jitter and short term deterministic
jitter of an HS-TX shall conform with the limits of STTJTX and STDJTX(), respectively. Note that jitter in
non-terminated mode cannot be practically measured.

Confidential
01-Dec-2016
HCDR(s) HJTF(s)
0
-5
Magnitude [dB]
-10
-15
-20
-25
1.00E+04 1.00E+05 1.00E+06 1.00E+07 1.00E+08
Frequency [Hz]
Figure 35 Clock and Data Recovery Transfer Function and Jitter Transfer Function
5.1.2.8 Transmitter De-emphasis

415 To mitigate additional channel-induced ISI at HS-G3 data rates or above, an HS-TX can utilize channel
equalization in the form of de-emphasis. The transmitter de-emphasis has two taps, where the first tap is the
cursor and the second tap is the first post-cursor. The taps are separated by UIHS and the transmitter de-
emphasis ratio EQTX determines the de-emphasis level. Two de-emphasis ratios are defined.
416 Figure 36 shows an example transmit waveform with de-emphasis. After a logical bit transition, the
amplitude of the differential output voltage signal VDIF_TX(t) conforms to the differential AC output voltage
amplitude V DIF_AC_TX . The next bit that retains the same logical state is reduced in amplitude. The
differential AC output voltage amplitude with de-emphasis V DIF_AC_EQ_TX is defined as the reduced
amplitude. EQTX is defined as the minus 20 log of the ratio of VDIF_AC_EQ_TX and VDIF_AC_TX as shown in
the following equation:
V DIF_AC_EQ_TX
EQ TX = – 20 log  ------------------------------------- (Equation 17)
V DIF_AC_TX

Confidential
01-Dec-2016
Figure 36 Example Transmit Waveform with De-emphasis
417 An HS-TX with de-emphasis, when operated in HS-G3 or above, shall conform to the HS-G3 and HS-G4
transmitter eye diagram mask (see Section 5.1.2.9). The transmitter de-emphasis defined for HS-G3 and
above may be implemented in HS-G1 and HS-G2 to facilitate longer channel lengths at lower data rates.
5.1.2.9 Transmitter Eye Opening

418 The transmitter eye opening, TEYE_TX, is defined as the duration in an eye diagram over which the absolute
value of the differential HS-TX output signal has to be larger than the lower limit of VDIF_AC_TX when the
HS-TX transmits a test pattern into a reference load RREF_RT or RREF_NT. TEYE_TX is defined for HS-G1 and
HS-G2.
419 TEYE_TX, VDIF_AC_TX and TJTX/2 define the eye mask for the accumulated M-TX signal in HS-G1 and
HS-G2 as shown in Figure 37. The absolute value of the HS-TX differential output voltage signal shall be
larger than the lower limit of VDIF_AC_TX over TEYE_TX. The accumulated eye diagram shall conform to the
eye diagram mask. For HS-G1 the position of TEYE_TX is limited by (UIHS - TEYE_TX)/2 to the left and
TJTX/2 to the right. For HS-G2 the midpoint of TEYE_TX is located at UIHS/2.
420 For HS-G3 the transmitter eye opening, TEYE_HS_G3_TX is defined as the duration over which no zero
crossings of VDIF_TX(t) are allowed in the eye diagram when the HS-TX transmits a test pattern into a
reference channel that is terminated with a reference load RREF_RT. Reference Channels CH1 and CH2 are
defined in Section 5.1.1.1.
421 For HS-G4 the transmitter eye opening, TEYE_HS_G4_TX is defined as the duration over which no zero
crossings of VDIF_TX(t) are allowed in the eye diagram when the HS-TX transmits a test pattern into a
reference channel that is terminated with a reference load RREF_RT and after the reference package and
reference channel equalizer. Reference Channels CH1 and CH2 and reference package are defined in
Section 5.1.1.1 and the receiver reference equalizers are defined in Section 5.2.1.1.
422 TEYE_HS_G3_TX and VDIF_AC_HS_G3_TX define the eye mask for the accumulated M-TX signal in HS-G3 and
HS-G4, as shown in Figure 38. TEYE_HS_G4_TX and VDIF_AC_HS_G4_TX define similarly the eye mask for the
accumulated M-TX signal in HS-G4. The accumulated M-TX signal in HS-G4 is defined after the reference
package and reference channel equalizer. The midpoints of TEYE_HS_G3_TX and TEYE_HS_G4_TX are located
at UI HS /2. The absolute value of the HS-TX differential output voltage signal shall be larger than
V DIF_AC_HS_G3_TX or V DIF_AC_HS_G4_TX at the midpoint of T EYE_HS_G3_TX or T EYE_HS_G4_TX ,

Confidential
01-Dec-2016
respectively. The accumulated eye diagram of an HS-TX in HS-G3 or in HS-G4 shall conform to the HS-G3
and HS-G4 eye diagram mask.
423 The parameters shown in Figure 37 and Figure 38 are based on the accumulated eye for the target BER,
where the total transmit jitter TJTX is defined around the mean of the zero crossings of the differential HS-TX
output voltage signal.
VDIF_AC_TX
VDIF_AC_TX Maximum
Minimum
0V 0V
Shaded areas VDIF_AC_TX

are keep-out Minimum VDIF_AC_TX
regions Maximum
TJTX/2 TEYE_TX TJTX /2

UIHS
Figure 37 HS-G1 and HS-G2 Differential Transmit Eye Diagram

Confidential
01-Dec-2016
TEYE_G3/G4_TX/2
0.5UIHS
VDIF_AC_TX
VDIF_AC_HS_G3/G4_TX Maximum
0V 0V
VDIF_AC_HS_G3/G4_TX
Shaded areas VDIF_AC_TX
are keep-out Maximum
regions
TEYE_HS_G3/G4_TX
UIHS
Figure 38 HS-G3 and HS-G4 Differential Transmitter Eye Diagram
5.1.2.10 Power Spectral Magnitude Limit

424 A power spectral magnitude limit is defined for the common-mode interference spectrum. A method of
acquiring the common-mode interference spectrum of an HS-TX is also defined.
5.1.2.10.1 Common-mode Power Spectral Magnitude Limit

425 The common-mode interference spectrum of the HS-TX is impacted by the intra-lane timing skew and gain
mismatches of the output signals at the TXDP and TXDN PINs. Slew rate control is an effective means of
limiting electromagnetic interference (EMI) of an HS-TX. The level of interference, quantified by the power
spectral density measured at TXDP and TXDN, can be controlled by the slew rate of the HS-TX signal
waveform. Smaller slew rates result in a significant suppression of high frequency content of the HS-TX
output power spectral density. The slew rate limit is application specific and interconnect dependent.
426 A common-mode power spectral magnitude limit is defined along with a method of generating the spectra of
an HS-TX.
427 The common-mode power spectral magnitude limit PSMLCM1_TX for HS-G1 is shown in Figure 39 and
defined by:
3
PSML CM1_TX = – 180 –  14.3log 10  f  10  – 159  (Equation 18)
428 where f ranges between fHS_MIN to 4*fHS_MAX in MHz.

429 For HS-G2 or above, common-mode power spectral magnitude limit PSMLCM2_TX is defined by:
3
PSML CM2_TX = – 235 –  5.0log 10  f  10  – 159  (Equation 19)
430 where f ranges between fHS_MIN to 4*fHS_MAX in MHz.

Confidential
01-Dec-2016
431 PSMLCM1_TX can be achieved by proper slew-rate control as well as by conforming to the limits of intra-lane
timing skew, output resistance mismatch and output signal amplitude. PSMLCM2_TX assumes additional
package isolation as compared to PSML CM1_TX. Furthermore, specific package isolation and victim-
aggressor geometry should be considered in order to minimize interference. An M-TX should conform to
PSMLCM1_TX or PSMLCM2_TX. Spurs may violate PSMLCM1_TX or PSMLCM2_TX outside the radio bands of
interest. RATE Series A or B can be selected in order to minimize the interference.
432 For illustration purposes the common-mode power-spectral density of an 8b10b coded common-mode
interference signal (gray curve) is also shown in Figure 39. This curve does not show the spurs at the
fundamental frequency nor at the harmonics of the data signal.
Power Spectral Density

-80
Common-Mode Limit
-100 F, MHz Limit, dBm/Hz
Power Spectrum Magnitude, dBm/Hz
500 -109.9
1000 -119.8
-120 1500 -125.6
Common-mode Limit 2000 -129.7
2500 -132.9
-140 3000 -135.5
3500 -137.7
> 4000 -139.6
-160
-180
-200
500 1000 1500 2000 2500 3000 3500 4000
Frequency, MHz
Figure 39 Common-mode Power Spectral Magnitude Limit
5.1.2.10.2 Spectrum Generation Method

433 The method of acquiring the common-mode interference spectrum of an HS-TX can be applied both in
simulation and measurement. The method is described in the following list:
434 • The operating condition of the HS-TX should be chosen such that it results in the maximum
amplitude for the selected amplitude setting when the M-TX is terminated with a reference load
RREF_RT. In case the HS-TX is operated with Small Amplitude, the temperature, supply voltage,
and process should be selected to result in a maximum HS-TX amplitude. This does not imply that
the investigation has to be performed with Large Amplitude instead of Small Amplitude.
435 • A continuous CRPAT test pattern should be used, where regular signal sequences may be used.
436 • The HS-TX common-mode signal VCM_TX(t) is calculated from the VTXDP(t) and VTXDN(t)
signals.
437 • A load of 50  is assumed for power calculation.
438 • The FFT of the common-mode signal with a Hamming window results in the interference
spectrum, which has to be adjusted for the relevant bandwidth, is defined by:
 2  abs(FFT(x)) 2 1  R-
PSD = 10log 10  ----------------------------------------- + 10log 10  ---------- (Equation 20)
 fs  S   – 3
10

Confidential
01-Dec-2016
where
439 • x = signal to analyze
440 • fs = sampling frequency
441 • S = sum(Hamming window2), is the Hamming window correction factor
442 • R = 50  (assumes an ideal probe antenna placed at the midpoint of the M-TX outputs)
5.1.2.11 Transmitter Frequency Offset

443 The transmitter frequency offset fOFFSET_TX is defined as the difference of the actual HS-TX frequency from
the nominal HS-TX frequency fHS. fOFFSET_TX is defined at the zero crossings of the differential HS-TX
output signal when driving a test pattern into a reference load RREF_RT or RREF_NT. The transmitter frequency
offset of an HS-TX shall conform with the limits of fOFFSET_TX. Modulation of the transmitter frequency
(e.g., by spread spectrum clocking) is not intended.
5.1.2.12 HS-TX Parameters

444 The electrical and timing parameters specific to an HS-TX are summarized in Table 16. Other than
parameters VDIF_AC_HS_G3_TX and TEYE_HS_G3_TX, the HS-TX parameters are defined at the M-TX pins
without de-emphasis. A channel with negligible loss or de-embedding method may be used to obtain the
measurements of all other timing, slew-rate and jitter parameters.
Table 16 HS-TX Parameters

Values
Min. Max.
HS-TX Electrical
Differential TX AC voltage in HS-G3. Defined for a
VDIF_AC_HS_G3_TX 40 mV reference channel, RREF_RT and CRPAT. See
Section 5.1.2.9.
Differential TX AC voltage in HS-G4. Defined for a
VDIF_AC_HS_G4_TX 40 mV reference channel, RREF_RT and CRPAT. See
Section 5.1.2.9.
HS-TX Timing
Fall time. Defined for RREF_RT2 or RREF_NT3 and test
TF_HS_TX1 0.1 UIHS
Rise time. Defined for RREF_RT2 or RREF_NT3 and test
TR_HS_TX1 0.1 UIHS
Maximum slew rate. Defined in HS-G1 for
SRDIF_TX[MAX] 0.9 V/ns VDIF_DC_SA_RT_TX5, RREF_RT6, and CRPAT. See
Section 5.1.2.2.
Minimum slew rate. Defined in HS-G1 for
SRDIF_TX[MIN] 0.35 V/ns VDIF_DC_SA_RT_TX5, RREF_RT6, and CRPAT. See
Section 5.1.2.2.
Resolution of slew rate states. Defined in HS-G1 for
SRDIF_TX 1 30 % VDIF_DC_SA_RT_TX5, RREF_RT6, and CRPAT. See
Section 5.1.2.2.
Intra-lane output skew. Defined for RREF_RT2 or
TINTRA_SKEW_TX -0.06 0.06 UIHS
RREF_NT3 and CRPAT. See Section 5.1.2.3.

Confidential
01-Dec-2016
Table 16 HS-TX Parameters (continued)

Values
Min. Max.
Transmitter pulse width. Defined for RREF_RT2 or
TPULSE_TX 0.9 UIHS
HS-TX Resistance
Output resistance mismatch. Defined for RREF_RT2 or
RSE_TX -6 6  RREF_NT3 when driving DIF-N and DIF-P. See
Section 5.1.2.5.
HS-TX Jitter
Transmitter eye opening in HS-G1 and HS-G27.
TEYE_TX 0.2 UIHS Defined for RREF_RT2 or RREF_NT3 and CRPAT over a
statistical confident record set8. See Section 5.1.2.9.
Transmitter eye opening in HS-G3. Defined for a
TEYE_HS_G3_TX 0.55 UIHS Reference Channel, RREF_RT2 and CRPAT over a
Transmitter eye opening in HS-G4. Defined for a
TEYE_HS_G4_TX 0.5 UIHS Reference Channel, RREF_RT2 and CRPAT over a
Transmitter deterministic jitter9. Defined for RREF_RT2
DJTX() 0.15 UIHS or RREF_NT3 and CRPAT for a statistical confident
record set8,10. See Section 5.1.2.7.
Transmitter total jitter9. Defined for RREF_RT2 or
TJTX 0.32 UIHS RREF_NT3 and CRPAT for a statistical confident record
set8,10. See Section 5.1.2.7.
Transmitter short term deterministic jitter9. Defined for
STDJTX() 0.10 UIHS RREF_RT2 or RREF_NT3 and CRPAT for a statistical
confident record set10,11. See Section 5.1.2.7.
Transmitter short term total jitter9. Defined for RREF_RT2
STTJTX 0.20 UIHS or RREF_NT3 and CRPAT for a statistical confident
record set10,11. See Section 5.1.2.7.
Transmitter frequency offset. Defined for RREF_RT2 or
fOFFSET_TX -2000 2000 ppm
HS-TX De-emphasis
De-emphasis ratio defined for Small and Large
EQ1_TX 2.5 4.5 dB
Amplitude differential TX voltage. See Section 5.1.2.8.
De-emphasis ratio defined for Large Amplitude
EQ2_TX 5.0 7.0 dB
differential TX voltage. See Section 5.1.2.8.
1. TR_HS_TX and TF_HS_TX are informative.

2. External reference load RREF_RT and a reference impedance ZREF_RT that conforms to SRLREF_RT.
CPIN_RX.
4. Repetitive sequence of D.30.3 symbols to be used for test. Such a sequence is part of CJTPAT.
5. Values are specified for Small Amplitude. For Large Amplitude the slew rate is a factor of 1.85
larger.

Confidential
01-Dec-2016
6. External reference load RREF_RT and a reference impedance ZREF_RT that conforms to SRLREF_RT.
The slew rate is only specified for when the M-TX is terminated. When the M-TX is not terminated,
slew rate control is not strictly required due to smaller LINE power. However, slew rate control may
also be used when the M-TX is not terminated, but in this case how the slew rate control performs
is not specified.
7. For slower slew rate settings the transmitter eye mask may be violated.
8. Filtered using a high-pass jitter transfer function HJTF(s).
9. Accumulated jitter as defined by the dual-Dirac model.
10. Measured for the target BER.
11. Filtered using a1st order high-pass filter with a pole at fSTJ_TX.
5.1.3 PWM-TX Characteristics

445 This section contains timing characteristics specific to a PWM-TX which are not covered by the common
M-TX characteristics in Section 5.1.1. The PWM signaling scheme is defined in Section 4.3.2.
5.1.3.1 PWM Bit Duration, Bit Duration Tolerance, and Ratio

446 A PWM bit consists out of a DIF-N LINE state followed by a DIF-P LINE state, which are either signaled for
the minor duration T PWM_MINOR_TX or for the major duration T PWM_MAJOR_TX . The durations
TPWM_MINOR_TX and TPWM_MAJOR_TX are defined as the time between the zero crossings of the differential
output signal.
447 The PWM transmit bit duration TPWM_TX is defined as the duration between zero crossings of two
consecutive falling edges of a differential signal at the PWM-TX output. T PWM _ MI NO R_T X ,
TPWM_MAJOR_TX, and TPWM_TX are shown in Figure 40. The PWM transmit bit duration TPWM_TX is for all
PWM GEARs the sum of its durations TPWM_MINOR_TX and TPWM_MAJOR_TX, as shown in the following
equation:
T PWM_TX = T PWM_MINOR_TX + T PWM_MAJOR_TX (Equation 21)
TPWM_MINOR_TX TPWM_MAJOR_TX
TPWM_MAJOR_TX TPWM_MINOR_TX
TPWM_TX
Figure 40 TX Minor and Major Duration in a PWM Signal
448 TPWM_MINOR_TX and TPWM_MAJOR_TX are determined by TPWM_TX and the PWM transmit ratio kPWM_TX
for PWM-G1 and higher PWM GEARs. k PWM_TX is defined as the ratio of T PWM_MAJOR_TX and
TPWM_MINOR_TX of one PWM bit, as shown in the following equation:
T PWM_MAJOR_TX
k PWM_TX = ----------------------------------------- (Equation 22)
T PWM_MINOR_TX

Confidential
01-Dec-2016
449 For PWM-G0 the minor duration TPWM_G0_MINOR_TX is directly specified. The range of
TPWM_G0_MINOR_TX is defined based on the minor duration in PWM-G1.
450 The PWM transmit bit duration tolerance, TOLPWM_TX, is the allowed tolerance of an instantaneous PWM
bit duration, TPWM_TX(i), in PWM-MODE. TOLPWM_TX is defined as the ratio of TPWM_TX(i) and the
average of N PWM transmit bit durations in PWM-MODE, as shown in the following equation:
T PWM_TX(i)
TOL PWM_TX = ------------------------------------------
N
-
1-
(Equation 23)
N  PWM_TX
--- T (j)
j=1
451 where N is a defined number of PWM bits, and i is in the range of 1 to N.

452 While the TPWM_TX range is wide for a PWM GEAR, TOLPWM_TX limits the variation of TPWM_TX(i). In
addition, a more restrictive transmit bit duration tolerance, TOLPWM_G1_LR_TX, is defined during LINE-
READ in PWM-G1
453 TOLPWM_G1_LR_TX is the allowed tolerance of TPWM_TX(i) during a LINE-READ state in PWM-G1.
TOLPWM_G1_LR_TX is defined as the ratio of TPWM_TX(i) and the average of N PWM transmit bit durations in
PWM-MODE, similar to the TOLPWM_TX definition in Equation 23. TOLPWM_G1_LR_TX is not defined for
states other than LINE-READ during a PWM-BURST.
454 A PWM-TX shall output a PWM signal with PWM transmit bit duration, TPWM_TX, in the specified range of
the operational PWM-GEAR during a PWM-BURST. For PWM-G1 and higher GEARs the PWM transmit
ratio k PWM_TX shall be in the specified range for each PWM bit. For PWM-G0 the minor duration
TPWM_G0_MINOR_TX shall be in the specified range for each PWM bit.
455 A PWM-TX shall output a PWM signal with PWM transmit bit duration tolerance in the limits of
TOLPWM_TX.
456 A PWM-TX shall output a PWM signal with PWM transmit bit duration tolerance in the limits of
TOLPWM_G1_LR_TX during LINE-READ in PWM-G1.
5.1.3.2 Rise and Fall Time

457 The PWM-TX rise and fall times, TR_PWM_TX and TF_PWM_TX, respectively, are defined as transition times
between the 20% and 80% signal levels of the differential PWM-TX output signal with an amplitude of
VDIF_DC_TX, when driving a reference load RREF_NT. The rise and fall times of a PWM-TX shall comply with
the limits of TR_PWM_TX and TF_PWM_TX.

458 The PWM-TX LANE-to-LANE skew TL2L_SKEW_PWM_TX is defined as the time between the zero crossings
of the falling edges of the differential output signals VDIF_TX(t) of any two PWM-TXs in one SUB-LINK,
when both PWM-TX drive a test pattern into identical reference loads RREF_RT or RREF_NT. The value of
TL2L_SKEW_PWM_TX is outside the scope of this document. If required, it shall be defined in the protocol
specification.
5.1.3.4 PWM-TX Parameters

459 The timing parameters specific to a PWM-TX are summarized in Table 17.

Confidential
01-Dec-2016
Table 17 PWM-TX Parameters

Values
Min. Max.
1--- 1- PWM transmit bit duration in PWM-G0. Defined for
TPWM_G0_TX --------- s
3 0.01 RREF_NT1 and CRPAT. See Section 5.1.3.1.
1--- 1--- PWM transmit bit duration in PWM-G1. Defined for
TPWM_G1_TX s
9 3 RREF_NT1 and CRPAT. See Section 5.1.3.1.
1- 1--- PWM transmit bit duration in PWM-G2. Defined for
TPWM_G2_TX ----- s
1- 1- PWM transmit bit duration in PWM-G3. Defined for
TPWM_G3_TX ----- ----- s
TPWM_G4_TX ----- ----- s
1 1 PWM transmit bit duration in PWM-G5. Defined for
TPWM_G5_TX --------- ------ s
TPWM_G6_TX -------- ----- s
TPWM_G7_TX -------- -------- s
PWM transmit bit duration tolerance. Defined for
TOLPWM_TX 0.90 1.10 RREF_NT1 and CRPAT in PWM-MODE. See
Section 5.1.3.1.
PWM transmit bit duration tolerance during
TOLPWM_G1_LR_TX 0.97 1.03 LINE-READ in PWM-G1. Defined for RREF_NT1
during LINE-READ. See Section 5.1.3.1.
Number of PWM bits. Sequence length for
N 50 50 TOLPWM_TX and TOLPWM_G1_LR_TX. See
Section 5.1.3.1.
1- 1--- PWM transmit minor duration in PWM-G0. Defined
TPWM_G0_MINOR_TX ----- s
27 9 for RREF_NT1 and CRPAT. See Section 5.1.3.1.
PWM transmit ratio for PWM-G1 and higher PWM
0.63 0.72
kPWM_TX ---------- ---------- GEARs. Defined for RREF_NT1 and CRPAT. See
0.37 0.28
Section 5.1.3.1.
Rise time. Defined for RREF_NT1 and CRPAT. See
TR_PWM_TX 0.070 TPWM_TX
Section 5.1.3.2.
Fall time. Defined for RREF_NT1 and CRPAT. See
TF_PWM_TX 0.070 TPWM_TX
Section 5.1.3.2.
CPIN_RX. If terminated state is supported external reference load RREF_RT and a reference
impedance ZREF_RT which conforms to SRLREF_RT has to be verified additionally.
5.1.4 SYS-TX Characteristics

460 This section contains timing characteristics specific to a SYS-TX which are not covered by the common
M-TX characteristics in Section 5.1.1.

Confidential
01-Dec-2016
5.1.4.1 Rise and Fall Times

461 The SYS-TX rise and fall times, TR_SYS_TX and TF_SYS_TX, respectively, are defined as transition times
between the 20% and 80% signal levels of the differential SYS-TX output signal, with an amplitude of
VDIF_DC_TX, when driving a repetitive D.30.3 symbol sequence into reference load RREF_NT. The rise and
fall times of a SYS-TX shall comply with the limits of TR_SYS_TX and TF_SYS_TX.

462 The SYS-TX LANE-to-LANE skew TL2L_SKEW_SYS_TX is defined as the time between the zero crossings of
the differential output signals VDIF_TX(t) of any two SYS-TXs in one SUB-LINK, when both SYS-TX drive
a test pattern into identical reference loads RREF_RT or RREF_NT. The value of TL2L_SKEW_SYS_TX is outside
the scope of this document. If required, it shall be defined in the protocol specification.
5.1.4.3 Data-to-Clock Skew

463 A system synchronous clocking scheme is used in the SYS-BURST mode, an example of which is shown in
Figure 17. Since the reference clock is not considered to be a part of an M-PORT, definition of the clock
characteristics is outside the scope of this specification. Parameters like the reference clock frequency, the
duty cycle distortion of the reference clock signal, or the rise and fall times of the reference clock signal have
to be covered in the protocol specification utilizing the M-PHY technology.
464 The data-to-clock skew between the data signals of a SYS-TX and the reference clock signal has also to be
defined in the protocol specification, such that no unnecessary limitations for the clocking scheme or system
timing are put forth by this specification. This leaves maximum flexibility to the protocol specification,
which only has to adhere to the zero crossing of the SYS-TX output signal, when it is driving a reference load
RREF_RT or RREF_NT, as reference timing point for such a definition. The data-to-clock skew has to be defined
for both SUB-LINKs. Interoperability in SYS-BURST mode thus has partly to be ensured by the protocol
specification.
465 There might be applications for which a data-to-clock skew cannot be defined, e.g. in case of an external
reference clock signal. In such a case, the propagation delay between the external reference clock signal and
the SYS-TX data signals has to be defined in the protocol specification.
5.1.4.4 SYS-TX Parameters

466 The timing parameters specific to a SYS-TX are summarized in Table 18.
Table 18 SYS-TX Parameters

Values
Min. Max.
Rise time. Defined for RREF_NT1 and test pattern2. See
TR_SYS_TX 0.20 UISYS
Section 5.1.4.1.
Fall time. Defined for RREF_NT1 and test pattern2. See
TF_SYS_TX 0.20 UISYS
Section 5.1.4.1.
CPIN_RX. If terminated state is supported external reference load RREF_RT and a reference
impedance ZREF_RT which conforms to SRLREF_RT has to be verified additionally.
2. Repetitive sequence of D.30.3 symbols to be used for test. Such a sequence is part of CJTPAT.
5.2 M-RX Characteristics

467 This document distinguishes three different operating modes and corresponding FUNCTIONs. Following the
definition of the common M-RX electrical and timing characteristics, which apply to HS-RX, PWM-RX, and

Confidential
01-Dec-2016
SYS-RX, additional characteristics, which are specific to each receive FUNCTION, are defined in this
section. The SQ-RX, which is an optional FUNCTION of an M-RX, is defined at the end of this section.
5.2.1 Common M-RX Characteristics

468 The common electrical and timing characteristics of an M-RX are defined in this section, which also contains
the PIN and signal definitions. The common M-RX characteristics apply to the HS-RX, PWM-RX, and
SYS-RX FUNCTIONs.
5.2.1.1 PIN, Signal, and Reference Characteristic Definitions

469 RXDP and RXDN are the input PINs of the M-RX. RXDP is defined as the positive input PIN and RXDN as
the negative input PIN.
470 VRXDP(t) and VRXDN(t) are defined as the voltage signals at these PINs with respect to ground. VRXDP and
VRXDN are defined as the voltage amplitudes of the VRXDP(t) and VRXDN(t) signals, respectively.
471 IRXDP(t) and IRXDN(t) are defined as the input currents flowing into RXDP and RXDN, respectively. IRXDP
and IRXDN are defined as the current amplitudes of the IRXDP(t) and IRXDN(t) signals, respectively.
472 IRXPN(t) is defined as the current, which flows from RXDP to RXDN, in case the termination resistor is
enabled. IRXPN is defined as the current amplitude of IRXPN(t).
473 The PIN voltages and currents are shown in Figure 41.
IRXDP
RXDP
+
VDIF_RX RDIF_RX IRXPN M-RX
-
VRXDP
RXDN
IRXDN
VRXDN
Figure 41 PIN Voltages and PIN Currents of an M-RX
474 The M-RX contains a differential line receiver that supports the detection of M-TX signals having Large
Amplitude as well as Small Amplitude. An M-RX has to support only FUNCTIONs required for the targeted
application. An M-RX may contain a switchable differential termination resistor RDIF_RX between its input
PINs RXDP and RXDN for improving the signal integrity. Section 4.7.2 defines when RDIF_RX shall be
enabled or disabled. When RDIF_RX is enabled, the M-RX is terminated, otherwise it is unterminated.

Confidential
01-Dec-2016
RXDP
RDIF_RX/2
Termination
Enable
RDIF_RX/2
RXDN
Figure 42 M-RX Implementation Example
475 A simplified diagram of an example implementation using a PMOS input stage is shown in Figure 42. The
common-mode voltage of the LINE has to remain in the common-mode voltage limits upon switching of the
termination resistor. This is achievable through an AC ground at the center tap of the termination resistor, for
example, by use of a capacitor.
476 To mitigate additional channel induced ISI at HS-G4 data rates, an HS-RX can utilize reference equalization
in the form of a first-order continuous-time linear equalizer (CTLE) followed by a 1-tap decision feedback
equalizer (DFE). The CTLE characteristics are defined by the following transfer function:
A DC  P1  P2 s + z
H  s  = ------------------------------ ---------------------------------------------- (Equation 24)
z  s +  P1   s +  P2 
477 where ADC is the DC gain, f, fz, is the zero, fP1 is the first pole, and fP2 is the second pole. Figure 43
shows various valid CTLE transfer function curves. Figure 42 shows examples of CTLE frequency
responses, when the CTLE parameters are chosen within the limits defined in Table 19.

Confidential
01-Dec-2016
4
Magnitude (dB)
-2
-4
-6 7 8 9 10 11
10 10 10 10 10
Frequency (Hz)
Figure 43 Examples of CTLE Frequency Responses
478 The DFE characteristics are defined by the following equation:
yk = xk – VDFE_RX
yk = xk – d1sgn(yk-1) (Equation 25)
479 where yk is the output voltage signal of the DFE, xk is the input voltage signal to the DFE, VDFE_RX is the
DFE feedback voltage signal, k is the sample index of a data bit and d1 is the DFE feedback coefficient.
Figure 44 illustrates the Reference DFE diagram.
1st order
CTLE
xk yk sgn(yk-1)
Σ Z-1
VDFE_RX
X -d1
Figure 44 Reference DFE Diagram
480 The sinusoidal jitter tolerance of an M-RX in HS-MODE is specified by means of a sinusoidal jitter tolerance
mask with a corner frequency fC_HS_RX. Jitter is integrated up to the upper RX cut-off frequency fU_RX. The
lower cut-off frequency fSJ4_RX is defined for the short term jitter of an M-RX. fC_HS_RX is also the corner
frequency of the receiver jitter tolerance.

Confidential
01-Dec-2016
481 Discrete test frequencies fC_HS_RX, fSJ2_RX, fSJ3_RX and fSJ4_RX are defined for the sinusoidal jitter tolerance.
fSJ3_RX is the system clock frequency of the chip, which in case of a Type-II M-PORT may be different than
fSYS_REF.
482 The jitter is defined for a BER of 10-12 according to [INC01]2. The mean () of the distribution function is
located at 0.
483 The reference parameters for the M-RX are summarized in Table 19.
Table 19 M-RX Reference Parameters

Values
Min. Nom. Max.
Frequency
1 -
---------------
fU_RX Hz Upper frequency for jitter tolerance.
2 UI HS
Corner frequency of sinusoidal jitter tolerance

fC_HS_G1_RX 2.0 MHz
mask in HS-G1.
fC_HS_G2_RX 4.0 MHz
mask in HS-G2.
fC_HS_G3_RX 8.0 MHz
mask in HS-G3.
fC_HS_G4_RX 8.0 MHz
mask in HS-G4.
f C_HS_RX
fSJ0_RX ----------------------- MHz Lower test frequency for sinusoidal tolerance.
10
fSJ2_RX 10 MHz Test frequency for sinusoidal jitter.
Test frequency for sinusoidal jitter. Frequency
fSJ3_RX fSYSTEM Hz
of system clock.
1
-------------------
fSJ4_RX Hz Test frequency for sinusoidal jitter.
30 UI HS
Limit for BER

QBER 7.0345 Q-factor for a BER of 10-12
BER 10-12 Target BER
HS-RX Reference Equalizer
AAC 6 dB CTLE AC gain
ADC -4 6 dB CTLE DC gain
fZ1 0.4 1.2 GHz CTLE zero frequency
fP2 10 GHz CTLE second pole frequency
VDFE_RX -60 60 mV DFE feedback voltage signal
1. fP1 is determined by other parameters: fP1 = fZ * 10((AAC - ADC)/20)
2. The BER is changed from 10-10 to 10-12 in M-PHY v4.1. Other jitter definitions remain unchanged. The
change in BER is tightening the M-TX jitter requirements.

Confidential
01-Dec-2016
5.2.1.2 Differential and Common-mode Voltage

484 The differential input voltage signal VDIF_RX(t) is defined as the difference of the voltage signals VRXDP(t)
and VRXDN(t) at the M-RX PINs. VDIF_RX is defined as the amplitude of VDIF_RX(t). VDIF_RX(t) can be
calculated from the following equation:
V DIF_RX(t) = V RXDP(t) – V RXDN(t) (Equation 26)
485 The minimum value of VDIF_RX defines the minimum differential voltage amplitude of a test pattern an
M-RX has to receive while the maximum value of V DIF_RX defines the maximum differential voltage
amplitude of a test pattern an M-RX has to receive.
486 The receiver common-mode voltage signal VCM_RX(t) is defined as the arithmetic mean value of the voltage
signals VRXDP(t) and VRXDN(t) when a test pattern is applied at the M-RX input PINs. VCM_RX is defined as
the amplitude of VCM_RX(t). VCM_RX(t) can be calculated from the following equation:
V RXDP  t  + V RXDN  t 
V CM_RX  t  = ----------------------------------------------------- (Equation 27)
2
487 The VCM_RX parameter values are defined such that they cover DC deviations, which can, e.g., be caused by
a ground shift between an M-TX and an M-RX or by an output signal mismatch of the M-TX.
488 An M-RX shall detect a differential input signal at its RXDP and RXDN PINs with a differential voltage
amplitude in the range of VDIF_RX and with common-mode voltage in the range of VCM_RX.
5.2.1.3 Termination Resistance

489 An M-RX may contain a switchable differential termination resistor RDIF_RX. RDIF_RX is defined by the ratio
of the difference of the PIN voltage amplitudes VRXDP and VRXDN and the current amplitude IRXPN, which
flows from RXDP to RXDN, when the differential input voltage amplitude and the receiver common-mode
voltage are both in the range of VDIF_RX and VCM_RX, respectively.
490 RDIF_RX can be calculated from the following equation:
V RXDP – V RXDN
R DIF_RX = --------------------------------------- (Equation 28)
I RXPN
491 The termination resistance shall conform with the limits of RDIF_RX.
5.2.1.4 Differential Termination Switching Time

492 If an M-RX contains a differential termination resistor, it detects from the LINE state, when RDIF_RX has to
be enabled or disabled, as defined in Section 4.7.2.
493 The differential termination enable time, TTERM_ON_HS_RX, TTERM_ON_PWM_RX or TTERM_ON_SYS_RX (see
Figure 16 for HS example), is defined as the time from the zero crossing of the triggering DIF-N to DIF-P
transition until the time when the differential input voltage reaches the evaluation level VTERM_ON_EVAL,
where V TERM_ON_EVAL is defined as the 20% level of the voltage difference when the M-RX is not
terminated and when the M-RX is terminated, as shown by the following equation:
V TERM_ON_EVAL = V DIF_RT_RX + 0.2  V DIF_NT_RX – V DIF_RT_RX  (Equation 29)
494 The differential termination enable time shall conform with the limit of the appropriate PREPARE time in
Table 7.
495 RDIF_RX is disabled through different triggering events for the HS-MODE, the PWM-MODE, and the
SYS-MODE. This results in three different definitions of the differential termination disabled time. All

Confidential
01-Dec-2016
termination disable times are defined using an evaluation level VTERM_OFF_EVAL, which is defined as the
80% level of the voltage difference when the M-RX is not terminated and when the M-RX is terminated, as
shown by the following equation:
V TERM_OFF_EVAL = V DIF_RT_RX + 0.8  V DIF_NT_RX – V DIF_RT_RX  (Equation 30)
496 In HS-MODE, the differential termination disable time, TTERM_OFF_HS_RX, is defined as the time starting
after TOB until the time when the differential input voltage reaches VTERM_OFF_EVAL. The differential
termination disable time shall conform with the limit defined by
RX_Min_STALL_NoConfig_Time_Capability in HS-MODE.
497 In PWM-MODE, the differential termination disable time, TTERM_OFF_PWM_RX, is defined as the time
starting after TOB until the time when the differential input voltage reaches V TERM_OFF_EVAL . The
differential termination disable time shall conform with the limit defined by
RX_Min_SLEEP_NoConfig_Time_Capability in PWM-MODE.
498 In SYS-MODE, the differential termination disable time, TTERM_OFF_SYS_RX, is defined as the time starting
after TOB until the time when the differential input voltage reaches VTERM_OFF_EVAL. The differential
termination disable time shall conform with the limit defined by
RX_Min_SLEEP_NoConfig_Time_Capability in SYS-MODE.
5.2.1.5 Return Loss

499 The receiver return loss parameter is based on a mixed-mode S-parameter matrix. The single ended
S-parameters are characterized using the reference impedance RREF_RT/2.
500 The characterization can be done with a setup, illustrated in Figure 45. VC denotes the common-mode
voltage whereas VD denotes the differential voltage.
RREF_RT/2
M-RX
RREF_RT/2
VC + VD/2 VC – VD/2
Figure 45 Measurement Setup for M-RX Return Loss
501 The differential receiver return loss, SDDRX, is defined for an M-RX with the termination resistor enabled.
SDDRX is defined at the PINs such that it includes contributions from the on-chip circuitry as well as from the
package. When the M-RX is not terminated, the PIN capacitance should be limited by CPIN_RX.
502 The SDDRX is considered to be informative. The SDDRX template is shown in Figure 46 along with the
return loss values at certain corner frequencies f HS_MIN , f HS and f HS_MAX , which are defined in
Section 5.1.1.1. The differential receiver return loss of an M-RX should conform with the specification limits
of SDDRX.

Confidential
01-Dec-2016
log f
0 f HS_MIN fHS fHS_MAX
0
SDD RX
[dB]
Frequency 0 fHS_MIN fHS fHS_MAX

HS-G1 -17 -17 -10 -7
HS-G2 -17 -17 -4.8 -3
HS-G3 -13 -13 -3.8 -2
HS-G4 -11 -11 -2.2 -1
Figure 46 Template for Differential Receiver Return Loss SDDRX
5.2.1.6 Common M-RX Parameters

503 The common electrical and timing parameters of an M-RX are summarized in Table 20.
Table 20 Common M-RX Parameters

Values
Min. Max.
M-RX Electrical
Differential RX voltage amplitude in terminated state.
VDIF_RT_RX 60 310 mV
Defined for CJTPAT1. See Section 5.2.1.2.
Differential RX voltage amplitude when the M-RX is not
VDIF_NT_RX 120 620 mV
terminated. Defined for CJTPAT1. See Section 5.2.1.2.
RX common-mode voltage2. Defined for CJTPAT1. See
VCM_RX 25 330 mV
Section 5.2.1.2.
M-RX Resistance
Differential input resistance3. Defined over VDIF_RX
RDIF_RX 80 110 
range. See Section 5.2.1.3.
1. Measurement based on accumulative eye diagram. Measurements are accomplished using the
Compliant Jitter Tolerance Pattern (CJTPAT).
2. The values include a ground shift of ±50 mV between the M-TX and M-RX.
3. The tolerance for the minimum and the maximum of RDIF_RX is different when a nominal resistance
of 100  is assumed. The reason for the 20  decrease of the minimum is to cope with interconnect
resistances below 50 . However, for the maximum only an increase of 10  is specified to limit the
voltage drop over RDIF_RX.

Confidential
01-Dec-2016
5.2.2 HS-RX Characteristics

504 This section contains the electrical and timing characteristics specific to an HS-RX which are not covered by
the common M-RX characteristics in Section 5.2.1.

505 The HS-RX LANE-to-LANE skew TL2L_SKEW_HS_RX is defined as the time between the zero crossings of
the differential input signal VDIF_RX(t) at any two HS-RXs in one SUB-LINK when test patterns are applied
at both HS-RX PINs. The value of TL2L_SKEW_HS_RX is outside the scope of this document. If required, it
shall be defined in the protocol specification.
5.2.2.2 Receiver Jitter Tolerance

506 The receiver total jitter tolerance, TJRX, is defined similarly to the transmitter total jitter, TJTX. The primary
difference between TJTX and TJRX is that TJTX is a jitter characteristic and directly measured while TJRX is a
jitter tolerance of HS-RX. TJRX is the sum of the receiver deterministic jitter tolerance, DJRX, and the
receiver random jitter tolerance, RJRX, of the differential input signal VDIF_RX(t). TJRX is defined for the
required BER and is shown by the following equation:
TJ RX = DJ RX + RJ RX (Equation 31)
507 TJRX and DJRX are defined relative to UIHS over a frequency range from DC up to fU_RX, whereas RJRX is
defined over the frequency from fC_HS_RX to fU_RX
508 The receiver short term total jitter tolerance, STTJRX, and the receiver short term deterministic jitter
tolerance, STDJRX, are defined and limit the jitter within a 30UIHS signal sequence. The short term jitter
corresponds to high frequency jitter in the frequency domain. In practice, short term deterministic jitter is
dominated by data dependent jitter DDJRX and crosstalk originating from the transmitter and the channel.
STTJRX is shown by the following equation:
STTJ RX = STDJ RX + STRJ RX (Equation 32)
509 where STRJRX is defined over the frequency range from fSJ4_RX up to fU_RX. STDJRX can be a combination
of DDJRX and short term sinusoidal jitter STSJRX. The frequency of STSJRX is greater than fSJ4_RX.
510 The receiver total short term jitter tolerance, STTJRX is defined for the differential input signal VDIF_RX(t) at
the zero crossings and conforms to the accumulated differential input voltage amplitude VDIF_ACC_RX when
a CJTPAT test pattern is applied at an HS-RX.
511 The receiver total jitter tolerance TJRX is defined for the differential input signal VDIF_RX(t) at the zero
crossings and conforms to the accumulated differential input voltage amplitude VDIF_ACC_RX when a
CJTPAT test pattern is applied at an HS-RX.
512 The deterministic jitter tolerance, DJRX, can be expressed by the following equation:
DJ RX = STDJ RX + SJ RX  f  (Equation 33)
513 A sinusoidal jitter tolerance mask is given in Figure 47, which defines the sinusoidal jitter tolerance
amplitude depending on frequency. The sinusoidal jitter is characterized by its oscillation frequency fSJ_RX
and its peak-to-peak amplitude, which is identical to the receiver sinusoidal jitter tolerance SJRX(f). In
practice sinusoidal jitter may or may not be present in an M-PHY LINK. However, sinusoidal jitter tolerance
is a convenient method for quantifying the HS-RX behavior and its effective minimum jitter tracking
bandwidth. The sinusoidal jitter tolerance SJRX(f) is defined in two frequency regions that range from fSJ0_RX

Confidential
01-Dec-2016
up to fC_HS_RX and from fC_HS_RX up to fSJ4_RX. The low frequency sinusoidal jitter fSJ0_RX is defined by the
following equation:
f C_HS_RX
f SJ0_RX = ---------------------- (Equation 34)
10
514 For separate reference clock topologies, the sinusoidal jitter tolerance mask continues with the same minus
20 dB/dec slope below fSJ0_RX as shown in Figure 47. The sinusoidal jitter tolerance mask for shared
reference clock topologies does not exceed SJRX(f) at fSJ0_RX for frequencies below fSJ0_RX. Table 19
contains a list of frequencies for conformance testing. fSJ3_RX is included in this list if it is within the range set
by fSJ0_RX and fSJ4_RX. The jitter amplitudes are given in Table 21. The reference clock jitter and M-RX PLL
jitter are not explicitly defined. However, reference clock and M-RX PLL jitter characteristics are included in
the receiver jitter tolerance.
515 An HS-RX shall tolerate a CJTPAT test pattern with a deterministic jitter tolerance DJRX onto which random
jitter tolerance RJRX is superpositioned, where the value of RJRX is indirectly specified through Equation 31.
516 An HS-RX shall tolerate a CJTPAT test pattern with short term deterministic jitter tolerance STDJRX onto
which short term random jitter tolerance STRJRX is superpositioned, where the value of STRJRX is indirectly
specified through Equation 32.
SJ(UIHS)
SJRX(f) = 0.15 UIHS*(fC_HS_RX/f)

1.50
SJRX(f) = 0.15 UIHS
0.20
0.15
0.10
f(MHz)
fSJ0_RX fC_HS_RX fSJ2_RX fSJ4_RX fU_RX
Figure 47 Sinusoidal Jitter Tolerance Mask
5.2.2.3 Receiver Eye Opening and Accumulated Differential Receiver Input Voltage
517 The minimum value of VDIF_RX, as described in Section 5.2.1.2, defines the minimum instantaneous
differential input voltage amplitude at the M-RX PINs. In addition, the accumulated differential receiver
input voltage VDIF_ACC_RX is defined as the minimum differential voltage amplitude within an accumulated
eye diagram generated from a CJTPAT test pattern. V DIF_ACC_HS_G1_RX , V DIF_ACC_HS_G2_RX ,
VDIF_ACC_HS_G3_RX, and VDIF_ACC_HS_G4_RX are the accumulated differential receiver input voltages for an
HS-RX operated in HS-G1, HS-G2, HS-G3, and HS-G4, respectively. V DIF_ACC_HS_G3_RX and
VDIF_ACC_HS_G4_RX are defined at the midpoint of the eye, UIHS/2.
518 For HS-G1 and HS-G2, the receiver eye opening, TEYE_RX, is defined as the duration over which the
differential voltage amplitude has to be larger than VDIF_ACC_RX in the accumulated eye diagram generated
from a CJTPAT test pattern. For HS-G3 and HS-G4, the receiver eye openings, T EYE_HS_G3_RX and
TEYE_HS_G4_RX, are defined as the duration over which no zero crossings of VDIF_RX(t) are allowed in the

Confidential
01-Dec-2016
eye diagram generated from a CJTPAT test pattern. The total receiver jitter tolerance TJRX is defined as the
duration between the earliest and latest zero crossing at one crossing point in the accumulated eye diagram as
defined in Section 5.2.1.2.
519 VDIF_ACC_RX, TEYE_RX, and TJRX/2 define the HS-G1 and HS-G2 eye mask for the accumulated M-RX
signal as shown in Figure 48. The absolute value of the HS-RX differential input voltage signal shall be
larger than the lower limit of VDIF_ACC_RX over the receiver eye opening TEYE_RX and the accumulated eye
diagram shall conform with the eye diagram mask. The position of TEYE_RX is centred in the middle of the
eye.
520 VDIF_ACC_HS_G3_RX, TEYE_HS_G3_RX and TJRX/2 define the HS-G3 eye mask for the accumulated M-RX
signal as shown in Figure 43. Similarly, VDIF_ACC_HS_G4_RX, TEYE_HS_G4_RX, and TJRX/2 define the HS-
G4 eye mask. The absolute value of the HS-RX differential input voltage signal shall be larger than the lower
limit of VDIF_ACC_HS_G3_RX or VDIF_ACC_HS_G4_RX . Additionally, the accumulated eye diagram shall
conform to the eye diagram mask. The position of TEYE_HS_G3_RX and TEYE_HS_G4_RX is centered in the
middle of the eye.
521 An HS-RX shall receive an input signal at the RXDP and RXDN PINs which conforms to the limits of
VDIF_ACC_RX, TEYE_RX, and TJRX for the respective HS-Gear. The accumulated eye diagram in HS-G4 shall
be post-processed with the reference package and receiver reference equalizer. Definitions visualized in
Figure 48 and Figure 49 are based on the accumulated eye for the target BER.
522 For conformance test, the accumulated eye diagram should closely meet the keep-out region of the eye mask
but the accumulated eye diagram is not required to touch the keep-out region of the eye mask in all points.
VDIF_RX
Maximum
VDIF_ACC_RX
Minimum
0V 0V
VDIF_ACC_RX
Minimum
Shaded areas VDIF_RX
regions
TJRX/2 T EYE_RX TJRX/2
(UIHS -TEYE_RX)/2
UIHS
Figure 48 HS-G1 and HS-G2 Differential Receiver Eye Diagram

Confidential
01-Dec-2016
0.5UIHS
VDIF_RX
VDIF_ACC_HS_G3/G4_RX Maximum
0V 0V
VDIF_ACC_HS_G3/G4_RX
Shaded areas VDIF_RX
regions
TEYE_HS_G3/G4_RX
TJRX/2
UI HS
Figure 49 HS-G3 and HS-G4 Differential Receiver Eye Diagram
5.2.2.4 Receiver Pulse Width

523 The receiver pulse width, TPULSE_RX, is defined as the minimum time between the zero crossings of the
differential input signal VDIF_RX(t) when a test pattern is applied at the RXDP and RXDN PINs of an HS-RX.
TPULSE_RX is shown in Figure 50 for a DIF-P pulse. Each symbol should conform with the receiver pulse
width in Figure 50 to ensure reliable reception.
524 An HS-RX shall detect an input signal with a receiver pulse width that conforms with the limit of TPULSE_RX.
VDIF_RX
TPULSE_RX
Ideal Waveform UIHS
Figure 50 Receiver Pulse Width

Confidential
01-Dec-2016
5.2.2.5 HS-RX Parameters

525 The electrical and timing parameters of the HS-RX are summarized in Table 21.
Table 21 HS-RX Parameters

Values
Min. Max.
HS-RX Electrical
Accumulated differential receiver input voltage for
VDIF_ACC_RX 40 mV HS-G11. Defined for CJTPAT2.
VDIF_ACC_HS_G2_RX 40 mV HS-G21. Defined for CJTPAT2.
HS-RX Timing
Receiver eye opening. Defined for CJTPAT2 over
TEYE_RX 0.20 UIHS a statistical confident record set4.
Receiver eye opening in HS-G3. Defined for
TEYE_HS_G3_RX 1 - TJRX UIHS CJTPAT2 over a statistical confident record set6.
Receiver eye opening in HS-G4. Defined for
TEYE_HS_G4_RX 1 - TJRX UIHS CJTPAT2 over a statistical confident record set6.
Receiver pulse width. Defined for CJTPAT2.
TPULSE_RX 0.80 UIHS
HS-RX Jitter
Receiver deterministic jitter3 over the frequency
range from fC_HS_RX to fU_RX which includes
DJRX 0.35 UIHS
STDJRX. Defined for CJTPAT for a statistical
confident record set2,4,5. See Section 5.2.2.2.
Receiver sinusoidal jitter tolerance3.
0.15 UIHS Defined for CJTPAT and frequency range from
fC_HS_RX to fSJ4_RX. See Section 5.2.2.2.
SJRX(f)
0.15  f C_HS_RX Receiver sinusoidal jitter tolerance3.
-------------------------------------- UIHS Defined for CJTPAT and frequency range from
f
fSJ0_RX to fC_HS_RX. See Section 5.2.2.2.
Receiver deterministic jitter over the frequency
range from fSJ4_RX to fU_RX.
STDJRX 0.20 UIHS
Defined for CJTPAT for a statistical confident
record set2,5,6. See Section 5.2.2.2.

Confidential
01-Dec-2016
Table 21 HS-RX Parameters (continued)

Values
Min. Max.
Receiver total jitter tolerance3 for galvanic
interconnect without OMC3.
TJRX 0.52 UIHS
Defined for CJTPAT and a statistical confident
Receiver total jitter over the frequency range from
fSJ4_RX to fU_RX.
STTJRX 0.30 UIHS
Defined for CJTPAT and a statistical confident
1. Measurement based on accumulative eye diagram.

2. The test has to be performed at the maximum data rate of the applicable HS-GEAR.
3. Accumulated jitter as defined by the jitter model in Section 5.2.2.2.
4. Filtered using a high-pass jitter transfer function HJTF(s).
5. Measured for the target BER.
6. Filtered using a1st order high-pass filter with a pole at fSJ4_RX.
5.2.3 PWM-RX Characteristics

526 This section contains the timing characteristics specific to a PWM-RX which are not covered by the common
M-RX characteristics in Section 5.2.1. The PWM signaling scheme is defined in Section 4.3.2.
5.2.3.1 Accumulated Differential Receiver Input Voltage

527 The minimum value of VDIF_RX, as described in Section 5.2.1.2, defines the minimum instantaneous
differential input voltage amplitude at the M-RX PINs. In addition, the accumulated differential receiver
input voltage V DIF_ACC_PWM_RX is defined as the minimum differential voltage amplitude within an
accumulated eye diagram generated from a test pattern, when the PWM-RX is operated in PWM-G5,
PWM-G6, or PWM-G7.
528 An PWM-RX operated in PWM-G5, PWM-G6, or PWM-G7 shall detect a differential input signal at the
RXDP and RXDN PINs, where the accumulated differential input voltage amplitude conforms with the limit
of VDIF_ACC_PWM_RX.
5.2.3.2 PWM Bit Duration, Bit Duration Tolerance, and Ratio

529 The PWM receive bit duration TPWM_RX is defined as the duration between zero crossings of two
consecutive falling edges of a differential signal at the PWM-RX input. TPWM_MINOR_RX, TPWM_MAJOR_RX,
and TPWM_RX are shown in Figure 51. The PWM receive bit duration TPWM_RX is, for all PWM GEARs, the
sum of its durations TPWM_MINOR_RX and TPWM_MAJOR_RX, as shown in the following equation:
T PWM_RX = T PWM_MINOR_RX + T PWM_MAJOR_RX (Equation 35)
530 The limits of TPWM_RX are, for all PWM GEARs, identical to the limits of TPWM_TX.

Confidential
01-Dec-2016
531
TPWM_MINOR_RX TPWM_MAJOR_RX
TPWM_MAJOR_RX TPWM_MINOR_RX
TPWM_RX
Figure 51 RX Minor and Major Duration in a PWM Signal
532 TPWM_MINOR_RX and TPWM_MAJOR_RX are determined by TPWM_RX and the PWM receive ratio kPWM_RX
for PWM-G1 and higher PWM GEARs. k PWM_RX is defined as the ratio of T PWM_MAJOR_RX and
TPWM_MINOR_RX of one PWM bit, as shown in following equation:
T PWM_MAJOR_RX
k PWM_RX = ----------------------------------------- (Equation 36)
T PWM_MINOR_RX
533 For PWM-G0, the minor duration TPWM_G0_MINOR_RX is directly specified. The range of
TPWM_G0_MINOR_RX is defined based on the minor duration in PWM-G1.
534 The PWM receive bit duration tolerance, TOLPWM_RX, is the allowed tolerance of an instantaneous PWM bit
duration, TPWM_RX(i), in PWM-MODE. TOLPWM_RX is defined as the ratio of TPWM_RX(i) and the average
of N PWM receive bit durations in PWM-MODE, as shown in the following equation:
T PWM_RX(i)
TOL PWM_RX = -------------------------------------------
N
(Equation 37)
1
----  T PWM_RX(j)
N
j=1
535 where N is a defined number of PWM bits, and i is in the range of 1 to N.

536 While the TPWM_RX range is wide for a PWM GEAR, TOLPWM_RX limits the variation of TPWM_RX(i)
during PWM-MODE. In addition, a more restrictive receive bit duration tolerance, TOLPWM_G1_LR_RX, is
defined during LINE-READ in PWM-G1.
537 TOLPWM_G1_LR_RX is the allowed tolerance of TPWM_RX(i) during a LINE-READ state in PWM-G1.
TOLPWM_G1_LR_RX is defined as the ratio of TPWM_RX(i) and the average of N PWM receive bit durations in
PWM-MODE, similar to the TOLPWM_RX definition in Equation 37. TOLPWM_G1_LR_RX is not defined for
states other than LINE-READ during a PWM-BURST.
538 A PWM-RX shall detect a PWM input signal with a PWM receive bit duration, TPWM_RX, in the specified
range of the operational PWM GEAR during a PWM-BURST. For PWM-G1 and higher GEARs, the PWM
receive ratio kPWM_RX shall be in the specified range for each PWM bit. For PWM-G0, the minor duration
TPWM_G0_MINOR_RX shall be in the specified range for each PWM bit.
539 A PWM-RX shall detect a PWM input signal with PWM receive bit duration tolerance in the limits of
TOLPWM_RX.

Confidential
01-Dec-2016
540 A PWM-RX shall detect a PWM input signal with PWM receive bit duration tolerance in the limits of
TOLPWM_G1_LR_RX during LINE-READ in PWM-G1.
5.2.3.3 Rise and Fall Time

541 The PWM-RX rise and fall times, TR_PWM_RX and TF_PWM_RX, respectively, are defined as transition times
between the 20% and 80% signal levels of the differential PWM-RX input signal with an amplitude of
VDIF_RX.
542 A PWM-RX shall detect a PWM input signal with rise and fall times that comply with the limits of
TR_PWM_RX and TF_PWM_RX.

543 The PWM-RX LANE-to-LANE skew TL2L_SKEW_PWM_RX is defined as the time between the zero crossings
of the falling edges of the differential input signal VDIF_RX(t) at any two PWM-RXs in one SUB-LINK when
test patterns are applied at both PWM-RX PINs. The value of TL2L_SKEW_PWM_RX is outside the scope of
this document. If required, it shall be defined in the protocol specification.
5.2.3.5 PWM-RX Parameters

544 The timing parameters of the PWM-RX are shown in Table 22.
Table 22 PWM-RX Parameters

Values
Min. Max.
PWM-RX Electrical
Accumulated differential RX voltage amplitude1.
VDIF_ACC_PWM_RX 40 mV Defined for CJTPAT in PWM-G5, PWM-G6, and
PWM-G7. See Section 5.2.3.1.
Accumulated differential RX voltage amplitude1.
Defined for CJTPAT in SYS-MODE, PWM-G0,
VDIF_ACC_RX 40 mV
PWM-G1, PWM-G2, PWM-G3, and PWM-G4. See
Section 5.2.3.1.
PWM-RX Timing
1--- 1- PWM receive bit duration in PWM-G0. Defined for
TPWM_G0_RX --------- s
3 0.01 CJTPAT. See Section 5.2.3.2.
1--- 1--- PWM receive bit duration in PWM-G1. Defined for
TPWM_G1_RX s
9 3 CJTPAT. See Section 5.2.3.2.
1- 1--- PWM receive bit duration in PWM-G2. Defined for
TPWM_G2_RX ----- s
1- 1- PWM receive bit duration in PWM-G3. Defined for
TPWM_G3_RX ----- ----- s
TPWM_G4_RX ----- ----- s
TPWM_G5_RX -------- ----- s
TPWM_G6_RX -------- ----- s

Confidential
01-Dec-2016
Table 22 PWM-RX Parameters (continued)

Values
Min. Max.
TPWM_G7_RX -------- -------- s
PWM receive bit duration tolerance. Defined for
TOLPWM_RX 0.82 1.18
CJTPAT in PWM-MODE. See Section 5.2.3.2.
PWM receive bit duration tolerance in PWM-G1.
TOLPWM_G1_LR_RX 0.89 1.11 Defined for CJTPAT during LINE-READ. See
Section 5.2.3.2.
Number of PWM bits. Sequence length for
N 50 50 TOLPWM_RX and TOLPWM_G1_LR_RX. See
Section 5.2.3.2.
1- 1--- PWM receive minor duration in PWM-G0. Defined
TPWM_G0_MINOR_RX ----- s
27 9 for CJTPAT. See Section 5.2.3.2.
0.60 0.75 PWM receive ratio for PWM-G1 and higher PWM
kPWM_RX ---------- ----------
0.40 0.25 GEARs. Defined for CJTPAT. See Section 5.2.3.2.
TR_PWM_RX 0.14 TPWM_RX Rise time defined for CJTPAT.
TF_PWM_RX 0.14 TPWM_RX Fall time defined for CJTPAT.
1. Measurements based on accumulative eye diagram.
5.2.4 SYS-RX Characteristics

545 This section contains the timing characteristics specific to a SYS-RX which are not covered by the common
M-RX characteristics in Section 5.2.1.

546 The SYS-RX LANE-to-LANE skew TL2L_SKEW_SYS_RX is defined as the time between the zero crossings of
the differential input signal VDIF_RX(t) at any two SYS-RXs in one SUB-LINK when test patterns are applied
at both SYS-RX pins. The value of TL2L_SKEW_SYS_RX is outside the scope of this document. If required, it
shall be defined in the protocol specification.
5.2.4.2 Setup and Hold Times

547 Some parameters of the SYS-BURST mode have to be defined by the protocol specification, as described in
Section 5.1.4.3. The setup and hold times of the data signal at the SYS-RX input with respect to the reference
clock signal belong to the parameters which are defined in the protocol specification. The zero crossing of the
differential signal at the SYS-RX input is used as reference timing point for such a definition. Thus,
Interoperability in SYS-BURST mode is partly ensured by the protocol specification.
5.2.5 SQ-RX Characteristics

548 This section contains the electrical and timing characteristics specific to a SQ-RX which are not covered by
the common M-RX characteristics in Section 5.2.1. The SQ-RX drives a DIF-Z LINE state in certain states.
Additionally, the SQ-RX can monitor the LINE state to detect a non-squelch state. The operation of the
SQ-RX is described in Section 4.6.

Confidential
01-Dec-2016
5.2.5.1 Squelch Common-mode Voltage and Squelch Differential Voltage

549 The squelch common-mode voltage signal VCM_SQ(t) is defined as the arithmetic mean value of the voltage
signals VRXDP(t) and VRXDN(t) when the SQ-RX drives a DIF-Z at RXDP and RXDN while the LINE is not
driven from the M-TX. VCM_SQ is defined as the amplitude of VCM_SQ(t). VCM_SQ(t) can be calculated from
following equation:
V RXDP  t  + V RXDN  t 
V CM_SQ  t  = ----------------------------------------------------- (Equation 38)
2
550 A SQ-RX shall keep the squelch common-mode voltage at the M-RX PINs within the limits of VCM_SQ,
while driving a DIF-Z and the LINE is not driven from the M-TX.
551 The squelch differential voltage signal VDIF_SQ(t) is defined as the difference of the signal voltages VRXDP(t)
and VRXDN(t) at the M-RX PINs when the SQ-RX drives a DIF-Z at RXDP and RXDN while the LINE is not
driven from the M-TX. VDIF_SQ is defined as the amplitude of VDIF_SQ(t). VDIF_SQ(t) can be calculated from
following equation:
V DIF_SQ  t  = V RXDP  t  – V RXDN  t  (Equation 39)
552 The SQ-RX shall control the signal voltages at the M-RX PINs such that the squelch differential voltage is
below the limit of VDIF_SQ, while the SQ-RX drives a DIF-Z and the LINE is not driven from the M-TX.
553 The limits of VCM_SQ and of VDIF_SQ can be achieved by use of a differential resistor or two single-ended
resistors, for instance. VCM_SQ and of VDIF_SQ impose limits on the M-RX input resistances at RXDP and
RXDN. The lower value of the M-RX input resistances at RXDP and RXDN has to be such that an M-TX
with Small Amplitude can drive the LINE from the squelch state to the non-squelch state while the SQ-RX is
driving DIF-Z. The upper value of the M-RX input resistances is limited by the PIN leakage currents of the
M-TX, the PIN leakage currents of the M-RX, and the mismatch of the M-TX PIN leakage currents. The
M-RX input resistances has to be such that the limits of VCM_SQ and of VDIF_SQ are met for the specified
M-RX and M-TX PIN leakage currents while the SQ-RX is driving DIF-Z.
5.2.5.2 Squelch Exit Voltage

554 The squelch exit voltage VSQ is the threshold voltage of the SQ-RX, which shall operate when the
common-mode voltage is in the VCM_SQ range. When enabled the SQ-RX shall indicate a squelch state of the
LINE, as long as the voltage difference of VRXDN and VRXDP is smaller than the minimum squelch exit
voltage VSQ, i.e., squelch shall be indicated when the following relation holds:
V RXDN  t  – V RXDP  t   V SQ MIN (Equation 40)
555 When enabled the SQ-RX shall indicate a non-squelch state of the LINE, as long as the voltage difference of
VRXDN and VRXDP is larger than the maximum squelch exit voltage VSQ, i.e., non-squelch shall be indicated
when the following relation holds:
V RXDN  t  – V RXDP  t   V SQ MAX (Equation 41)
556 The SQ-RX does not need to detect if VRXDP is by more than VSQ larger than VRXDN, because it is only
required to detect the transition of the LINE state from DIF-Z to DIF-N.
5.2.5.3 Squelch Exit Time

557 The squelch exit time TSQ is the duration from non-squelch detection until the M-RX enters the SLEEP state.
TSQ is defined from the crossing of the differential signal VRXDN – VRXDP with VSQ,MAX until the M-RX

Confidential
01-Dec-2016
enters the SLEEP state. No value is defined for TSQ, which is an M-RX internal characteristic. However the
DIF-N, which is signaled by the M-TX upon exit of the HIBERN8 state for the period TACTIVATE, is an upper
bound for TSQ. A lower bound is the pulse width of a DIF-N pulse, which is detected as a non-squelch state by
the SQ-RX. This pulse width is not specified, but bounded by the squelch pulse rejection.
5.2.5.4 Squelch Pulse and RF Rejection

558 The squelch noise pulse width TPULSE_SQ is defined as the time the M-RX input signal VRXDN(t) – VRXDP(t)
is larger than VSQ,MAX. TPULSE_SQ is shown in Figure 52. The SQ-RX shall reject single input noise pulses
with an amplitude beyond VSQ,MAX and shorter than the squelch noise pulse width TPULSE_SQ, where the
pulse is of a rectangular shape.
559 The noise pulse spacing TSPACE_SQ is defined as the time between the crossings of two adjacent pulse edges
of two different, but adjacent, noise pulses with VSQ,MAX. Multiple pulses shall be rejected by the SQ-RX
when the duration between adjacent pulses is larger than TSPACE_SQ. An example is shown in Figure 52.
560 Furthermore, the SQ-RX has to be tolerant to superimposed RF interferences onto the VRXDP(t) and
VRXDN(t) signals. This implies an input signal filter. The RF interference is modelled by a sinusoidal signal
with a peak interference amplitude VINT_SQ and an interference frequency fINT_SQ. The RF interference is
superimposed on the M-RX input signal. The SQ-RX shall meet all specifications in presence of RF
interferences with a peak interference amplitude VINT_SQ and frequencies higher than the interference
frequency fINT_SQ. The interference shall not cause glitches or incorrect operation during signal transitions.
TSPACE_SQ
DIF-Z
VRXDP (t) – VRXDN(t)
-VSQ, MAX
TPULSE_SQ TPULSE_SQ
Figure 52 Pulse Rejection and Non-squelch State Detection
5.2.5.5 SQ-RX Parameters

561 The electrical and timing parameters of the SQ-RX are summarized in Table 23.
Table 23 SQ-RX Parameters

Values
Min. Max.
SQ-RX Electrical
Squelch exit voltage. Defined for test pattern. See
VSQ 50 140 mV
Section 5.2.5.2.
Squelch differential voltage amplitude. Defined for test
VDIF_SQ 20 mV
pattern. See Section 5.2.5.1.

Confidential
01-Dec-2016
Table 23 SQ-RX Parameters (continued)

Values
Min. Max.
Squelch common-mode voltage. Defined for test
VCM_SQ 0 330 mV
pattern. See Section 5.2.5.1.
Peak interference amplitude. Defined for test pattern.
VINT_SQ 200 mV
Interference frequency. Defined for test pattern. See
fINT_SQ 500 MHz
Section 5.2.5.4.
SQ-RX Timing
Noise pulse width. Defined to test pattern. See
TPULSE_SQ 20 ns
Section 5.2.5.4.
Noise pulse spacing. Defined for test pattern. See
TSPACE_SQ 500 ns
Section 5.2.5.4.
5.3 PIN Characteristics

562 The PIN characteristics of an M-TX and of an M-RX are defined in this section.
5.3.1 PIN Capacitance

563 The single-ended PIN capacitance CPIN_RX of the M-RX is defined as the capacitance between the RXDP
and RXDN PINs to ground. CPIN_RX is the lump sum of all single-ended capacitance at an M-RX PIN. The
single-ended PIN capacitance should conform to the limit of CPIN_RX.
564 The PIN capacitance mismatch CPIN_RX of an M-RX is defined as the difference of the PIN capacitances at
RXDP and RXDN. The PIN capacitance mismatch shall conform to the limits of CPIN_RX. CPIN_RX limits
the timing skew between the single-ended signals.
5.3.2 PIN Signal Voltage Range

565 The PIN signal voltage VPIN is defined as the single-ended signal voltage of an M-RX or M-TX PIN to
ground. No structure within an M-RX or M-TX shall be damaged when a DC voltage that is within the limits
of VPIN is applied at a PIN for an indefinite period of time. The single-ended output signals of an M-TX shall
conform with the limits of VPIN.
5.3.3 PIN Leakage Current

566 The PIN leakage current, ILEAK, is defined as the PIN current flowing in, or out, of a MODULE when a
single-ended voltage in the PIN signal voltage range, VPIN, is applied at a MODULE PIN. ILEAK is defined
for a MODULE that does not drive the LINE and, in the case of an M-RX, with its termination resistor
disabled. The PIN leakage current of a MODULE PIN shall conform with the limits of ILEAK.
567 The PIN leakage current mismatch ILEAK_TX is defined as the difference of the PIN leakage currents at the
TXDP and TXDN PINs of an M-TX, when signal voltages are applied which conform with the VCM_SQ and
VDIF_SQ ranges. The PIN leakage current mismatch shall stay in the limits of ILEAK_TX.
5.3.4 Ground Shift

568 The ground shift VGNDSH is defined as the ground potential difference of an M-TX and M-RX within a
LANE. The ground shift of MODULEs within a LANE shall conform with the limits of VGNDSH.
569 The ground shift is taken into account in the definition of signal voltage parameters. It does not need to be
added on top of any signal parameter.

Confidential
01-Dec-2016
5.3.5 PIN Parameters

570 The common PIN characteristics of an M-RX and M-TX are summarized in Table 24.
Table 24 PIN Parameters

Values
Min. Max.
PIN capacitance. Recommended PIN capacitance to
CPIN_RX 1.5 pF
ground at an M-RX PIN1.
Mismatch of PIN capacitance. Mismatch of M-RX PIN
CPIN_RX -0.15 0.15 pF
capacitances2.
VPIN -100 600 mV PIN signal voltage range. Signal voltage range.
ILEAK -10 10 A
PIN leakage current. Measured over VCM
ILEAK_TX -5 5 A
VGNDSH -50 50 mV Ground shift. Ground shift between M-TX and M-RX.
1. Includes package capacitance.

2. For recommended PIN capacitance only.

Confidential
01-Dec-2016
6 Electrical Interconnect (informative)

571 This section provides an implementation guideline for the interconnect simulation environment. A
methodology is also provided that allows the evaluation of interconnect performance.
572 A LINE is defined as an interconnect between an M-TX and an M-RX that conducts the LANE signals. These
signals include differential signaling for both high speed and low speed data transfer. Thus, a LINE should be
implemented by means of balanced, differential, point-to-point transmission lines referenced to ground.
573 A LINE might consist of several cascaded transmission lines, such as printed circuit boards, flex-foils, or
cable connections that might also include vias and connectors.
574 An M-PHY LANE is a unidirectional connection between an M-TX and an M-RX using a LINE as an
interconnect. Overall LANE performance is determined by the combination of these three elements.
Figure 53 shows a simple point-to-point interconnect.
575 The interconnect under test should reflect the application such that M-PHY specifications are met at the
M-RX inputs. Therefore, the interconnect model needs to include noise source and target components when
applicable, e.g. when simulating several LANEs, a supply distribution network, side-band signals, or
sensitive or noisy elements such as radio antennas.
M-TX LINE M-RX
Figure 53 Point-to-Point Interconnect
6.1 Line Characteristics

576 The LINE delay, TLINE, is defined as the time during which a signal is transmitted from the M-TX to M-RX
through the LINE. The TLINE parameters and test conditions are summarized in Table 25.
.
Table 25 Interconnect Parameters

Values
Parameter Symbol Unit Note / Test Condition
Min. Max.
Measured between zero
crossings at test points1 with
LINE delay TLINE 7 ns
conformance test signal source2
and pattern3
1. Measured between LINE input port and LINE output port, which is terminated by a reference
resistor, RREF, and reference capacitors, CPIN_RX, at both pins.
2. External signal source connected to LINE input port.
3. Test pattern CJTPAT at maximum data rate.
6.2 Methodology
577 The method described here imports a LANE's S-parameters into a simulation environment that includes
worst case models for M-TX and M-RX as well as stress patterns. The resulting time domain simulation,
from which voltage and timing can be obtained, is compared against those defined for the M-RX in Section 5.
578 The interconnect characteristics are completely defined by its mixed-mode S-parameter models., i.e.
insertion loss, return loss, and coupling effects. These parameters are sufficient to completely characterize all
interconnect-induced parasitic effects including impedance mismatch and discontinuities, insertion loss,
crosstalk, jitter amplification, jitter attenuation and insertion. A long interconnect tends to be dominated by

Confidential
01-Dec-2016
insertion loss and crosstalk, while a short interconnect tends to be dominated by impedance discontinuities.
Since both types of LINE are possible, it is necessary to provide a means of characterizing the interconnect
that comprehends all possible LANE characteristics.
579 It is also necessary to take into account the LANE's S-parameters with a worst case M-TX behavioral model
and stress patterns, e.g. CJTPAT. The time domain results can be compared against the parameters defined in
Section 5.
6.3 Methodology Guidance for Validating a LANE

580 An interconnect can be characterized using the following methodology:
581 • Extract S-parameters (insertion loss, return loss and, if applicable, coupling) for the interconnect
under test.
582 • Import S-parameters into an interface simulation environment based on M-TX and M-RX models.
583 • Tune the models to produce electrical characteristics as defined in Section 5.
584 • Worst case M-TX model feeds stressed test patterns, e.g. CJTPAT, into interconnect S-parameters
model and then into M-RX model.
585 • Compare simulation results to specifications that should be respected at the input of the M-RX.
6.3.1 Interconnect S-parameters Extraction

586 Interconnect S-parameters should be taken over the entire signaling spectral range, which extends from the
Low Speed minimal bit rate to more than five times fU_RX of the highest supported GEAR. Both near and far
end return loss, as well as forward and reverse insertion loss, should be measured since most simulation tools
require a complete mixed-mode S-parameter representation.
6.3.2 Simulation Environment Setup

587 A simple end-to-end simulation environment is illustrated in Figure 54. The environment includes an M-TX
model, LINE model using interconnect S-parameters, an M-RX model, and stress pattern. A single LANE
environment suffices for a topology with minimal crosstalk. Otherwise, the simulation environment needs to
include noise source and noise target components as shown in Figure 55.
588 At a minimum, the M-TX behavioral model should have an ideal source and consider all transmitter
specification parameters listed in Section 5.1 to accommodate worst case simulations over the whole
parameter range. Moreover, a realistic M-TX model should include package parasitic elements. Some
parameters need to be simulated over their minimum to maximum range in order to guarantee worst case
voltage and time margins for a particular interconnect. For example, VDIF_TX produces worst case eye
margins when set to a minimum and at the same time produces low crosstalk.
589 The test pattern needs to provide worst case results while conforming to 8b10b coding rules. The simulation
environment should use CJTPAT since most M-PHY electrical parameters are derived from it. Other test
patterns that create different stress conditions should also be considered. When the simulation environment is
composed of several LANEs, either the same time-shifted pattern, or different patterns, can be used for
individual LANEs.
LINE LINE
Input Port Output Port
M-TX S-Parameter M-RX

Test Pattern
Model LINE Model Model
Figure 54 Single LANE Simulation Environment

Confidential
01-Dec-2016
LINE LINE

Test Pattern 1
Noise Source
LINE LINE

Test Pattern 2
Noise Target
LINE LINE

Test Pattern 3
Noise Source
Figure 55 Multiple LANE Simulation Environment

Confidential
01-Dec-2016

Confidential
01-Dec-2016
7 Optical Media Converter (OMC)

590 An Optical Media Converter (OMC), illustrated in Figure 56, converts electrical signals from an M-TX into
optical signals (light waves), transports the signals across a medium such as a Plastic Optical Fiber (POF),
and converts the optical signals back into electrical signals that an M-RX can receive.
591 An OMC is considered an inseparable unit, consisting of an optical transmitter (O-TX), an optical receiver
(O-RX), each with appropriate photonics, and an optical wave guide. An auxiliary interconnection parallel
with the optical interconnect as shown in the figure may be implemented between the O-TX and O-RX. The
mechanical and optical interconnect solution and optical interface between the O-TX and O-RX are not
within the scope of this specification.
592 A LINE shall contain only one OMC.
LANE
Optical Media Converter (OMC)
Electrical
Electrical
RX
Optical wave guide
TX
M-TX O-TX O-RX M-RX
Auxiliary interconnect
PINs PINs
LINE (black-box)
= optional
Figure 56 LANE with an OMC
7.1 Application Benefits of the OMC

593 An OMC can replace a galvanic interconnect for improving signal integrity over longer distances, improving
EMI characteristics, as well as offering assembly and reliability benefits provided by optical mediums such
as flexible Plastic Optical Fiber.
7.2 Types of OMCs

594 This specification defines two type of OMCs: Basic and Advanced. A Basic OMC supports defined minimal
functionality including LCC-WRITE, and can operate within a LANE under the condition that the protocol
has knowledge that an OMC has been applied and its capabilities known. An Advanced OMC supports
LCC-READ and LCC-WRITE and therefore can communicate its presence and capabilities to the protocol.
Read and write functions are provided for OMC configuration. Definitions and operation of these functions
are in Section 4.7.4.2 and Section 4.8.1.2. OMC-specific details can be found in Section 7.6.
7.3 Internal and External OMCs

595 An Internal OMC is contained within the mechanical outline of the mobile device and has no externally
available end-user connector. An optical interconnect inside a mobile device can be used to interconnect two
printed circuit boards (PCB) or a module to a PCB. Some common examples include connections from
displays, cameras, or non-cellular RF transceivers to the main PCB.
596 An External OMC is used to connect a mobile device to other devices such as an auxiliary display.
Implementation details for External OMCs are beyond the scope of this specification. An OMC used by a
mobile manufacturer for test purposes is also not within the scope of this specification.
597 An OMC may be implemented as an internal or external interconnect. From the electrical interface
perspective there is no difference between the two options.

Confidential
01-Dec-2016
7.4 OMC – Architecture and Operations

598 An OMC shall support the state machine illustrated in Figure 57, which is based on the M-RX Type-I state
machine defined in Section 4.6.1. Differences from the Type-I state machine include the following:
599 • RCT from STALL to SLEEP and STALL to HIBERN8 are not supported by an OMC and as such
these transitions are not shown in Figure 57.
600 • DISABLED is a transitory state where the OMC shall independently move to HIBERN8 after an
internal POR condition within TOMC_POR.
DIF-P for 9 to 20 UIHS + TPWM-PREPARE . Ready for LINE-CFG within that period (with respect to maximum allowed data rate in configured PWM-GEAR)
HS-MODE DIF-N
DIF-N to DIF-P
transition
STALL HS-BURST
9 to 20 UI HS of DIF-N
9x PWM-b1
DIF-N for
TACTIVATE DIF-N
DIF-P to DIF-N DIF-N to DIF-P
transition at RCT transition
completion of
MODE-LCC
9x PWM-b0 + 1x PWM-b1
LS-MODE
DIF-P to DIF-N
Update of INLINE configuration = State
transition
settings during SLEEP or STALL HIBERN8 = State with sub-FSM
after Re-Configuration Trigger (RCT) = Global state
= Power saving (SAVE) states
Internal POR DIF-Z
= HS-MODE states
(t < TOMC_POR)
= LS-MODE states (PWM)
POR Completion = Special states
DISABLED LINE-RESET = NRZ-LINE condition
= PWM-LINE condition
Power
= CONFIG condition
Supply DIF-P
On
Power
DIF-P for TLINE-RESET
Supply
Off
Figure 57 OMC State Diagram (based on Type-I M-RX)
601 The state machine requires that the OMC pass static, DC-unbalanced and DC-balanced signaling. For
STALL, SLEEP, HIBERN8, LINE-RESET states and the transition out of these states, a static driven signal is
transmitted. The maximum time that a LANE may stay in these power saving states is not defined. For
LINE-CFG and the transmission of LCCs, unbalanced signaling is transmitted. The worst case condition
occurs in LINE-INIT, which is maintained by the transmission of a continuous PWM-b1. The upper limit for
the time duration of LINE-INIT is not specified. DC unbalancing is defined by the PWM signaling
characteristics, the FIXED-RATIO scheme is used for gears PWM-G1 and greater, and the FIXED-MINOR
scheme for the optional PWM-G0. Finally, during PWM-BURST and HS-BURST 8b10b fully DC-balanced
data is transmitted.

Confidential
01-Dec-2016
602 The following sections add further information to the state machine state definitions given in Section 4.6 with
reference to the OMC and OMC state machine. The OMC state machine shall change state based on input
from the protocol through the M-TX using LINE signaling only. No additional signaling for the OMC,
outside of the LINE, is provided in this document.
7.4.1 OMC – Data Transmission BURST Modes

603 This document supports three kinds of BURST transmission, including SYS-BURST, HS-BURST and
PWM-BURST. An OMC shall support the Type-I PWM-BURST state, and may support the Type-I
HS-BURST state.
604 While operating in BURST mode the O-TX input shall conform to the M-RX input specifications defined in
Section 5.2.1, and the O-RX output shall conform to the M-TX output specifications defined in
Section 5.1.1.
7.4.1.1 OMC – PWM-BURST

605 A SYNC period does not follow the PREPARE period when moving from SLEEP state into PWM-BURST
Therefore, the OMC connection to the M-RX shall provide PWM data immediately following the PREPARE
period.
7.4.2 OMC – HS-BURST

606 For HS-BURST, an 8b10b-encoded SYNC sequence for a configurable period follows the PREPARE period.
Part of this sequence is available for OMC settling as well as the tuning and settling of any clock and data
recovery circuits in the M-RX. The OMC settling TOMC_HS_START shall be added to any requirement of
M-RX circuitry when setting the SYNC length. During the SYNC period the OMC shall hold a PREPARE
DIF-P at the output pins until sufficient settling is achieved to transmit valid in-specification data. A small
amount of additional pulse width distortion is expected due to desquelching the O-RX output driver.
7.4.3 OMC – DISABLED

607 The DISABLED state is a transitory state whereby the OMC initiates an independent internal POR. Upon
completion of an internal POR, the OMC shall automatically transition to HIBERN8, which is the lowest
power state for the OMC. A POR condition, from entering the DISABLED state to exiting the POR into the
HIBERN8 state shall conform to TOMC_POR as specified in Table 26.
Table 26 POR Timing

Values Note / Test
Parameter Symbol Units
Min. Max. Condition
Time taken from entering

DISABLED to exiting POR into TOMC_POR 1 ms
HIBERN8
7.4.3.1 Power Supply Removal

608 The OMC shall enter the DISABLED state from any state with the removal and reapplication of the power
supplies. No additional signaling is available to enter the DISABLED state. The OMC should internally
handle any additional requirements for POR.
609 The OMC shall exit the DISABLED state with default configuration settings.

Confidential
01-Dec-2016
7.4.3.2 OMC – HIBERN8

610 HIBERN8 is the lowest power dissipating state for an OMC. During HIBERN8 the OMC shall ensure the
LINE is properly terminated. For implementations where the M-TX relies on the O-TX for termination and
O-RX relies on the M-RX for termination, the O-TX shall include a weak pull down (DIF-Z), and the O-RX
shall maintain a high output impedance as defined in Section 5.2.1 and illustrated for the OMC use-case in
Figure 58.
LANE
M-TX M-RX
PINs Optical wave guide PINs
HIBERN8 HIBERN8
Auxiliary
RHIBERN8 interconnect
O-TX O-RX
LINE (blackbox)
= optional
Figure 58 DIF-Z OMC Implementation
7.4.4 OMC – Transitional States
7.4.4.1 OMC – LINE-RESET

611 OMC outputs shall follow M-TX outputs for the LINE-RESET condition and therefore shall comply with the
TLINE-RESET specification in Table 11.
7.5 OMC – Electrical and Interconnect

612 The electrical parameters defined in this section for the OMC use-case is referenced to the test points
illustrated in Figure 59. In order to meet an acceptable LINE jitter budget the galvanic connection between
the M-TX and O-TX, and the O-RX and M-RX, respectively, should be kept short. These short galvanic
connections are defined within this section, but are described for information only. For OMC use-cases the
mandatory specification are parameters defined at TP1 and TP4.
613 It is important to note that the OMC input (TP2) electrical characteristics are specified as per the M-RX in
Section 5.2.1 and the OMC output (TP3) electrical characteristics are specified as per the M-TX as defined in
Section 5.1.1.

Confidential
01-Dec-2016
TP1 TP2 TP3 TP4
LANE
Electrical
Electrical
RX
Optical wave guide
TX
M-TX O-TX O-RX M-RX
Auxiliary interconnect
PINs PINs
LINE (black-box)
= optional
Figure 59 Electrical Specification Test Points
7.5.1 OMC – Galvanic Connection Specification

614 Table 27 defines the electrical characteristics of a short galvanic connection for OMC use-cases. The
maximum expected connection length per side of the OMC is specified by Djgal-OMCcase.
Table 27 Galvanic Connection Specification (informative)

Values Note / Test
Min Max. Condition
Deterministic jitter contribution

from a length, Lgal-OMCcase of Djgal-OMCcase 0.04 UI
galvanic connection
615 For HS-G3 and HS-G4, the M-TX and O-TX, and the O-RX and M-RX should be separated with short
galvanic connections to meet the Djgal-OMCcase budget. If longer galvanic connections are necessary due to
usage requirements, independent LINE jitter budgets may be required between the M-TX and O-TX, and the
O-RX and M-RX. The independent LINE jitter budget is defined in Section 5.1.2.7 and Section 5.2.2.2,
however, the synchronization of independent LANEs to an OMC is outside the scope of this document.
7.5.2 OMC – Signal Delay

616 LINE delay due to galvanic connections and signal propagation delay due to the use of an OMC (or
electrically buffered PWM transmission using OMC auxiliary interconnect) are considered separately.
7.5.2.1 OMC – LINE Delay

617 A LINE delay is specified in Section 6.1 for electrical signal integrity. For the OMC use-case it is expected
that the short galvanic connection should easily meet this requirement. For some use-cases it is desirable to
bypass low speed signals from the input PINs to the output PINs by switching in a direct galvanic connection.
For this implementation the LINE is dependant on the termination in the M-RX. The OMC shall meet the
accordant LINE delay requirement.
7.5.2.2 OMC – Signal Propagation Delay

618 Some propagation delay is expected through the OMC during optical transmission, and in implementations
where bypassing is achieved using some form of buffering across an OMC auxiliary interconnect. This

Confidential
01-Dec-2016
propagation delay is not expected to result in signal integrity issues and shall be handled at a protocol level.
An OMC shall create no more than TOMC-PropDelay during BURST transmission.
619 The parameters for signaling delay through the OMC are defined in Table 28.
.
Table 28 Signaling Delay

Values Note / Test
Min. Max. Condition
Signal propagation delay through

optical media converter (for optical TOMC-PropDelay 50 ns
or buffered electrical transmission)
7.5.3 OMC – HS-BURST Operation
7.5.3.1 OMC – HS-BURST Timing

620 When entering HS-BURST state it is necessary to allow the OMC additional time to settle any internal
control loops, e.g., DC restoration or automatic gain control. This is supported by a SYNC period during
which a training sequence of configurable length is transmitted. It is important that the M-RX receive only
valid M-PHY signals and as such the OMC shall hold the PREPARE state at the outputs to the O-RX from the
beginning of the SYNC period until the OMC is fully settled, as defined by TOMC_HS_START.
621 For an advanced OMC this capability shall be stored as SI in the allocated field, MC_HS_START_TIME, for
reporting during an LCC-READ-CAPABILITY, as shown in Table 34.
622 It is likely that the first few bits transmitted from the OMC output upon entering HS-BURST will have
out-of-specification pulse width distortion while the O-RX output driver recovers from a squelched state.
TOMC_HS_START shall include all SYNC and PREPARE time requirements for the OMC, including any
termination switching time considerations for the O-TX. Any pulse width settling shall occur within the
specified start-up time TOMC_HS_START and therefore shall not reduce any settling time allocated for the
M-RX circuitry within the SYNC sequence. An OMC shall meet the specified HS-BURST amplitude
requirements during this time.
623 The SYNC period shall be configured for the additive settling of both the OMC and the M-RX circuitry.
624 When the OMC detects the TAIL-OF-BURST, HS-BURST ends, and the OMC shall return to STALL or
enter LINE-CFG state depending on the polarity of the TOB sequence. The OMC shall disconnect the
differential termination at the O-TX inputs within TOMC_TERM_DIS following the start of TAIL-OF-BURST.
TOMC_TERM_DIS provides sufficient time for the OMC to detect the TAIL-OF-BURST and disconnect the
differential termination for any HS-GEAR. Refer to Table 29 for OMC HS-BURST timing requirements.

Confidential
01-Dec-2016
HS Termination Connected
O-TX
DIF-N DIF-P HS Data
Input
Settling Data
O-RX
DIF-N DIF-P HS Data
Output
Valid
THS_PREPARE TOMC_HS_START
Data
DP
DN
Figure 60 HS-BURST Entry
Table 29 OMC HS-BURST Entry

Values Note / Test
Min. Max. Condition
Time required for the OMC to

TOMC_HS_START 10 s
transmit in-specification data
OMC differential termination Measured from
TOMC_TERM_DIS 50 ns
disconnect time the start of TOB
7.5.3.2 OMC – HS-BURST Jitter Budget

625 An OMC is intended as a drop-in signal repeater that substitutes the copper interconnects with a medium of
inherently higher bandwidth capability, mechanical reliability and lower EMI. While acknowledging these
inherent benefits it is also important to note the challenges of designing an optical LINK into a mobile
application. When designing to the ultra-low power demands of the mobile application, jitter becomes
strongly correlated to power dissipation. For these reasons, the optical jitter budget is kept as high as possible
while ensuring no disproportionate impact is made on other inline components. Table 30 specifies a separate
jitter budget for the OMC use-case that takes advantage of the shorter galvanic connections at the electrical
interfaces.
626 While the galvanic connection is short, jitter is expected to be generated by impedance mismatches from both
connection impedance and device termination. In addition to this, capacitive loading and reflections are also
seen as possible contributors to jitter on these connections.
627 The OMC total jitter TJOMC is a convolution of the deterministic jitter DJOMC and random jitter RJOMC (see
Equation 14). The OMC electrical jitter characteristics are defined in Section 5.1.2.7 for transmit jitter and
Section 5.2.2.2 for receive jitter tolerance.

Confidential
01-Dec-2016
Table 30 Optical Media Converter (OMC) Jitter Budget

Symbol Values Unit
TJOMC 0.27 UIHS
DJOMC 0.12 UIHS
7.5.3.3 OMC – PWM Transmit Ratio Budget

628 During an LCC-READ it is necessary to transmit data stored in the OMC to the M-RX requiring the
reproduction of the PWM transmit ratio. Table 31 provides values for the expected allocation of the link
budget. Values for M-TX output and M-RX input in Table 31 correspond to the parameters kPWM_TX and
kPWM_RX specified in Section 5 for galvanic interconnect use-cases and are provided here for information
only.
Table 31 Optical Media Converter (OMC) Transmit Ratio Budget

M-TX Galvanic OMC OMC Galvanic M-RX
Parameter Unit OMC
Output Connection Input Output Connection Input
Reference 1 1–2 2 2–3 3 3–4 4
0.630 / 0.625 / 0.605 / 0.600 /
KPWM (min) – 0.005 0.020 0.005
0.370 0.375 0.395 0.400
0.720 / 0.725 / 0.745 / 0.750 /
KPWM (max) – 0.005 0.020 0.005
0.280 0.275 0.255 0.250
7.6 OMC Configuration

629 An OMC shall support line-control-codes (LCCs) for state transitions out of LINE-CFG. A Basic OMC
supporting optional features beyond those specified as mandatory shall also support the required
CONFIG-LCCs associated with the supported features as outlined in Table 32. An OMC shall pass all LCCs
to the M-RX.
630 An Advanced OMC is defined as additionally supporting the CONFIG-LCC-READ commands, providing a
mechanism for the protocol to interrogate the PHY for information on OMC configurable capabilities and
settings as well as other proprietary data, e.g., device ID, IC revision etc.
7.6.1 OMC Detection
7.6.1.1 Basic OMC

631 It is expected that for a Basic OMC, system awareness is hard-coded at the implementation stage in some
protocol memory. This is then acknowledged by the protocol during system configuration. Further to this any
configurable capabilities supported by a Basic OMC shall also be hard-coded if it is to be used by the PHY
interface.
7.6.1.2 Advanced OMC

632 An Advanced OMC shall support read capability as defined in Section 7.6.2.2. The presence of an Advanced
OMC within a PHY can be determined through interrogation of the read data stored at the M-RX, after an
LCC read action. In order to support discovery, one bit is assigned in the OMC capability register
(OMC_TYPE_Capability in Table 34). In the case of an Advanced OMC this attribute shall be set to “0”.

Confidential
01-Dec-2016
633 If a read operation is attempted on a PHY without an Advanced OMC, i.e. where LCC-READ-CAPABILTIY
is not supported, the four PWM-b1 bytes transmitted by the M-TX during a read, see Figure 62, shall be
received by the M-RX and stored in the OMC capability register. Therefore, for implementations using a
basic OMC, or a direct galvanic connection, the OMC_TYPE_Capability shall be set by default to “1”.
634 If OMC_TYPE_Capability is “1”, the other OMC attribute data stored in the M-RX is invalid since it is filled
with the four PWM-b1 bytes transmitted by the M-TX during the read operation.
635 The OMC_TYPE_Capability does not differentiate between a basic OMC and a direct galvanic connection; it
only indicates the presence of an Advanced OMC.
7.6.2 OMC – Configuration LCCs

636 Table 32 is an OMC-specific representation of the generic LCC definition provided in Table 12. The
capabilities of an OMC should be known by the protocol, outlined for Basic and Advanced use-cases in
Section 7.6.1, before configuration is attempted in order to prevent selection of unsupported options.
Table 32 OMC Line Control Codes1

b0 b1 TYPE b2 b3 b4 PARAM SETTING b5 b6 b7 b8 b9
0 0 0 RESERVED 1 1 1 1 1
0 0 1 RESERVED 0 1 1 0 0
0 1 0 RESERVED 0 0 0 1 1
0 1 1 HIBERN8-SLEEP 1 0 0 0 0
0 0 MISC
1 0 0 RESERVED 1 0 0 1 0
1 0 1 RESERVED 0 0 0 0 1
1 1 0 RESERVED 0 1 1 1 0
1 1 1 HIBERN8-STALL 1 1 1 0 1
0 0 0 READ-CAPABILITY 0 1 0 1 0
2
0 0 1 READ-CUSTOM-OTX 1 1 0 0 1
2
0 1 0 READ-CUSTOM-ORX 1 0 1 1 0
READ/ 0 1 1 READ-MFG-INFO 0 0 1 0 1
0 1
WRITE 1 0 0 READ-VEND-INFO 0 0 1 1 1
1 0 1 WRITE-ATTRIBUTE 1 0 1 0 0
2
1 1 0 WRITE-CUSTOM-OTX 1 1 0 1 1
1 1 1 WRITE-CUSTOM-ORX2 0 1 0 0 0
0 0 0 PWM-G0 0 0 1 1 0
0 0 1 PWM-G1 1 0 1 0 1
0 1 0 PWM-G2 1 1 0 1 0
0 1 1 PWM-G3 0 1 0 0 1
1 0 PWM-MODE
1 0 0 PWM-G4 0 1 0 1 1
1 0 1 PWM-G5 1 1 0 0 0
1 1 0 PWM-G6 1 0 1 1 1
1 1 1 PWM-G7 0 0 1 0 0

Confidential
01-Dec-2016
Table 32 OMC Line Control Codes1 (continued)

b0 b1 TYPE b2 b3 b4 PARAM SETTING b5 b6 b7 b8 b9
0 0 0 HS-G1A 1 0 0 1 1
0 0 1 HS-G2A 0 0 0 0 0
0 1 0 HS-G3A 0 1 1 1 1
0 1 1 HS-G4A 1 1 1 0 0
1 1 HS-MODE
1 0 0 HS-G1B 1 1 1 1 0
1 0 1 HS-G2B 0 1 1 0 1
1 1 0 HS-G3B 0 0 0 1 0
1 1 1 HS-G4B 1 0 0 0 1
1. Columns for LCC data bits in this table are not intended to convey any information on bit-order
transmission. Transmission of a 10-bit LCC should always begin with b0.
2. OMC-specific LCC.
637 Line-Control-Codes shall be entered from LINE-INIT, a LINE-CFG sub-state, where the LINE-CFG
sub-state machine is defined in Section 4.7.4.2. An OMC exits LINE-CFG to one of three states, SLEEP,
STALL or HIBERN8, on a Re-Configuration Trigger (RCT) shown in Figure 57. For an OMC, an RCT is an
internally driven event that shall occur within TRCT_SAVE moving to STALL and THIBERN8_ENTER_RX
moving to HIBERN8 from the DIF-P to DIF-N transition at the completion of an LCC. Further reference to
RCTs is given in Section 4.7.4.2.4.
638 The LCC type in Table 32 indicates the OMC destination state upon complete transmission of the code. A
READ/WRITE type LCC shall exit to LINE-INIT ready for additional LCCs. MODE-PWM type LCC
commands shall be followed by SLEEP. A MODE-HS-type LCC command shall be followed by STALL,
configured and ready for BURST mode transmission. MISC contains a mixed group of LCCs where
destination states are considered on an individual basis.
639 The OMC may enter the HIBERN8 state via two codes in order to indicate whether the OMC enters the
STALL or SLEEP state upon exiting HIBERN8 state. These codes are implemented to support direct entry
into the desired BURST state following HIBERN8.
7.6.2.1 OMC – LCC-WRITE

640 The write function may be used to load data onto the OMC for configuration purposes. Two types of write are
defined, WRITE-ATTRIBUTE supporting configuration of operational settings, e.g. termination settings,
and WRITE-CUSTOM supporting proprietary configurations required for stand-alone testing purposes.
641 Configurable write attributes within an OMC should be considered as write-only. There is no read function
for reading out configured write attribute data from an OMC to the M-RX.
642 Following an LCC-WRITE, the OMC shall expect a configuration field of 10-bit words. The first and last bit
of each 10-bit word shall be delimited with a PWM-b0, the remaining eight bits shall contain configuration
data.
643 For WRITE-ATTRIBUTE, the OMC shall return to the LINE-INIT sub-state immediately after receiving the
four delimited WRITE bytes. For WRITE-CUSTOM, the OMC shall return to the LINE-INIT sub-state upon
receiving nine PWM-b1s, as illustrated in Figure 61.

Confidential
01-Dec-2016
Write Data Field
LCC-WRITE LCC-WRITE exit LINE-INIT STATE

LINE-INIT STATE
WRITE1 WRITE2 WRITE3 WRITE<n> (9*PWM-b1's) (PWM-b1's)
(PWM-b1's)
OMC I/P
b0 b9
PWM-b0
Write Data Field
LCC-WRITE exit LINE-INIT STATE

LINE-INIT STATE LCC-WRITE
WRITE1 WRITE2 WRITE3 WRITE<n> (9*PWM-b1's) (PWM-b1's)
(PWM-b1's)
OMC O/P
b0 b9 WRITE-ATTRIBUTE <n> = 4
PWM-b0
WRITE-CUSTOM <n> = undefined
Figure 61 OMC WRITE Function
7.6.2.1.1 OMC – LCC-WRITE-ATTRIBUTE

644 WRITE-ATTRIBUTE is intended for setting configuration parameters required for LANE operation and
therefore requires protocol support. Following an LCC-WRITE-ATTRIBUTE the OMC shall expect a four
byte field of attribute configuration data as defined in Table 33.
645 M_TX_Amplitude, defined in Table 33, informs the OMC of the M-TX output amplitude and is derived from
TX_Amplitude, detailed in Table 51. M_TX_Amplitude is provided as information only for OMC
optimization at the implementer’s discretion. Details on the configuration of the settings listed in Table 33 are
provided in Table 53. For an LCC-WRITE, RESERVED data bit designations shall default to PWM-b1.
Table 33 LCC-WRITE-ATTRIBUTE
WRITE BIT Configuration Setting
0 DELIMITER (always 0)
1 M_TX_Amplitude (SA = 0, LA = 1))
2 MC_OUTPUT_Amplitude
3 MC_HS_Unterminated_Enable
4 MC_LS_Terminated_Enable
WRITE1
5 MC_HS_Unterminated_LINE_Drive_Enable
6 MC_LS_Terminated_LINE_Drive_Enable
7 RESERVED
8 RESERVED

Confidential
01-Dec-2016
Table 33 LCC-WRITE-ATTRIBUTE (continued)

WRITE BIT Configuration Setting
1 RESERVED
2 RESERVED
3 RESERVED
4 RESERVED
WRITE2
5 RESERVED
6 RESERVED
7 RESERVED
8 RESERVED
1 RESERVED
2 RESERVED
3 RESERVED
4 RESERVED
WRITE3
5 RESERVED
6 RESERVED
7 RESERVED
8 RESERVED
1 RESERVED
2 RESERVED
3 RESERVED
4 RESERVED
WRITE4
5 RESERVED
6 RESERVED
7 RESERVED
8 RESERVED
7.6.2.1.2 OMC – LCC-WRITE-CUSTOM

646 WRITE-CUSTOM is intended for stand-alone test purposes only and therefore does not require protocol
support. Provision is made for two WRITE-CUSTOM LCCs addressing the O-RX and O-TX individually.
Given the proprietary nature of this feature, and that no interoperability is required, the configuration field
length is undefined.

Confidential
01-Dec-2016
7.6.2.2 OMC – LCC-READ

647 Support for OMC LCC-READ commands is optional (see Table 36). However, if a MODULE includes a
particular OMC LCC-READ command, it shall implement it as described in the appropriate section.
648 Upon receiving an LCC-READ command the OMC shall transmit a four byte configuration field containing
OMC-specific data. This read function provides a mechanism for the PHY to read data from the OMC. Three
read commands are available, READ-CAPABILITY, which is used to recover data about the OMC’s
capabilities and is shown in Table 34, READ-MFG-INFO, which is used to retrieve manufacturing ID and
vendor-specific information, and READ-CUSTOM, which provides a configuration field that is left to the
implementer's definition.
649 Following an LCC-READ command the M-TX shall transmit four PWM-b1 delimited bytes to complement
the configuration field, illustrated in Figure 62. A PWM-b1 delimited byte shall consist of eight PWM-b1s
delimited by PWM-b0s. These bytes shall take the common construction of eight PWM-b1s delimited by a
PWM-b0 at the beginning and end to make ten PWM bits. The M-TX transmitted PWM-b1 bytes can be used
by the OMC to time the READ data onto the O-RX data outputs to the M-RX.
1*PWM-b1 1*PWM-b1 1*PWM-b1 1*PWM-b1

LINE-INIT STATE LCC-READ LINE-INIT STATE
delimited byte delimited byte delimited byte delimited byte
(PWM-b1's) (PWM-b1's)
OMC I/P
PWM-b0
Read Data Field
LINE-INIT STATE LCC-READ LINE-INIT STATE

READ1 READ2 READ3 READ4
(PWM-b1's) (PWM-b1's)
OMC O/P
b0 b9
PWM-b0
Figure 62 OMC READ Function
7.6.2.2.1 OMC – LCC-READ-CAPABILITY

650 The READ-CAPABILITY function can be used to retrieve an OMC’s capabilities for PHY configuration.
Following an LCC-READ-CAPABILITY the OMC shall transmit a four byte field of capability data to the
M-RX as defined in Table 34.
651 Details on the setting of the attributes listed in Table 34 are defined in Section 8.4.
Table 34 LCC-READ-CAPABILITY Supported Capabilities Bit Definitions

READ BIT Capabilities
1 MC_HSMODE_Capability
2 MC_HSGEAR_Capability (up to which GEAR) – bit0 (LSB)
3 MC_HSGEAR_Capability (up to which GEAR) – bit1
4 MC_HS_START_TIME – Var – bit0 (LSB)
READ1
5 MC_HS_START_TIME – Var – bit1
8 MC_HS_START_TIME – Range – bit0

Confidential
01-Dec-2016
Table 34 LCC-READ-CAPABILITY Supported Capabilities Bit Definitions (continued)

READ BIT Capabilities
1 MC_HSGEAR_Capability (up to which GEAR) - bit2 (MSB)
2 RESERVED
3 MC_RX_SA_Capability
4 MC_RX_LA_Capability
READ2
5 MC_LS_PREPARE_LENGTH – bit0 (LSB)
6 MC_LS_PREPARE_LENGTH – bit1
1 MC_PWMG0_Capability
2 MC_PWMGEAR_Capability (up to which GEAR) – bit0 (LSB)
3 MC_PWMGEAR_Capability (up to which GEAR) – bit1
4 MC_PWMGEAR_Capability (up to which GEAR) – bit2
READ3
5 MC_HS_Unterminated_Capability
6 MC_LS_Terminated_Capability
7 MC_HS_Unterminated_LINE_Drive_Capability
8 MC_LS_Terminated_LINE_Drive_Capability
1 OMC_TYPE_Capability (Advanced = 0)
2 RESERVED
3 RESERVED
4 RESERVED
READ4
5 RESERVED
6 RESERVED
7 RESERVED
8 RESERVED
7.6.2.2.2 OMC – LCC-READ-MFG-INFO and LCC-READ-VEND-INFO

652 The READ-MFG-INFO function can be used to retrieve the Manufacturing ID and vendor-specific
information from an OMC. The Manufacturing ID two byte field shall be constructed as defined in
[ITUT01]. There are two LCCs assigned for this function that follow the four byte format as defined in
Section 7.6.2.2.

Confidential
01-Dec-2016
653 After receiving an LCC-READ-MFG-INFO an OMC shall transmit two delimited bytes containing
Manufacturing ID in the fields READ1 and READ2, followed by two delimited bytes containing
vendor-specific information in fields READ3 and READ4, defined in Table 35.
654 After receiving an LCC-READ-VEND-INFO an OMC shall transmit an additional four delimited bytes
containing vendor-specific information as defined in Table 35. This additional vendor-specific information
complements the two bytes transmitted during an LCC-READ-MFG-INFO triggered read.
655 The content of vendor-specific information is not defined further in this specification to allow full
implementation flexibility. For example, the field could be fixed, reporting IC revision data, or
programmable, using Non-Volatile Memory, supporting OMC revision data.
656 Further description of the bytes listed in Table 35is defined in Table 57
Table 35 LCC-READ-MFG-INFO and LCC-READ-VEND-INFO Byte Map

Byte READ-MFG-INFO READ-VEND-INFO
READ1 MC_MFG_ID_Part1 MC_Vendor_Info_Part1
READ2 MC_MFG_ID_Part2 MC_Vendor_Info_Part2
READ3 MC_PHY_MajorMinor_Release_Capability MC_Vendor_Info_Part3
READ4 MC_PHY_Editorial_Release_Capability MC_Vendor_Info_Part4
7.6.2.2.3 OMC – LCC-READ-CUSTOM

657 The READ-CUSTOM function is intended for stand-alone test purposes only and therefore does not require
protocol support. Provision is made for two READ-CUSTOM LCCs addressing the O-RX and O-TX
individually. This read function shall follow the four byte format as defined in Section 7.6.2.2.
7.7 OMC – M-PHY Conformance

658 There are different levels of M-PHY conformance for an OMC as defined in Table 36.
659 An OMC shall support the features in Table 36 labeled “Required”. An OMC may support features labeled
“Optional”. An OMC shall not support features labeled as “Not Supported”.
Table 36 OMC M-PHY Conformance

Feature Support
SLEEP State Required
PWM-BURST-MODE – GEAR1 Required
PWM-BURST-MODE GEARs other than GEAR1 Optional
HS-BURST-MODE Optional
Required
STALL State
If HS-BURST-MODE is supported
LINE-CFG State Required
WRITE-ATTRIBUTE Command Required
WRITE-CUSTOM Command Optional
READ-CAPABILITY Command Required for Advanced OMC
READ-CUSTOM Command Optional

Confidential
01-Dec-2016
Table 36 OMC M-PHY Conformance (continued)

Feature Support
READ-MFG-INFO and READ-VEND-INFO Required for Advanced OMC
LINE-RESET State Required
HIBERN8 State Required
SYS-BURST-MODE Not Supported
7.8 OMC – Test Methodology

660 An OMC shall be tested against the M-PHY-specified electrical characteristics. The OMC shall provide a
signal at its outputs that conforms to all M-RX requirements for any valid input signals provided by an
M-TX, except as provided for in this section. For conformance testing this requirement is inclusive of the
galvanic connection between the OMC and MODULE.
661 Parameters requiring special attention for the OMC use-case, i.e. jitter, propagation delay, POR timing etc,
have test conditions or notes outlined within Section 7. These conditions can be found alongside the
appropriate parameter definition.

Confidential
01-Dec-2016
8 The Protocol Interface

662 This section defines the Protocol Interface of M-PORTs. This interface connects an M-PORT with the
Protocol Layer that utilize M-PHY for the Physical Layer. Protocols applying M-PHY technology include
UniProSM and DigRFSM v4. The M-PORT Protocol Interface is represented in Figure 63.
Protocol Layer
LANE MANAGEMENT
M-TX- M-RX-
M-TX-CTRL M-RX-CTRL
SAP
DATA SAP
DATA
SAP SAP
Control Entity Data Entity Control Entity Data Entity

M-TX M-RX
MIB MIB
Control Plane Data Plane Control Plane Data Plane

M-TX M-RX
M-PORT
Figure 63 M-PORT Protocol Interface
663 The normative interface specification is based on service access points (SAPs) and service primitives.
M-TX-DATA SAP (M-TX Data Service Access Point) and M-RX-DATA SAP (M-RX Data Service Access
Point) provide access to the data services of an M-TX and an M-RX, respectively. M-TX-CTRL SAP (M-TX
Control Service Access Point) and M-RX-CTRL SAP (M-RX Control Service Access Point) provide access
to configuration and reset services of an M-TX and M-RX, respectively.
664 All data transported across LANEs goes through, and is controlled by, the M-TX-DATA and M-RX-DATA
SAPs, while the M-TX and M-RX local RESET, LINE-RESET, mode and parameter settings (configuration)
are controlled through the M-TX-CTRL and M-RX-CTRL SAPs.
665 An M-PORT may consist of one or more M-TXs and one or more M-RXs. All individual M-TXs and M-RXs
in an M-PORT are independent from the Protocol Interface perspective and each MODULE has its own
DATA and CTRL SAP. Constraints on supported MODULE functionality of multi-LANE SUB-LINKS are
specified in Section 4.9. LINK composition and usage of LANEs shall be defined by protocols that utilize
M-PHY technology for the Physical Layer.
8.1 Service Primitive Naming Convention

666 This document uses an OSI-conforming naming convention for service primitives. Service primitive names
are structured as follows:
667 <service-primitive>::= <name-of-service-primitive> ( {<parameter>, }*)
668 <name-of-service-primitive> ::= <layer-identifier> - <service-primitive-name> .
<primitive>
669 <parameter> ::= <service control information> | <service user data>

Confidential
01-Dec-2016
670 <layer-identifier> ::= M (or M-LANE or M-CTRL)

671 <service-primitive-name> ::= e.g. SYMBOL | PREPARE | CFGGET | CFGSET | …
672 <primitive> ::= request | indication | response | confirm
673 Services are specified by describing the service primitives and parameters that characterize them. A service
may have one or more related primitives that constitute the activity that is related to that particular service.
Each service primitive may have zero or more parameters that convey the information required to provide the
service.
674 A primitive can be one of four generic types:
675 • Request: The request primitive is passed from the Protocol Layer to a MODULE to request that a
service is initiated by the MODULE.
676 • Indication: The indication primitive is passed from a MODULE to the Protocol Layer to indicate
an event that is significant to the Protocol Layer. This event may be logically related to a remote
service request, or it may be caused by a LANE event.
677 • Response: The response primitive is passed from Protocol Layer to a MODULE to complete a
procedure previously invoked by an indication primitive.
678 • Confirm: The confirm primitive is passed from a MODULE to the Protocol Layer to convey the
results of one or more associated previous service requests.
8.2 M-TX-DATA and M-RX-DATA SAP

679 The M-TX-DATA SAP and M-RX-DATA SAP contain service primitives for data transfer between the
Protocol Layer and the MODULEs of an M-PORT. More specifically, M-TX-DATA SAP provides service
primitives for sending data, FILLER symbols, changing the LINE state between BURST-SAVE loop, and
sending programmable synchronization pattern during SYNC period of HS-BURST. M-RX-DATA SAP
provides service primitives to transfer received data, indicate LINE state change between BURST-SAVE
loop and reception of FILLER symbols to the Protocol Layer. Each MODULE (M-TX or M-RX) shall have
its own SAP (M-TX-DATA SAP or M-RX-DATA SAP, respectively). Table 37 and Table 38 give an
overview of the service primitives provided by the M-TX-DATA SAP and the M-RX-DATA SAP,
respectively, and displays the respective section numbers.
Table 37 M-TX-DATA SAP Service Primitives

Name Request Indication Response Confirm
M-LANE-SYMBOL 8.2.1 n/a n/a 8.2.3
M-LANE-PREPARE 8.2.4 n/a n/a 8.2.6
M-LANE-SYNC 8.2.7 n/a n/a 8.2.8
M-LANE-BurstEnd 8.2.9 n/a n/a 8.2.11
M-LANE-SaveState n/a 8.2.13 n/a n/a
M-LANE-AdaptStart 8.2.15 n/a n/a 8.2.16
M-LANE-AdaptComplete n/a 8.2.17 n/a n/a
Table 38 M-RX-DATA SAP Service Primitives

M-LANE-SYMBOL n/a 8.2.2 n/a n/a

Confidential
01-Dec-2016
Table 38 M-RX-DATA SAP Service Primitives (continued)

M-LANE-PREPARE n/a 8.2.5 n/a n/a
M-LANE-BurstEnd n/a 8.2.10 n/a n/a
M-LANE-HIBERN8Exit n/a 8.2.12 n/a n/a
M-LANE-AdaptComplete n/a 8.2.17 n/a n/a
680 There are parameters associated with some of these primitives. Table 39 defines the names, types and valid
ranges of these parameters.
Table 39 Parameters of M-TX-DATA SAP and M-RX-DATA Service Primitives

Name Type Valid Range Description
DataN_Ctrl Boolean FALSE, TRUE Data symbol or control symbol selector
Normal PAYLOAD data.
DataValue Integer 0 to 1023 When 8b10b coding is enabled, the valid range
is 0 to 255.
MarkerN_Filler Boolean FALSE, TRUE MARKER or FILLER control symbol selection
MarkerNumber Integer 0 to 6 Type of MARKER symbol selector
3b4b_Error Boolean FALSE, TRUE 3b4b Sub-block coding error
5b6b_Error Boolean FALSE, TRUE 5b6b Sub-block coding error
Res_Error Boolean FALSE, TRUE Reserved symbol error
RD_Error Boolean FALSE, TRUE Running Disparity error
State Enum SLEEP, STALL Entering SAVE state
Status Boolean ACCEPTED, BUSY Indicates acceptance of symbol
Data for programmable synchronization
SyncData Integer 0 to 1023
sequence
WaitType Enum NoConfig, Config Indicates minimum waiting time in SAVE state
681 The following sections define the meaning of M-TX-DATA SAP and M-RX-DATA SAP service primitives
and their associated parameters.
8.2.1 M-LANE-SYMBOL.request
682 This primitive requests the transmission of either a PAYLOAD data symbol or a control symbol from the
Protocol Layer to an M-TX. The control symbol can be either a MARKER symbol or a FILLER symbol. See
Section 4.5.2 and Section 4.7.2 for constraints on MARKER usage by the Protocol.
8.2.1.1 Semantics of the Service Primitive

683 The semantics of the M-LANE-SYMBOL.request are as follows:
684 M-LANE-SYMBOL.request (
685 DataN_Ctrl,
686 DataValue,
687 MarkerN_Filler,
688 MarkerNumber

Confidential
01-Dec-2016
689 )
690 Table 40 specifies the parameters for the M-LANE-SYMBOL request primitive.
Table 40 Parameters for the M-LANE-SYMBOL.request Primitive

DataN_Ctrl set to “FALSE” selects value associated
with the DataValue parameter for transmission;
FALSE = 0,
DataN_Ctrl Boolean DataN_Ctrl set to “TRUE” chooses either a MARKER
TRUE = 1
or a FILLER control symbol based on the value of
MarkerN_Filler parameter for transmission.
Normal PAYLOAD data.
When 8b10b coding is enabled, the valid range is 0
DataValue Integer 0 to 1023 to 255.
This parameter shall be ignored when DataN_Ctrl set
to “TRUE”.
MarkerN_Filler set to “FALSE” selects MARKER
symbol based on the value of MarkerNumber
parameter for transmission;
FALSE = 0,
MarkerN_Filler Boolean MarkerN_Filler set to “TRUE” selects the FILLER
TRUE = 1
symbol for transmission;
to “FALSE”.
MarkerNumber set to n selects MKn for transmission,
where n is any number in the valid range. For
MarkerNumber Integer 0 to 6 example, if MarkerNumber = 0, MK0 is selected.
This parameter shall be ignored when DataN_Ctrl is
set to “FALSE” or MarkerN_Filler is set to “TRUE”.
8.2.1.2 When Generated

691 This primitive shall be generated by the Protocol Layer in order to transmit a data symbol, a MARKER
symbol or a FILLER symbol over the LINE. This primitive, with details as M-LANE-SYMBOL.request
(FALSE, DataValue, X, X), where DataValue takes valid range as defined in Table 40 and X means ignore
that parameter, shall be generated by the Protocol Layer in order to transmit a symbol over the LINE.
692 Since MARKER0 symbol is needed to achieve symbol boundary synchronization at M-RX, before actual
PAYLOAD data transmission starts, the Protocol Layer shall generate this primitive with MARKER0 symbol
details, i.e., M-LANE-SYMBOL.request (TRUE, X, FALSE, 0), where X means ignore that parameter, at the
very beginning of a data transmission BURST. In other words, the Protocol Layer shall generate this
primitive with MARKER0 symbol details after issuing an M-LANE-PREPARE.request, but before issuing
this primitive with details other than MARKER0 symbol.
693 This primitive with MKn symbol details, i.e., M-LANE-SYMBOL.request (TRUE, X, FALSE, n), where X
means ignore a parameter and n is the MarkerNumber, is used by the Protocol Layer to request a MARKERn
during a BURST.
694 Protocol Layer may request transmission of a FILLER symbol, explicitly, by using this primitive with
FILLER symbol details, i.e., M-LANE-SYMBOL.request (TRUE, X, TRUE, X), where X means ignore that
parameter. Note that M-TX will insert FILLER symbols autonomously in a BURST state as described in the
Section 4.7.2.4.
695 The Protocol Layer shall not exceed the valid range of any parameter. The Protocol Layer shall not request
this primitive with DataN_Ctrl set to “TRUE” when 8b10b coding is disabled. If this primitive is requested

Confidential
01-Dec-2016
with DataN_Ctrl set to “TRUE” when 8b10b coding is disabled, the MODULE might not behave properly. A
MODULE shall not verify the validity of any parameter value. Out of range values might lead to malfunction
of a MODULE.
8.2.1.3 Effect on Receipt

696 When this primitive is requested with DataN_Ctrl set to “FALSE” and 8b10b encoding is enabled, the M-TX
shall encode the DataValue byte into an 8b10b Data symbol and then transfer the symbol over the LINE.
697 When this primitive is requested with DataN_Ctrl set to “FALSE” and 8b10b coding is disabled, the M-TX
shall transfer the symbol in DataValue unchanged over the LINE.
698 When this primitive is requested with DataN_Ctrl set to “TRUE”, MarkerN_Filler set to “FALSE”,
MarkerNumber set to a valid MARKER symbol number, and 8b10b encoding is enabled, the M-TX shall
transmit an 8b10b control symbol corresponding to the requested MARKER symbol over the LINE.
699 When this primitive is requested with DataN_Ctrl set to “TRUE” and MarkerN_Filler set to “TRUE”, and
8b10b coding is enabled, the M-TX shall transmit the 8b10b control symbol corresponding to the FILLER
symbol over the LINE.
700 Refer to Section 4.5 for encoding and serialization process.
8.2.2 M-LANE-SYMBOL.indication
701 This primitive reports the reception of a data PAYLOAD byte or a MARKER or a FILLER symbol over the
LINE.

702 The semantics of the M-LANE-SYMBOL.indication primitive are as follows:
703 M-LANE-SYMBOL.indication(
704 DataN_Ctrl,
705 DataValue,
706 MarkerN_Filler,
707 MarkerNumber,
708 3b4b_Error,
709 5b6b_Error,
710 RD_Error,
711 Res_Error
712 )
713 Table 41 specifies the parameters for the M-LANE-SYMBOL.indication primitive.
Table 41 Parameters for the M-LANE-SYMBOL.indication Primitive

When DataN_Ctrl set to “FALSE”, the value
associated with the DataValue parameter shall be
FALSE = 0, considered as a received PAYLOAD symbol;
DataN_Ctrl Boolean
TRUE = 1 When DataN_Ctrl is set to “TRUE”, the value of
MarkerN_Filler shall be used to identify the type of
control symbol received
Indicates normal PAYLOAD data, one symbol in
length. When 8b10b decoding is enabled, the valid
DataValue Integer 0 to 1023
range is 0 to 255. This parameter shall be ignored
when DataN_Ctrl set to “TRUE”

Confidential
01-Dec-2016
Table 41 Parameters for the M-LANE-SYMBOL.indication Primitive (continued)

If the value set to MarkerN_Filler is “FALSE”, then
the value associated with a MarkerNumber
parameter shall be used in identifying the type of
MARKER symbol received;
FALSE = 0,
MarkerN_Filler Boolean When MarkerN_Filler is set to “TRUE”, it shall be
TRUE = 1
considered as reception of a FILLER symbol over the
LINE;
to “FALSE”
MarkerNumber set to n indicates MKn is received,
where n is any number in the valid range. For
MarkerNumber Integer 0 to 6 example, if MarkerNumber = 0, MK0 is received.
This parameter shall be ignored when DataN_Ctrl is
set to “FALSE” or MarkerN_Filler is set to “TRUE”.
3b4b Sub-block coding error;
FALSE = 0,
3b4b_Error Boolean FALSE: No error detected
TRUE = 1
TRUE: Error detected
5b6b Sub-block coding error;
FALSE = 0,
5b6b_Error Boolean FALSE: No error detected
TRUE = 1
Running Disparity error;
FALSE = 0,
RD_Error Boolean FALSE: No error detected
TRUE = 1
Reserved symbol error;
FALSE = 0,
Res_Error Boolean FALSE: No error detected
TRUE = 1

714 This primitive shall be generated by the M-RX when an 8b10b data symbol or a control symbol
corresponding to any valid MARKER symbol, or FILLER is received over the LINE.
715 When 8b10b decoding is disabled, DataN_Ctrl shall be set to “FALSE”, DataValue shall carry the symbol as
received and all other fields shall be ignored.
716 When 8b10b decoding is enabled, if the received 8b10b symbol is a valid data symbol, DataValue shall carry
the decoded PAYLOAD byte. In this case, 3b4b_Error, 5b6b_Error, Res_Error and DataN_Ctrl shall be set to
“FALSE”, and all other parameter values, except DataValue, shall be ignored
717 When 8b10b decoding is enabled, if the received 8b10b symbol is a MARKER symbol, then the M-RX shall
set DataN_Ctrl to “TRUE”, MarkerN_Filler to “FALSE”, and MarkerNumber to a number corresponding to
the received MARKER symbol. DataValue may be set to “0”. The Protocol Layer shall ignore DataValue. All
error parameters shall be set to “FALSE”.
718 When 8b10b decoding is enabled, if the received 8b10b symbol is a FILLER symbol, then the M-RX shall set
DataN_Ctrl to “TRUE” and MarkerN_Filler to “TRUE”. DataValue and MarkerNumber may be set to “0”.
The Protocol Layer shall DataValue and MarkerNumber. All error parameters shall be set to “FALSE”.
719 When 8b10b decoding is enabled, if the received 8b10b symbol is an invalid symbol, DataValue shall carry
the remapped PAYLOAD byte, with potentially incorrect bits for the invalid sub-block, but correct bits of the

Confidential
01-Dec-2016
valid sub-block. In this case, 3b4b_Error or 5b6b_Error shall be set to “TRUE”, depending on which of the
sub-blocks was in error.
720 When 8b10b decoding is enabled, if the received 8b10b symbol is a valid, but reserved symbol (i.e. not equal
to a data symbol, a MARKER symbol or FILLER), DataValue shall carry the remapped PAYLOAD byte. In
this case, Res_Error shall be set to “TRUE”.
721 When 8b10b decoding is enabled, if the Running Disparity (RD) in the M-RX (See Section 4.5.3) computes
an RD error for the currently received 8b10b symbol, the RD_Error parameter shall be set to “TRUE”. This
setting shall not depend on the other error parameters described above.

722 On receipt of the M-LANE-SYMBOL.indication primitive, the Protocol Layer is notified of the availability
of inbound data byte, or the reception of a MARKER symbol or FILLER symbol, by the M-RX and
generating a corresponding MARKER number or FILLER indication, and error information at M-RX. The
Protocol Layer shall consume the data byte or a MARKER number along with error information, and may
carry out appropriate Protocol action.
723 The Protocol Layer shall ignore MarkerN_Filler and MarkerNumber when DataN_Ctrl is set to “FALSE”,
and it shall ignore DataValue when DataN_Ctrl is set to “TRUE”. The Protocol Layer shall ignore
MarkerNumber when MarkerN_Filler is set to “TRUE”.
8.2.3 M-LANE-SYMBOL.confirm
724 This primitive informs the Protocol Layer that the M-TX has completed the previously issued
M-LANE-SYMBOL.request.

725 The semantics of M-LANE-SYMBOL.confirm primitive are as follows
726 M-LANE-SYMBOL.confirm(
727 Status
728 )
729 Table 42 specifies the parameters for the M-LANE-SYMBOL.confirm primitive.
Table 42 Parameters for the M-LANE-SYMBOL.confirm Primitive

Status = ACCEPTED means that M-TX has accepted
the previously requested symbol for transmission and
ACCEPTED = 0, ready for new request to be served.
Status Boolean
BUSY = 1 Status = BUSY means that M-TX has rejected the
previously requested symbol; the Protocol Layer may
issue the request again.

730 This primitive shall be generated when the M-TX has either accepted or rejected the previously issued
M-LANE-SYMBOL.request primitive. It also confirms that the M-TX may accept another request to transfer
a PAYLOAD byte or a MARKER or a FILLER symbol from the Protocol Layer.

731 Following the issuing of an M-LANE-SYMBOL.request and prior to the reception of an
M -L A N E -S Y M B O L . c o n f i r m p r i m i t i v e , t h e P r o t o c o l L a y e r s h a l l n o t t r i g g e r a n e w

Confidential
01-Dec-2016
M-LANE-SYMBOL.request primitive. Upon receiving this primitive the Protocol Layer may issue a new
data or MARKER symbol, or configuration request or retry the previously rejected symbol request.
8.2.4 M-LANE-PREPARE.request
732 This primitive requests the M-TX to enter into a BURST state, either HS-BURST, PWM-BURST or
SYS-BURST depending upon the mode of operation, from the power saving state. See Section 4 for more
details on BURST state, power saving state and operating modes.

733 The semantics of the M-LANE-PREPARE.request primitive are as follows:
734 M-LANE-PREPARE.request (
735 )
736 This primitive has no parameter.

737 The Protocol Layer shall issue this primitive to request the M-TX to enter from power saving state to BURST
state corresponding to the M-TX mode of operation. This primitive shall only be issued when the M-TX is in
power saving state.

738 The M-TX shall enter into the BURST state following the sequence of operation as described in
Section 4.7.2.
8.2.5 M-LANE-PREPARE.indication
739 This primitive informs the Protocol Layer that the M-RX is coming out of power saving state and entering
into a BURST state (HS-BURST, PWM-BURST, or SYS-BURST) or ADAPT state depending on the M-RX
mode of configuration. See Section 4 for more details on BURST state, power saving state and operating
modes.

740 The semantics of the M-LANE-PREPARE.indication primitive are as follows:
741 M-LANE-PREPARE.indication (
742 )

744 The M-RX shall issue this primitive to the Protocol Layer when M-RX detects the start of the PREPARE sub-
state period while it is in power saving state.

745 The Protocol Layer shall accept M-RX entering to the BURST state corresponding to the M-RX mode of
operation and shall be prepared to receive data.
8.2.6 M-LANE-PREPARE.confirm
746 This primitive informs the Protocol Layer that the M-TX has started entering into BURST state following the
reception of M-LANE-PREPARE.request.

Confidential
01-Dec-2016

747 The semantics of M-LANE-PREPARE.confirm primitive are as follows
748 M-LANE-PREPARE.confirm(
749 )

751 This primitive shall be generated by the M-TX when it enters into a PREPARE period upon the reception of
an M-LANE-PREPARE.request primitive.

752 Upon receiving this primitive the Protocol Layer may issue a programmable synchronization sequence
through M-LANE-SYNC.request primitive when the M-TX is configured to receive external synchronization
pattern from the protocol. Otherwise, the Protocol Layer may issue MARKER0 symbol request at any time
during the SYNC period.
8.2.7 M-LANE-SYNC.request
753 This primitive requests the transmission of a programmable sync pattern byte wise over the LINE. For more
details on SYNC sequences see Section 4.7.2.2.

754 The semantics of the M-LANE-SYNC.request primitive are as follows:
755 M-LANE-SYNC.request (
756 SyncData
757 )
758 Table 43 specifies the parameters for the M-LANE-SYNC.request primitive
Table 43 Parameters for M-LANE-SYNC.request Primitive

A byte of data from the programmable sync
SyncData Integer 0 to 1023
sequence

759 This primitive shall be generated by the Protocol Layer to request the transmission of a synchronization
pattern to be provided by the protocol. This primitive only has effect if the M-TX is configured to send a
programmable synchronization sequence (i.e., TX_SYNC_Source is EXTERNAL_SYNC and the
configured GEAR requires a synchronization pattern). The synchronization sequence shall be issued to the
M-TX one byte at a time using this primitive. The Protocol Layer shall wait for the M-LANE-SYNC.confirm
primitive before issuing this primitive again. The first issue of this primitive shall only take place after the
Protocol Layer receives M-LANE-PREPARE.confirm primitive from the M-TX to the previously issued
M-LANE-PREPARE.request primitive and before SYNC period starts.

760 When 8b10b coding is enabled, the M-TX shall encode SyncData byte as an 8b10b symbol and then transfer
the symbol over the LINE. When 8b10b coding is disabled, the M-TX shall transfer the symbol in SyncData
unch anged ov er th e LIN E. Upo n tran smissio n of SyncD ata b yte th e M-T X sh all issue an
M-LANE-SYNC.confirm primitive to the Protocol Layer.

Confidential
01-Dec-2016
8.2.8 M-LANE-SYNC.confirm
761 This primitive informs the Protocol Layer that the M-TX has completed the previously issued service request
M-LANE-SYNC.request.

762 The semantics of M-LANE-SYNC.confirm primitive are as follows
763 M-LANE-SYNC.confirm(
764 )

766 This primitive shall be generated when the M-TX has completed serving the previously issued
M-LANE-SYNC.request primitive and is ready to accept another synchronization sequence symbol from the
Protocol Layer to transfer.

767 The Protocol Layer may issue a new synchronization symbol or MARKER symbol request upon receiving
this primitive. The Protocol Layer shall not issue a new M-LANE-SYNC.request until a previously issued
M-LANE-SYNC.request has been responded with this primitive.
8.2.9 M-LANE-BurstEnd.request
768 This primitive requests the M-TX to send TAIL-OF-BURST sequence.

769 The semantics of the M-LANE-BurstEnd.request primitive are as follows:
770 M-LANE-BurstEnd.request (
771 )

773 The Protocol Layer shall issue this primitive to request the M-TX end BURST state and enter a SAVE state or
LINE-CFG state.

774 The M-TX shall end the BURST state following the sequence of operation as described in Section 4.7.2.5.
8.2.10 M-LANE-BurstEnd.indication
775 This primitive reports the reception of a BURST CLOSURE condition to the Protocol as described in
Section 4.7.2.5.

776 The semantics of the M-LANE-BurstEnd.indication primitive are as follows:
777 M-LANE-BurstEnd.indication(
778 )

Confidential
01-Dec-2016

780 This primitive shall be generated by the M-RX to the Protocol Layer when M-RX detects a sequence of b0 or
b1 on LINE over the period defined in Section 4.7.2.5 while it is in BURST state.

781 Protocol Layer shall accept end of the BURST state and shall consider that the M-RX is entering either into
LINE-CFG state when sequence of b1 received over a period as described in Section 4.7.2.5.2 or SAVE state
when sequence of b0 received over a period as described in Section 4.7.2.5.1.
8.2.11 M-LANE-BurstEnd.confirm
782 This primitive informs the Protocol Layer that the M-TX has started sending a TAIL-OF-BURST sequence
following the reception of M-LANE-BurstEnd.request.

783 The semantics of M-LANE-BurstEnd.confirm primitive are as follows:
784 M-LANE-BurstEnd.confirm( WaitType )
785 Table 44 specifies the parameters for the M-LANE-BurstEnd.confirm primitive
Table 44 Parameters for M-LANE-BurstEnd.confirm Primitive

NoConfig = 0, Indicates minimum wait time before new BURST is
WaitType Enum
Config = 1 requested

786 The M-TX shall generate this primitive once it starts sending a TAIL-OF-BURST sequence after the
reception of an M-LANE-BurstEnd.request primitive.

787 Upon receiving this primitive, the Protocol Layer shall wait before asserting M-LANE-PREPARE.request for
at least TX_Min_SAVE_Config_Time_Capability if any configuration request is made (i.e. WaitType is
“ C o n f i g ” ) o r a t l e a s t T X _ M i n _ S L E E P _ N o C o n f i g _ Ti m e _ C a p a b i l i t y i n S L E E P s t a t e , o r
TX_Min_STALL_NoConfig_Time_Capability in STALL state, when no configuration request is made (i.e.
WaitType is “NoConfig”) after M-LANE-SaveState.indication primitive issued by M-TX.
8.2.12 M-LANE-HIBERN8Exit.indication
788 This primitive reports the exit of HIBERN8 state to the Protocol as described in Section 4.7.1.3.

789 The semantics of the M-LANE-HIBERN8Exit.indication primitive are as follows:
790 M-LANE-HIBERN8Exit.indication(
791 )

793 This primitive shall be generated by the M-RX to the Protocol Layer when M-RX detects exit of HIBERN8
state as defined in Section 4.7.1.3 while M-RX is in HIBERN8 state.

Confidential
01-Dec-2016

794 Protocol Layer shall accept exit of HIBERN8 state and shall consider that the M-RX is entering either to
SLEEP or to STALL state based on the value of RX_MODE attribute. The Protocol Layer may use this
primitive to get out of hibernation.
8.2.13 M-LANE-SaveState.indication
795 This primitive reports entry into a SAVE state to the Protocol.

796 The semantics of the M-LANE-SaveState.indication primitive are as follows:
797 M-LANE-SaveState.indication( State )
798 Table 45 specifies the parameters for the M-LANE-SaveState.indication primitive
Table 45 Parameters for M-LANE-SaveState.indication Primitive

SLEEP = 0,
State Enum SAVE state
STALL = 1

799 This primitive shall be generated by an M-TX when the M-TX enters either SLEEP state or STALL state.

800 Protocol Layer shall accept entry of the M-TX into either SLEEP or STALL state.
8.2.14 M-LANE-MRXSaveState.indication
801 This primitive reports M-RX entry into a SAVE state to the Protocol.

802 The semantics of the M-LANE-MRXSaveState.indication primitive are as follows:
803 M-LANE-MRXSaveState.indication( State )
804 Table 46 specifies the parameters for the M-LANE-MRXSaveState.indication primitive
Table 46 Parameters for M-LANE-MRXSaveState.indication Primitive

SLEEP = 0,
State Enum SAVE state
STALL = 1

805 This primitive shall be generated by an M-RX when the M-RX enters either SLEEP state or STALL state.

806 Protocol Layer shall accept entry of the M-RX into either SLEEP or STALL state.

Confidential
01-Dec-2016
8.2.15 M-LANE-AdaptStart.request
807 This primitive requests the transmission of the ADAPT sequence as described in Section 4.7.2.3.

808 The semantics of the M-LANE-AdaptStart.request primitive are as follows:
809 M-LANE-AdaptStart.request (
810 )

812 This primitive shall be generated by the Protocol Layer to request the ADAPT sub-state upon completion of
the PREPARE sub-state. The Protocol Layer shall issue this primitive when M-TX is configured in HS-
MODE and is in STALL state. The Protocol Layer may control the duration of the ADAPT sequence period
by setting the appropriate value of TX_HS_ADAPT_LENGTH prior to issuing this primitive.

813 M-TX shall prepare to transition from the STALL state to the PREPARE sub-state upon receiving this
primitive. After completion of the PREPARE period, the M-TX shall transmit the ADAPT sequence for
TADAPT as described in Section 4.7.2.3.
8.2.16 M-LANE-AdaptStart.confirm
814 This primitive confirms the Start of the ADAPT sequence initiated due to the previously issued
M-LANE-AdaptStart.request primitive.

815 The semantics of the M-LANE-AdaptStart.confirm primitive are as follows:
816 M-LANE-AdaptStart.confirm (
817 )

819 This primitive shall be generated by M-TX upon entering the PREPARE sub-state due to reception of the M-
LANE-AdaptStart.request primitive.

820 The Protocol Layer shall wait for completion of the ADAPT sequence indicated by M-TX through generation
of the M-LANE-AdaptComplete.indication service primitive and shall not request a new burst in between.
8.2.17 M-LANE-AdaptComplete.indication
821 This primitive indicates the completion of the ADAPT sequence.

822 The semantics of the M-LANE-AdaptComplete.indication primitive are as follows:
823 M-LANE-AdaptComplete.indication (
824 )

Confidential
01-Dec-2016

826 This primitive shall be generated by the M-TX and by the M-RX upon completion of the ADAPT sequence as
described in Section 4.7.2.3. After the ADAPT sequence, MODULE shall return to the STALL state, without
going through LINE-CFG.

827 The Protocol Layer shall consider completion of the ADAPT sequence when it receives this primitive. The
Protocol Layer may start a new burst.
8.2.18 Sequence of Service Primitives

828 The possible relationships among primitives at M-TX-DATA SAP and M-RX-DATA SAP are illustrated by
the given time sequence diagrams shown in Figure 64. They also indicate a possible logical relationship in
terms of time. Primitives that occur earlier in time and connected by dotted lines are logical predecessors of
subsequent primitives.

Confidential
01-Dec-2016
S e r v ic e
S e r v ic e U s e r S e r v ic e U s e r
P r o v id e r
( P r o to c o l L a y e r ) ( P r o to c o l L a y e r )
(P H Y )
M -L A N E -S Y M B O L .re q u e s t
M - L A N E - S Y M B O L . c o n fir m M - L A N E -S Y M B O L .in d ic a tio n
M -L A N E -P R E P A R E .re q u e s t
M - L A N E - P R E P A R E . c o n fir m M - L A N E -P R E P A R E .in d ic a tio n
M - L A N E -S Y N C . r e q u e s t
M -L A N E -S Y N C . c o n fir m
M - L A N E - B u r s tE n d . r e q u e s t
M - L A N E - B u r s tE n d . c o n fir m M - L A N E -B u r s tE n d .in d ic a tio n
M - L A N E -H IB E R N 8 E x it .in d ic a tio n
M - L A N E -S a v e S ta te . in d ic a tio n
M - L A N E - A d a p tS ta r t . r e q u e s t
M - L A N E - A d a p tS ta r t . c o n fir m
M -L A N E -A d a p tC o m p le te .in d ic a tio n M - L A N E - A d a p tC o m p le te . in d ic a tio n
M - L A N E -R X S a v e S ta te .in d ic a tio n
Figure 64 Sequence of Primitives at M-TX-DATA SAP and M-RX-DATA SAP
8.3 M-TX-CTRL SAP and M-RX-CTRL SAP

829 M-TX-CTRL SAP and M-RX-CTRL SAP contain service primitives for configuring M-TX and M-RX,
respectively, and obtaining capability and status information from these MODULEs. Table 47 and Table 48
give an overview of the service primitives provided by M-TX-CTRL SAP and M-RX-CTRL SAP,
respectively, and display the respective section numbers. There are parameters associated with these
primitives. Section 8.4 defines the name, type and valid range of these parameters.

Confidential
01-Dec-2016
Table 47 M-TX-CTRL SAP Service Primitives

M-CTRL-CFGGET 8.3.1 n/a n/a 8.3.2
M-CTRL-CFGSET 8.3.3 n/a n/a 8.3.4
M-CTRL-CFGREADY 8.3.5 n/a n/a 8.3.6
M-CTRL-RESET 8.3.7 n/a n/a 8.3.8
M-CTRL-LINERESET 8.3.9 n/a n/a 8.3.11
Table 48 M-RX-CTRL SAP Service Primitives

M-CTRL-CFGGET 8.3.1 n/a n/a 8.3.2
M-CTRL-CFGSET 8.3.3 n/a n/a 8.3.4
M-CTRL-CFGREADY 8.3.5 n/a n/a 8.3.6
M-CTRL-RESET 8.3.7 n/a n/a 8.3.8
M-CTRL-LINERESET n/a 8.3.10 n/a n/a
M-CTRL-LCCReadStatus n/a 8.3.12 n/a n/a
830 The parameters associated with these primitives are defined in Table 49 with the name, type and valid range.
Table 49 Parameters of M-TX-CTRL SAP and M-RX-CTRL SAP Service Primitives

Any AttributeID as defined in
MIBattribute Attribute name The name of the MIB attribute
Section 8.4
Depends on Depends on the attribute as
MIBvalue The value of the MIB attribute
attribute defined in Section 8.4
Indicates which Layer controls
TACTIVATE time and driving DIF-N.
ProtocolControlled = 0,
TActivateControl Enum TActivateControl is an optional
PhyControlled = 1
parameter. The default value is
ProtocolControlled.
831 The following sections define the meaning of M-TX-CTRL SAP and M-RX-CTRL SAP service primitives
and their associated parameters.
8.3.1 M-CTRL-CFGGET.request
832 This primitive requests information about a MIB attribute, which are defined in Section 8.4.

833 The semantics of the M-CTRL-CFGGET.request primitive are as follows:
834 M-CTRL-CFGGET.request(

Confidential
01-Dec-2016
835 MIBattribute
836 )
837 The primitive parameter is defined in Table 49.

838 This primitive is generated by the Protocol Layer to obtain information of an MIBattribute from a
MODULE’s MIB. The Protocol Layer shall ensure that the requested MIBattribute exists. The MODULE
may not check the validity of an MIBattribute. Undefined attribute names may result in malfunctioning of a
MODULE. After issuing an M-CTRL-CFGGET.request primitive, the Protocol Layer shall wait for the
M-CTRL-CFGGET.confirm primitive reception before issuing a new configuration service request.

839 The MODULE retrieves value of the requested attribute from its MIB and responds with
M-CTRL-CFGGET.confirm that gives the result.
8.3.2 M-CTRL-CFGGET.confirm
840 This primitive reports the result of a service request on MIBattribute.

841 The semantics of the M-CTRL-CFGGET.confirm primitive are as follows:
842 M-CTRL-CFGGET.confirm(
843 MIBvalue
844 )
845 The primitive parameters are defined in Table 49.

846 This primitive shall be generated by a MODULE in response to the most recent M-CTRL-CFGGET.request
by the Protocol Layer. The MIBvalue parameter shall contain the value of the requested MIBattribute.

847 The Protocol Layer shall accept this primitive in order to receive the value of the requested MIBattribute. The
MIBvalue parameter will carry this value.
8.3.3 M-CTRL-CFGSET.request
848 This primitive requests to set an MIB attribute indicated by the parameter MIBattribute to the value hold by
the parameter MIBvalue.

849 The semantics of the M-CTRL-CFGSET.request primitive are as follows:
850 M-CTRL-CFGSET.request(
851 MIBattribute,
852 MIBvalue
853 )
854 The primitive parameters are defined in Table 49.

855 The Protocol Layer shall generate this primitive to set an MIB attribute indicated by MIBattribute parameter
with the value of MIBvalue parameter. The Protocol Layer shall ensure that the requested MIBattribute exists
and the MIBvalue is in valid range of the requested MIBattribute. A MODULE may not check the validity of

Confidential
01-Dec-2016
MIBattribute and MIBvalue. Undefined attribute names or out of range attribute values may result in
malfunctioning of the MODULE. After issuing an M-CTRL-CFGSET.request primitive, the Protocol Layer
shall wait for the M-CTRL-CFGSET.confirm primitive reception before issuing a new configuration service
request.

856 The MODULE shall set the specified MIBattribute with the value carried by MIBvalue in its MIB registry. If
setting the value of an MIBattribute implies a specific action, then this action shall not be performed until the
M -C T R L -C F G R E A D Y. r e q u e s t p r i m i t i v e i s r e c e i v e d . T h e M O D U L E s h a l l r e s p o n d w i t h
M-CTRL-CFGSET.confirm after registering the MIBvalue for the requested attribute.
8.3.4 M-CTRL-CFGSET.confirm
857 This primitive confirms registering the attribute value based on the last issued request to set the value of an
attribute in the MIB.

858 The semantics of the M-CTRL-CFGSET.confirm primitive are as follows:
859 M-CTRL-CFGSET.confirm(
860 )

862 This primitive shall be generated by a MODULE in response to the most recent M-CTRL-CFGSET.request
by the Protocol Layer after setting the value of the requested MIBattribute.

863 The Protocol Layer is informed about serving the M-CTRL-CFGSET.request issued previously. The Protocol
Layer may issue another service request upon receiving this primitive.
8.3.5 M-CTRL-CFGREADY.request
864 This primitive requests a MODULE to update the operation settings of MIB attribute(s) with the
corresponding MIB values that are issued through previous M-CTRL-CFGSET.request.

865 The semantics of the M-CTRL-CFGREADY.request primitive are as follows:
866 M-CTRL-CFGREADY.request(
867 )

869 The Protocol Layer shall issue this primitive after sending all setting requests to MIB attributes that compose
a consistent new configuration parameter set. Issuing this primitive enables the MODULE to perform
specific actions based on the MIB attributes set and the values assigned to these attributes. If a MODULE is
in BURST state when this primitive is issued, then the Protocol Layer shall bring the MODULE into power
saving state before specific actions can be taken and the new setting become effective.

Confidential
01-Dec-2016

870 The MODULE shall perform specific actions, if any, required upon receiving this primitive, based on the
configuration set requests received before. These actions shall be performed, if needed, when the MODULE
is entering into or in power saving state.
8.3.6 M-CTRL-CFGREADY.confirm
871 This primitive reports the reception of M-CTRL-CFGREADY.request to update the operation settings to the
configured MIB attribute(s).

872 The semantics of the M-CTRL-CFGREADY.confirm primitive are as follows:
873 M-CTRL-CFGREADY.confirm(
874 )

876 This primitive shall be generated by the MODULE in response to the reception of
M-CTRL-CFGREADY.request by the Protocol Layer.

877 The Protocol Layer is informed about registering the M-CTRL-CFGREADY.request issued previously. Upon
receiving this primitive, if the MODULE is in BURST state, then the Protocol Layer shall request the
MODULE enter into power saving state.
8.3.7 M-CTRL-RESET.request
878 This primitive requests the MODULE reset to its Power-on Reset state. All previous configuration settings
are lost.

879 The semantics of the M-CTRL-RESET.request primitive are as follows:
880 M-CTRL-RESET.request(
881 )

883 The Protocol Layer issues this request when it is desired to reset the MODULE to its default state and
settings.

884 When the Protocol Layer issues this request, the MODULE shall enter into DISABLED state specified in
Section 4.7.1.4.
8.3.8 M-CTRL-RESET.confirm
885 This primitive shall only be utilized for modeling purposes of Protocol Layer.
886 This primitive informs the Protocol Layer that the MODULE has completed previously requested RESET
action and ready to service any request.

Confidential
01-Dec-2016

887 The semantics of the M-CTRL-RESET.confirm primitive are as follows
888 M-CTRL-RESET.confirm(
889 )

891 After a request from the Protocol Layer to reset the MODULE, the MODULE shall generate this primitive
upon completion of initialization and ready to receive a service request.

892 Upon receiving this primitive the Protocol Layer should aware that the MODULE has completed
initialization, reset all configuration settings to default values and entered HIBERN8 state.
8.3.9 M-CTRL-LINERESET.request
893 This primitive requests an M-TX perform a LINE-RESET action. All configuration settings (rates,
amplitudes, etc.) are lost and reset to default values. The M-TX also asserts a signal on the LINE so that the
remote M-RX recognizes the LINE-RESET state and acts as defined in Section 4.7.4.1.

894 The semantics of the M-CTRL-LINERESET.request primitive are as follows:
895 M-CTRL-LINERESET.request(
896 TActivateControl
897 )
898 The primitive parameter is defined in Table 49.

899 The Protocol Layer shall issue M-LANE-BurstEnd.request and wait for TACTIVATE after the M-TX has
generated M-LANE-SaveState.indication before issuing M-CTRL-LINERESET.request with
TActivateControl set to “ProtocolControlled”.
900 If M-CTRL-LINERESET.request with TActivateControl set to “PhyControlled” is issued when the M-TX is
in BURST state, the Protocol Layer shall be aware the PAYLOAD of an ongoing BURST is interrupted
immediately, and the M-TX might not trigger the proper BURST closure condition.

901 Upon receiving this request with TActivateControl set to “ProtocolControlled”, the M-TX shall immediately
drive the LINE-RESET condition as described in Section 4.7.4.1.
902 If this request is received with TActivateControl set to “PhyControlled”, the M-TX shall immediately drive
DIF-N on the LINE for TACTIVATE before driving the LINE-RESET condition.
8.3.10 M-CTRL-LINERESET.indication
903 This primitive reports to the Protocol Layer that the M-RX has been reset by a LINE-RESET

904 The semantics of the M-CTRL-LINERESET.indication primitive are as follows:
905 M-CTRL-LINERESET.indication(
906 )

Confidential
01-Dec-2016

908 When M-RX detects LINE-RESET as described in Section 4.7.4.1, it shall indicate the same to the Protocol
Layer using this primitive.

909 When the Protocol Layer receives this primitive, it should be aware that the LANE is reset by a LINE-RESET
and both M-TX and M-RX on this LANE will be in default state with default attribute values.
8.3.11 M-CTRL-LINERESET.confirm
910 This primitive informs the Protocol Layer that the MODULE has completed a previously requested
LINE-RESET action.

911 The semantics of the M-CTRL-LINERESET.confirm primitive are as follows:
912 M-CTRL-LINERESET.confirm(
913 )

915 After a request from the Protocol Layer to an M-TX to reset the LANE by a LINE-RESET, the M-TX shall
issue this primitive upon completion of the LINE-RESET operation as described in Section 4.7.4.1.
916 After exiting LINE-RESET, the Protocol Layer shall keep the M-TX for a given LANE in SLEEP state for
the greater of the local TX_Min_SAVE_Config_Time_Capability and, if known, the remote
RX_Min_SAVE_Config_Time_Capability.

917 Upon receiving this primitive the Protocol Layer should aware that the M-TX has completed LINE-RESET
activity and reset all configuration settings to default values while entering into SLEEP state.
8.3.12 M-CTRL-LCCReadStatus.indication
918 This primitive informs the Protocol Layer that M-RX is received result of LCC-READ command, which is
initiated at M-TX and the received result is set in the corresponding OMC Status attributes.

919 The semantics of the M-CTRL-LCCReadStatus.indication primitive are as follows
920 M-CTRL-LCCReadStatus.indication(
921 )

923 M-RX shall generate this primitive when it has received at least one LCC-READ sequence from the OMC
and has updated all pending OMC Status attributes addressed by the LCC-READ sequences indicated by an
LCC-MODE exit. The OMC status register consists of those OMC attributes listed in Table 57.

924 This primitive indicates to the Protocol Layer that an LCC-READ operation has been initiated at M-TX and
the corresponding LCC-READ result is available through OMC Status attributes. Protocol Layer may read
the value of OMC Status attributes using M-CTRL-CFGGET.request primitive before they are overwritten.

Confidential
01-Dec-2016
925 Whenever any member of a group is read via LCC-READ, all the members of the group are updated. Since a
group of attributes are read at the same time, the OMC status attributes output might change after receiving
another M-CNTRL-CFGGET.request primitive for that group.
8.3.13 Sequence of Service Primitives

926 The possible relationships among primitives at M-TX-CTRL SAP and M-RX-CTRL SAP are illustrated by
the given time sequence diagrams shown in Figure 65. They also indicate a possible logical relationship in
terms of time. Primitives that occur earlier in time and connected by dotted lines are logical predecessors of
subsequent primitives.
Service User Service Service User Service

Service User Service User
(Protocol Layer ) Provider (Protocol Layer ) Provider
(Protocol Layer ) (Protocol Layer )
(PHY) (PHY)
M-CTRL-CFGGET.request M-CTRL-CFGSET.request
M-CTRL-CFGGET.confirm M-CTRL-CFGSET.confirm
Service User Service Service User Service

Service User Service User
(Protocol Layer ) Provider (Protocol Layer ) Provider
(Protocol Layer ) (Protocol Layer )
(PHY) (PHY)
M-CTRL-
CFGREADY.request
M-CTRL-
CFGREADY.confirm M-CTRL-
LCCReadStatus.indication
Service Service
Service User Service User Service User Service User
Provider Provider
(Protocol Layer ) (Protocol Layer ) (Protocol Layer ) (Protocol Layer )
(PHY) (PHY)
M-CTRL- M-CTRL-
RESET.request LINERESET.request
M-CTRL-
M-CTRL- M-CTRL-
RESET.confirm
LINERESET.confirm
LINERESET.indication
Figure 65 Sequence of Service Primitives at M-TX-CTRL SAP and M-RX-CTRL SAP
8.4 M-TX and M-RX Attributes

927 Capability, configuration and status attributes for an M-TX are listed in Table 50, Table 51, and Table 52,
respectively, and for an M-RX these attributes are listed in Table 54, Table 55, and Table 56, respectively.
Write-only and status attributes relevant to OMC are listed in Table 53, and Table 57, respectively. Capability
attributes describe the capabilities of an implementation and shall be read-only. Currently, only one status
attribute is defined for a MODULE to provide the current operating state of the MODULE. In case of an
OMC, status attributes that are accessible at M-RX provide the result of an LCC-READ operation initiated at
M-TX. No request, such as M-CTRL-CFGSET.request, shall be made by Protocol to write any value to any
capability or status attribute. Any write request, such as M-CTRL-CFGSET.request, to a capability or status
attribute shall be ignored and shall not be responded by a MODULE.
928 Configuration attributes are used for configuring a MODULE based on applicable capabilities, if there are
any, to control its behavior. Configuration attributes shall be readable and writable. A write request, such as
M-CTRL-CFGSET, to a configuration attribute shall hold a valid AttributeID and attribute value
corresponding to that AttributeID. The attribute value shall not violate range of values of applicable
capabilities, if any, for that attribute. Validity check of AttributeID and its corresponding value for a write
request may not be performed in a MODULE. A read request, such as M-CTRL-CFGGET, to a configuration
or capability attribute shall hold a valid AttributeID. Validity check of AttributeID for a read request may not
be performed in a MODULE.
929 Write-only attributes of an OMC are used for configuring the OMC; there is no read function for reading
configured write attribute data from an OMC to the M-RX. No request, such as M-CTRL-CFGGET.request,

Confidential
01-Dec-2016
shall be made by the Protocol Layer to read a value from a write-only attribute. Any read request, such as
M-CTRL-CFGGET.request, to a write-only attribute shall be ignored and shall not be responded by a
MODULE.
930 The “Attribute Name” column in the tables specifies a symbolic name in a human readable form for an
attribute.
931 The “AttributeID” column contains a hexadecimal code for an attribute which shall be used in read or write
request made to an attribute. The parameter MIBattribute of M-CTRL-CFGGET.request and
M-CTRL-CFGSET.request service primitives shall contain AttributeID of an attribute.
932 The “Description” column of an attribute provides a brief description of the attribute and four optional fields.
933 • The “Existence depends on” field of an attribute contains capability attributes that are applicable
for its existence. An attribute becomes an Existence-dependant attribute if the “Description”
contains an “Existence Depends on” field. An Existence-dependent attribute exists if all attributes
listed in its “Existence Depends on” field are “TRUE”. Before making any read or write access to
an existence dependant attribute, the Protocol shall ensure that all the applicable attributes for its
existence are realizable to logical “TRUE” condition. If any of the attributes listed in the
“Existence Depends on” field of an Existence-dependant attribute results in a logical “FALSE”
condition then no access shall be made to that Existence-dependant attribute. For example, before
accessing TX_HSGEAR_Capability attribute, TX_HSMODE_Capability attribute’s value is
verified because the latter attribute is listed in the former attribute’s “Existence Depends on” field
(see Table 50). The TX_HSGEAR_Capability attribute is accessed if and only if
TX_HSMODE_Capability attribute’s value is “TRUE”.
934 • The “Value depends on” field of an attribute contains capability attributes that are applicable for
defining its value. While writing to an attribute that has a “Value Depends on” field, the value
being written to the attribute shall not exceed the worst case value limits defined for those
capability attributes that are listed in its “Value Depends on” field. For example, to set
TX_PWMGEAR attribute’s value, TX_PWMGEAR_Capability and TX_PWMG0_Capability
attribute values must be read as these attributes are listed in the former attribute’s “Value Depends
on” field. For example, if the value of the TX_PWMGEAR_Capability attribute is 5 and
TX_PWMG0_Capability is NO, then the value of TX_PWMGEAR attribute must be in the range
[1, 5] (worst case value limit).
935 • The “Req’d Values” field is applicable only to configuration attributes. If a configuration attribute
is supported by a MODULE, then the MODULE shall support all values or range of values
specified in the The “Req’d Values” field of that configuration attribute.
936 • The “Reset Value” field is applicable to configuration attributes only and specifies the default
value of an attribute. A configuration attribute shall hold this default value after exiting the
DISABLED state.
937 The “FSM” column of an attribute contains those FSM types that this attribute shall be applicable. So, this
column specifies the validity of an attribute to be used in either TYPE-I or TYPE-II or both (TYPE-I and
TYPE-II).
938 The “Type” column of an attribute specifies the type of data (as used in most common programming
languages) it holds.
939 The “Bits” column of an attribute either recommends or mandates which bits to use for representing the
possible values listed inside an attribute’s value range.
940 The “Range” column of an attribute specifies permissible limits of range of values that an attribute can take.
Supported value range for an attribute shall not exceed the range of values specified in the “Range” column of
that attribute.

Confidential
138

Table 50 M-TX Capability Attributes
Attribute Name AttributeID Description FSM Type Bits Range
FALSE = 0,
TX_HSMODE_Capability 0x01 Specifies support for HS-MODE. Both Bool B[0]1
TRUE = 1
HS_G1_ONLY = 1,
Specifies supported HS-GEARs.
HS_G1_TO_G2 = 2,
TX_HSGEAR_Capability 0x02 Existence depends on: Both Enum B[2:0]1
HS_G1_TO_G3 = 3
TX_HSMODE_Capability
HS_G1_TO_G4 = 4
NO = 0,
TX_PWMG0_Capability 0x03 Specifies support for PWM-G0. TYPE-I Bool B[0]1
YES = 1
PWM_G1_ONLY = 1,
PWM_G1_TO_G2 = 2,
Confidential
PWM_G1_TO_G3 = 3,
Specifies support for PWM-GEARs
TX_PWMGEAR_Capability 0x04 TYPE-I Enum B[2:0]1 PWM_G1_TO_G4 = 4,
other than PWM-G0.
PWM_G1_TO_G5 = 5,
PWM_G1_TO_G6 = 6,
PWM_G1_TO_G7 = 7
SMALL_AMPLITUDE_ONLY
= 1,
Specifies supported signal amplitude LARGE_AMPLITUDE_ONLY
TX_Amplitude_Capability 0x05 Both Enum B[1:0]1
levels. = 2,
LARGE_AND_SMALL_
AMPLITUDE = 3
Specifies support for external SYNC
pattern.
Existence depends on: FALSE = 0,
TX_ExternalSYNC_Capability 0x06 TX_HSMODE_Capability OR Both Bool B[0]
01-Dec-2016
TRUE = 1
Version 4.1
TX_PWMGEAR_Capability = 6
OR
TX_PWMGEAR_Capability = 7
Table 50 M-TX Capability Attributes (continued)
01-Dec-2016
Version 4.1
Specifies whether or not M-TX
supports driving an unterminated LINE
TX_HS_Unterminated_LINE_Drive_Capabili NO = 0,
0x07 in HS-MODE. Both Bool B[0]1
ty YES = 1
Existence depends on:
Specifies whether or not M-TX NO = 0,
TX_LS_Terminated_LINE_Drive_Capability 0x08 supports driving a terminated LINE in Both Bool B[0]1
LS-MODE. YES = 1
Specifies minimum time (in SI) in

TX_Min_SLEEP_NoConfig_Time_Capability 0x09 SLEEP state needed when inline Both Int B[3:0]1 1 to 15
configuration was not performed.
Specifies minimum time (in SI) in
TX_Min_STALL_NoConfig_Time_Capability 0x0A STALL state needed when inline Both Int B[7:0]1 1 to 255
Confidential
configuration was not performed.

Specifies minimum reconfiguration
TX_Min_SAVE_Config_Time_Capability2 0x0B time (in 40 ns steps). This applies only Both Int B[7:0] 1 to 250 (10000 ns)
to SLEEP and STALL states.
Specifies support for a shared NO = 0,
TX_REF_CLOCK_SHARED_Capability 0x0C TYPE-I Bool B[0]1
reference clock. YES = 1
Specifies the major and minor B[7:4] Major version number, 0 to 9
TX_PHY_MajorMinor_Release_Capability 0x0D numbers of the M-PHY version Both Int
supported by the M-TX. B[3:0] Minor version number, 0 to 9
Specifies the sequence number of the

TX_PHY_Editorial_Release_Capability 0x0E M-PHY version supported by the Both Int B[7:0] 0 to 99
M-TX.
Specifies minimum time
TX_Hibern8Time_Capability 0x0F Both Int B[7:0] 1 to 128 (100 s to 12.8 ms)
(in 100 s steps) in HIBERN8 state.
139
Table 50 M-TX Capability Attributes (continued)
140

step size
Support and degree of fine granularity B[2:1] b00 = 4 s, b01 = 8 s,
steps for a reduced time in HIBERN8 b10 = 16 s, b11 = 32 s
TX_Advanced_Granularity_Capability 0x10 state. If a finer granularity is specified, Both Int
all coarser granularities shall be supports fine granularity
supported. B[0] steps: No = 0 (100 s step),
Yes = 1
Specifies minimum time in HIBERN8
state when advanced granularity is
supported in steps defined by

TX_Advanced_Hibern8Time_Capability 0x11 TX_Advanced_Granularity_Capability. Both Int B[7:0] 1 to 128
TX_Advanced_Granularity_Capa
bility
Confidential
B[0] = 0: De-emphasis of
3.5dB not supported,
Support for transmit path de-emphasis B[0] = 1; De-emphasis of
for HS-MODE 3.5dB supported,
TX_HS_Equalizer_Setting_Capability 0x12 Both Int B[1:0]
Existence depends on: B[1] = 0; De-emphasis of
TX_HSMODE_Capability 6dB not supported,
B[1] = 1; De-emphasis of
6dB supported
1. Recommended bit assignment.

2. There is a potential timing mismatch between the setting of this capability, implementation width of RMMI when the prior gear is PWM-G0 or PWM-
G1. As neither timing nor width is defined at the RMMI interface, if such a hazard exists for an M-PHY implementation, then the M-PHY IP has to
advertise this in its data sheet. This allows the implementer to ensure the protocol and the selected M-PHY IP are in a good match and allows sufficient
time for attributes to be updated. Since the sensitivity is only in PWM-G0 or PWM-G1, the protocol has to take the current GEAR into account while
computing the minimum time between BURSTs after a configuration change.
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Table 51 M-TX Configuration Attributes
M-TX operating mode.
LS_MODE = 1,
TX_MODE 0x21 TX_HSMODE_Capability Both Enum B[1:0]1
HS_MODE = 2
Req’d Value: LS_MODE
Reset Value: LS_MODE
HS mode RATE series value of M-TX.

A = 1,
TX_HSRATE_Series 0x22 TX_HSMODE_Capability Both Enum B[1:0]1
B=2
Req’d Value: A and B
Reset Value: A
HS-GEAR value of M-TX.

Confidential
Existence depends on: HS_G1 = 1,

TX_HSMODE_Capability HS_G2 = 2,
TX_HSGEAR 0x23 Both Enum B[2:0]1
Value depends on: TX_HSGEAR_Capability HS_G3 = 3
Req’d Value: HS_G1 HS_G4 = 4
Reset Value: HS_G1
PWM_G0 = 0,
PWM-GEAR value of M-TX. PWM_G1 = 1,
Value depends on: PWM_G2 = 2,
TX_PWMGEAR_Capability, PWM_G3 = 3,
TX_PWMGEAR 0x24 TX_PWMG0_Capability TYPE-I Enum B[2:0]1
PWM_G4 = 4,
Req’d Value: PWM_G1

PWM_G5 = 5,
Reset Value: PWM_G1 PWM_G6 = 6,
PWM_G7 = 7
Type of drive strength on PINs at M-TX.
Value depends on: SMALL_AMPLITUDE = 1,
TX_Amplitude 0x25 Both Enum B[1:0]1
TX_Amplitude_Capability LARGE_AMPLITUDE = 2
Reset Value: LARGE_AMPLITUDE
141
Table 51 M-TX Configuration Attributes (continued)
142

Slew Rate control of M-TX output driver.
TX_HS_SlewRate 0x26 Both Int B[7:0]3 0 to 2554
Reset Value: see 2
Source of synchronization pattern at M-TX.
(TX_HSMODE_Capability OR
TX_PWMGEAR_Capability = 6 OR INTERNAL_SYNC = 0,
TX_SYNC_Source 0x27 TX_PWMGEAR_Capability = 7) AND Both Enum B[0]1

EXTERNAL_SYNC = 1
TX_ExternalSync_Capability
Req’d Value: INTERNAL_SYNC
Reset Value: INTERNAL_SYNC
High Speed Synchronization pattern length of SYNC_range

Confidential
M-TX in SI. B[7:6] FINE = 0,

Existence depends on: COARSE = 1
TX_HS_SYNC_LENGTH 0x28 TX_HSMODE_Capability Both Int
Req’d Values: FINE, COARSE, SYNC_length5
0 to 15 B[5:0] 1 to 15 for FINE,
Reset Values: COARSE, 15 0 to 15 for COARSE
HS PREPARE length multiplier for M-TX.

TX_HS_PREPARE_LENGTH6 0x29 TX_HSMODE_Capability Both Int B[3:0]1 0 to 15
Req’d Values: 0 to 156
Reset Value: 156
PWM-BURST or SYS-BURST PREPARE
length multiplier for M-TX.
TX_LS_PREPARE_LENGTH7 0x2A Both Int B[3:0]1 0 to 15
01-Dec-2016
Reset Value: 107
Version 4.1
01-Dec-2016
Version 4.1
M-TX HIBERN8 state control.
Req’d Values: ENTER, EXIT
TYPE-I EXIT = 0,
TX_HIBERN8_Control 0x2B Reset Value: Bool B[0]1
TYPE-II8 ENTER = 1
ENTER for Local RESET
EXIT for LINE-RESET
LCCs support by the M-TX.
This attribute setting is immediately effective
upon receipt of
NO = 0,
TX_LCC_Enable 0x2C M-CTRL-CFGREADY.request (see TYPE-I Bool B[0]1
Section 4.7.4.2).
YES = 1
Req’d Values: YES, NO
Reset Value: NO9
Confidential
BURST CLOSURE sequence duration in SI.

The value shall be greater than, or equal to,
the value of RX_PWM_Burst_
TX_PWM_BURST_Closure_Extension 0x2D Closure_Length_Capability. TYPE-I Int B[7:0]1 0 to 255
Reset Value: 32
Bypass 8b10b encoding operation at M-TX.
FALSE = 0,
TX_BYPASS_8B10B_Enable 0x2E Req’d Value: FALSE Both Bool B[0]1
TRUE = 1
Reset Value: FALSE
M-TX output driver polarity.
Req’d Values: NORMAL, INVERTED

NORMAL = 0,
TX_DRIVER_POLARITY 0x2F Reset Value: NORMAL for local RESET. Both Enum B[0]1
INVERTED = 1
LINE-RESET shall not reset the value of this
attribute.
143
144

Enable M-TX to drive unterminated LINE in
HS-MODE.
TX_HS_Unterminated_LINE_Drive_ TX_HSMODE_Capability AND NO = 0,
0x30 TX_HS_Unterminated_LINE_Drive_Cap Both Bool B[0]1
Enable YES = 1
ability
Req’d Values: NO, YES
Reset Value: NO
Enable M-TX to drive terminated LINE in

LS-MODE.
TX_LS_Terminated_LINE_Drive_ NO = 0,
0x31 TX_LS_Terminated_LINE_Drive_Capabi Both Bool B[0]1
Enable YES = 1
lity
Confidential
Req’d Values: NO, YES

Reset Value: NO
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
B[0] = 1: LCC
READ-CAPABILITY
requested,
To set bits for carrying out multiple B[0] = 0: LCC
LCC-READ or LCC-WRITE operations. READ-CAPABILITY
To perform an LCC operation the not requested,
corresponding bit for this attribute shall be B[1] = 1: LCC
set. READ-MFG-INFO
requested,
TX_LCC_Sequencer bits are cleared by

M-TX when it issues the associated LCC B[1] = 0: LCC
request. READ-MFG-INFO not
This attribute setting is immediately effective requested,
upon receipt of B[2] = 1: LCC
TX_LCC_Sequencer 0x32 TYPE-I Enum B[7:0]

M-CTRL-CFGREADY.request (see READ-VEND-INFO
Confidential
Section 4.7.4.2). requested,

Req’d Values: B[2] = 0: LCC
READ-CAPABILITY, READ-VEND-INFO
READ-MFG-INFO, not requested,
READ-VEND-INFO, B[6:3]: Reserved and shall
WRITE-ATTRIBUTE be set to 0b0000,
Reset Values: B[7] = 1: LCC
0 (no READ or WRITE operation WRITE-ATTRIBUTE
requested) requested,
B[7] = 0: LCC
WRITE-ATTRIBUTE
not requested.

145
146

Specifies minimum activate time needed in
100 µs steps.
If an OMC is not present, this value must be
greater than or equal to the smaller of
RX_Min_ActivateTime_Capability or
RX_Advanced_Min_ActivateTime_
Capability from the remote M-RX.
TX_Min_ActivateTime 0x33 If an OMC is present, this value must be Both Int B[3:0] 1 to 15
greater than or equal to the smaller of
RX_Min_ActivateTime_Capability + 1
(i.e., the Protocol Layer shall add 100 µs
when an OMC is present) or
RX_Advanced_Min_ActivateTime_
Capability + 100 µs.

Confidential
Reset Values: 15
Synchronization pattern length of M-TX, in SI, SYNC_range
for PWM-G6 and PWM-G7 in LS-MODE. B[7:6] FINE = 0,
TX_PWM_G6_G7_SYNC_LENGTH 0x34 TX_PWMGEAR_Capability TYPE-I Int
Req’d Values: FINE, COARSE, SYNC_length5
0 to 15. B[5:0]
0 to 15
Reset Values: COARSE, 15
step size
B[2:1] b00 = 4 s, b01 = 8 s,
Support and degree of fine granularity steps b10 = 16 s, b11 = 32 s
TX_Advanced_Granularity_Step 0x35 for TACTIVATE Both Int
Reset Value: 0 Supports advanced
B[0] granularity
No = 0, Yes = 1
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Specifies minimum activate time when
advanced granularity is supported in
steps defined by
TX_Advanced_Granularity 0x36 TX_Advanced_Granularity_Step. Both Int B[3:0] 1 to 15
The configured value has to meet the
requirements of TACTIVATE in Table 5.
Reset Value: 15
HS Transmit path de-emphasis value
selection.
b000: No de-emphasis
TX_HSMODE_Capability AND
selected,
TX_HS_Equalizer_Setting_Capability
b001: De-emphasis of
Value depends on:

TX_HS_Equalizer_Setting 0x37 Both Int B[2:0] 3.5 dB selected,
Confidential
TX_HS_Equalizer_Setting_Capability
b010: De-emphasis of
Required Values: Support for de-emphasis of
6 dB selected,
3.5 dB or 6 dB
b011 to b111: Reserved
Reset Value: 0 for local RESET.
LINE-RESET shall not reset the value of this
attribute.
This amount of time (in SI) ensures M-RX has
transitioned to termination disable entering
SLEEP.
Greater than or equal to the larger of
TX_Min_SLEEP_NoConfig_Time 0x38 Both Int B[3:0] 1 to 15
TX_Min_SLEEP_NoConfig_Time_Capability
and

RX_Min_SLEEP_NoConfig_Time_Capability.
Reset Value: 15.
147
148

This amount of time (in SI) ensures M-RX has
transitioned to termination disable entering
STALL.
Greater than or equal to the larger of
TX_Min_STALL_NoConfig_Time 0x39 Both Int B[7:0] 1 to 255
TX_Min_STALL_NoConfig_Time_Capability
and
RX_Min_STALL_NoConfig_Time_Capability.
Reset Value: 255.
High Speed adaptation pattern length of ADAPT_type

M-TX. B[7] FINE = 0,
TX_HS_ADAPT_LENGTH 0x3A TX_HSMODE_Capability Both Int

Confidential
Required Values: FINE, COARSE, ADAPT_length10

0 to 127 B[6:0] 0 to 127 for FINE
Reset Values: COARSE, 17 0 to 17 for COARSE
1. Recommended bit assignment

2. Implementation should ensure that the TX_HS_SlewRate value does not violate other parameter specifications
3. 256 steps monotonically decreasing
4. “0” represents the fastest slew rate value and “255” represents the slowest slew rate value. Maximum number of possible steps are 256 (0 to 255).
An implementation may support less than 256 steps but be able to interpret the 8-bit range.
5. Actual SYNC length is calculated using the formula for TSYNC in Table 7
6. Actual HS PREPARE length is calculated using the formula for THS_PREPARE in Table 7 with TX_HSGEAR
7. Actual PWM PREPARE length is calculated using the formula for TPWM_PREPARE in Table 7 with TX_PWMGEAR
8. TYPE-II with embedded HIBERN8 exit control. See Section 4.7.1.3
9. The Reset Value was changed from YES to NO from M-PHY version v4.1 onward
01-Dec-2016
Version 4.1
10. Actual ADAPT length is calculated using the formula for TADAPT in Table 7
01-Dec-2016
Version 4.1
Table 52 M-TX Status Attributes
DISABLED = 0,
HIBERN8 = 1,
SLEEP = 2,
STALL = 3,
TX_FSM_State 0x41 To read out the current state of M-TX Both Enum B[3:0]1
LS-BURST = 4,
HS-BURST = 5,
LINE-CFG = 6
LINE-RESET = 7

Confidential
Table 53 OMC Write-only Attributes

Type of drive strength on PINs at OMC
output.
Value depends on:
MC_RX_LA_Capability,
MC_RX_SA_Capability SMALL_AMPLITUDE = 0,
MC_Output_Amplitude 0x61 TYPE-I Enum B[0]1
Reset Value: LARGE_AMPLITUDE = 1
LARGE_AMPLITUDE if
MC_RX_LA_Capability is true,

SMALL_AMPLITUDE if
MC_RX_LA_Capability is false.
149
Table 53 OMC Write-only Attributes (continued)
150

Enable disconnection of resistive
termination of O-TX in HS-MODE.
OFF = 0,
MC_HS_Unterminated_Enable 0x62 MC_HSMODE_Capability AND TYPE-I Bool B[0]
MC_HS_Unterminated_Capability ON = 1
Req’d Value: OFF
Reset Value: OFF
Enable O-TX resistive termination in
LS-MODE.
Existence depends on: OFF = 0,
MC_LS_Terminated_Enable 0x63 MC_LS_Terminated_Capability TYPE-I Bool B[0]1
ON = 1
Req’d Value: OFF
Reset Value: OFF

Confidential
Enable O-RX to drive unterminated LINE in

HS-MODE.
MC_HS_Unterminated_LINE_Drive MC_HSMODE_Capability AND OFF = 0,
0x64 TYPE-I Bool B[0]1
_Enable MC_HS_Unterminated_LINE_Drive_ ON = 1
Capability
Req’d Value: OFF
Reset Value: OFF
Enable O-RX to drive terminated LINE in
LS-MODE.
MC_LS_Terminated_LINE_Drive OFF = 0,
0x65 MC_LS_Terminated_LINE_Drive_ TYPE-I Bool B[0]1
_Enable ON = 1
Capability
Req’d Value: OFF
Reset Value: OFF
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Table 54 M-RX Capability Attributes
FALSE = 0,
RX_HSMODE_Capability 0x81 Specifies support for HS-MODE. Both Bool B[0]1
TRUE = 1
HS_G1_ONLY = 1,
Specifies supported HS-GEARs.
HS_G1_TO_G2 = 2,
RX_HSGEAR_Capability 0x82 Existence depends on: Both Enum B[2:0]1
HS_G1_TO_G3 = 3
RX_HSMODE_Capability
HS_G1_TO_G4 = 4
NO = 0,
RX_PWMG0_Capability 0x83 Specifies support for PWM-G0. TYPE-I Bool B[0]1

YES = 1
PWM_G1_ONLY = 1,
PWM_G1_TO_G2 = 2,
PWM_G1_TO_G3 = 3,
Specifies supported PWM-GEARs other

TYPE-I Enum B[2:0]1
Confidential
RX_PWMGEAR_Capability 0x84 PWM_G1_TO_G4 = 4,

than PWM-G0.
PWM_G1_TO_G5 = 5,
PWM_G1_TO_G6 = 6,
PWM_G1_TO_G7 = 7
Specifies support for disconnection of
resistive termination in HS-MODE. NO = 0,
RX_HS_Unterminated_Capability 0x85 Both Bool B[0]1
Existence depends on: YES = 1
Specifies support for enabling resistive NO = 0,
RX_LS_Terminated_Capability 0x86 TYPE-I Bool B[0]1
termination in LS-MODE. YES = 1
Specifies minimum time (in SI) in SLEEP
RX_Min_SLEEP_NoConfig_Time_Capability 0x87 state needed when inline configuration Both Int B[3:0]1 1 to 15

was not performed.
Specifies minimum time (in SI) in STALL
RX_Min_STALL_NoConfig_Time_Capability 0x88 state needed when inline configuration Both Int B[7:0]1 1 to 255
was not performed.
Specifies minimum reconfiguration time
RX_Min_SAVE_Config_Time_Capability2 0x89 (in 40 ns steps). This applies only to Both Int B[7:0] 1 to 250 (10000 ns)
SLEEP and STALL states.
151
Table 54 M-RX Capability Attributes (continued)
152

Specifies support for a shared reference NO = 0,
RX_REF_CLOCK_SHARED_Capability 0x8A TYPE-I Bool B[0]1
clock. YES = 1
SYNC_range
High Speed GEAR 1 Synchronization B[7:6] FINE = 0,
pattern length in SI. COARSE = 1
RX_HS_G1_SYNC_LENGTH_Capability 0x8B Both Int
Existence depends on: SYNC_length3
RX_HSMODE_Capability B[5:0] 1 to 15 for FINE,
0 to 15 for COARSE
HS-G1 PREPARE length multiplier for

M-RX.
RX_HS_G1_PREPARE_LENGTH_Capability4 0x8C Both Int B[3:0]1 0 to 15
PWM-BURST or SYS-BURST
RX_LS_PREPARE_LENGTH_Capability5 0x8D Both Int B[3:0]1 0 to 15

PREPARE length multiplier for M-RX.
Confidential
Specifies minimum burst closure time (in

RX_PWM_Burst_Closure_Length_Capability 0x8E SI) necessary to guarantee complete TYPE-I Int B[4:0] 0 to 31
data processing inside M-RX
Specifies minimum activate time needed
RX_Min_ActivateTime_Capability 0x8F Both Int B[3:0] 1 to 9
in 100 s steps.
Major version number,
Specifies the major and minor numbers B[7:4]
0 to 9
RX_PHY_MajorMinor_Release_Capability 0x90 of the M-PHY version supported by the Both Int
M-RX. Minor version number,
B[3:0]
0 to 9
Specifies the sequence number of the
RX_PHY_Editorial_Release_Capability 0x91 Both Int B[7:0] 0 to 99
M-PHY version supported by the M-RX.
Specifies minimum time (in 100 s 1 to 128
RX_Hibern8Time_Capability 0x92 Both Int B[7:0]
steps) in HIBERN8 state. (100 s to 12.8 ms)
SYNC_range
Synchronization pattern length, in SI, for B[7:6] FINE = 0,
01-Dec-2016
PWM-G6 and PWM-G7 in LS-MODE . COARSE = 1
RX_PWM_G6_G7_SYNC_LENGTH_Capability 0x93 TYPE-I Int
Version 4.1
SYNC_length3
RX_PWMGEAR_Capability B[5:0]
0 to 15
01-Dec-2016
Version 4.1
SYNC_range
RX_HS_G2_SYNC_LENGTH_Capability 0x94 Both Int
RX_HSGEAR_Capability B[5:0] 1 to 15 for FINE,
0 to 15 for COARSE
SYNC_range
RX_HS_G3_SYNC_LENGTH_Capability 0x95 Both Int

0 to 15 for COARSE
M-RX.
Confidential
RX_HS_G2_PREPARE_LENGTH_Capability4 0x96 Both Int B[3:0]1 0 to 15

RX_HSGEAR_Capability
M-RX.
RX_HS_G3_PREPARE_LENGTH_Capability4 0x97 Both Int B[3:0]1 0 to 15
step size
B[2:1] b00 = 4 s, b01 = 8 s,
Support and degree of fine granularity b10 = 16 s, b11 = 32 s
RX_Advanced_Granularity_Capability 0x98 Both Int
steps for THIBERN8 and TACTIVATE. supports fine granularity
B[0] steps No = 0 (100 s
step), Yes = 1

Specifies minimum time in HIBERN8
state when advanced granularity is
supported in steps defined by
RX_Advanced_Hibern8Time_Capability 0x99 RX_advanced_Granularity_Capability. Both Int B[7:0] 1 to 128
RX_Advanced_Granularity_Capability
153
154

Specifies minimum activate time when
advanced granularity is supported in
steps defined by
RX_Advanced_Min_ActivateTime_Capability 0x9A RX_Advanced_Granularity_Capability. Both Int b[3:0] 1 to 14
RX_Advanced_Granularity_Capability
SYNC_range
RX_HS_G4_SYNC_LENGTH_Capability 0x9B Both Int

0 to 15 for COARSE
M-RX.
RX_HS_G4_PREPARE_LENGTH_Capability4 B[3:0]1
Confidential
0x9C Both Int 0 to 15

Support for receiver path channel
equalization for HS-MODE. B0 = 0: No equalization
RX_HS_Equalizer_Setting_Capability 0x9D Both Int B[0]
Existence depends on: B0 = 1: Yes equalization
REFRESH is used for RX adaptation ADAPT_type
refresh. B[7] FINE=0,
High Speed adaptation pattern length of COARSE=1
RX_HS_ADAPT_REFRESH_Capability 0x9E Both Int
M-RX. ADAPT_length6
Existence depends on: B[6:0] 0 to 127 for FINE,
RX_HS_Equalizer_Setting_Capability 0 to 17 for COARSE
ADAPT_type
INITIAL is used for initial RX adaptation.
B[7] FINE=0,
High Speed adaptation pattern length of COARSE=1
RX_HS_ADAPT_INITIAL_Capability 0x9F M-RX. Both Int
ADAPT_length6
01-Dec-2016
Version 4.1
B[6:0] 0 to 127 for FINE,
RX_HS_Equalizer_Setting_Capability
0 to 17 for COARSE
01-Dec-2016
Version 4.1
2. There is a potential timing mismatch between the setting of this capability, implementation width of RMMI when the prior gear is PWM-G0 or PWM-
G1. As neither timing nor width is defined at the RMMI interface, if such a hazard exists for an M-PHY implementation, then the M-PHY IP has to
advertise this in its data sheet. This allows the implementer to ensure the protocol and the selected M-PHY IP are in a good match and allows sufficient
time for attributes to be updated. Since the sensitivity is only in PWM-G0 or PWM-G1, the protocol has to take the current GEAR into account while
computing the minimum time between BURSTs after a configuration change.
3. Actual SYNC length is calculated using the formula for TSYNC in Table 7.
4. Actual HS PREPARE length is calculated using the formula for THS_PREPARE in Table 7 with RX_HXGEAR.
5. Actual PWM PREPARE length is calculated using the formula for TPWM_PREPARE in Table 7 with RX_PWMGEAR.
6. Actual ADAPT length is calculated using the formula for TADAPT in Table 7
Confidential

155
156

Table 55 M-RX Configuration Attributes
Operating mode.
LS_MODE = 1,
RX_MODE 0xA1 RX_HSMODE_Capability Both Enum B[1:0]1
HS_MODE = 2
Req’d Value: LS_MODE
Reset Value: LS_MODE
HS mode RATE series value.

A = 1,
RX_HSRATE_Series 0XA2 RX_HSMODE_Capability Both Enum B[1:0]1
B=2
Req’d Values: A and B
Reset Value: A
Current HS-GEAR.
Confidential
Existence depends on: HS_G1 = 1,

HS_G2 = 2,
RX_HSGEAR 0xA3 Value depends on: Both Enum B[2:0]1
RX_HSGEAR_Capability HS_G3 = 3
Req’d Value: HS_G1 HS_G4 = 4
Reset Value: HS_G1
PWM_G0 = 0,
PWM_G1 = 1,
PWM_G2 = 2,
Current PWM-GEAR.
PWM_G3 = 3,
RX_PWMGEAR 0xA4 Req’d Value: PWM_G1 TYPE-I Enum B[2:0]1
PWM_G4 = 4,
Reset Value: PWM_G1
PWM_G5 = 5,
PWM_G6 = 6,
PWM_G7 = 7
01-Dec-2016
Version 4.1
Table 55 M-RX Configuration Attributes (continued)
01-Dec-2016
Version 4.1
Enable resistive termination of M-RX
in LS-MODE.
Existence depends on: OFF = 0,
RX_LS_Terminated_Enable 0xA5 RX_LS_Terminated_Capability TYPE-I Bool B[0]1
ON = 1
Req’d Value: OFF
Reset Value: OFF
Enable disconnection of resistive
termination of M-RX in HS-MODE.

OFF = 0,
RX_HS_Unterminated_Enable 0xA6 RX_HSMODE_Capability AND Both Bool B[0]1
RX_HS_Unterminated_Capability ON = 1
Req’d Value: OFF
Reset Value: OFF

Confidential
NO = 0: Protocol Layer shall not set

the value of this attribute to
“NO”. When the M-RX is in
HIBERN8 state, upon squelch
M-RX entry to HIBERN8 state control. detection the M-RX exits
Req’d Values: YES, NO HIBERN8 state (to SLEEP or
TYPE-I
RX_Enter_HIBERN8 0xA7 Reset Value: Bool B[0]1 STALL state) and resets this
TYPE-II2 attribute value to NO,
YES for Local RESET,
NO for LINE-RESET YES = 1: Can be set by the Protocol.
The M-RX enters from SLEEP
or STALL state to HIBERN8
state, if it is not already in

HIBERN8 state.
Bypass 8b10b Decoding at the M-RX.
FALSE = 0,
RX_BYPASS_8B10B_Enable 0xA8 Req’d Value: FALSE Both Bool B[0]1
TRUE = 1
Reset Value: FALSE
157
Table 55 M-RX Configuration Attributes (continued)
158

Force connection of differential
termination resistance, RDIF_RX, to
enabled state, for RX S-Parameter NO = 0,
RX_Termination_Force_Enable 0xA9 test purposes. Both Bool B[0]1
YES = 1
Req’d Value: NO
Reset Value: NO
M-RX ADAPT sub-state control and ADAPT_type

ADAPT_type. B[1] INITIAL = 0,

Req’d Values: REFRESH = 1
RX_ADAPT_Control3 0xAA ADAPT Control: ADAPT, SYNC Both Int
ADAPT Type: REFRESH, ADAPT_control
INITIAL B[0] ADAPT = 0,

Confidential
Reset Value: INITIAL, SYNC SYNC = 1
M-RX receiver polarity.

Req’d Values: NORMAL, INVERTED
Reset Value: NORMAL for local NORMAL = 0,
RX_RECEIVER_POLARITY 0xAB Both Enum B[0]
RESET. INVERTED = 1
LINE-RESET shall not reset the value
of this attribute.

2. TYPE-II with embedded HIBERN8 exit control. See Section 4.7.1.3.
3. The local module sets to SYNC after completion of the ADAPT sub-state.
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Table 56 M-RX Status Attributes
DISABLED = 0,
HIBERN8 = 1,
SLEEP = 2,
STALL = 3,
RX_FSM_State 0xC1 To read out the current state of M-RX Both Enum B[3:0]1
LS-BURST = 4,
HS-BURST = 5,
LINE-CFG = 6
LINE-RESET = 7

Confidential
Table 57 OMC Status Attributes

ADVANCED = 0,
OMC_TYPE_Capability 0xD1 Specifies the type of OMC present. TYPE-I Enum B[0]1
BASIC = 1
Specifies whether or not OMC FALSE = 0,
MC_HSMODE_Capability 0xD2 TYPE-I Bool B[0]1
supports HS-MODE. TRUE = 1
Specifies which HS-GEARs that HS_G1_ONLY = 1,

OMC supports. HS_G1_TO_G2 = 2,
MC_HSGEAR_Capability 0XD3 TYPE-I Enum B[2:0]1
Existence depends on: HS_G1_TO_G3 = 3,

MC_HSMODE_Capability HS_G1_TO_G4 = 4
Specifies High Speed start up time of
MC_HS_START_TIME_Var_Capa OMC.
0xD4 TYPE-I Int B[3:0]1 0 to 15
bility2 Existence depends on:
MC_HSMODE_Capability
159
Table 57 OMC Status Attributes (continued)
160

Specifies the granularity that High
MC_HS_START_TIME_Range_ Speed start up time OMC takes. FINE = 0,
0xD5 TYPE-I Bool B[0]1
Capability Existence depends on: COARSE = 1
MC_RX_SA_Capability 0xD6 TYPE-I Bool B[0]1
supports Small Amplitude TRUE = 1
MC_RX_LA_Capability 0xD7 TYPE-I Bool B[0]1
supports Large Amplitude TRUE = 1

PWM-BURST PREPARE length
MC_LS_PREPARE_LENGTH2 0xD8 TYPE-I Bool B[3:0] 0 to 15
multiplier for OMC.
Specifies whether or not OMC NO = 0,
MC_PWMG0_Capability 0xD9 TYPE-I Bool B[0]1

supports PWM-G0. YES = 1
Confidential
PWM_G1_ONLY = 1,
PWM_G1_TO_G2 = 2,
Specifies which PWM-GEARs other PWM_G1_TO_G3 = 3,
MC_PWMGEAR_Capability 0xDA than PWM-G0 are supported by TYPE-I Enum B[2:0]1 PWM_G1_TO_G4 = 4,
OMC PWM_G1_TO_G5 = 5,
PWM_G1_TO_G6 = 6,
PWM_G1_TO_G7 = 7
Specifies whether or not O-TX NO = 0,
MC_LS_Terminated_Capability 0xDB supports enabling of resistive TYPE-I Bool B[0]1
termination in PWM-MODE YES = 1
Specifies support for disconnection

of resistive termination in HS-MODE
NO = 0,
MC_HS_Unterminated_Capability 0xDC by O-TX. TYPE-I Bool B[0]1
YES = 1
01-Dec-2016
Version 4.1
Table 57 OMC Status Attributes (continued)
01-Dec-2016
Version 4.1
Specifies whether or not O-RX NO = 0,
MC_LS_Terminated_LINE_Drive_
0xDD supports driving a terminated LINE in TYPE-I Bool B[0]1
Capability YES = 1
PWM-MODE.
Specifies whether or not O-RX
supports driving a unterminated
MC_HS_Unterminated_LINE_ NO = 0,
0xDE LINE in HS-MODE. TYPE-I Bool B[0]1
Drive_Capability YES = 1
Manufacturer identification least

MC_MFG_ID_Part1 0xDF TYPE-I Int B[7:0] 0 to 255
significant byte
Manufacturer identification most
MC_MFG_ID_Part2 0xE0 TYPE-I Int B[7:0] 0 to 255
significant byte
Confidential
Major version number, 0 to

Specifies the major and minor B[7:4]
MC_PHY_MajorMinor_Release_ 9
0xE1 numbers of the M-PHY version TYPE-I Int
Capability Minor version number, 0 to
supported by the OMC. B[3:0]
9
Specifies the sequence number of
MC_PHY_Editorial_Release_
0xE2 the M-PHY version supported by the TYPE-I Int B[7:0] 0 to 99
Capability
OMC.
Vendor-specific information least
MC_Vendor_Info_Part1 0xE3 TYPE-I Int B[7:0] 0 to 255
significant byte
Vendor-specific information second
least significant byte

Vendor-specific information third
least significant byte
Vendor-specific information most
significant byte

161
2. Actual HS SYNC length is calculated using the formula for TSYNC in Table 7.
01-Dec-2016

Confidential
01-Dec-2016
Annex A Signaling Interface Description (normative)

941 The signaling interface described in this annex, the Reference M-PHY MODULE Interface (RMMI), is
optional. However, if a MODULE includes the RMMI it shall implement it as described in this annex.
942 The RMMI signaling interface for a MODULE (M-TX or M-RX) consists of two independent interfaces for
control service primitives (M-TX-CTRL SAP and M-RX-CTRL SAP) and for data transfer service
primitives (M-TX-DATA SAP and M-RX-DATA SAP). An M-PORT with multiple M-TXs or M-RXs uses a
set of signals defined for M-TX or M-RX for each MODULE. To keep the same structure used for SAP
definitions, the signaling interface of a MODULE is divided into DATA and CTRL signaling interfaces.
943 A shadow memory bank inside the MODULE implements the INLINE-CR registry as defined in
Section 4.8.1, and a separate effective configuration bank implements the INLINE-SET and OFFLINE-SET
registries. Both the shadow memory and the effective configuration banks are written sequentially. However,
the entire contents of the shadow memory bank can be uploaded to the effective configuration bank in a
single, Protocol Layer-requested operation.
944 Due to the high data rates supported in M-PHY implementations, the width of the data buses conveying data
to and from the Physical Layer can be increased, and different parallelization options are provided.
945 Finally, testability extensions to the CTRL signal interface are also included in this specification. However,
the definition of the internal M-RX and M-TX structures controlled by these extensions is out of scope for
this document.
946 Section A.2 and Section A.3 define the signals used in the signaling interface of an M-TX, and M-RX,
respectively. While the CTRL signaling interfaces for M-TXs and M-RXs cannot be identical, this annex
provides a common signal definition for M-TX-CTRL SAP and M-RX-CTRL SAP to the furthest extent
possible. M-TX-DATA SAP and M-RX-DATA SAP signaling interfaces are, by their nature, substantially
different.
A.1 One-Hot Coding of Control Symbols

947 Table 58 defines the One-Hot coding of control symbols.
Table 58 One-Hot Coding of Control Symbols

One-Hot Code Type of Control Symbol at TX Type of Control Symbol at RX
0000 0000 Reserved Reserved
0000 0001 MARKER0 MARKER0
1000 0000 FILLER FILLER
A.2 The M-RX Signaling Interface

948 A schematic overview of the M-RX signaling interface is shown in Figure 66.

Confidential
01-Dec-2016
Control Interface Test Extensions
RX_CfgRdyN
SLEEP/STALL/HIBERN8? 8
RX_Hibern8Exit_Type-I TST_RTObserve
RX_LCCRdDet LCC-READ received? 8
8
RX_AttrRdVal TST_RTControl
RX_AttrRdCnf
Effective Config
RX_AttrID 8
8b10b
RX_RefClk
INLINE/
RX_AttrWRn OFFLINE
8
detection and RX_SymbolClk
RX_AttrWrVal
Write Control/ 1/2/4
Update Logic RX_PhyDORDY
RX_InLnCfg*
Shadow Bank
1/2/4
RX_DataNCtrl
S2P
10/20/40
RX_Symbol
RX_CfgUpdt 1/2/4
RX_CfgEnbl ENBL RX_SymbolErr
RX_CfgClk RX_Burst
RX_Reset
RCV
RX_LineReset
LINE-RESET? RXDP RXDN
Data Interface
RX_InLnCfg* - This signal is optional. Implementations may choose appropriate fixed value for
backward compatibility.
Figure 66 M-RX Signal Interfaces Diagram
A.2.1 M-RX Signal Description

949 In Table 59 through Table 61, entries in the “Direction” column specifies the direction of each signal from the
perspective of the M-RX. An input signal (abbreviated as “I”) is driven by the Protocol Layer. An output
signal (abbreviated as “O”) is driven by the M-RX.
950 The “Detection Type” column indicates the relevant condition for a given signal. A Detection Type of
“Level” means the relevant information is either a high or low level on the signal. A Detection Type of
“Transition” means a change from high-to-low or low-to-high causes the described action. A Detection Type
of “Clock” indicates the signal is used to synchronize other signals on the interface. A Detection Type of
“Asynch” means the signal changes state asynchronously to the relevant clock signal.

Confidential
01-Dec-2016
Version 4.1
Table 59 M-RX-CTRL Interface Signals
Detection
Signal Name Direction Width Signal Description
Type
Control Interface Clock.
All M-RX-CTRL interface signals, with the exception of RX_Reset and
RX_Hibern8Exit_Type-I, are synchronous with this signal.
RX_CfgClk I Clock 1 The exact frequency of RX_CfgClk is implementation specific. Choice of frequency should
consider squelch detection, adequate measurement of TLINE-RESET, LCC-READ event
signaling and minimizing interface access latencies. RX_CfgClk may change frequency
depending on state, but is expected to be available in all M-RX states except DISABLED and
UNPOWERED.
RX_Reset is the active-high asynchronous reset for all logic inside the M-RX. RX_Reset
RX_Reset I Asynch 1 implements the local RESET function as defined in Section 4.7.
The Protocol Layer, or other source, shall set RX_Reset to “1” for at least 100 ns.
Confidential
RX_LineReset indicates the status of the LINE-RESET action in the M-RX.

M-RX shall set RX_LineReset to “1” when LINE-RESET is detected.
RX_LineReset O Transition 1
M-RX shall set RX_LineReset to “0” once it has transitioned to the LINE-RESET exit state
(see Section 4.7.4.1).
RX_AttrID carries the AttributeID of M-RX Configuration attributes for read or write operations,
RX_AttrID I Level 8
or M-RX Capability attribute or OMCS Status Attributes for read operation.
RX_AttrRdVal carries the attribute value read from an M-RX-MIB attribute specified by
RX_AttrID.
The M-RX-MIB attribute value should be held on this bus until a subsequent read command is
RX_AttrRdVal O Level 8
issued by the protocol.

When RX_AttrRdCnf is not implemented, the M-RX shall provide the specified attribute value
within one-half of the RX_CfgClk period.
RX_AttrRdCnf confirms that RX_AttrRdVal carries a new value.
M-RX shall set RX_AttrRdCnf to "1" for a single RX_CfgClk cycle to inform the Protocol Layer
RX_AttrRdCnf O Level 1
that RX_AttrRdVal carries a recently requested attribute read value.
RX_AttrRdCnf is an optional signal.
165
Table 59 M-RX-CTRL Interface Signals (continued)
166

Detection
Type
RX_AttrWrVal carries the attribute value to write to an M-RX-MIB attribute specified by
RX_AttrWrVal I Level 8
RX_AttrID.
RX_AttrWRn specifies the operation, read or write, to perform on an M-RX-MIB attribute.
RX_AttrWRn I Level 1 The Protocol Layer shall set RX_AttrWRn to “0” to indicate a read operation.
The Protocol Layer shall set RX_AttrWRn to “1” to indicate a write operation.
Config Enable
The Protocol Layer shall set RX_CfgEnbl to “1” for a single RX_CfgClk cycle to perform an
RX_CfgEnbl I Level 1 attribute read, or write, operation.
The Protocol Layer shall set RX_CfgEnbl, RX_AttrID, RX_AttrWRn and RX_AttrWrVal in the
same RX_CfgClk cycle.
RX_CfgUpdt transfers the contents of the INLINE-CR registry to the effective configuration
Confidential
bank during a SAVE state. RX_CfgUpdt indicates the completion of the required configuration
settings to the MODULE for effectuating configuration change requests atomically.
RX_CfgUpdt I Transition 1 The Protocol Layer shall set RX_CfgUpdt to “1” for a single RX_CfgClk cycle to trigger the
upload of the entire M-RX shadow memory contents to the effective configuration bank. The
Protocol Layer shall move the MODULE into a SAVE state, if not already in a SAVE state,
before the new settings become effective.
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Detection
Type
RX_CfgRdyN indicates the M-RX cannot process a register write command to its effective
configuration bank.
The M-RX shall set this signal to “1” in the same RX_CfgClk cycle that triggers its internal FSM
exit from SLEEP, STALL, or HIBERN8 state to any other state.
The M-RX may also set this signal to “1” while it is processing a Protocol-issued change to its
effective configuration bank.
The M-RX shall set this signal to “0” when its internal FSM is in SLEEP, STALL, or HIBERN8
state and the MODULE is ready to accept a register write command to any register of its
effective configuration bank.
For a RX_Reset (local RESET command), the M-RX shall set RX_CfgRdyN to “1”
asynchronously.
If the Protocol Layer issues write commands to the M-RX effective configuration bank
RX_CfgRdyN O Level 1 (including RX_CfgUpdt) while RX_CfgRdyN is set to “0”, the M-RX shall process those
Confidential
commands immediately. If the Protocol Layer issues write commands to the M-RX effective
configuration bank while RX_CfgRdyN is set to “1”, the specific M-RX behavior is dependent
on the command itself addressing an OFFLINE-SET or INLINE-SET attribute. The M-RX shall
execute a write command to an OFFLINE-SET Attribute in the effective configuration bank.
The M-RX shall redirect a write command to an INLINE-SET attribute in the effective
configuration bank to the associated shadow register.
The M-RX shall not ignore a write command or Rx_CfgUpdt request from the Protocol Layer
except in UNPOWERED and DISABLED states, or when local RESET is asserted.
The M-RX shall respond to read commands from the Protocol Layer regardless of the value of
RX_CfgRdyN.
The M-RX shall process register write commands to its shadow memory bank regardless of
the value of RX_CfgRdyN.

RX_Hibern8Exit_Type-I indicates the M-RX is exiting HIBERN8. The M-RX sets
RX_Hibern8Exit_Type-I to “1” when it detects a HIBERN8 exit condition on the LINE (see
Transition, Section 4.7.1.3 and Figure 12). The M-RX sets RX_Hibern8Exit_Type-I to “0” when the M-RX
RX_Hibern8Exit_Type-I O 1
Asynch is in either HIBERN8 or DISABLED state.
A Type-I implementation shall include this signal.
167
168

Detection
Type
RX_LCCRdDet indicates the M-RX received at least one LCC-READ sequence, and has
updated all corresponding attributes of the pending LCC-READ sequences.
RX_LCCRdDet O Transition 1
Upon exiting LCC-MODE following a LCC-READ sequence, the M-RX shall set
RX_LCCRdDet to “1” for a single RX_CfgClk cycle.
Table 60 M-RX-DATA Interface Signals

Detection
Type
Reference Clock.
RX_RefClk may not be accessible in the M-RX-DATA interface for an M-PHY implementation that
Confidential
RX_RefClk I Clock 1 comprises an integrated clock multiplier.

RX_RefClk shall have no specific phase relationship requirement to any signal in the M-RX-DATA
interface.
Symbol Clock.
All M-RX-DATA interface signals are synchronous with this signal.
The M-RX may disable RX_SymbolClk generation when the M-RX is not in LINE-CFG,
PWM-BURST, SYS-BURST, or HS-BURST states.
The M-RX shall provide the minimum number of cycles to transfer all M-RX data to the Protocol
Layer. At the end of BURST, the M-RX shall provide a minimum of two additional clock cycles beyond
the de-assertion of RX_Burst.
RX_SymbolClk O Clock 1
In HS-MODE and SYS-MODE, RX_SymbolClk shall have a period of 10 UI for a 10-bit RX_Symbol
bus, 20 UI for a 20-bit RX_Symbol bus, or 40 UI for a 40-bit RX_Symbol bus.
In PWM-MODE, RX_SymbolClk shall have a period of 10 TPWM-RX for a 10-bit RX_Symbol bus,
20 TPWM-RX for a 20-bit RX_Symbol bus, or 40 TPWM-RX for a 40-bit RX_Symbol bus.
The behavior of RX_SymbolClk must be glitch-free even when this signal is being enabled or
01-Dec-2016
disabled. The M-RX shall not provide a RX_SymbolClk “1” or “0” pulse with a duration less than
Version 4.1
one-quarter of the nominal RX_SymbolClk period.
Table 60 M-RX-DATA Interface Signals (continued)
01-Dec-2016
Version 4.1
Detection
Type
RX_Symbol is used for BURST data transfer to the Protocol Layer. The contents of this bus depend
on the interface width (10, 20 or 40 bits, corresponding to 1, 2 and 4 parallel symbols, respectively),
and also on whether or not the 10b8b decoding function is bypassed.
10, When the 10b8b decoding function is disabled, RX_Symbol carries the raw data as received on the
RX_Symbol O Level 20, LINEs, parallelized according to the implemented width. The LSb of RX_Symbol shall correspond to
or 40 the earliest received bit.
When the 10b8b decoding function is enabled, only the 8, 16, or 32 LSbs of RX_Symbol are used to
carry the decoded DATA or control symbol. The M-RX shall set the remaining MSbs to “0”.
Control symbols shall be decoded as listed in Table 58.

PHY Data Output Ready.
RX_PhyDORDY indicates data is available in the corresponding RX_Symbol bus range. The width of
RX_PhyDORDY is one, two or four bits depending on the RX_Symbol bus width of 10, 20, or 40 bits,
Confidential
respectively.
Each bit in RX_PhyDORDY corresponds to a 10b8b symbol in RX_Symbol bus.
RX_PhyDORDY bitRX_Symbol bits (10b8b enabled)
0 bits[9:0] (bits[7:0])
1 bits[19:10] (bits[15:8])
RX_PhyDORDY O Level 1, 2 or 4
2 bits[29:20] (bits[23:16])
3 bits[39:30] (bits[31:24])
The M-RX shall set each bit of RX_PhyDORDY to “1” for every RX_SymbolClk cycle that the
corresponding RX_Symbol bus range contains new data.
The M-RX shall set each bit of RX_PhyDORDY bit to “0” for every RX_SymbolClk cycle that the
corresponding RX_Symbol bus range does not contain new data.

The Protocol Layer shall always be ready to consume the data from the M-RX.
During ADAPT, the RX_Phy_DORDY signal shall be set to zero.
169
Table 60 M-RX-DATA Interface Signals (continued)
170

Detection
Type
RX_DataNCtrl indicates the type of symbol on the indicated range of RX_Symbol.
The width of RX_DataNCtrl is one, two or four bits depending on the RX_Symbol bus width of 10, 20,
or 40 bits, respectively.
RX_DataNCtrl are mapped the same as RX_PhyDORDY.
RX_DataNCtrl O Level 1, 2 or 4 The M-RX shall set the corresponding bit of RX_DataNCtrl to “0” when the related RX_Symbol bus
range carries a data symbol.
The M-RX shall set the corresponding bit of RX_DataNCtrl to “1” when the related RX_Symbol bus
range carries a control symbol or a reserved symbol.

The M-RX shall set all bits of RX_DataNCtrl to “0” when 10b8b decoding is bypassed.
The width of RX_SymbolErr is one, two or four bits depending on the RX_Symbol bus width of 10, 20,
or 40 bits, respectively.
The M-RX shall set each bit of RX_SymbolErr to “1” for one RX_SymbolClk cycle when any of the
Confidential
following conditions on the corresponding RX_Symbol bus range are “TRUE”:

• The 3b4b sub-block is in error while decoding the related 8b10b symbol received over the
LINE
RX_SymbolErr O Level 1, 2 or 4 • The 5b6b sub-block is in error while decoding the related 8b10b symbol received over the
LINE
• The Running Disparity algorithm computes an RD error for the related 8b10b symbol received
over the LINE
• The related 8b10b symbol received over the LINE is a reserved symbol
The M-RX shall set all bits of RX_SymbolErr to “0” for all other conditions.
RX_Symbol shall carry, in the corresponding bus range, the remapped PAYLOAD byte.
The M-RX shall set all bits of RX_SymbolErr to “0” when 10b8b decoding is bypassed.
RX_Burst provides a framing window to the Protocol Layer for received BURSTs.
The M-RX shall set RX_Burst to “1” when it detects the start of a PREPARE period.
RX_Burst O Transition 1 The M-RX shall set RX_Burst to “0” when it detects any of the BURST exit conditions and all 8b10b
PAYLOAD data has been sent to the Protocol Layer via RX_Symbol (see Section 4.7.2.5). The
M-RX shall set RX_Burst to “0” when it detects the ADAPT sub-state exit condition (see
01-Dec-2016
Section 4.7.2.3).
Version 4.1
01-Dec-2016
Version 4.1
Table 61 M-RX Test Extensions
Detection
Type
TST_RTObserve makes internal M-RX real-time signals observable, e.g. through DMA, by the
Protocol Layer, or external test equipment. These signals are asynchronous to any clock on the
M-RX-DATA or M-RX-CTRL interfaces.
TST_RTObserve O Asynch 8
Signals are selected by programming implementation-specific M-RX registers using the
M-RX-CTRL interface.
The M-RX implementation shall not require TST_RTObserve for normal operation.
TST_RTControl carries real-time signals to control implementation-specific signals, e.g. test

features, inside the M-RX. These signals are asynchronous to any clock on the M-RX-DATA or
M-RX-CTRL interfaces.
TST_RTControl I Asynch 8 Internal multiplexers with signals on this bus are selected by programming
implementation-specific M-RX registers using the M-RX-CTRL interface.

Confidential
The M-RX implementation shall not require any specific behavior or value on TST_RTControl for
normal operation.

171
01-Dec-2016
A.3 The M-TX Signaling Interface

951 A schematic overview of the M-TX signaling interface is shown in Figure 67.
Control Interface Test Extensions
TX_CfgRdyN SLEEP/STALL/HIBERN8? 8
TST_RTObserve
8
TX_AttrRdVal 8
TST_RTControl
TX_AttrRdCnf
Effective Config
8
TX_AttrID
INLINE/
TX_AttrWRn OFFLINE
8
8b10b
detection and TX_SaveState_status_N
TX_AttrWrVal
Write Control/
Update Logic TX_BitClk
TX_InLnCfg*
TX_SymbolClk
Shadow Bank
TX_PhyDIRDY
1/2/4
TX_ProtDORDY
S2P
TX_CfgUpdt
1/2/4
TX_CfgEnbl ENBL TX_DataNCtrl
10/20/40
TX_CfgClk
TX_Symbol
TX_Reset
TX_LineReset DRV
TX_Burst
TX_DIFNDrive
TX_Controlled_ActTimer
TXDP TXDN
Data Interface
TX_InLnCfg* - This signal is optional. Implementations may choose appropriate fixed value for
backward compatibility.
Figure 67 M-TX Signal Interfaces Diagram
A.3.1 M-TX Signal Description

952 In Table 62 through Table 64, entries in the “Direction” column specifies the direction of each signal from the
perspective of the M-TX. An input signal (abbreviated as “I”) is driven by the Protocol Layer. An output
signal (abbreviated as “O”) is driven by the M-TX.
953 The “Detection Type” column indicates the relevant condition for a given signal. A Detection Type of
“Level” means the relevant information is either a high or low level on the signal. A Detection Type of
“Transition” means a change from high-to-low or low-to-high causes the described action. A Detection Type
of “Clock” indicates the signal is used to synchronize other signals on the interface. A Detection Type of
“Asynch” means the signal changes state asynchronously to the relevant clock signal.
Table 62 M-TX-CTRL Interface Signals

Detection
Type
TX_CfgClk I Clock 1 Identical behavior as RX_CfgClk
TX_Reset I Asynch 1 Identical behavior as RX_Reset
TX_AttrID I Level 8 Identical behavior as RX_AttrID

Confidential
01-Dec-2016
Table 62 M-TX-CTRL Interface Signals (continued)

Detection
Type
TX_AttrRdVal O Level 8 Identical behavior as RX_AttrRdVal
Identical behavior as RX_AttrRdCnf.
TX_AttrRdCnf O Level 1
TX_AttrRdCnf is an optional signal.
TX_AttrWrVal I Level 8 Identical behavior as RX_AttrWrVal
TX_AttrWRn I Level 1 Identical behavior as RX_AttrWRn
TX_CfgEnbl I Level 1 Identical behavior as RX_CfgEnbl
Identical behavior as RX_CfgUpdt. Protocol shall
not issue TX_CfgUpdt between the protocol
TX_CfgUpdt I Transition 1
setting TX_Burst to "1" and the M-TX setting
TX_SaveState_Status_N to "1”.
TX_CfgRdyN O Level 1 Identical behavior as RX_CfgRdyN
TX_LineReset triggers the M-TX to issue a
LINE-RESET condition.
When TX_Controlled_ActTimer is set to “0”, or
TX_Controlled_ActTimer is not implemented, the
Protocol Layer shall set TX_Burst to “0” and wait
for TACTIVATE after the M-TX sets
TX_SaveState_Status_N to “0” before it sets
TX_LineReset to “1” for one TX_CfgClk cycle.
After the Protocol Layer sets TX_LineReset to “1”
TX_LineReset I Transition 1
for one TX_CfgClk cycle, the M-TX shall
immediately drive the LINE-RESET condition (see
Section 4.7.4.1).
When TX_Controlled_ActTimer is set to “1”, after
the Protocol Layer sets TX_LineReset to “1” for
one TX_CfgClk cycle, the M-TX shall immediately
drive DIF-N for TACTIVATE, irrespective of its
current state, before it drives the LINE-RESET
condition.
TX_Controlled_ActTimer informs the M-TX which
Layer controls the TACTIVATE time.
TX_Controlled_ActTimer is an optional signal.
The Protocol Layer shall set
TX_Controlled_ActTimer to “1” to inform the M-TX
to drive DIF-N for at least TACTIVATE, irrespective of
the current M-TX state, before driving DIF-P for
TLINE-RESET after TX_LineReset is asserted. The
TX_Controlled_ M-TX shall also control the TACTIVATE time upon
I Level 1
ActTimer HIBERN8 exit.
When TX_Controlled_ActTimer is set to “0”, the
Protocol Layer shall wait TACTIVATE after M-TX sets
TX_SaveState_Status_N to “0” before asserting
TX_LineReset. If TX_Controlled_ActTimer is set to
“0”, when TX_LineReset is asserted, the M-TX
shall immediately drive the LINE-RESET
condition. The Protocol Layer shall also control the
TACTIVATE time upon HIBERN8 exit.

Confidential
01-Dec-2016
Table 62 M-TX-CTRL Interface Signals (continued)

Detection
Type
Required only if TX_Controlled_ActTimer is 0 and
M-TX supports RSE_PO_TX.
When set to 1, supports the protocol control of M-
TX output resistance to RSE_TX.
TX_DIFNDrive I Level 1
If TX_Controlled_ActTimer is 0, the protocol shall
set this signal to 1 for at least T_ACTIVATE before
issuing a pulse on TX_LineReset or on exiting
HIBERN8.

Confidential
01-Dec-2016
Version 4.1
Table 63 M-TX-DATA Interface Signals
Detection
Type
TX_SaveState_Status_N indicates the M-TX is entering or exiting a SAVE state. The Protocol
Layer can use this signal to understand when the M-TX is not transmitting PREPARE, SYNC,
HOB, PAYLOAD, TOB, BURST Extension or LINE-CFG information. The M-TX sets
TX_SaveState_Status_N to “0” when it enters into a SAVE state. The M-TX sets
TX_SaveState_Status_N O Level 1 TX_SaveState_Status_N to “1” when it exits a SAVE state.
A Type-I implementation shall include this signal. Though not required, a Type-II
implementation should include this signal. There may be a delay between the LINE state
change and the indication of SAVE state entry.
Bit Clock
TX_BitClk is used to transmit data bits over the LINEs.
TX_BitClk may not be accessible in the M-TX-DATA interface for M-PHY implementations that
Confidential
TX_BitClk I Clock 1
comprise an integrated clock multiplier.
TX_BitClk shall have no specific phase relationship requirement to any signal in the
M-TX-DATA interface.
Symbol Clock
All M-TX-DATA interface signals are synchronous with this signal.
The Protocol Layer may disable TX_SymbolClk generation when the M-TX is not in
LINE-CFG, PWM-BURST, SYS-BURST, or HS-BURST states. For this purpose, the Protocol
Layer shall read the M-TX FSM state attribute.
TX_SymbolClk I Clock 1 In HS-MODE and SYS-MODE, TX_SymbolClk shall have a period of 10 UI for a 10-bit
TX_Symbol bus, 20 UI for a 20-bit TX_Symbol bus, or 40 UI for a 40-bit TX_Symbol bus.
In PWM-MODE, TX_SymbolClk shall have a period of 10 TPWM_TX for a 10-bit TX_Symbol

bus, 20 TPWM_TX for a 20-bit RX_Symbol bus, or 40 TPWM_TX for a 40-bit TX_Symbol bus.
The behavior of TX_SymbolClk must be glitch-free even when this signal is being enabled or
disabled. TX_SymbolClk shall not have a “1” or “0” pulse with a duration less than one-quarter
of the nominal TX_SymbolClk period.
175
Table 63 M-TX-DATA Interface Signals (continued)
176

Detection
Type
PHY Data Input Ready
TX_PhyDIRDY indicates the M-TX is ready to accept new data on the TX_Symbol bus.
The M-TX shall set TX_PhyDIRDY to “1” when the M-TX is ready to consume data.
TX_PhyDIRDY O Level 1
The M-TX shall set TX_PhyDIRDY to “0” when the M-TX is busy.
The Protocol Layer should not update TX_Symbol while TX_PhyDIRDY is “0” and TX_Burst is
“1”.
TX_Symbol is used for BURST data transfer to the M-TX. The contents of this bus depend on
the interface width (10, 20 or 40 bits, corresponding to 1, 2 and 4 parallel symbols,

respectively), and also on whether the 8b10b encoding function in the M-TX is bypassed.
When the M-TX 8b10b encoding function is bypassed, TX_Symbol carries the raw data to
send on the LINEs, parallelized according to the implemented width. The LSb of TX_Symbol
10,
shall correspond to the earliest transmitted bit.

Confidential
TX_Symbol I Level 20
When the M-TX 8b10b encoding function is enabled, only the 8, 16, or 32 LSbs of TX_Symbol
or 40 are used to carry the unencoded DATA or control symbol. The M-TX shall ignore the unused
MSbs of TX_Symbol. The Protocol Layer should set the unused MSbs to “0”.
Control symbols shall be encoded as listed in Table 58.
TX_Symbol is accepted by the M-TX on every TX_SymbolClk cycle in which TX_ProtDORDY,
TX_PhyDIRDY and TX_Burst are “1”.
01-Dec-2016
Version 4.1
01-Dec-2016
Version 4.1
Detection
Type
Protocol Data Output Ready
TX_ProtDORDY indicates data is available in the corresponding TX_Symbol bus range. The
width of TX_ProtDORDY is one, two or four bits depending on the TX_Symbol bus width of 10,
20, or 40 bits, respectively.
Each bit in TX_ProtDORDY corresponds to a range of bits in the TX_Symbol bus.
TX_ProtDORDY Bits TX_Symbol bits (8b10b enabled)
0 bits[9:0] (bits[7:0])
1 bits[19:10] (bits[15:8])
TX_ProtDORDY I Level 1, 2 or 4
2 bits[29:20] (bits[23:16])
3 bits[39:30] (bits[31:24])
When a TX_Symbol bus range contains new data, the Protocol Layer shall set the
corresponding bit of TX_ProtDORDY to “1” for each TX_SymbolClk cycle.

Confidential
When a TX_Symbol bus range does not contain new data, the Protocol Layer shall set the
corresponding bit of TX_ProtDORDY to “0” for each TX_SymbolClk cycle.
When the M-TX 8b10b encoding function is bypassed, the Protocol Layer shall set the
applicable bits of TX_ProtDORDY to “1” for each TX_SymbolClk cycle during a BURST.
TX_DataNCtrl indicates the type of symbol on the indicated range of TX_Symbol.
The width of the TX_DataNCtrl is one, two or four bits depending on the TX_Symbol bus width
of 10, 20, or 40 bits, respectively.
The bits of TX_DataNCtrl are mapped the same as the bits of TX_ProtDORDY.
The Protocol Layer shall set the corresponding bit of TX_DataNCtrl to “0” when the related
TX_DataNCtrl I Level 1, 2 or 4 TX_Symbol bus range carries a data symbol.
The Protocol Layer shall set the corresponding bit of TX_DataNCtrl to “1” when the related

TX_Symbol bus range carries a control symbol.
The Protocol Layer should set all bits of TX_DataNCtrl to “0” when 8b10b encoding is
bypassed.
The M-TX shall ignore all bits of TX_DataNCtrl when 10b8b decoding is bypassed.
177
178

Detection
Type
TX_Burst initiates a BURST.
The Protocol Layer shall set TX_Burst to “1” to initiate a BURST, and hold the value for the
duration of the BURST.
Once TX_Burst is set to “1”, the M-TX shall send the PREPARE sequence (and SYNC
sequence in the case of a HS-BURST), followed by data or FILLER symbols.
If any bit of TX_ProtDORDY is set to “1”, the M-TX shall send the data present on the
TX_Burst I Transition 1
corresponding TX_Symbol bus range.
If any bit of TX_ProtDORDY is set to “0”, the M-TX shall send one FILLER for each
TX_ProtDORDY bit set to 0.
Once TX_Burst is set to “0”, the M-TX shall send the TAIL-OF-BURST sequence (see
Section 4.7.2.4).
TX_Burst shall not be asserted while TX_ADAPT_ACTIVE or TX_ADAPT_REQ are asserted.

Confidential
TX_ADAPT_ACTIVE = 1 indicates to the Protocol that MTX is in ADAPT sub-state. The signal
TX_ADAPT_ACTIVE O Level 1
is asserted after PREPARE. The signal is de-asserted with the end of the ADAPT sequence.
The Protocol Layer shall set TX_ADAPT_REQ to “1” to initiate an ADAPT sequence.
Once set to “1”, the M-TX shall send the PREPARE sequence followed by the ADAPT
sequence.
TX_ADAPT_REQ I Level 1
The Protocol shall de-assert TX_ADAPT_REQ with TX_ADAPT_ACTIVE = 1 earliest, but
latest with the end of the ADAPT sequence when the MTX returns to STALL. The Protocol
Layer shall ensure RX_ADAPT_Control set to ADAPT prior to assertion of this signal.
01-Dec-2016
Version 4.1
01-Dec-2016
Table 64 M-TX Test Extensions

Detection
Type
TST_RTObserve O Asynch 8 Identical behavior as in M-RX interface
TST_RTControl I Asynch 8 Identical behavior as in M-RX interface
A.4 Interface Usage Examples

954 To aid in the design of a conformant implementation, the following use-cases are provided depicting the
required interface behavior.
A.4.1 Attribute Read from Effective Configuration

955 Figure 68 illustrates an example of an attribute read from the M-RX. The example shows the M-RX effective
configuration bank being read regardless of RX_CfgRdyN value.
T1 T2 T3 T4
RX_Reset
RX_LineReset
RX_CfgClk
RX_CfgRdyN
RX_CfgUpdt
RX_CfgEnbl
RX_AttrID Don t Care Valid Don t Care Valid Don t Care
RX_AttrWRn
RX_AttrRdVal Previous Value EFFECTIVE CONFIG VALUE EFFECTIVE CONFIG VALUE
RX_AttrRdCnf
RX_AttrWrVal Don t Care Don t Care Don t Care
Figure 68 Interface Behavior for Attribute Read Operations
956 At T1, on the rising edge of RX_CfgClk, the Protocol Layer sets RX_CfgEnbl to “1”, sets RX_AttrWRn to
“0”, and sets the value of RX_AttrID to the attribute identifier.
957 At T2, on the rising edge of RX_CfgClk, the M-RX captures the command. In response, the M-RX updates
RX_AttrRdVal with the effective configuration bank attribute value and, if implemented, asserts
Rx_AttrRdCnf for one RX_CfgClk cycle. Also at T2, the Protocol Layer sets RX_CfgEnbl to “0” on the
rising edge of RX_CfgClk.
958 At T3, the Protocol Layer can capture RX_AttrRdVal. The M-RX holds the value on RX_AttrRdVal until a
subsequent read operation, or local RESET.
959 At T4, on the rising edge of RX_CfgClk, the Protocol Layer initiates a second read operation. In this instance,
the M-RX has set RX_CfgRdyN set to “1” indicating it cannot process a write operation. Note that the read
operation is unaffected by the RX_CfgRdyN signal.

Confidential
01-Dec-2016
A.4.2 Attribute Write to Shadow Memory and Effective Configuration

960 Figure 69 shows two attribute writes to the M-RX. In this use-case, an attribute in the shadow memory bank
is updated independently of RX_CfgRdyN, then an effective configuration bank attribute is updated only
when RX_CfgRdyN is “0”.
T1 T2 T3 T4 T5
RX_Reset
RX_LineReset
RX_CfgClk
RX_CfgRdyN
RX_CfgUpdt
RX_CfgEnbl
RX_AttrID Don t Care Valid Don t Care Valid Don t Care
RX_AttrWRn
RX_AttrRdVal Don t Care Don t Care Don t Care
RX_AttrWrVal Don t Care Valid Don t Care Valid Don t Care
Figure 69 Interface Behavior for Attribute Write Operations
961 At T1, on the rising edge of RX_CfgClk, the Protocol Layer sets RX_CfgEnbl and RX_AttrWRn to “1”, and
sets the value of RX_AttrID and RX_AttrWrVal.
962 At T2, the M-RX samples these signals on the rising edge of RX_CfgClk and performs the requested
operation, in this case updating its shadow memory bank. Since the effective configuration bank is not
changed, the M-RX performs the requested operation even though RX_CfgRdyN is “1” at this time. The
Protocol Layer, on the rising edge of RX_CfgClk at T2, sets RX_CfgEnbl and RX_AttrWRn to “0”, and
optionally sets to “0” RX_AttrID and RX_AttrWrVal.
963 At T3, another write operation is performed in the same manner as the first, which causes the M-RX to write
either to the effective configuration bank or to the shadow memory bank, depending on the implementation as
this operation is performed by the M-RX when RX_CfgRdyN is “0” as illustrated in this use-case.
964 As a result of the operation, the M-RX optionally sets RX_CfgRdyN to “1” at T4, when the write operation is
processed. The M-RX optionally holds RX_CfgRdyN at “1” until the change in the configuration is
complete. The M-RX then sets RX_CfgRdyN to “0” synchronously with RX_CfgClk at T5. The M-RX is
then ready to perform any subsequent write operation.
A.4.3 Effective Configuration Single-step Update and Local RESET

965 Figure 70 shows a single-step (atomic) update of the effective configuration bank followed by a local
RESET.

Confidential
01-Dec-2016
T1 T2 T3 T4 T5 T6
RX_Reset
RX_LineReset
RX_CfgClk
RX_CfgRdyN
RX_CfgUpdt
RX_CfgEnbl
RX_AttrID Don t Care Don t Care Don t Care
RX_AttrWRn
Internal M-RX
Previous Settings Shadow Memory Contents Default Settings
Configuration
Figure 70 Interface Behavior for RX_CfgUpdt and RX_Reset
966 At T1, the Protocol Layer sets RX_CfgUpdt to “1” for one cycle of RX_CfgClk to upload the entire shadow
memory bank into the effective configuration bank in one step. The Protocol Layer holds RX_CfgEnbl at “0”
for this operation. RX_AttrID, RX_AttrWRn, and RX_AttrWrVal are ignored by the M-RX.
967 The M-RX processes the command on the rising edge of RX_CfgClk at T2, when the entire shadow memory
is uploaded into the effective configuration bank. The M-RX then sets RX_CfgRdyN to “1” and holds the
value until the change in the M-RX configuration is complete and the M-RX is ready to perform subsequent
write operations.
968 At T3, the M-RX sets RX_CfgRdyN to “0”on the rising edge of RX_CfgClk.
969 At T4, the Protocol Layer sets RX_Reset to “1”, asynchronous to RX_CfgClk, causing a local RESET. The
M-RX asynchronously sets RX_CfgRdyN to “1” in response, and holds the value until the Protocol Layer
sets RX_Reset to “0”, which occurs at T5, and it finishes processing the local RESET. Once the M-RX is
ready to perform subsequent write operations, it sets RX_CfgRdyN to “0”, which occurs synchronously at
T6.
A.4.4 Received LCC and LINE-RESET

970 Figure 71 shows a Type-I M-RX receiving an LCC after an HS-BURST or PWM-BURST followed by a
LINE-RESET.

Confidential
01-Dec-2016
T1 T2 T3 T4 T5 T6 T7
HS-BURST or LCC-READ
RXDP/RXDN PWM-BURST Command READ1 to READ4 LCC-MODE SLEEP LINE-RESET SLEEP
RX_Reset
RX_LineReset
RX_CfgClk
RX_CfgRdyN
RX_LCCRdDet
RX_CfgUpdt
RX_CfgEnbl
RX_AttrID Don t Care Don t Care Don t Care
RX_AttrWRn
Internal M-RX
Previous Settings LCC Attribute Update Updated Settings Default Settings
Configuration
Figure 71 Interface Behavior for LCC Command and LINE-RESET
971 Following an HS-BURST or PWM-BURST, a Type 1 M-RX receives an LCC starting at T1. As shown in the
figure, the LCC is asynchronous to RX_CfgClk. Since the LCC follows from HS-BURST or PWM-BURST
without passing through STALL, SLEEP or HIBERN8 states, the M-RX holds RX_CfgRdyN at “1”.
972 At T2, the M-RX waits for LCC data from the media convertor.
973 At T3, the M-RX exits LCC-MODE.
974 At T4, on the first rising edge of RX_CfgClk after the end of LCC-MODE, all LCC attributes are updated.
The M-RX sets RX_LCCRdDet to “1” for one cycle of RX_CfgClk indicating all LCC-READ sequences
have been processed, and sets RX_CfgRdyN to “0” indicating it has entered a SAVE state. Additional PWM
edges provided during the LCC-MODE command can be used for clocking data to the signaling interface.
975 At T5, on the rising edge of RX_CfgClk, the M-RX sets RX_CfgRdyN to “1” indicating the LINE is no
longer in SLEEP, STALL or HIBERN8 state.
976 At T6, on the rising edge of RX_CfgClk, the M-RX sets RX_LineReset to “1” indicating it has detected the
LINE-RESET condition. Both RX_CfgRdyN and RX_LineReset are held at “1” for the duration of the
LINE-RESET action.
977 At T7, on the rising edge of RX_CfgClk, the M-RX sets RX_CfgRdyN and RX_LineReset to “0” indicating
the LINE is in SLEEP state and the LINE-RESET action is complete.
978 Note:
979 RX_CfgRdyN and RX_LineReset behaviors are independent. In the use-case shown in Figure 71,
the M-RX may hold RX_CfgRdyN at “1” at T7 until it is ready to accept subsequent write commands.

Confidential
01-Dec-2016
A.4.5 HS Data Reception with 20-bit RX_Symbol Bus

980 Figure 72 shows the interface behavior for an M-RX with a 20-bit interface during HS data reception. 10b8b
decoding is enabled in this use-case.
981 In this use-case, the M-RX receives a data transmission from the attached M-TX. An RD error occurs near the
end of the transmission.
T1 T2 T3 T4 T5 T6 T7 T8
Data D.E.
RXDP/RXDN PREPARE SYNC MK0 A5 B3 7F C4 FLR A9 82 E4 TOB
RX_SymbolClk
RX_PhyDORDY[1:0] 00 11 11 11 11 01 00
RX_DataNCtrl[1:0] 00 01 00 10 00 00 00
RX_Symbol[15:8] 00 A5 7F 80 82 00 00
RX_Symbol[7:0] 00 01 B3 C4 A9 E4 00
RX_SymbolErr[1:0] 00 00 00 00 10 00 00
RX_Burst
D.E. = Disparity Error
Figure 72 Example 20-bit Interface Behavior for HS Data Reception
982 At T1, the M-RX detects the PREPARE sequence and sets RX_Burst to “1” on the rising edge of
RX_SymbolClk at T2.
983 At T3, the SYNC sequence ends. The M-RX receives the first two symbols, a MARKER0 (MK0) and A5
(data).
984 At T4, on the rising edge of RX_SymbolClk, the M-RX sets RX_Symbol[7:0] to “01” (MARKER0) and
RX_Symbol[15:8] to “A5”. The M-RX also sets RX_DataNCtrl[0] to “1” indicating a control symbol is on
RX_Symbol[7:0], and sets RX_DataNCtrl[1] to “0” indicating data is on RX_Symbol[15:8].
RX_SymbolErr[1:0] is held at “00” indicating no errors on RX_Symbol. Finally, the M-RX sets
RX_PhyDORDY[1:] to “11” indicating data is available on RX_Symbol. On the next rising edge of
RX_SymbolClk, the M-RX sets RX_Symbol[7:0] and RX_Symbol[15:8] to the next two symbols received,
“B3” and “7F”, respectively. The M-RX sets RX_DataNCtrl[1:0] to “00” indicating both symbols are data.
The M-RX sets the remaining signals the same as at T4.
985 At T5, the M-RX sets RX_DataNCtrl[1:0] to “10” indicating it received another control symbol. The M-RX
also sets RX_Symbol[7:0] to “C4” (data) and RX_Symbol[15:8] to “80” (FILLER). The M-RX sets the
remaining signals the same as at T4.
986 Note:
987 By itself, the FILLER symbol does not cause the M-RX to set RX_PhyDORDY[1] to “0”. However, a
midstream deassertion of RX_PhyDORDY is possible in plesiochronous Type-I systems due to, e.g.
internal FIFO refills in an M-RX implementation.
988 The M-RX receives the next two symbols, “A9” and “82”, in the same manner as the first six symbols.
However, as shown in Figure 72, the “82” symbol has an RD error.

Confidential
01-Dec-2016
989 At T6, on the rising edge of RX_SymbolClk, the M-RX sets RX_Symbol[7:0] to “A9”, RX_Symbol[15:8] to
“82”, and RX_SymbolErr[1:0] to “10” indicating an error in the data on RX_Symbol[15:8]. Finally, the
M-RX sets RX_PhyDORDY[1:0] to “11” indicating data is available on RX_Symbol.
990 At T7, the M-RX detects the end of the BURST and determines it has received an odd number of symbols. It
sets RX_Symbol[7:0] to “E4”, RX_Symbol[15:8] to “00”, and RX_PhyDORDY[1:0] to “01” indicating
RX_Symbol[15:8] does not contain data. The M-RX also sets RX_DataNCtrl[1:0] to “00” indicating
RX_Symbol does not contain any control symbols. Finally, the M-RX sets RX_SymbolErr[1:0] to “00”
indicating there are no errors.
991 At T8, on the rising edge of RX_SymbolClk, the M-RX sets RX_Burst to “0” indicating the end of the Burst.
“00” on RX_Symbol[15:0] is a don't care condition.
A.4.6 TX_LineReset Behavior

992 Figure 73 shows a LINE-RESET use-case. In this use-case, the Protocol Layer sends a LINE-RESET to
initialize the M-TX and M-RX attached to the LINE.
T0 T1 T2 T3 T4
TACTIVATE
DIF-P
TXDP/TXDN Don t Care DIF-N TLINE-RESET SLEEP
TX_Reset
TX_DIFNDrive
TX_LineReset
TX_CfgClk
TX_CfgRdyN
TX_CfgUpdt
TX_CfgEnbl
TX_AttrID Don t Care Don t Care Don t Care
TX_AttrWRn
TX_AttrRdVal Don t Care Don t Care Don t Care
TX_AttrWrVal Don t Care Don t Care Don t Care
Internal M-TX
Previous Settings Default Settings
Configuration
Figure 73 Interface Behavior for a TX_LineReset Command
993 At T0, the Protocol Layer sets TX_DIFNDrive to “1” and holds it to “1” for TACTIVATE before issuing
LINE-RESET.
994 At T1, the Protocol Layer ensures the M-TX is in SLEEP or STALL state, and waits for TACTIVATE before
issuing LINE-RESET. The M-TX detects TX_DIFNDrive at “1” and drives DIF-N on the LINE.

Confidential
01-Dec-2016
995 At T2, the Protocol Layer sets TX_LineReset to “1” on the rising edge of TX_CfgClk, and optionally sets it
to “0” one TX_CfgClk cycle later at T3.
996 At T3, the M-TX sets TX_CfgRdyN to “1”, updates its internal configuration registers to their default values,
and starts driving the LINE-RESET condition.
997 The M-TX holds TX_CfgRdyN at “1” while it is processing the LINE-RESET.
998 At T4, on the rising edge of TX_CfgClk, the M-TX sets TX_CfgRdyN to “0” to signal its internal FSM exit to
SLEEP state. At this time, the M-TX is ready for any subsequent write command or TX_LineReset pulse.
999 Note:
1000 The M-TX only monitors the 0-to-1 transition on TX_LineReset to interpret the command.
Consequently, the M-TX does not detect whether the Protocol Layer leaves TX_LineReset at “1” or
sets it to “0” at T3.
A.4.7 HS Transmission on 20-bit TX_Symbol Bus with Data Throttled by Protocol Layer
1001 Figure 74 shows an HS transmission with the Protocol Layer controlling the data throughput. 8b10b
encoding is enabled in this use-case.
1002 In this use-case, the Protocol Layer cannot supply transmission requests as fast as the M-TX transmissions on
the LINE. The Protocol Layer throttles the data throughput by changing the value on TX_ProtDORDY. The
M-TX continues to transmit, but inserts FILLER symbols whenever the Protocol Layer does not have new
data to send.
T1 T2 T3 T4 T5 T6 T7 T8 T9
Data
TXDP/TXDN PREPARE SYNC MK0 A5 B3 7F FLR FLR A9 82 MK2 FLR TOB DIF-N or DIF-P
TX_SymbolClk
TX_ProtDORDY[1:0] 11 11 00 11 01 00
TX_DataNCtrl[1:0] 01 00 xx 00 x1 00
TX_Symbol[15:8] A5 7F xx 82 xx 00
TX_Symbol[7:0] 01 B3 xx A9 04 00
TX_PhyDIRDY
TX_Burst
to LINE-CFG
TX_SaveState_Status_N
to STALL
Figure 74 Interface Behavior for HS Transmission with Protocol Layer Throttling Data
1003 At T1, on the rising edge of TX_SymbolClk, the Protocol Layer sets TX_ProtDORDY[1:0] to “11”,
indicating both TX_Symbol[7:0] and TX_Symbol[15:8] contain data; TX_DataNCtrl[1:0] to “01”,
indicating the value on TX_Symbol[7:0] (01) is a control symbol (MARKER0), and the value on
TX_Symbol[15:8] (A5) is a data symbol. Finally, the Protocol Layer initiates the HS transmission by setting
TX_Burst to “1”.
1004 At T2, on the rising edge of TX_SymbolClk, the M-TX reads the Protocol Layer request and issues
PREPARE and SYNC sequences. The M-TX also sets TX_SaveState_Status_N to “1”.
1005 At T3, on the rising edge of TX_SymbolClk, the M-TX sets TX_PhyDIRDY to “1”, far enough in advance of
the start of data transmission for the Protocol Layer to read TX_PhyDIRDY at T4.

Confidential
01-Dec-2016
1006 At T4, on the rising edge of TX_SymbolClk, the Protocol Layer holds TX_ProtDORDY[1:0] at “11”,
indicating new data is available, and sets TX_DataNCtrl[1:0] to “00”, indicating the values on
TX_Symbol[7:0] (B3) and TX_Symbol[15:8] (7F) are data symbols.
1007 At T5, on the rising edge of TX_SymbolClk, the Protocol Layer sets TX_ProtDORDY to “00” indicating it
does not have new data to send. The M-TX ignores the values on TX_DataNCtrl[1:0] and TX_Symbol[15:0],
and inserts two FILLER symbols on the LINE.
indicating only TX_Symbol[7:0] has available data, and sets TX_DataNCtrl[1:0] to “01”, indicating the
value on TX_Symbol[7:0] (04) is a control symbol (MARKER2).
1009 At T7, on the rising edge of TX_SymbolClk, the Protocol Layer sets TX_Burst to “0” indicating the end of
the HS-BURST. In this use-case, the M-TX inserts a FILLER symbol after the MARKER2 symbol. “00” on
TX_Symbol[15:0] is a don't care condition.
1010 At T8, on the rising edge of TX_SymbolClk, the M-TX reads the TX_Burst signal as “0” and begins
transmitting the TAIL-OF-BURST sequence on the LINE. The M-TX sets TX_PhyDIRDY to “0”, indicating
it is no longer prepared to accept new data to transmit.
1011 At T9, on completion of TOB, the M_TX sets TX_SaveState_Status_N to “0” and enters STALL state or
proceeds to LINE-CFG, leaving TX_SaveState_Status_N at “1”.
A.4.8 HS Transmission on 20-bit TX_Symbol Bus with Data Throttled by M-TX

1012 Figure 75 shows an HS transmission with the M-TX controlling the data throughput. 8b10b encoding is
enabled in this use-case.
1013 In this use-case, the M-TX transmissions on the LINE lag the Protocol Layer requests so the M-TX needs to
slow down the transfer from the Protocol Layer. The M-TX throttles the data throughput by changing the
value on TX_PhyDIRDY.
T1 T2 T3 T4 T5 T6 T7 T8 T9
Data
TXDP/TXDN PREPARE SYNC MK0 A5 B3 7F A9 82 E4 MK2 TOB DIF-N or DIF-P
TX_SymbolClk
TX_ProtDORDY[1:0] 11 11 11 11 00
TX_DataNCtrl[1:0] 01 00 00 10 00
TX_Symbol[15:8] A5 7F 82 04 00
TX_Symbol[7:0] 01 B3 A9 E4 00
TX_PhyDIRDY
TX_Burst
to LINE-CFG
TX_SaveState_Status_N
to STALL
Figure 75 Interface Behavior for HS Transmission with M-TX Throttling Data
indicating both TX_Symbol[7:0] and TX_Symbol[15:8] contain data; TX_DataNCtrl[1:0] to “01”,
indicating the value on TX_Symbol[7:0] (01) is a control symbol (MARKER0), and the value on
TX_Symbol[15:8] (A5) is a data symbol. Finally, the Protocol Layer initiates the HS transmission by setting
TX_Burst to “1”.

Confidential
01-Dec-2016
1015 At T2, on the rising edge of TX_SymbolClk, the M-TX reads the Protocol Layer request and issues
PREPARE and SYNC sequences. The M-TX also sets TX_SaveState_Status_N to “1”.
1016 At T3, on the rising edge of TX_SymbolClk, the M-TX sets TX_PhyDIRDY to “1”, far enough in advance of
the start of data transmission for the Protocol Layer to read TX_PhyDIRDY.
indicating new data is available, and sets TX_DataNCtrl[1:0] to “00”, indicating the values on
TX_Symbol[7:0] (B3) and TX_Symbol[15:8] (7F) are data symbols.
1018 At T5, on the rising edge of TX_SymbolClk, the M-TX sets TX_PhyDIRDY to “0”, indicating the M-TX is
busy. The Protocol Layer holds TX_ProtDORDY at “11” indicating it has new data to send.
1019 At T6, on the rising edge of TX_SymbolClk, the M-TX sets TX_PhyDIRDY to “1” indicating it is again
available to accept new data. However, the Protocol Layer reads TX_PhyDIRDY as “0”, and consequently
holds the values on TX_ProtDORDY[1:0], TX_DataNCtrl[1:0], and TX_Symbol[15:0].
1020 On the next rising edge of TX_SymbolClk, the Protocol Layer sets TX_ProtDORDY[1:0] to “11”, and sets
TX_DataNCtrl[1:0] to “10”, indicating the value on TX_Symbol[7:0] (E4) is a data symbol and the value on
TX_Symbol[15:8] (04) is a control symbol (MARKER2).
1021 At T7, on the rising edge of TX_SymbolClk, the Protocol Layer sets TX_Burst to “0” indicating the end of
the HS-BURST.
1022 At T8, the M-TX reads the TX_Burst signal as “0” on the rising edge of TX_SymbolClk, and begins
transmitting the TAIL-OF-BURST sequence on the LINE. The M-TX sets TX_PhyDIRDY to “0”, indicating
it is no longer prepared to accept new data to transmit.
1023 At T9, on completion of TOB, the M_TX sets TX_SaveState_Status_N to “0” and enters STALL state or
proceeds to LINE-CFG, leaving TX_SaveState_Status_N at “1”.

Confidential
01-Dec-2016
Annex B Recommended Test Functionality (informative)

1024 The purpose of this annex is to provide guidelines for testability features for M-PHY applications. Because
explicit test modes are not defined within the Physical Layer, most test functionality is left to higher layers to
implement. However, this must be done in a manner that produces the necessary behavior at the Physical
Layer interface that is needed for performing physical layer measurements with standard laboratory
equipment.
1025 This annex describes the functional behavior that should be provided at the Physical Layer interface in order
for various classes of measurements to be performed. The behavior is described in an abstract manner,
without reference to specific protocols or applications. Because multiple applications of M-PHY technology
exist, options for different architectures are discussed. Applications that use M-PHY technology should
ensure that sufficient functionality is designed into the higher layer specifications to allow the necessary test
functionality to be supported at the Physical Layer interface. Note that this functionality may be supported
within the normal operating capabilities of the protocol, or may be implemented via specialized test modes if
necessary.
1026 This annex is divided into two main sections, test pattern generation and test pattern verification. Test pattern
generation is primarily applicable to transmitter measurements, and test pattern verification is applicable to
receiver tolerance measurements. A brief section on interoperability testing is also discussed.
B.1 Test Pattern Generation

B.1.1 General Transmitter Test Approach
1027 In order to perform transmitter signaling measurements such as amplitude (swing), rise and fall times, skew,
jitter, etc, it is necessary for the M-PHY Device Under Test (DUT) to transmit known test patterns into a
reference termination load. The signals observed at this reference load are captured using an oscilloscope,
and measured for conformance.
1028 The reference termination may consist of an external fixture that contains a precision reference termination
structure, which is then probed using high-bandwidth active probes. Or in some cases the oscilloscope itself
may be used as the reference termination (in cases where a 100  differential termination is required), in
which case the signal is sent directly into the instrument, using coaxial cables.
1029 In the case of M-PHY technology, where signals must also be measured into an open (unterminated)
termination, active probing must be used, as it is the only way to observe signals under these conditions.
Active probing is also preferable for terminated measurements, as it allows the signal to be observed as close
to the TX PINs as possible, and with minimal capacitive loading.
1030 An example transmitter test setup is shown in Figure 76, where the DUT is mounted on an SMA-based Test
Vehicle Board (TVB), and is connected to a Reference Termination Board (RTB). Each signaling Lane is
probed using two active differential probes.

Confidential
01-Dec-2016
Real-Time Oscilloscope
Active Differential Probes

(two per lane)
DUT mounted
on TVB
RTB
SMA Connectors
Figure 76 Transmitter Test Setup
B.1.2 Test Patterns

1031 Some transmitter measurements, e.g., rise and fall times, are typically performed on short repeating patterns
consisting of a single repeated 10-bit code word, e.g., D30.7, D10.2, etc. Other measurements, such as
transmitter jitter, are required to be performed on longer repeating patterns such as CJTPAT and CRPAT (see
[INC01]).
1032 As a result, it is desirable for M-PHY devices to support a mode that allows a test pattern (up to 2320 bits in
length for CJTPAT, and 1960 bits for CRPAT). For maximum flexibility, this mode should allow arbitrary
sequences of validly encoded 8b10b 10-bit codewords up to several thousand bits in length.
B.1.3 Signaling Type and Speed

1033 Two types of signaling are used for an M-PHY implementation, NRZ and PWM. A Type-I MODULE uses
NRZ signaling for HS transmission and uses PWM signaling for LS transmission. A Type-II MODULE uses
NRZ signaling for LS and HS transmission. In addition, different speed ranges (GEARs) are defined for both
HS and LS transmission.
1034 DUTs should provide a mechanism that allows both the signaling type and GEAR to be controlled for test
purposes.
B.1.4 Continuous vs. Burst Modes

1035 Under normal operation, data transmission occurs in bursts, with power-saving states occurring between
bursts.

Confidential
01-Dec-2016
1036 Most transmitter measurements can be performed on burst-mode signaling using a real-time oscilloscope.
These instruments can capture individual burst waveforms, which can then be post-processed to extract the
required measurements.
1037 Note that a second class of oscilloscope exists, known as a sampling oscilloscope, which requires a
continuous, repeating pattern in order to observe and measure a signal. These instruments sample multiple
instances of the same repeating waveform at different time offsets in order to build a picture of the transmitted
signal. These types of instruments are typically capable of higher bandwidths and greater vertical precision
than real-time oscilloscopes, however they require a continuous, repeating pattern, and cannot measure
burst-mode signaling.
1038 In order to support the widest range of test instruments and greatest measurement flexibility, M-PHY devices
should support both burst-based and continuous transmission modes for test pattern generation.
B.1.5 Disconnect
1039 Mechanisms may exist within the protocol to allow configuration of desired test modes and capabilities
through the Physical Layer interface. However in these instances, capability must be provided that allows the
DUT to remain in the configured test mode once the test mode has been entered, such that it may be
disconnected from a protocol-aware LINK partner (that may have been used to perform all or part of the
configuration), and reconnected to the test setup. This implies that the DUT maintains the configured
transmitter test mode even when no signaling is present at the DUT's receiver. This functionality is often
informally referred to as 'disconnect' in the test community, in that if a DUT supports “disconnect”, it will
maintain its test modes after being disconnected from a LINK partner.
1040 M-PHY devices should support disconnect for all test modes.
B.1.6 Configuration
1041 One method for implementing such a feature would be to define a special protocol mechanism, which would
allow a special frame or command containing the desired pattern to be sent to the DUT via the Physical Layer
interface. Upon reception of this packet, the DUT would transmit the provided pattern continuously, using the
desired signaling type, gear, and any other desired settings (which could also be specified along with the
pattern.) The test pattern could be transmitted continuously until a separate reset packet is received, or the
DUT is power cycled.
B.2 Test Pattern Verification

B.2.1 General Receiver Test Approach
1042 The general approach used for verifying receiver conformance involves using a laboratory-grade signal
generator to generate signaling that contains controlled amounts of degradation, of various types, per the
specification requirements. The signal generator is calibrated by measuring the specified characteristics into
a reference termination (which is the same reference termination used for the transmitter conformance
measurements). Once the required amount of degradation is calibrated, the signal is removed from the
reference termination and applied to the DUT's receiver.
1043 At this point, some observable mechanism must be used to determine whether or not the DUT can
successfully decode the received signaling without error. There are several ways that this can be achieved.
B.2.2 Loopback Mode

1044 Loopback mode is one of the most common mechanisms used for receiver testing. In this mode, data that is
received at the RX is retransmitted out the TX. The TX signal can then be observed to verify whether or not
any bits were received in error (as the error would be propagated to the TX). Note however that different
types of loopback modes exist, and the subtleties of these differences can impact their ability to be used with
different types of test instruments. The important differences are discussed below:

Confidential
01-Dec-2016
B.2.2.1 Synchronous vs. Plesiochronous

1045 One of the most important characteristics of a loopback mode pertains to how the clocking architecture is
defined with respect to the receiver and transmitter. For a synchronous loopback, the recovered clock from
the RX is used to retransmit the signal on the TX. This means there is a bit-for-bit relationship between
receiver and transmitter, and the exact bit sequence that was sent into the receiver will appear at the
transmitter.
1046 Typically, this type of loopback mode is implemented outside the scope of normal operation, where the
standard protocol operation is no longer applicable, and the DUT will simply forward any data received to the
transmitter. The received data is typically not 8b10b decoded and re-encoded in the loopback path, which
ensures that a single error at the receiver translates to a single error at the transmitter. This behavior allows
traditional Bit Error Rate Tester (BERT) instruments to be used to test the receiver (as these instruments
typically require a bit-for-bit correlation between the transmitted and received data patterns.)
1047 This document actually specifies this exact type of loopback. The LOOPBACK feature defined in
Section 4.10.1 is intended for symmetric architectures that support the same MODE and GEAR settings for
the M-RX and M-TX. If this feature is supported, it can actually be used for both receiver and transmitter
verification, as most transmitter measurements can be performed on the TX output while the desired test
pattern is transmitted into the RX. Note however that this case is not ideal for all transmitter tests, particularly
jitter, as measured jitter and frequency while in LOOPBACK are not necessarily the same as during normal
operation, as the clock reference is not the same.
1048 Other types of loopback include a plesiochronous loopback (sometimes referred to as a “far-end retimed
loopback”), which is similar to the synchronous loopback, except the transmitter and receiver run on separate
clock domains, i.e., have separate clock references. This means that the RX and TX are operating at almost
the same rate, but are not exactly matched. This is still considered a test mode that operates outside the scope
of normal protocol operation, where data must be inserted or deleted from the data being looped back in order
to account for the rate difference between RX and TX. This is typically accomplished by inserting or deleting
specifically defined control codewords that are not considered part of the CRC-checked frame data stream.
1049 In this scenario, a BERT or other signal source may be used to generate the test signal that is sent into the
receiver, however the signal that is retransmitted by the DUT must be checked using a Frame Error Counter,
which is a device that can receive the framed data patterns, and compute or check the CRC (which is included
as part of the defined pattern.)
B.2.3 Receiver Pattern Checking

1050 Note that the loopback described above can only be used for symmetric architectures, and requires the same
MODEs and GEARs to be supported by both the M-RX and M-TX. For M-PHY applications and
architectures that are not bidirectional and symmetric, a different approach must be used to verify received
data for the purposes of conformance testing.
1051 One option consists of a dedicated RX test mode, whereby a predefined test pattern can be transmitted into
the M-RX, and the checking operation is actually performed by the receiver itself. This can be done on a
bit-for-bit level (if the expected pattern is known by the receiver). However, an easier approach is to use the
CRC functionality that already exists in most devices.
1052 Such a dedicated RX test mode must be simple enough that a majority of the protocol is bypassed. The DUT
must be placed into a mode where simple, framed patterns containing valid CRC's can be sent into the
receiver, using a non-protocol-aware signal generator. Note that most current lab signal sources contain some
degree of sequencing capability that can be used to send startup or configuration information prior to a
repeating test sequence. The only limitation to these instruments however is that they cannot be “interactive”
in that they cannot detect and react to transmissions coming from the DUT, if timing-sensitive handshaking is
required as part of the protocol. In some cases where the timings are known and repeatable, it may be possible
to create sequences that can mimic an interactive protocol exchange, however these typically must be created
on a per-DUT basis, and require knowledge of the exact timings required.

Confidential
01-Dec-2016
1053 If a mode exists where a receiver is able to verify CRC-checked frame data, a mechanism must be provided
that allows for observation of the results of the checking operation. While this may be achieved though
internal vendor-specific registers and counters, it is also possible (and preferable) to allow this to be
performed through the Physical Layer interface.
1054 Several options exist to enable this, which are all based on acknowledgement mechanisms, provided the DUT
contains a low-speed TX, which may be used to communicate information about the received data.
1055 If sufficient bandwidth exists, the DUT could transmit some form of defined positive acknowledgement for
each successfully received frame, and a negative acknowledgement for each frame received in error. If
sufficient bandwidth does not exist, the positive acknowledgements can be omitted, and only the negative
acknowledgements sent in the error cases (which are assumed to be few). The acknowledgements may be as
simple as a single codeword or short pattern, or any other sequence that can be detected and counted using
non-protocol-specific laboratory instruments (or possibly a simple FPGA).
1056 In the extreme case, the DUT technically only needs to indicate if any errors were observed over a given
period in order for a test to be designed that can verify conformance. If a known amount of data is transmitted
to the DUT over a given interval, and the DUT indicates provides a single acknowledgement that no errors
were observed, this is a sufficient observable to determine conformance. While knowing an exact error count
may certainly be useful for debugging and troubleshooting purposes, such level of detail is not necessary for
determining conformance.
1057 Applications that do not or cannot implement LOOPBACK should implement some form of dedicated
pattern-checking mode, which is capable of verifying a CRC-checked, framed pattern, and which can provide
some form of acknowledgement-based observation mechanism.
B.2.4 Receiver Configuration – Termination

1058 Note that for the dedicated RX pattern checking test mode (and also potentially loopback modes as well),
some level of configuration of the receiver must occur. This includes the MODE and GEAR operation of the
receiver, as well as the termination mode (terminated or unterminated).
1059 Configuration of the termination mode is another important mechanism. The receiver HS termination is
either disabled during normal operation, or enabled such that it is only active during the reception of an HS
burst. However, another mode is needed for test purposes, in which the termination can be manually forced
into an enabled state.
1060 This mode is necessary in order to perform S-parameter measurements of the receiver termination. Because
the measurement cannot be made during reception of an HS burst, the receiver must be placed into a mode
where the termination is permanently enabled for the duration of the measurement.
1061 Applications should provide a mechanism that allows manual enabling and disabling of the receiver HS
termination.
B.3 Interoperability Testing

1062 Note that the mentioned transmitter and receiver test mechanisms all have been discussed in the context of
conformance testing. However, it is important to note that the same mechanisms, e.g., dedicated pattern
generation and checking modes, loopback, etc., can also be used to perform physical layer interoperability
verification as well.
1063 This is performed in the same manner as conformance testing, however instead of using a lab signal generator
to generate the test signals, another M-PHY device is used, which is placed into pattern generation mode.
This allows vendor-to-vendor physical layer interoperability testing to be performed using the same
methodologies that are used for conformance testing. (Note that this only verifies interoperability of the
physical layer, however isolation and verification of just the physical layer functionality is an important
component of any interoperability test strategy.)

Confidential
01-Dec-2016
Annex C SI Dithering (informative)

1064 When constructing systems using the high speed interface to connect a baseband IC (BBIC) with a radio
frequency IC (RFIC) noise coupling between the high speed interface and sensitive LNA inputs of the RFIC
is a concern. Interface bit rates are at frequencies that may cause EMI near some of the air interface
frequencies. The least destructive EMI would occur if the interface data appeared as a random UI rate bit
stream with no repeating sub-UI rate patterns. However, the encoding of the interface data into 8b10b
symbols causes repetitive 10 UI patterns in an HS-BURST. Analysis has shown that these repeating SI rate
patterns can cause spectral peaking in the EMI that exacerbates the noise coupling problem.
1065 SI rate symbol timing can not be changed during a BURST. Symbol boundaries are established at the start of
each BURST and must remain on the same 10 UI boundary for the remainder of the BURST. However, 10 UI
symbol boundaries may be changed from HS-BURST to HS-BURST. Analysis shows that dithering of the SI
starting locations, BURST to BURST, by some fraction of an SI, spreads SI rate EMI enough to offer some
EMI benefit.
C.1 Dither Method

1066 Delaying the start of each HS-BURST with reference to the last BURST, some random number of UI,
accomplishes the desired dithering. This happens naturally in many implementations, but forced dithering
ensures a good distribution of starting locations in any system.
1067 Within the physical interface there is a UI rate divide by ten counter to produce the SI rate symbol boundaries.
If this counter is left running during STALL states, then all HS-BURSTs have the same SI boundaries. That
is, the SI clock will be coherent from BURST to BURST, producing maximum EMI. In order to accomplish
dithering, this counter should be stopped and restarted from BURST to BURST. Stopping the counter during
STALL may be a good practice for power efficiency as well. However, even when the counter is restarted for
each HS-BURST, it is possible that the “frames to send”, or “start” signal to the physical interface is
generated in a way that produces a poor distribution of symbol boundaries from BURST to BURST, the worst
case being the same symbol boundary every BURST. To guarantee a good distribution of BURST to BURST
SI starting locations, the “start” signal may be delayed a random number of UI intervals before starting the
divide by ten counter to establish the new symbol boundary.
1068 In order to adequately randomize the dither delay value, some type of pseudorandom value is needed from
BURST to BURST. For example, an 8-bit PRBS might be used to provide the random dither locations. This
can be done by ensuring that the PRBS is clocked at least once per HS-BURST. The recommended method is
to clock it once at the EOT symbol of each BURST.
1069 Figure 77 is an example of a circuit that accomplishes this BURST to BURST starting location dither.
dither_enable
random_delay_value 1
fixed_default_value 0
SI Rate
SET
D Q /10 State
Machine
SI_CLOCK
SET SET
drv_enbl
frames_to_send D Q D Q CLR Q tx_symbols
SET
n-bit S/R D Q tx_data_out
Clock
CLR Q CLR Q
Gate UI_CLOCK
CLR Q
ui_rate_pll_clk 10-bit Tx S/R
Figure 77 Dithering Circuit Example
C.1.1 Dither Magnitude

1070 Since the SI rate patterns repeat every 10 UI, the maximum useful dithering spreads starting locations over a
10 UI range. The minimum dither possible is two locations. Spreading the starting locations over just two
locations showed significant benefit in simulations. Table 65 shows all of the possible useful dithering

Confidential
01-Dec-2016
ranges. Because of the reduced complexity required to produce a flat dithering distribution when using a
power-of-2 (2x) number of starting locations, dithering control is limited to four settings; one location (no
dithering), two, four and eight locations. In this case, one, two or three bits of the eight bit PRBS generator
can be used directly, with no division of the random number by the dither amount necessary.
Table 65 Dithering Ranges

Number of
Divide
Random Start Starting UI Delay Range Range from Default Delay
Required?
Positions
1 (no dither) 4 (default) [0] No
2 4-5 [0] [+1] No
3 3-4-5 [-1] [0] [+1] Yes
4 3-4-5-6 [-1] [0] [+1] [+2] No
5 2-3-4-5-6 [-2] [-1] [0] [+1] [+2] Yes
6 2-3-4-5-6-7 [-2] [-1] [0] [+1] [+2] [+3] Yes
7 1-2-3-4-5-6-7 [-3] [-2] [-1] [0] [+1] [+2] [+3] Yes
8 1-2-3-4-5-6-7-8 [-3] [-2] [-1] [0] [+1] [+2] [+3] [+4] No
9 0-1-2-3-4-5-6-7-8 [-4] [-3] [-2] [-1] [0] [+1] [+2] [+3] [+4] Yes
10 0-1-2-3-4-5-6-7-8-9 [-4] [-3] [-2] [-1] [0] [+1] [+2] [+3] [+4] [+5] Yes
1071 In case a HS-BURST is started to issue a real time critical message over the interface, then the random delay
inserted between the “start” signal to the physical interface and the actual start of the BURST adds
uncertainty to the delivery time of the message. In order to produce the least uncertainty for this message, a
default start delay of half of the maximum dither range should be used when dither is disabled. The range of
dither delays is then spread equally around this default delay to produce an uncertainty of approximately plus
or minus one half of the maximum dither range.

Confidential
01-Dec-2016
Annex D Setting of Attributes Values (informative)

1072 The purpose of this informative annex is to provide guidelines for setting attribute values of a MODULE at
one end of a LANE to their corresponding attribute values of a MODULE at the other end of the LANE in
M-PHY applications. Value assignment to the attributes need to be performed in a careful manner in order to
have successful operation of a LANE and thus a LINK. Though every effort has been made to keep attribute
names identical for M-TX and M-RX thus providing guidance to which attribute pairs need to be matched,
for some attributes it might be difficult to deduce values to be set or control. To ensure successful operational
behavior of a LANE after reconfiguration, the protocol above M-PHY needs to analyze the capabilities of
M-PHY MODULEs (through capability attributes) before setting required values to configurable attributes.
1073 This annex is divided into two main sections, a set of attributes that needs to be matched between M-RXs and
M-TXs of a LANE, and a set of attributes that should to be changed when M-PHY speed needs to be changed
with implications for changing certain attributes.
D.1 Attribute Pair Matching for MODULEs of a LANE

1074 Table 66 provides a list of attribute pairs that need to be set to the same value for successful LANE operation.
If an attribute value of a pair is changed to a new value, then the value of matching attribute in the pair also
needs to be changed to the same value. The TX_HIBERN8_Control and RX_Enter_HIBERN8 attributes
need to be matched only when the attribute value is set to one of the corresponding values specified after
“==” sign, otherwise the attribute values do not need to be matched.
Table 66 Attribute Pairs of a LANE to be Matched

M-TX Configuration Attribute M-RX Configuration Attribute
TX_MODE RX_MODE
TX_HSRATE_Series RX_HSRATE_Series
TX_HSGEAR RX_HSGEAR
TX_PWMGEAR RX_PWMGEAR
TX_BYPASS_8B10B_Enable RX_BYPASS_8B10B_Enable
TX_HS_Unterminated_LINE_Drive_Enable RX_HS_Unterminated_Enable
TX_LS_Terminated_LINE_Drive_Enable RX_LS_Terminated_Enable
TX_HIBERN8_Control == ENTER RX_Enter_HIBERN8 == YES
1075 Table 67 lists the M-TX configuration attribute values and their recommended logical relationship with the
corresponding M-RX capability attribute values.
Table 67 Relationship between M-TX Configuration and M-RX Capability Attributes

Logical
M-TX Configuration Attribute M-RX Capability Attribute
Relationship
TX_HS_SYNC_LENGTH  RX_HS_Gn_SYNC_LENGTH_Capability1
TX_HS_PREPARE_LENGTH  RX_HS_Gn_PREPARE_LENGTH_Capability1
TX_LS_PREPARE_LENGTH  RX_LS_PREPARE_LENGTH_Capability
TX_PWM_BURST_Closure_Extension  RX_PWM_BURST_Closure_Length_Capability

Confidential
01-Dec-2016
Table 67 Relationship between M-TX Configuration and M-RX Capability Attributes

Logical
M-TX Configuration Attribute M-RX Capability Attribute
Relationship
Min[RX_Min_ActivateTime_Capability,
TX_Min_ActivateTime 
RX_Advanced_Min_ActivateTime_Capability]
1. n = 1, 2 or 3 and depends on the value of RX_HSGEAR.
1076 OMC Write-only attribute values should be set according to the corresponding M-TX or M-RX configuration
attributes as shown in Table 68. However, since OMC placement with respect to the corresponding
MODULE is not mandated, there could be cases where it is beneficial to set OMC attributes independently.
For example, if the distance between a MODULE and its corresponding OMC is longer on one end of a LINK
than the other, one OMC might need to be unterminated while the other OMC might need to be terminated.
Table 68 Recommended Settings of OMC Write-only Attributes

OMC_Write-only Attribute MODULE Configuration Attribute
MC_Output_Amplitude TX_Amplitude
MC_HS_Unterminated_Enable RX_HS_Unterminated_Enable
MC_LS_Terminated_Enable RX_LS_Terminated_Enable
MC_HS_Unterminated_LINE_Drive_Enable TX_HS_Unterminated_LINE_Drive_Enable
MC_LS_Terminated_LINE_Drive_Enable TX_LS_Terminated_LINE_Drive_Enable
D.2 Attribute Values Changed with LANE Speed Setting

D.2.1 Intra-MODE GEAR Change
1077 The following attribute pairs should be changed when a LANE needs to be switched from one HS_GEAR to
another HS_GEAR (Intra-MODE change), while accommodating the restrictions in Table 66:
1078 • TX_HSGEAR and RX_HSGEAR – for a different HS-GEAR in the same RATE series
1079 • TX_HSRATE_Series and RX_HSRATE_Series – for the same HS-GEAR in a different RATE
series
1080 • TX_HSGEAR and RX_HSGEAR, TX_HSRATE_Series and RX_HSRATE_Series – for a
different HS-GEAR in a different RATE series
1081 TX_PWMGEAR and RX_PWMGEAR attributes should be changed when a LANE needs to be switched
from one LS_GEAR to another LS_GEAR, while accommodating the restrictions in Table 66.
D.2.2 Inter-MODE Gear Change

1082 When LANE settings need to be changed from one MODE to another, the TX_MODE and RX_MODE
attribute values should be changed, while accommodating the restrictions in Table 66, along with the
attribute pairs listed in Section D.2.1 based on the MODE and GEAR being requested.
D.3 Interpretation of Certain Attributes

D.3.1 TX_LCC_Enable
1083 An M-TX should enter SLEEP, STALL or LINE-CFG state based on the value set in TX_LCC_Enable and
requests made to change configuration settings. The M-TX should enter LINE-CFG state upon a TOB
request (M-LANE_BurstEnd.request) from the Protocol Layer if the value of TX_LCC_Enable is set to
“YES” and a configuration request (M-CTRL-CFGSET.request) to any attribute is made, or configuration
ready request (M-CTRL-CFGREADY.request) is issued, prior to the M-TX sending the TOB sequence.

Confidential
01-Dec-2016
Otherwise, the M-TX should enter SLEEP or STALL state based on the current value of TX_MODE upon
getting a TOB request. An M-TX may enter LINE-INIT based only on M-CTRL-CFGSET.request.
D.3.2 TX_PWM_BURST_Closure_Extension
1084 The protocol above the M-TX determines the value of the PWM BURST Closure length for the M-TX from
the RX_PWM_BURST_Closure_Length_Capability value of the M-RX and requirements of the protocols
above the M-RX and M-TX. The RX_PWM_BURST_Closure_Length_Capability value of the M-RX
communicates to the local protocol any extra cycles needed by the PHY to flush the pipeline. In case the
remote protocol requires additional clock cycles for symbol or PAYLOAD processing, the protocol may
adopt any of the following methods.
1085 In the first method, the local protocol at M-TX lengthens PWM-BURST by setting
TX_PWM_BURST_Closure_Extension. The value of TX_PWM_BURST_Closure_Extension should be set
to greater than, or equal to, the sum of the value of RX_PWM_BURST_Closure_Length_Capability and the
number of additional clock cycles required by the remote protocol. The sum of the additional clock cycles
n e e d e d b y t h e r e m o t e p r o t o c o l a t M -R X a n d t h e m a x i m u m l i m i t o f
RX_PWM_BURST_Closure_Length_Capability set by the protocol cannot exceed 255 SI.
1086 In addition, the local protocol at M-TX should get the value of
RX_PWM_BURST_Closure_Length_Capability of the remote M-RX from the remote protocol. Also, the
local protocol at M-TX should get any additional clock cycles required by the remote protocol through
protocol level communication.
1087 In the second method, the local protocol at M-TX inserts the needed number of FILLERs before requesting a
TAIL-OF-BURST sequence, i.e. before issuing M-LANE-BurstEnd.request, at the end of the last PAYLOAD
o f a P W M -B U R S T. T h e l o c a l p r o t o c o l a t M -T X s h o u l d s e t t h e v a l u e o f
TX_PWM_BURST_Closure_Extension to greater than, or equal to, the value of
RX_PWM_BURST_Closure_Length_Capability.
D.3.3 M-TX and M-RX Polarity Control

1088 With the TX_DRIVER_POLARITY and RX_RECEIVER_POLARITY attributes, MPHY provides the
ability to adapt to any potential MPHY LINE-interface pin-swap at the device level and reduces constraints
for routing the high-speed LINE traces on a PCB. Pin swaps and LINE crossing on PCB traces can be
compensated by programming TX_DRIVER_POLARITY and/or RX_RECEIVER_POLARITY according
to the PCB trace polarity.
1089 TX_DRIVER_POLARITY and RX_RECEIVER_POLARITY are system-dependent attributes that are
independent of LINE-RESET. If TX_DRIVER_POLARITY or RX_RECEIVER_POLARITY are changed
to new values by the Protocol after the initial local RESET, the Protocol should change these attribute values
to the new values after a subsequent local RESET is applied and de-asserted, and before M-TX or M-RX is
requested to exit HIBERN8 state.

Confidential
01-Dec-2016
Annex E Guidance for Protocols on Managing LANE-to-LANE

Skew (informative)
1090 This annex provides recommendations for skew parameters in a SUB-LINK with multiple LANEs. As shown
in Figure 78, a SUB-LINK subsystem consists of a LANE management controller and M-TX on the
transmitting side of the SUB-LINK, interconnect, and LANE management controller and M-RX on the
receiving side of the SUB-LINK. The interconnect can be either completely galvanic, or it can contain OMCs
and an optical wave guide.
1091 LANE-to-LANE skew (L2L skew) must be considered in the case where there are multiple LANEs
transmitting data, and where it is desired to optimally reuse hardware in the LANE management controller.
Architecture decisions for the LANE management controller are based on the use of an optimized clocking
mechanism, maximum skew possible between Symbol clocks of data LANEs of multiple RMMIs, shift
register depth requirements, and possibly a de-skewing mechanism to be adopted along with throughput
desired.
1092 M-TX and M-RX skew parameters originate due to clock generation, clock routing skews and analog block
skews due to device mismatches. The total skew can be a combination of UIHS lengths and fixed delays in
terms of propagation time. Interconnect induced skew parameters are generally independent of GEAR, and
are in terms of propagation time. Although this annex does not discuss use-cases involving implementations
with a large number of LANEs within a SUB-LINK, a higher number of LANEs tends to correlate with
increased skew.
1093 Parameters defined in this document pertaining to skew parameters, and the sections where the definitions
can be found, are shown in Table 69.
Table 69 LANE-to-LANE Skew Parameters

Parameter Section Description
HS-TX 5.1.2.4 M-TX in HS-MODE
PWM-TX 5.1.3.3 M-TX in PWM-MODE
SYS-TX 5.1.4.2 M-TX in SYS-MODE
HS-RX 5.2.2.1 M-RX in HS-MODE
PWM-RX 5.2.3.4 M-RX in PWM-MODE
SYS-RX 5.2.4.1 M-RX in SYS-MODE
1094 A graphical representation of the point of measurement for each parameter is shown in Figure 78. A skew
parameter is the aggregate skew possible at the indicated interface in the figure.

Confidential
01-Dec-2016
M-TX HS Skew LINE HS Skew M-RX HS Skew

M-TX PWM Skew LINE PWM Skew M-RX PWM Skew
SUB-LINK
M-PORT M-PORT
LANE
TXDP LINE RXDP
M-TX RMMI M-TX M-RX M-RX RMMI
TXDN RXDN
LANE MANAGEMENT
LANE MANAGEMENT
LANE
TXDP LINE RXDP
TXDN RXDN
LANE
TXDP LINE RXDP
TXDN RXDN
TL2L_SKEW_HS_TX TL2L_SKEW_HS_RX
TL2L_SKEW_TX_RMMI TL2L_SKEW_RX_RMMI
TL2L_SKEW_PWM_TX TL2L_SKEW_PWM_RX
Figure 78 Measurement Points
1095 HS-MODE skew equations:
M-TX HSSkew = T L2L_SKEW_HS_TX – T L2L_SKEW_TX_RMMI (Equation 42)
Interconnect HS Skew = T L2L_SKEW_HS_RX – T L2L_SKEW_HS_TX (Equation 43)
M-RX HSSkew = T L2L_SKEW_RX_RMMI – T L2L_SKEW_HS_RX (Equation 44)
1096 PWM-MODE Skew equations:
M-TX PWM Skew = T L2L_SKEW_PWM_TX – T L2L_SKEW_TX_RMMI (Equation 45)
Interconnect PWM Skew = T L2L_SKEW_PWM_RX – T L2L_SKEW_PWM_TX (Equation 46)
M-RX PWM Skew = T L2L_SKEW_RX_RMMI – T L2L_SKEW_PWM_RX (Equation 47)
1097 Two new parameters are defined in this annex for discussing the LANE-to-LANE skew. The first parameter,
TL2L_SKEW_TX_RMMI, is the LANE-to-LANE skew on the transmitting side of the SUB-LINK, and is defined
as the time difference between the TX_SymbolClk at the M-TX RMMIs in a SUB-LINK. For the purposes of
this annex, an M-TX RMMI is assumed to be a synchronous interface to the M-TX, and as such is considered
the T0 reference plane. Any symbol skew accumulated before TL2L_SKEW_TX_RMMI is not considered.
1098 TL2L_SKEW_RX_RMMI is defined as the time difference between two RX_SymbolClk that qualify reference
data points, e.g., MARKER0, on M-RX-DATA SAP of the M-RX RMMIs in a SUB-LINK.
T L2L_SKEW_RX_RMMI is a design parameter. The LANE management controller needs to respect
TL2L_SKEW_RX_RMMI for implementation of adequate LANE recomposition.

Confidential
01-Dec-2016
1099 Note:
1100 This document does not mandate a clock source synchronous system. In plesiochronous systems,
the RX_SymbolClk at the M-RX RMMI cannot be assumed to show a constant phase relationship
between any two LANEs of the same SUB-LINK.
1101 LANE management controllers at M-RX RMMI and M-TX RMMI have the option to exercise the de-skew
mechanism of multiple LANEs in a given SUB-LINK by using training sequences and offsetting the phase of
the reference clock either at M-RX or at M-TX.
1102 Table 70 shows the L2L skew parameter values for a galvanic-only interconnect, i.e., no OMCs in the LINE,
in a tightly coupled use-case where latency requirements are stringent.
Table 70 L2L Skew Parameters for Tightly Coupled Use-case

Parameter Value
TL2L_SKEW_HS_TX 2 UIHS
TL2L_SKEW_PWM_TX 2 * TPWM_TX
TL2L_SKEW_HS_RX 2 UIHS + 33 ps
TL2L_SKEW_PWM_RX 2 * TPWM_TX + 33 ps
HS-MODE 5 UIHS
TL2L_SKEW_RX_RMMI
PWM-MODE 5 * TPWM_RX
1103 In order to ensure interoperability between an M-PORT and a LANE management controller, the LANE
management controller should be able to de-skew by at least ±1 SI at the M-RX RMMI.
1104 In this first example, a short interconnect ( 10 cm) using galvanic LINEs on a FR4-class PCB, travel time is
about 6 ps  mm . From Table 70, the skew interconnect margin is 33 ps, which provides about 5 mm of
physical length mismatch ( 33 ps  6 ps/mm  5 mm ) over 10 cm, or about 5%, for a worst case interconnect.
Interconnect skew parameters are GEAR independent. Note, the UIHS values shown in Table 70 apply for all
modes of communication.
1105 Table 71 shows the L2L skew parameter values for another galvanic-only interconnect in a nominally
coupled use-case where latency requirements are less stringent than in the previous example.
Table 71 L2L Skew Parameters for Nominally Coupled Use-case

Parameter Value
TL2L_SKEW_HS_TX 10 UIHS
TL2L_SKEW_HS_G4_TX 20 UIHS
TL2L_SKEW_PWM_TX 10 TPWM_TX
TL2L_SKEW_HS_RX 30 UIHS
TL2L_SKEW_HS_G4_RX 60 UIHS
TL2L_SKEW_PWM_RX 30 TPWM_TX
40 UIHS @ HS-G1, HS-G2, HS-G3
HS-MODE
TL2L_SKEW_RX_RMMI 80 UIHS @ HS-G4
PWM-MODE 40 TPWM_RX

Confidential
01-Dec-2016
1106 In the second example, a long interconnect can use galvanic LINEs on a FR4-class PCB for LINEs not
exceeding 30 cm, and even longer LINEs using OMCs and an optical wave guide.
1107 Using the same travel time approximation as in the previous example, a 30 cm interconnect with a 50 mm
physical length mismatch has a corresponding interconnect skew of 50 mm  6 ps/mm = 300 ps .
1108 In the case where LANEs contain OMCs, the OMC contribution to LANE-to-LANE skew must also be
considered. LANE-to-LANE skew analysis for an OMC includes all elements of the LINE between the
M-TX PINs and M-RX PINs, including the O-TX, optical waveguide, O-RX, and galvanic interconnect to
each end of the OMC. Therefore, in multi-LANE SUB-LINKs where OMCs are used, the OMC
LANE-to-LANE skew should be used as the interconnect skew value.
1109 OMC LANE-to-LANE skew is due to propagation delay mismatches that are largely independent of
HS-GEAR. Therefore, LANE-to-LANE skew (in UIHS) increases for higher HS-GEARs. The scaling factor
provided in Table 72 is used to determine the OMC LANE-to-LANE skew based on the highest HS-GEAR
supported.
1110 The first example, O1, assumes OMCs (electronics and optical waveguide) are independent components, i.e.,
multiple O-TX and O-RX circuits within a SUB-LINK are on separate silicon, and the optical waveguides for
each LANE are independent, so part-to-part mismatch is considered. For this use-case, OMCs could come
from different manufacturing lots, so process variation is considered; temperature and power supply voltage
are assumed to be similar between OMCs.
1111 This use-case assumes that OMCs have the maximum allowable propagation delay (TOMC-PropDelay) of 50 ns,
8
which is equivalent to a waveguide length of about 10 m (speed of light in fiber is approximately 2 10 m/s ).
1112 In the second example, O2, OMCs (electronics and optical waveguide) are also independent components, i.e.,
multiple O-TX and O-RX circuits within a SUB-LINK are on separate silicon, with shorter optical
waveguide length (< 1 m), and therefore, reduced length mismatch.
1113 In the final example, O3, OMCs (electronics and optical waveguide) are “matched” modules, i.e., multiple
O-TXs and O-RXs are integrated onto the same silicon, from the same manufacturing lot, or steps have been
taken to limit the maximum LANE-to-LANE skew. The matching of the optical waveguide length is also
optimized for this case.
1114 Note:
1115 Each of these use-cases assumes OMCs within a SUB-LINK come from the same manufacturer.
1116 The LANE-to-LANE skew parameters for the three OMC use-cases are of the order shown in Table 72.
Table 72 L2L Skew Parameters Optical Media Use-cases

SKEWL2L_OMC1
Example Use-case
HS-G1 (SKEWOMC-G1) HS-G2 HS-G3
O1 (Easily Achievable) 2.21 UIHS 4.42 UIHS 8.84 UIHS
O2 (“Typical”) 1.48 UIHS 2.96 UIHS 5.92 UIHS
O3 (“Optimized”) 0.68 UIHS 1.36 UIHS 2.72 UIHS
1. Skew values are scaled per HS-GEAR using SKEWL2L_OMC = SKEWOMC-G1 * 2(HS-GEAR - 1)
1117 In the case of PWM-MODE, Example Case O1 results in OMC skew of 2  TPWM_RX for PWM-G6 and
PWM-G7, while an OMC skew value of TPWM_RX can be used for GEARs PWM-G5 and below. An OMC
skew of TPWM_RX can be used for all PWM GEARs in example use-cases O2 and O3.
1118 Regardless of which OMC example case is considered, the implementer should confirm SKEWL2L_OMC
values with the OMC vendor in order to verify that the required LANE-to-LANE skew is supported.

Confidential
01-Dec-2016

Confidential
01-Dec-2016
Annex F Guidance for Protocols on Managing ADAPT Sub-State

and RX Equalization (informative)
1119 The purpose of the ADAPT sequence is to train an M-RX equalizer to adapt its filter characteristics to the
channel. The properties of a channel depend predominantly on the material characteristics of the printed
circuit board, the package and bonding material, the line length, and potential connectors involved. In
addition to these mostly time-invariant properties, the channel characteristics may be influenced by
temperature and voltage variations.
F.1 When to Use ADAPT

1120 The specification does not mandate the use of ADAPT sequences. A protocol running on top of M-PHY
should implement provisions to initiate the ADAPT sub-state, but should not enforce the use of ADAPT.
1121 In general, a long length Initial ADAPT sequence is intended only for the first M-RX calibration after power
up, to train the M-RX equalizer onto the channel and M-TX characteristics. The Initial ADAPT sequence can
also be used by the protocol when handling fatal Link error recovery.
1122 A Refresh ADAPT sequence is much shorter than an Initial ADAPT sequence. Refresh ADAPT is intended
to compensate for temperature and voltage drifts in the channel by incrementally adjusting the equalizer
settings. However, a protocol may not always need to do this, particularly under the following conditions:
1123 • The M-RX implementation can guarantee signal reception under worst-case channel conditions,
specifically when an application uses a low-loss channel.
1124 • Temperature and voltage drifts are compensated sufficiently by the implementation.
1125 An embedded application may not require an Initial ADAPT training sequence. For example, if the optimal
equalizer settings are determined during laboratory bring-up and restored using vendor-specific sideband
programming any time the Link enters operation in HS-G4.
1126 At the expense of additional power consumption, an M-RX may not need Refresh ADAPT training. It may
continuously or periodically re-adapt its equalizer using information from toggling activities during an HS-
BURST.
1127 There is no requirement to initiate ADAPT after HIBERN8 exit, as the equalizer settings are retained during
HIBERN8. However, a Refresh ADAPT can be required after a lengthy HIBERN8 due to temperature and
voltage drift.
1128 A protocol should initiate ADAPT after a change, which affects the signal waveform, e.g., the M-TX
equalizer settings, the M-TX amplitude setting, or a HS RATE series change.
F.2 Detecting the Need for ADAPT

1129 The M-PHY ADAPT sequence is an open-loop training. This specification does not define a means for an
M-TX to detect if the M-RX equalizer training is successful. It is assumed that an M-RX receives data with
the defined BER at the end of an ADAPT sequence. However, the protocol needs to ensure that channel
degradations are monitored at the M-RX and that this information may be used by the peer M-TX to trigger
an ADAPT sequence.
F.3 ADAPT Sequences in Lower HS-GEARS

1130 This specification defines ADAPT for use in the HS-G4 RATE series A and B only.
F.4: See Errata 01, Item 1

Confidential
01-Dec-2016
Participants
The list below includes those persons who participated in the Working Group that developed this Specification
and who consented to appear on this list.
Radha Atukula, NVIDIA Ofir Michaeli, Cadence Design Systems, Inc.

Seok-Keun Choi, Keysight Technologies Inc. Raj Kumar Nagpal, Synopsys, Inc.
Ralf Gaisbauer, Toshiba Corporation Victor Sanchez-Rico, BitifEye Digital Test Solutions
GmbH
Abdelaziz Goulahsen, STMicroelectronics
Bill Simms, NVIDIA
Ramesh Hanchinal, Synopsys, Inc.
Jurgen Urban, Toshiba Corporation
Henrik Icking, Intel Corporation
The list below includes those persons who participated in the Working Group that developed this Specification
up to version 4.0 and who consented to appear on this list.
Ahmed Aboulella, Mixel, Inc. James Jaussi, Intel Corporation

Bhupendra Ahuja, NVIDIA Robert C Johnson, IEEE-ISTO (staff)
Radha Atukula, NVIDIA Anant Shankar Kamath, Texas Instruments
Incorporated
Andrew Baldman, UNH-IOL
Marcin Kowalewski, Synopsys, Inc.
Johannes Baston, Renesas Electronics Corporation
Luke Lai, NVIDIA
Paul E Berg, MCCI Corporation
Michal Lewandowski, Synopsys, Inc.
Cedric Bertholom, STMicroelectronics
Jiri Macku, Silicon Line GmbH
Gerrit den Besten, NXP Semiconductors
Thomas Marik, BitifEye Digital Test Solutions,
George Brocklehurst, Mindspeed Technologies, Inc.
GmbH
Thierry Campiche, LeCroy Corporation
Patrick Mone, Texas Instruments Incorporated
Mara Carvalho, Synopsys, Inc.
Marcus Muller, Nokia Corporation
Ninous Davoudi, Mixel, Inc.
Raj Kumar Nagpal, Synopsys, Inc.
Kirill Dimitrov, SanDisk Corporation
Long Nguyen, Mixel, Inc.
Dan Draper, Mindspeed Technologies, Inc.
Berndt Pilgram, Intel Corporation
Ken Drottar, Intel Corporation
Vipul Raithatha, Texas Instruments Incorporated
Mahmoud El-Banna, Mixel, Inc.
Parthasarathy Raju, Tektronix, Inc.
Michael Fleischer-Reumann, Keysight
Juha Rakkola, Nokia Corporation
Technologies, Inc.
P.E. Ramesh, Tektronix, Inc.
Ralf Gaisbauer, Toshiba Corporation
James Rippie, IEEE-ISTO (staff)
Joaquim Gomes, Synopsys, Inc.
Jose Sarmento, Synopsys, Inc.
Will Harris, Advanced Micro Devices, Inc.
Roland Scherzinger, Keysight Technologies, Inc.
Ols Hidri, Silicon Line GmbH
Marcus Schorpp, Nokia Corporation
Michael Herz, Research in Motion Ltd
Sridhar Shashidharan, Arasan Chip Systems, Inc.
Henrik Icking, Intel Corporation

Confidential
01-Dec-2016
Sergio Silva, Synopsys, Inc. Martti Voutilainen, Nokia Corporation

Bill Simms, NVIDIA Manuel Weber, Toshiba Corporation
Vikas Sinha, Texas Instruments Incorporated Heiner Wiese, Toshiba Corporation
Bob Trocke, Motorola Mobility, Inc. Victor Wilkerson, Skyworks Solutions, Inc.
Jurgen Urban, Toshiba Corporation Richard Williams, Texas Instruments Incorporated
Aravind Vijayakumar, Cadence Design Systems,
Inc.

Confidential

Mipi M-PHY Specification V4-1-Er01

Uploaded by

Copyright:

Available Formats

Mipi M-PHY Specification V4-1-Er01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mipi M-PHY Specification V4-1-Er01

Uploaded by

Copyright:

Available Formats

Errata 01 Errata for MIPI M-PHY Specification v4.

Specification Version 4.1

Errata 01 Dated 14 May 2018

* IMPORTANT NOTE TO IMPLEMENTERS *

Copyright © 2018 MIPI Alliance, Inc.

2 Copyright © 2018 MIPI Alliance, Inc.

F.4 ADAPT Sequence

Figure 79 One ADAPT Sequence before 8b10b Encoding

Figure 81 Start and End of Serialized 8b10b Encoded ADAPT Sequence

Copyright © 2018 MIPI Alliance, Inc. 3

This page intentionally left blank.

4 Copyright © 2018 MIPI Alliance, Inc.

Version 4.1 – 01 December 2016

Copyright © 2008-2017 MIPI Alliance, Inc.

This page intentionally left blank.

Copyright © 2008-2017 MIPI Alliance, Inc.

C SI Dithering (informative) 193

Copyright © 2008-2017 MIPI Alliance, Inc.

ii Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. iii

5.1.1 Common M-TX Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iv Copyright © 2008-2017 MIPI Alliance, Inc.

8.2.5 M-LANE-PREPARE.indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Copyright © 2008-2017 MIPI Alliance, Inc. v

Annex B Recommended Test Functionality (informative) . . . . . . . . . . . . . . . . . . . 188

vi Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. vii

Figure 33 Impact of Signal Skew on Common-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

viii Copyright © 2008-2017 MIPI Alliance, Inc.

Figure 66 M-RX Signal Interfaces Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Copyright © 2008-2017 MIPI Alliance, Inc. ix

x Copyright © 2008-2017 MIPI Alliance, Inc.

Table 36 OMC M-PHY Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Copyright © 2008-2017 MIPI Alliance, Inc. xi

xii Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. 1

2 Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. 3

36 FLAG Control signal that indicates the occurrence of a certain event.

4 Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. 5

94 O-RX Optical Receiver

6 Copyright © 2008-2017 MIPI Alliance, Inc.

Copyright © 2008-2017 MIPI Alliance, Inc. 7

This page intentionally left blank.

8 Copyright © 2008-2017 MIPI Alliance, Inc.

4 Architecture and Operation

4.1 PIN, LINE, LANE, SUB-LINK, LINK, and M-PORT

Figure 1 M-PHY Lane Example

Copyright © 2008-2017 MIPI Alliance, Inc. 9

Figure 2 Example LANE Configuration with Media Converter

4.2 LINE States

Table 1 LINE Conditions and Resulting LINE States

10 Copyright © 2008-2017 MIPI Alliance, Inc.

4.2.1 Termination Scheme

RHOLD RDIFF_RX/2 RDIFF_RX/2 RHOLD

Figure 3 Example I/O Termination

4.2.2 Signal Amplitudes

4.3 Signaling Schemes