diiva specification 1.1 draft a informational version ...diiva specification 1.1 draft a -...

DIGITAL INTERACTIVE INTERFACE FOR VIDEO & AUDIO

Title

DiiVA Specification 1.1 Draft A - Informational Version

Author

DiiVA Promoters Group (Changhong, Haier, Hisense, Konka, Panda, Samsung, Skyworth, SVA, Synerchip, TCL)

Status

Draft A

This Informational Version document is provided for review by thThe unabridged version of this document more information on becoming a DiiVA Adopter

Copyright © 2009 DiiVA Promoters Groupelectronic file, to make a copy and to print the content for the sole purpose of reviewing the document. You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without permission in wr

DIGITAL INTERACTIVE INTERFACE FOR

DiiVA Specification 1.1 Draft A Informational Version

DRAFT TECHNICAL SPECIFICATION

Distribution Date

7 January 2010

Comment Period Termination Date

28 February

Supersedes document

DiiVA Specification 1.0a

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. ITSHOULD NOT BE USED FOR REFERENCE PURPOSES.

RECIPIENTS OF THIS DOCUMENT ARE INVITED TO SUBMIT THEIR COMMPRIOR TO THE COMMENT PERIOD TERMINATION DATE

Informational Version

(Changhong, Haier, Hisense, Konka, Panda, Samsung, Skyworth,

This Informational Version document is provided for review by those considering becoming DiiVA Adopters. The unabridged version of this document will be available to DiiVA Adopters. Please visit www.diiva.org for more information on becoming a DiiVA Adopter

DiiVA Promoters Group. All rights reserved. It is permitted to doelectronic file, to make a copy and to print the content for the sole purpose of reviewing the document. You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without permission in writing from the DiiVA Promoters Group.

DiiVA Specification 1.1 Draft A -Informational Version

DRAFT TECHNICAL SPECIFICATION

Comment Period Termination Date

February 2010

UBJECT TO CHANGE. IT

TO SUBMIT THEIR COMMENTSATE.

(Changhong, Haier, Hisense, Konka, Panda, Samsung, Skyworth, Sony,

ose considering becoming DiiVA Adopters. available to DiiVA Adopters. Please visit www.diiva.org for

. All rights reserved. It is permitted to download this electronic file, to make a copy and to print the content for the sole purpose of reviewing the document. You may not copy or "mirror" the file or printed version of the document, or any part of

iting from the DiiVA Promoters Group.

DiiVA 1.1 Draft A – Informational Version – 2 – DiiVA Promoters Group:2010

CONTENTS

FOREWORD ........................................................................................................................ 11

DOCUMENT REVISION HISTORY ....................................................................................... 13

1 Scope ............................................................................................................................ 14

2 Normative references ..................................................................................................... 15

3 Terms, definitions and abbreviations .............................................................................. 16

3.1 Terms and definitions............................................................................................ 16

3.2 Abbreviations and Acryonyms ............................................................................... 17

3.3 Presentation convention........................................................................................ 18

4 Overview........................................................................................................................ 20

4.1 DiiVA Capabilities ................................................................................................. 20

4.2 DiiVA Architecture and Topology........................................................................... 21

4.3 DiiVA Layered Definition ....................................................................................... 23

5 Physical Layer ............................................................................................................... 24

5.1 Physical Layer Operational Overview .................................................................... 24

5.2 Hybrid Link PHY.................................................................................................... 25

5.2.1 Hybrid Link PHY Electrical Sub-layer......................................................... 25

5.2.2 Hybrid Link PHY Logical Sub-layer ............................................................ 27

5.2.3 Hybrid Link PHY Management ................................................................... 28

5.3 Video Link PHY..................................................................................................... 29

5.3.1 Video Link PHY Electrical Sub-layer .......................................................... 29

5.3.2 Video Link PHY Logical Sub-layer ............................................................. 31

5.3.3 Video Relay Modes ................................................................................... 32

5.3.4 Video Relay Mode Control......................................................................... 34

5.3.5 Video Link PHY Management .................................................................... 34

5.4 Detailed Electrical Specifications .......................................................................... 34

5.4.1 Common Hybrid Link and Video Link Requirements .................................. 34

5.4.2 Hybrid Link Transmitter Specification ........................................................ 35

5.4.3 Hybrid Link Receiver Specification ............................................................ 36

5.4.4 Video Link Transmitter Specification ......................................................... 37

5.4.5 Video Link Receiver Specification ............................................................. 38

6 Link Layer – Video Link .................................................................................................. 40

6.1 Video Data Flow of Video Source .......................................................................... 40

6.1.1 Color Component Packer .......................................................................... 41

6.1.2 Video Link Transport Assembly ................................................................. 41

6.1.3 Scrambler ................................................................................................. 41

6.1.4 ANSI 8b10b Encoder ................................................................................. 41

6.1.5 10-bit to 1-bit Serializer ............................................................................. 41

6.2 Video Data Flow of DiiVA Sink .............................................................................. 41

6.3 Video Transport .................................................................................................... 42

6.3.1 Control Sequences .................................................................................... 42

6.3.2 Timing Information Byte (TIB).................................................................... 42

6.3.3 Field Info Packet (FIP) .............................................................................. 43

6.3.4 Start of Subsidiary Packet (SOS) .............................................................. 44


6.4 Video Packing and Lane Selection ........................................................................ 44

6.4.1 Pixel and Color Component Bit Widths and Pixel Encoding ....................... 44

6.4.2 Pixel and Symbol Frequencies .................................................................. 45

6.4.3 Number of Lanes....................................................................................... 45

6.4.4 Color Component Packing ......................................................................... 45

6.4.5 Pixel Packing Examples ............................................................................ 46

6.4.6 Other (16/36/48-bpp) Pixel Packing ........................................................... 46

6.4.7 Video Colorimetry...................................................................................... 46

6.4.8 xvYCC Support ......................................................................................... 46

7 Link Layer – Hybrid Link................................................................................................. 47

7.1 Hybrid Link Overview ............................................................................................ 47

7.2 DiiVA Device Address (DDA) ................................................................................ 47

7.3 Subchannels ......................................................................................................... 47

7.3.1 Audio Subchannel ..................................................................................... 47

7.3.2 Command Subchannel .............................................................................. 47

7.3.3 Guaranteed and Best Effort Data Subchannel ........................................... 48

7.3.4 Transmission Terminals for Each Subchannel ........................................... 48

7.4 Packet Format ...................................................................................................... 48

7.4.1 Device Addressing (DEST_DDA, INIT_DDA) ............................................. 49

7.4.2 Subchannel ID (CH_ID) and Service ID (SID) ............................................ 49

7.4.3 Flags......................................................................................................... 50

7.4.4 Time-to-Live (TTL) .................................................................................... 51

7.4.5 Receiver Readiness (CH_RDY) ................................................................. 51

7.4.6 Payload and Payload Length (PAYLOAD and LEN) ................................... 52

7.4.7 CRC-32 ..................................................................................................... 52

7.5 Packet Flow Control .............................................................................................. 53

7.5.1 IDLE Packet .............................................................................................. 53

7.5.2 State Diagram for Sender/Receiver Mode Change .................................... 54

7.5.3 Basic Packet Flow ..................................................................................... 54

7.5.4 Packet Flow for Link Error Recovery ......................................................... 57

7.6 Quality of Service.................................................................................................. 59

7.6.1 Reliable Transfer: Error Detection ............................................................. 59

7.6.2 Subchannel Arbitration and Priority ........................................................... 60

7.7 Command Subchannel .......................................................................................... 61

7.8 Data Subchannel .................................................................................................. 62

8 DiiVA Control Layer (DCL) ............................................................................................. 63

8.1 Hybrid Link Addressing ......................................................................................... 63

8.2 Examples of a DiiVA Network................................................................................ 63

8.2.1 Source and Sink Only................................................................................ 63

8.2.2 Daisy Chain Device ................................................................................... 64

8.2.3 DiiVA Switch ............................................................................................. 65

8.3 Device Discovery .................................................................................................. 65

8.3.1 Capabilities List Structure ......................................................................... 65

8.3.2 Routing Table Management....................................................................... 65

8.3.3 Network Topology ..................................................................................... 66


8.4 DiiVA Control Layer Overview ............................................................................... 66

8.4.1 DCL Packet Format ................................................................................... 66

8.5 Basic DCL Packets ............................................................................................... 68

8.6 Capability Sections ............................................................................................... 68

9 Audio/Video Application Layer........................................................................................ 69

9.1 Video .................................................................................................................... 69

9.1.1 Video Format Requirements ...................................................................... 69

9.1.2 Enhanced Colorimetry Support .................................................................. 70

9.1.3 Video Stream Management ....................................................................... 70

9.2 Audio .................................................................................................................... 70

9.2.1 Audio Format Requirements ...................................................................... 70

9.2.2 Audio Subchannel ..................................................................................... 72

9.2.3 Audio Stream Management ....................................................................... 79

9.2.4 Packets for Audio Stream Management ..................................................... 79

9.3 A/V Synchronization.............................................................................................. 79

9.4 DiiVA A/V Content Protection Options ................................................................... 79

9.4.1 Content Protection Recommendation ........................................................ 79

9.4.2 HDCP 2.0.................................................................................................. 79

9.4.3 DTCP-IP ................................................................................................... 79

9.5 DiiVA Equipment Control (DEC) ........................................................................... 79

9.5.1 DEC Interoperability Rules ........................................................................ 79

9.5.2 DEC Overview........................................................................................... 79

9.5.3 DEC Packet in DCL Packet ....................................................................... 80

9.5.4 DEC Packets ............................................................................................. 81

10 USB Application Layer ................................................................................................... 85

10.1 Requirements – USB............................................................................................. 85

10.2 USB Relay Support ............................................................................................... 85

10.3 USB Data Service ................................................................................................. 85

11 Ethernet Application Layer ............................................................................................. 87

11.1 Requirements – Ethernet ...................................................................................... 87

11.2 Ethernet Data Service ........................................................................................... 87

12 Power over DiiVA (PoD) ................................................................................................. 88

12.1 PoD Overview ....................................................................................................... 88

12.1.1 Power States............................................................................................. 88

12.2 DiiVA Topologies and PoD Domains ..................................................................... 88

12.3 PoD Implementation.............................................................................................. 89

12.3.1 Board Level Implementation ...................................................................... 90

12.3.2 Link Level Implementation......................................................................... 90

13 Connectors and Cable Assemblies ................................................................................. 91

13.1 Physical Specifications ......................................................................................... 91

13.1.1 Pin assignment ......................................................................................... 91

13.1.2 Contact Sequence..................................................................................... 91

13.1.3 Connectors ............................................................................................... 92

13.1.4 Cable Construction.................................................................................... 98

13.1.5 Wire Assignment ....................................................................................... 99


13.1.6 Cable Wire Connection............................................................................ 100

13.2 Electrical Requirements ...................................................................................... 101

13.2.1 Connector and Cable Assembly Electrical Performance .......................... 101

13.2.2 Cable Assembly Signal Integrity Requirements ....................................... 101

13.3 Mechanical and Environmental Requirements ..................................................... 104

13.3.1 Mechanical Performance ......................................................................... 104

13.3.2 Environmental Performance .................................................................... 106


FIGURES

Figure 1 Simplified Diagram of DiiVA Link ............................................................................ 21

Figure 2 Daisy-chain topology of DiiVA................................................................................. 22

Figure 3 DiiVA Source Internal Layers .................................................................................. 22

Figure 4 DiiVA Layered Implementation ................................................................................ 23

Figure 5 DiiVA Link Electrical Connection Diagram............................................................... 24

Figure 6 DiiVA PHY Sub-layer Diagram ................................................................................ 25

Figure 7 Hybrid Link Eye Diagram at TP1 ............................................................................. 26

Figure 8 Hybrid Link Eye Diagram at TP2 after Reference Equalizer .................................... 27

Figure 9 Hybrid Link Bit Stream Format ................................................................................ 28

Figure 10 DiiVA Test Points.................................................................................................. 30

Figure 11 Video Link Eye Diagram at TP1 ............................................................................ 31

Figure 12 Video Link Eye Diagram at TP2 After Reference Equalizer ................................... 31

Figure 13 Circuit Diagram of Resampling Mode Device (Informative) .................................... 33

Figure 14 Circuit Diagram of Buffering Mode Device (Informative) ........................................ 34

Figure 15 Circuit Diagram of Bypassing Mode Device (Informative) ...................................... 34

Figure 16 Frequency Characteristics of Reference Cable Equalizer ...................................... 35

Figure 17 Logical Pipe Order of Link Layer and Physical Layer of Video Source................... 40

Figure 18 Logical Pipe Order of Link Layer and Physical Layer of DiiVA Sink ....................... 42

Figure 19 Video Frame in Video Link .................................................................................... 42

Figure 20 DiiVA Device Address Format ............................................................................... 47

Figure 21 Transmission Terminals for Each Subchannel in Hybrid Link ................................ 48

Figure 22 Definition of LEN [15..0] in Packet ........................................................................ 52

Figure 23 Location of CRC-32 .............................................................................................. 52

Figure 24 Examples of Packet Flow ...................................................................................... 54

Figure 25 State Diagram for Sender/Receiver Mode Change in Hybrid Link .......................... 54

Figure 26 Example of Packet Flow when the DS Audio Subchannel is Used ......................... 55

Figure 27 Example of Packet Flow when the US Audio Subchannel is Used ......................... 55

Figure 28 Example of Packet Flow when the US Command Subchannel is Used .................. 55

Figure 29 Example of Packet Flow when both the DS Audio Subchannel and the US Command Subchannel are Used .......................................................................................... 56

Figure 30 Example of Packet Flow with Arbitration ............................................................... 56

Figure 31 Example of Packet Flow when Receiving Terminal is not Ready ........................... 57

Figure 32 Example of Packet Flow when Receiving Terminal is not Ready ........................... 57

Figure 33 Example of Packet Flow when CRC Doesn’t Match ............................................... 58

Figure 34 Example of Packet Flow when Timeout Occurs ..................................................... 58

Figure 35 Example of Packet Flow when Toggle Bit Mismatches .......................................... 59

Figure 36 CMD Packet Format for the Command Subchannel............................................... 62

Figure 37 DATA Packet Format for the Data Subchannel...................................................... 62


Figure 38 Basic DiiVA Devices ............................................................................................. 63

Figure 39 DiiVA Daisy Chain Device ..................................................................................... 64

Figure 40 DiiVA Switch Device ............................................................................................. 65

Figure 41 AUDIO Packet Format in the Audio Subchannel .................................................... 73

Figure 42 Audio Data Format for Linear PCM ....................................................................... 74

Figure 43 Audio Data Format for Non-PCM........................................................................... 75

Figure 44 Audio Data Format for DSD .................................................................................. 76

Figure 45 Audio Data Format for DST................................................................................... 76

Figure 46 USB Relay Packet Switched Connection ............................................................... 85

Figure 47 USB Ecosystem with DiiVA Network ..................................................................... 86

Figure 48 USB Block Diagram in DiiVA................................................................................. 86

Figure 49 Sample DiiVA Interconnections ............................................................................. 89

Figure 50 Sample DiiVA PoD Interconnect............................................................................ 89

Figure 51 Receptacle Connector Interface Dimensions ......................................................... 92

Figure 52 Reference Receptacle Connector Footprint (Informative) ...................................... 93

Figure 53 Plug Connector Interface Dimensions (Part 1) ...................................................... 94

Figure 54 Plug Connector Interface Dimensions (Part 2) ...................................................... 95

Figure 55 Plug Connector with Active Latches ...................................................................... 96

Figure 56 Fully Mated Space between Receptacle and Plug Overmold ................................. 96

Figure 57 Cable Bend........................................................................................................... 97

Figure 58 Bulk Cable Construction Examples (Informative)................................................... 98

Figure 59 Plug Connector ................................................................................................... 100

Figure 60 Cable Assembly Test Points ............................................................................... 102

Figure 61 NEXT Requirement ............................................................................................. 103

Figure 62 Attenuation Requirement .................................................................................... 103

Figure 63 Cable Return Loss Requirement ......................................................................... 104


TABLES

Table 1 Hybrid Link Speeds.................................................................................................. 25

Table 2 Hybrid Link Jitter Budget .......................................................................................... 26

Table 3 Video Link Jitter Budget ........................................................................................... 30

Table 4 Comparison of DiiVA Video Relay Modes................................................................. 32

Table 5 Hybrid Link Transmitter Specifications ..................................................................... 36

Table 6 Hybrid Link Receiver Specifications ......................................................................... 37

Table 7 Video Link Transmitter Specifications ...................................................................... 38

Table 8 Video Link Receiver Specifications .......................................................................... 39

Table 9 Timing Information Byte (TIB) Definition................................................................... 43

Table 10 Field Information Packet Definition......................................................................... 43

Table 11 Field Information Packet Format for HDCP 2.0 ....................................................... 44

Table 12 Relationship Between Pixel Encoding and Components ......................................... 45

Table 13 Symbol Frequency vs. Pixel Frequency.................................................................. 45

Table 14 DiiVA Video Colorimetry Support Requirement....................................................... 46

Table 15 Hybrid Link Packet Format ..................................................................................... 49

Table 16 Subchannel IDs and Service IDs ............................................................................ 50

Table 17 Flags Field ............................................................................................................. 50

Table 18 Examples of CRC-32.............................................................................................. 52

Table 19 Required QoS for Each Subchannel ....................................................................... 59

Table 20 Parameters for Link Statistics ................................................................................ 60

Table 21 Packet Transfer Priority ......................................................................................... 61

Table 22 Capabilities (Caps) List Format in Heartbeat Packet .............................................. 65

Table 23 DCL Packet Format................................................................................................ 66

Table 24 Basic DCL Packets ................................................................................................ 67

Table 25 Video Circuit Management Packets ........................................................................ 67

Table 26 Audio Connection Management Packets ................................................................ 67

Table 27 USB Connection Management Packets .................................................................. 68

Table 28 SSINFO Field Definitions in AUDIO Packet ............................................................ 73

Table 29 Recommended Audio Data Size for PCM ............................................................... 74

Table 30 Recommended Audio Data Size for Non-PCM........................................................ 74

Table 31 Field Definitions in IEC Audio Data Format ............................................................ 75

Table 32 Field Definitions in Packed IEC-61937 Audio Data Format ..................................... 75

Table 33 Field Definitions in DSD Audio Data Format ........................................................... 76

Table 34 Field Definitions in DST Audio Data Format ........................................................... 77

Table 35 Audio Control General Format................................................................................ 77

Table 36 Audio Control Format for AV_SEQ ......................................................................... 77

Table 37 Audio Control Format for HDCP 2.0 Link Synchronization ...................................... 78

Table 38 Supported Audio Sampling Frequencies................................................................. 78


Table 39 DEC Packet Bytes Description ............................................................................... 80

Table 40 Remote Device Control Request Packet Description .............................................. 80

Table 41 Remote Device Control Request Packet Format ..................................................... 80

Table 42 Remote Device Control Response Packet Description............................................ 81

Table 43 Remote Device Control Response Packet Format .................................................. 81

Table 44 Error Response Description ................................................................................... 81

Table 45 DEC Command Groups .......................................................................................... 82

Table 46 DEC General Commands ....................................................................................... 82

Table 47 DEC Navigation Commands ................................................................................... 82

Table 48 DEC Tuner Commands .......................................................................................... 83

Table 49 DEC Recorder Commands ..................................................................................... 83

Table 50 DEC Player Commands ......................................................................................... 83

Table 51 DEC Audio Commands .......................................................................................... 83

Table 52 DEC Closed Captioning Commands ....................................................................... 84

Table 53 DiiVA Power States................................................................................................ 88

Table 54 Connector and Cable Assembly Pin assignment..................................................... 91

Table 55 Connector Contact Sequence................................................................................. 91

Table 56 Cable Wire Assignments ........................................................................................ 99

Table 57 Cable Wire Connection ........................................................................................ 100

Table 58 Connector Electrical Performance ........................................................................ 101

Table 59 Cable Assembly Signal Integrity Requirement ...................................................... 102

Table 60 Connector and Cable Assembly Mechanical Performance .................................... 105

Table 61 Connector and Cable Assembly Environmental Performance ............................... 106


DIGITAL INTERACTIVE INTERFACE FOR VIDEO & AUDIO

____________

DiiVA Specification 1.1 Draft A - Informational Version –


FOREWORD

Access to this DiiVA Specification 1.1 Draft A - Informational Version was obtained through the agreement of the recipient of the following terms. If you have received this DiiVA Specification other than by agreeing to the terms and conditions for access from the DiiVA website, you hereby agree to the following terms:

Terms and Conditions of Use

IMPORTANT! PLEASE READ THIS LEGAL STATEMENT CAREFULLY. THIS AGREEMENT (THE "AGREEMENT") IS A LEGALLY BINDING AGREEMENT BETWEEN YOU ON BEHALF OF YOURSELF AND, IF YOU ARE USING THE SPECIFICATION IN A PROFESSIONAL CAPACITY, YOUR EMPLOYER (COLLECTIVELY "RECIPIENT" OR "YOU"), AND DIIVA LICENSING LLC ("AGENT") ACTING AS AGENT FOR THE DIIVA PROMOTERS. BY CLICKING ON THE "I AGREE" BUTTON, OR BY OTHERWISE DOWNLOADING OR USING THE SPECIFICATION, YOU ARE INDICATING THAT YOU HAVE READ THIS AGREEMENT, THAT YOU UNDERSTAND IT, AND THAT YOU CONSENT TO BE BOUND BY ALL OF ITS TERMS AND CONDITIONS. IF APPLICABLE AS SET FORTH ABOVE, YOU REPRESENT AND WARRANT THAT YOU ARE AUTHORIZED TO ACCEPT THIS AGREEMENT ON YOUREMPLOYER'S BEHALF.

Ownership - This site, and your access to the DiiVA Specification 1.1 Draft A - Informational Version (the “DiiVA Specification” OR “Specification”), is being permitted by Agent to allow you to determine if you wish to enter into an adopters agreement with respect to the DiiVA Specification (the “Purpose”). This site and all perceptible components hereof, including without limitation the DiiVA Specification, text, images and audio, are copyrighted by the DiiVA Promoters. To obtain a license to utilize the DiiVA Specification you must execute a written Adopter Agreement with the Agent. No other rights or license, express or implied, are granted. All right, title and interest in and to the Specification is and shall remain the sole and exclusive property of the DiiVA Promoters and their licensors.

Restrictions on use - This site and the DiiVA Specification are available only for your personal use. You may not copy, reproduce, republish, post, distribute, transmit or modify in any way all or any part of this site or the DiiVA Specification. The DiiVA Specification is confidential information and shall be used by you only for the Purpose. You will not disclose the DiiVA Specification to any third party. Neither access to the DiiVA Specification nor any other of these terms and conditions of use is intended to grant to you any license to DiiVA Promoters’ or any other person’s patents, copyrights, trade secrets or other intellectual property.

Trademark Notice – The DiiVA name, logo and trademarks are the property of the DiiVA Promoters and you may not use any of such materials for any purpose without the express written agreement of the DiiVA Promoters.

DISCLAIMER OF WARRANTIES - ALL SPECIFICATIONS, INFORMATION, MATERIALS, TRADEMARKS, SERVICES, AND ALL OTHER ITEMS PROVIDED BY AGENT AND/OR ANY DIIVA PROMOTER ARE PROVIDED "AS IS" AND WITHOUT ANY WARRANTIES OR REPRESENTATIONS OF ANY KIND. DIIVA PROMOTERS MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE ACCURACY, RELIABILITY OR COMPLETENESS OF THE DIIVA SPECIFICATION TO THE EXTENT PERMISSIBLE BY LAW. DIIVA PROMOTERS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. AGENT AND THE DIIVA PROMOTERS MAKE


NO WARRANTIES OR REPRESENTATIONS WITH RESPECT TO INTEROPERABILITY, FUNCTIONALITY, RELIABILITY AND/OR SECURITY.

Limitation of Liability – DiiVA Promoters shall not be liable for damages of any kind, including without limitation special or consequential damages, arising out of your access to, or inability to access, this site or your use of, or reliance upon, the DiiVA Specification, even if informed in advance of the possibility of such damages. THE AGGREGATE CUMULATIVE LIABILITY OF AGENT AND/OR THE DIIVA PROMOTERS FOR ALL CLAIMS (WHETHER UNDER CONTRACT, TORT, STATUTE OR OTHERWISE) RELATED TO THIS AGREEMENT, THE DIIVA SPECIFICATIONS, ANY SUBJECT OF THIS AGREEMENT AND ANY INFORMATION, MATERIALS AND SERVICES PROVIDED BY AGENT AND/OR THE DIIVA PROMOTERS SHALL NOT EXCEED THE AMOUNT, IF ANY, PAID BY YOU FOR THE DIIVA SPECIFICATION.

Other - If any term, condition, or provision of this Agreement is determined to be unlawful, invalid, void, or for any reason unenforceable, the validity and enforceability of the remaining terms, conditions and provisions shall not in any way be affected or impaired thereby. This Agreement constitutes the entire agreement between you and DiiVA Promoters relating to the subject matter herein. You may not assign this Agreement to any third party. The term of this Agreement is one year. Agent in its sole discretion may terminate this Agreement at any time and without prior notice. Upon expiration or termination of this Agreement, you agree to immediately destroy and cease all use of the Specification and all materials and information related to the Specification.

Governing law – Disputes regarding these terms and conditions of use of the website or the draft DiiVA Specification shall be construed and controlled by the laws of Hong Kong, Chinawithout reference to conflict of laws principles. The United Nations Convention on Contracts for the International Sale of Goods and any other similar convention shall not apply. Any legal action relating to this Agreement or its subject matter may be brought in the courts of Hong Kong, China, and you hereby irrevocably consent to the jurisdiction and venue thereof.

Please send questions or comments to [email protected]. For more information on DiiVA, please visit http://www.diiva.org

Copyright (c) 2009 by DiiVA Promoters Group. All rights reserved. The DiiVA name, logo and trademarks are the property of the DiiVA Promoters. Any use of such materials for any purpose without the express written agreement of the DiiVA Promoters is prohibited. Third party trademarks and servicemarks are property of their respective owners.

.


DOCUMENT REVISION HISTORY

Date Document Version Description

2009.04.21 1.0 Initial Release

2009.04.29 1.0a Minor proof-reading edits

Terms and Conditions Updated

Figure 26 inserted

Edits to Chapter 8: Cable-Connector Assembly

Inclusion of Document Revision History

2010.01.07 1.1 Draft A - This Version -

DiiVA Specification 1.1 Draft A - Informational Version –


1 Scope

This specification describes the requirements to design and build products that are compliant with the Digital Interactive Interface for Video & Audio (DiiVA). DiiVA products include DiiVA devices such as A/V Source and Sink devices, and DiiVA cable assemblies that interconnect DiiVA devices. The goal is to enable products from different vendors to reliably interoperate when connected with other DiiVA products in an open-industry architecture.

Other goals for the specification include:

Making interactive television a reality by combining a reliable high-speed bi-directional data channel with an uncompressed video and audio channel to allow users to connect, configure, and control various home CE devices from their digital televisions.

Simplifying overall system cabling by combining multiple protocols in a single cable. Creating a home-network infrastructure in which any DiiVA Sink device can access any

DiiVA Source device within the same DiiVA network.

As consumers use more electronic entertainment devices and digital home appliances, the DiiVA interface streamlines and simplifies connectivity of technology in the home, offering ease of connection and use while maximizing the entertainment experience.


2 Normative references

The following standards contain provisions that, through reference in this text, constitute normative provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. If the referenced standard is dated, the reader is advised to use the version specified.

CEA-861-E, A DTV Profile For Uncompressed High-speed Digital Interfaces, March 2008

VESA E-EDID Standard, ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD Release A, Revision 1, February 9, 2000

ITU-R BT.601-5, Studio encoding parameters of digital television for standard 4:3 and widescreen 16:9 aspect ratios (October 1995)

ITU-R BT.709-5, Parameter values for the HDTV standards for production and international programme exchange (2002)

IEC 60958-1, Digital audio interface – Part 1: General, First edition 1999-12

IEC 60958-3, Digital audio interface – Part 3: Consumer applications, Third edition 2006-05

IEC 61937, Digital Audio - Interface for non-linear PCM encoded audio bitstreams applying IEC 60958, First edition 2000-04

IEC 61966-2-4, Multimedia systems and equipment - Colour measurement and management -Part 2-4: Colour management - Extended-gamut YCC colour space for video applications –xvYCC, January 2006

IEEE 802.3-2000, Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 2000

ANSI X3.230-1994, Information Technology - Fibre Channel - Physical and Signaling Interface (FC-PH), 1994


3 Terms, definitions and abbreviations

3.1 Terms and definitions

Active (Video) Period: A period during which the actual pixel information is being transferred.

ANSI 8b10b: 8-bit to 10-bit encoding scheme specified in IEEE 802.3-2000, clause 36 and ANSI X3.230-1994, utilized in DiiVA’s Video Link and Hybrid Link.

Audio Sink: Subdevice within a DiiVA device that is capable of receiving and processing audio stream(s) from DiiVA VI port, typically for amplified output to speakers or for bridging to some other audio interface (e.g. HDMI or S/PDIF).

Audio Source: Subdevice within a DiiVA device that is capable of originating audio stream(s) for transmission on DiiVA, typically from pre-recorded audio content, audio streaming content or a bridge from some other audio interface (e.g. HDMI or S/PDIF).

Color Component Packer: A module to assign three color components into the activated Video Lane(s).

Dx.y: A 10-bit data code from ANSI 8b10b encoding.

DiiVA Control Layer (DCL): DCL uses the Hybrid Link Command Subchannel to send and receive special packets to configure and control DiiVA devices.

DiiVA Equipment Control (DEC): Protocol using the Hybrid Link Command Subchannel for high-level control of DiiVA devices to perform end-user requested operations typically associated with remote control button presses.

DiiVA Device Address: 48-bit hardware address to uniquely identify a DiiVA device and the Hybrid Link service.

Downstream: From the Video Source to the Video Sink. For data flow direction or relative device positions, Downstream means “toward the Video Sink”.

Hybrid Link: The differential pair on a DiiVA link used to carry bi-directional control and data, including USB and Ethernet bulk data.

Hybrid Link Receiver: The portion of a DiiVA port responsible for receiving high-speed differential data from the hybrid link.

Hybrid Link Transmitter: The portion of a DiiVA port responsible for transmitting high-speed differential data onto the hybrid link.

K28.x: A 10-bit “control” code that is part of the ANSI 8b10b encoding.

PHY: Physical layer of Video Link or Hybrid Link.

Receiver mode: Port is ready to receive or is currently receiving a packet over the Hybrid Link.

Subdevice: A portion of a DiiVA device that represents a single audio and/or video Source or Sink, USB port or Ethernet port. The subdevice may be a functional block within the DiiVA device itself (e.g. a Blu-ray player or TV), or may be a proxy for an HDMI, WHDI or other type of device that exists on the non-DiiVA side of a bridge between DiiVA and a non-DiiVA interface.

Transceiver: The portion of a DiiVA VO or VI port responsible for transmitting and receiving high-speed differential data onto the hybrid link of the DiiVA port.


Transmitter mode: Port is ready to transmit or is currently transmitting a packet over the Hybrid Link.

Upstream: From the Video Sink to the Video Source. For data flow direction or relative device positions, Upstream means “towards the Video Source”.

Video Lane: One of the three differential pairs of the Video Link.

Video Link: Set of up to three Video Lanes on a DiiVA port, used to carry uncompressed video data

VO Port: A DiiVA port that is capable of transmitting uncompressed video on the DiiVA Video Link.

VI Port: A DiiVA port that is capable of receiving uncompressed video, either for consumption locally or for re-transmission to a downstream device.

(Video) Sink: Subdevice within a DiiVA device that is capable of receiving and processing uncompressed video from DiiVA VI port, typically for rendering on a display or for bridging to some other video interface (e.g. HDMI).

(Video) Source: Subdevice within a DiiVA device that is capable of originating uncompressedvideo stream(s), typically from pre-recorded video content, video streaming content or a bridge from some other video interface (e.g. HDMI), for transmission on DiiVA VO port.

Video Receiver: The portion of a DiiVA VI port responsible for receiving high-speed differential data from the video link.

Video Transmitter: The portion of a DiiVA VO port responsible for transmitting high-speed differential data onto the video link.

3.2 Abbreviations and Acryonyms

ACP Audio Content Protection (Packet)

ASP Audio Sample Packet

AWG American Wire Gauge

BER Bit Error Rate

bpc bits per component

bpp bits per pixel

CRC Cyclic Redundancy Check

CRU Clock Recovery Unit

DDA DiiVA Device Address

DCL DiiVA Control Layer

DPI DiiVA PHY Interface

E-EDID Enhanced EDID (Extended Display Identification Data)

EOP End of Packet

EQ Equalization


FIB Field Information Byte

fs audio sampling frequency

fv external system reference clock frequency

FSM Finite State Machine

GBD Gamut Boundary Descriptor

GCP General Control Packet

HL Hybrid Link

ISI Inter-Symbol Interference

LFSR Linear Feedback Shift Register

L-PCM Linear PCM

LSb Least Significant bit

MSb Most Significant bit

PLL Phase-Locked Loop

PoD Power Over DiiVA

ppm Parts per million

QoS Quality of Service

Rx Receiver

SOI Start Of Inactive stream

SOF Start of Frame

SOH Start of Horizontal line

SOP Start of Packet

SOS Start of Subsidiary period

SID Service ID (SSID/INIT_SID, DSID/DEST_SID)

Tx Transmitter

UL Underwriters Laboratories

VL Video Link

3.3 Presentation convention

expected A key word used to describe the behavior of the hardware or software in the design models assumed by this specification. Other hardware and software design models may also be implemented.


shall A key word indicating a mandatory requirement. Implementers are required to implement all such requirements.

may A key word that indicates flexibility of choice with no implied preference

should A key word indicating flexibility of choice with a strongly preferred alternative. Equivalent to the phase is recommended.

2b’01 A constant word of length 2 bits, with the most significant bit (MSb) = 0 and the least significant bit (LSb) = 1. General form: <size in bits>b’<value in binary>

8h’80 A constant word of length 8 bits, with a value of 80 hexadecimal (128 decimal). General form: <size in bits>h’<value in hexadecimal>

8d’128 A constant word of length 8 bits, with a value of 128 decimal (8b’10000000). General form: <size in bits>d’<value in decimal>. Note: Any constant values shown without explicit bases (i.e., without b’, h’, d’) are decimal values.


4 Overview

4.1 DiiVA Capabilities

DiiVA technology described in this specification version enables downstream (source to display)video at up to 13.5Gbps (4.5Gbps per differential pair), a rate capable of handling well beyond 1080p resolution video with Deep Color and high refresh rates. In addition, DiiVA contains a high-speed bi-directional hybrid data channel (“Hybrid Link”) that can operate at up to 4.32Gbps in half-duplex mode.

The bi-directional Hybrid Link is logically segmented into subchannels that transport audio, command, and bulk data. The protocol for the hybrid link can bridge to other wired and wireless interfaces, allowing DiiVA-interface products to easily connect to a home network of devices.

Downstream transmission of an uncompressed or compressed audio stream through the Audio Subchannel is supported with virtually no bandwidth limitation, allowing transmission of up to 16 channels of uncompressed PCM, with 24 bits per sample and rates up to 192kHz. In addition to a “Downstream” audio transmission that typically corresponds to the Downstream video transmission, a simultaneous “Upstream” transmission is supported, allowing, for instance, a TV with a built-in HDTV decoder to display video while passing the audio stream to an external audio amplifier.

The Command Subchannel enables bi-directional, low-bandwidth data such as control commands from TV to DVD player to be carried with low latency.

The Data Subchannel enables reliable transmission of bulk data such as USB and/or Ethernet to pass through the Hybrid Link. USB and Ethernet packets are encapsulated and sent through the DiiVA Network using the DiiVA Hybrid Link Protocol which is described in this specification.

Content protection is available to protect the Downstream uncompressed video and corresponding audio streams and makes use of the Command Subchannel for authentication and other CP operations.


4.2 DiiVA Architecture and Topology

Figure 1 Simplified Diagram of DiiVA Link

DiiVA cables are based on standard high-speed Ethernet cable stock (such as Cat6, Cat6a, Cat7with DiiVA-specific connectors at both ends. As with standard Ethernet cables, DiiVA cables contain four twisted pairs, each designed for high-speed differential signaling. This cable architecture (shown in Figure 1) was chosen for its cost-effectiveness at long distances and potential for use in a network configuration.

One of the differential twisted pairs in the cable is the Hybrid Link, which carries audio, control, bulk data (Ethernet and USB), and status information.

The remaining three differential pairs comprise the Video Link and are dedicated to carrying uncompressed video pixel data and synchronization information. Depending upon the video resolution, frame rate, and number of bits per pixel (“color depth”), either one, two, or three of these pairs are used for the transmission. If a device only supports up to HDTV video resolution(e.g., 1920x1080i 50/60Hz, 1280x720p 50/60Hz), then only a single pair is needed for video. All standard DiiVA cables contain all four pairs.

DiiVA devices may be interconnected in a “Daisy Chain” and/or a “Switched” configuration.

Many DiiVA devices will have both an input and output port, as shown in Figure 2, allowing them to be interconnected in a daisy-chain configuration. Some Sinks might only have an input (or “VI”) port, and some Sources might only have an output (or “VO”) port. Devices with both an input and output port support the relaying of uncompressed video (downstream only), audio,Ethernet, and other Hybrid Link data. Full video relaying capability (max speed and all three Video Link pairs) is provided in all such devices.

Sink Device or SwitchSource Device or Switch

Hybrid Link(Audio, Control, USB, Ethernet, other data)

Video Link(video data)

Cable with Four Twisted Pairs

DiiVA VI Port(video input)

DiiVA VO Port(video output)

DiiVA 1.1 Draft A – Informational Version

Figure

DiiVA devices may also be interconnected in a switch/tree configuration in which a switch device with multiple inputs (VI ports) will relay the video and relevant Hybrid Link data to one or more outputs (VO ports).

Each DiiVA device has a 48-bit addressed to the destination device or is broadcast to all devices. Intermediate devices are responsible for relaying or, if the device is a switch, switching the the device.

Figure

Informational Version – 22 – DiiVA Promoters Group:2010

Figure 2 Daisy-chain topology of DiiVA

DiiVA devices may also be interconnected in a switch/tree configuration in which a switch device s) will relay the video and relevant Hybrid Link data to one or more

bit hardware address. Hybrid Link communication is explicitly addressed to the destination device or is broadcast to all devices. Intermediate devices are

or, if the device is a switch, switching the Hybrid Link

Figure 3 DiiVA Source Internal Layers

DiiVA Promoters Group:2010

DiiVA devices may also be interconnected in a switch/tree configuration in which a switch device s) will relay the video and relevant Hybrid Link data to one or more

communication is explicitly addressed to the destination device or is broadcast to all devices. Intermediate devices are

Hybrid Link packets through


4.3 DiiVA Layered Definition

This specification principally creates compliance requirements for signals transmitted on the DiiVA connector, for reception ability for those signals, and for higher-level behaviors (video format support, etc.). Compliance to these various requirements is determined at the device’s DiiVA connectors and by observing the device itself (e.g., watching the screen).

For ease and clarity in the description of these requirements, a device-internal layering has been defined that corresponds to a theoretical signal-flow of the audio, video, auxiliary, and other hybrid data through the device. These layers – Application, Link, and PHY (including two sub-layers) – are shown in Figure 4.

The signaling and reception requirements are largely covered in the PHY layer and include electrical and timing specifications and symbol encoding.

The Link layer includes packet construction and sequences, handshaking protocols, etc. In order to allow for implementation of DiiVA functionality in non-DiiVA PHY technologies (e.g., other wired and wireless channels), the Link Layer definition is abstracted from and minimally affected by the characteristics of the PHY technology.

Higher-level behavioral requirements, such as defining which video and audio formats must be supported, are considered to be in the Application layer.

Figure 4 DiiVA Layered Implementation


5 Physical Layer

5.1 Physical Layer Operational Overview

A DiiVA Link is a connection between two DiiVA devices, consisting of a Video Link and a Hybrid Link. The Video Link is uni-directional (Downstream) and has three Video Lanes: VL0, VL1, and VL2, corresponding to three separate differential pairs. The Hybrid Link is half-duplex bi-directional and uses a single differential pair. As shown in Figure 5, all four pairs are AC coupled on both sides of the cable. Each differential pair is electrically terminated inside both the VO portand the VI port with a 50-ohm termination.

The DC level of each pair is determined by separate voltage references: VU0, VU1, VU2, VU3, VD0, VD1, VD2, and VD3. The voltage references are isolated from the differential signaling by high frequency block filters such as ferrite beads. DC power is delivered over the DiiVA connection to activate repeater or relay devices and small mobile devices. This feature is called “Power Over DiiVA” (PoD) and is described in Chapter 11.

Figure 5 DiiVA Link Electrical Connection Diagram

The DiiVA PHY consists of a Video Link PHY and a Hybrid Link PHY. Each PHY has a Logical Sub-layer and an Electrical Sub-layer as shown in Figure 6. The interfaces between the various layers and sub-layers are informative.

VD0

VD1

VL2+VL2-

VL1+VL1-

VL0+VL0-

HL+HL-

VD2

VD3

VU0

VU1

VU2

VU3Hybrid Link Data

Uncompressed Video Stream

Upstream Device Downstream Device

: Low-pass filter


Figure 6 DiiVA PHY Sub-layer Diagram

5.2 Hybrid Link PHY

5.2.1 Hybrid Link PHY Electrical Sub-layer

5.2.1.1 Hybrid Link Speed

The Hybrid Link supports four speed grades as shown in Table 1. The Hybrid Link determines the maximum reliable operating speed during initialization.

Table 1 Hybrid Link Speeds

Speed Grade

Data Rate

S0 540Mbps

S1 1.08Gbps

S2 2.16GBps

S3 4.32Gbps

5.2.1.2 Hybrid Link Clocking

Hybrid data is transferred over the Hybrid Link in plesiochronous mode. This means that each device maintains a local crystal oscillator, typically running at 27MHz or an integer multiple of 27MHz. Over time, the accuracy of the local clock shall remain within +/-200 ppm. Each packet starts with Hybrid Link preambles, as in Figure 9. Each device resets the phase information of the sampling clock according to the preambles.

The Hybrid Link transmitter shall insert one or more NULL symbols (K28.5) per every 180 bytes starting from SOP. This ensures proper operation with a spread spectrum clock (see section 5.4.1.3). The Hybrid Link receiver PHY either takes out a NULL symbol or inserts a NULL symbol before further processing by the upper layer.

5.2.1.3 Hybrid Link Jitter Budget

According to the Dual-Dirac method, the total jitter (TJ) is simply expressed as

DiiVA PHY—Link Interface *

HD[7:0] 8

VDx[7:0] 24

VLx3

Video Link PHY Logical Sublayer

Video Link PHY Electrical Sublayer

Hybrid Link PHY Logical Sublayer

Hybrid Link PHY Electrical Sublayer

HL

DiiVA Cable

DownstreamVideo

*This interface is informative.


TJ = 2 Q X RJ + DJ

Where RJ is the deviation of random jitter component, DJ is the peak-to-peak range of deterministic jitter component and Q is a factor determined by error function, erfc(x), and the required bit error rate (BER). For data communication, a BER of 10-12 is regarded as a standard requirement, which dictates a Q value of 7. The actual error rate of Hybrid Link is further improved by Link layer retransmission mechanism and upper layer error handling.

Table 2 Hybrid Link Jitter Budget

Transmitter @ TP1 Receiver @ TP2 Unit

DJ TJ DJ TJ

Jitter Budget 0.12 0.3 0.24 0.5 UI

* TP1 jitter shall be measured with 50 ohm termination to ground.** TP2 jitter shall be measured with the reference PLL and the reference equalizer model. The reference PLL has a 4MHz bandwidth with a 1st order loop filter and may be a software PLL embedded in the test equipment. The reference equalizer is defined in Section 5.4.1.2.

5.2.1.4 Hybrid Link Eye Diagram

Figure 7 Hybrid Link Eye Diagram at TP1

0.0-0.5

0.5

0.4

-0.4

0.15 0.85[UI]

1.00.35 0.65

[V] 0.6

-0.6


Figure 8 Hybrid Link Eye Diagram at TP2 after Reference Equalizer

5.2.2 Hybrid Link PHY Logical Sub-layer

The minimum bandwidth and signal quality of the point-to-point link to sustain the DiiVA network are ensured through cooperation between the devices at the ends of the link. Each of those two devices shall do its own optimization of PHY parameters.

5.2.2.1 Symbol Encoding and Serialization

Symbol encoding and decoding follow ANSI 8b10b, specified in IEEE 802.3-2000 clause 36 and ANSI X3.230-1994, but the code rules (including the defined ordered sets) are not used.

ANSI 10-bit symbols are converted to 1-bit symbols for transmission of the LSb first.

5.2.2.2 Control Symbols

Control symbols indicate the start of a packet and end of a packet. The receiver uses this information to receive packets. Control symbols are mapped to K symbols as follows:

Start of Packet (SOP): {K28.5-, K28.5+, K28.5-, K28.5+}

End of Packet (EOP): {K28.1-,K28.1+, K28.1-, K28.1+} or {K28.1+,K28.1-,K28.1+,K28.1-}

5.2.2.3 Basic Hybrid Link Packetization

The Hybrid Link is a half-duplex link with a direction change after every packet frame. Each packet frame is composed of direction identifier, a preamble of fifty D10.2 symbols, four SOP symbols, the packet, and four EOP symbols, as shown in Figure 9. The packet is composed of a header, a payload and CRC. The packet definition is given in Chapter 7.

0.0-0.5

0.5

0.12

-0.12

0.25 0.75[UI]

1.00.45 0.55

[V] 0.6

-0.6


Figure 9 Hybrid Link Bit Stream Format

5.2.2.4 Flow Control

CRC information is contained within the Hybrid Link packet. If the received packet has a CRC error, retransmission is requested (see sections 7.4.7 and 7.4.3.3).

Each Hybrid Link port indicates whether it was unable to accept a previously received packet (typically due to FIFO full), and if it is unable to accept a new packet. Details are described in Chapter 7.

5.2.3 Hybrid Link PHY Management

Connection/Disconnection detection

Speed grade negotiation

PHY parameter optimization

Power management

5.2.3.1 State Transitions

<This information is available in the unabridged version of this document.>

5.2.3.2 Hybrid Link Reset Condition


5.2.3.3 PHY Testing with Test Equipment


5.2.3.3.1 HandOver Transaction


5.2.3.3.2 HLRXTest Transaction

50 D10.2

SOP EOP

Packet

Direction Identifier

Downstream

Upstream

>10 UI >10 UI

Transitionfrom neutral state<10 UI



5.2.3.4 HLTXTest Transaction


5.3 Video Link PHY

5.3.1 Video Link PHY Electrical Sub-layer

5.3.1.1 Video Lane Requirements

Video relay capability on all three video lanes shall be supported between all DiiVA VI and all DiiVA VO ports on a product. Devices with only a single DiiVA port (either VI or VO) are not required to support video pass-through capability. Devices with more than one VI port and one or more VO ports are required to support relay capability from any VI port to the appropriate VOport.

Such relay capability shall be capable of carrying full DiiVA rate video signals (as described in Chapter 6) on all three video lanes.

A VO port or VI port shall be able to transmit or receive video streams using the minimum number of Video Lanes necessary to carry the format. A VO port may choose a larger number of Video Lanes in consideration of power consumption and signal quality if the VI port supports those additional lanes.

A VI port shall support reception of video streams across more than the minimum number of lanes required for that format.

5.3.1.2 Video Link Clocking

Video data is transferred using a source-synchronous clock, that is, the inherent video timing of the signal, with the symbol rate proportional to the pixel rate. This allows optimized processing of uncompressed video information in terms of power consumption and circuit complexity. Video clock information can then easily be recovered at the Sink, if needed to drive a display panel, monitor, or other video output port. The actual bit frequency of the Video Lanes depends on the number of Video Lanes and the video resolution.

The video transmitter jitter transfer bandwidth shall be less than 4MHz following existing industry standards. The receiver bandwidth should surpass 5 times that of the transmitter, or 20MHz considering ANSI 8b10b run-length.

5.3.1.3 Video Link Signaling

Signaling levels are common for all three pairs and are covered in Section 5.4.


5.3.1.4 Video Link Compliance Testing

Transmitter compliance tests will be performed using eye masks and jitter analysis and receiver compliance tests will be based on determining the ability of the receiver to tolerate various signaldegradations, including various levels of and types of jitter. Test points are shown in Figure 10. TP1 and TP2 are used for compliance tests and TP0 and TP3 are assigned for referencing purposes.

Figure 10 DiiVA Test Points.

5.3.1.5 Video Link Jitter Budget

Video Link jitter is understood with the same equation as Hybrid Link. For consumer electronic video application, a BER of 10-9 is regarded as a standard requirement, which dictates a Q value of 6.15.

Jitter tolerance characteristics shall be met by all receivers.

Table 3 Video Link Jitter Budget

Transmitter @ TP1 Receiver @ TP2Unit

DJ TJ DJ TJ

Jitter Budget 0.15 0.3 0.3 0.5 UI

* TP1 jitter shall be measured with 50 ohm termination to ground.** TP2 jitter shall be measured with the reference PLL and the reference equalizer model. The reference PLL has a 4MHz bandwidth with a 1st order loop filter and may be a software PLL embedded in the test equipment. The reference equalizer is defined in Section 5.4.1.2.


5.3.1.6 Video Link Eye Diagram

Figure 11 Video Link Eye Diagram at TP1

Figure 12 Video Link Eye Diagram at TP2 After Reference Equalizer

5.3.2 Video Link PHY Logical Sub-layer

5.3.2.1 Symbol Encoding and Serializing

Symbol encoding and decoding follow ANSI 8b10b specified in IEEE 802.3-2000, clause 36 and ANSI X3.230-1994, but the code rules (including the defined ordered sets) are not used.

ANSI 10-bit symbols are converted to 1-bit symbols for transmission of the LSb first.

5.3.2.2 Video Pixel Data Scrambling


5.3.2.3 Control Sequences


0.0-0.5

0.5

0.12

-0.12

0.25 0.75[UI]

1.00.45 0.55

[V] 0.6

-0.6

0.0-0.5

0.5

0.4

-0.4

0.15 0.85 [UI]1.00.35 0.65

[V] 0.6

-0.6


5.3.3 Video Relay Modes

DiiVA allows a number of sources, switches and other devices to be connected between a Video Source and a Video Sink. Devices between an active Video Source and the Video Sink are responsible for retransmitting the video data while maintaining full Hybrid Link operation. Three Video Relay Modes are defined below. All Video Relay mode-capable devices shall support Resampling and Buffering modes.

Specifications for Video Source output characteristics, Video Sink input tolerance, and Video Relay Mode transfer characteristics are calculated based on the presence of six worst-case intermediate devices present between a worst-case Source and a worst-case Sink. Typical configurations will support significantly more intermediate devices.

Table 4 compares the three Video Relay Modes, showing the advantages and disadvantages of each.

Table 4 Comparison of DiiVA Video Relay Modes

Resampling Mode Buffering Mode Bypassing Mode

Power Consumption Full PHY Power Partial PHY Power Stand-by Power

Jitter Transfer Removes high frequency jitter.

Removes ISI with cable equalizer.

Local PLL jitter may accumulate.

Removes ISI with cable equalizer

Local data path may increase ISI.

Local data path may increase ISI.

Signal Swing Boosted Boosted No Boosting

5.3.3.1 Resampling Relay Mode

In Resampling Relay Mode, the VI port PHY recovers the clock information from the video data stream with the video Clock Recovery Unit (CRU). The recovered clock information, possibly after some further processing, is used to resample the received video data and to retransmit it onto the VO port. This operation counteracts signal degradation on the cable, connector, and PCB lines. Resampling Mode requires that the receiver be in full-operation mode. Cascading several Resampling Mode devices may increase jitter due to the accumulation of each device’s PLL/CRU jitter-transfer characteristics. Accordingly, the number of devices operating in Resampling Mode between Source and Sink must be limited. This configuration occurs during the Video Path Setup operation.

While operating in Resampling Relay mode, the VO (transmitter) port(s) shall comply with the transmitter specifications given in Table 7 when the VI port receives a video signal compliant with the receiver specification in Table 8.

Figure 13 shows one implementation example. The video clock is recovered from video lane 0 and is used to resample and align video data from all three lanes. The local drivers regenerate serial data from the digital bits with proper driver strength and pre-emphasis.


Figure 13 Circuit Diagram of Resampling Mode Device (Informative)

5.3.3.2 Buffering Relay Mode

In Buffering Relay Mode, the PHY improves the signal integrity of the Downstream data without resampling. Detailed improvement methods are implementation-specific and not mandated . This mode shall not add PLL/CRU jitter, though it may induce deterministic jitter from insufficient compensation.

While operating in Buffering Relay Mode, the VO port(s) shall comply with the transmitter specification in Table 7 when the VI port receives a video signal compliant with the receiver specification in Table 8.

This mode may be used in a cable signal booster to extend cable length.

When a Video Relay Mode device other than the cable extender has the option of utilizing Buffering Mode for power saving purposes, the repeater device shall support the data recovery and BER checking capability during the video link PHY initialization described in Section Error! Reference source not found..

Figure 14 shows one implementation example. The sampler can have an equalization function to compensate for the ISI effect. The driver may have a pre-emphasis function to improve the output waveform .

Clock Recovery Unit

VL2rx

VL1rx

VL0rx

VL2tx

VL1tx

VL0tx

Receiver Driver


Figure 14 Circuit Diagram of Buffering Mode Device (Informative)

5.3.3.3 Bypassing Relay Mode

In Bypassing Mode, the video lane signals are rerouted to the VO port with minimal or no signal reconditioning. While operating in Bypassing Relay Mode, the signal quality at the VO port is no better than that at the VI port.

Bypassing Relay Mode may only be used when a device has insufficient power available to perform Resampling or Buffering Relay Modes, either from AC mains, battery or PoD.

Figure 15 shows one implementation example in which the switches may be commercially-available RF MEMS switches.

Figure 15 Circuit Diagram of Bypassing Mode Device (Informative)

5.3.4 Video Relay Mode Control


5.3.5 Video Link PHY Management


5.4 Detailed Electrical Specifications

5.4.1 Common Hybrid Link and Video Link Requirements

The following requirements apply to all differential pairs.

VL0rx

VL1rx

VL2rx

VL0tx

VL1tx

VL2tx

Receiver Driver


5.4.1.1 ESD/EOS

IEC61000-4-2, Level 4 (8kV contact)

5.4.1.2 Cable Equalizer

One of DiiVA’s objectives is to enable the use of long, inexpensive cables. To achieve thireceivers must be capable of handling the high levels of signal degradation created by such cables. This is most commonly accomplished through the use of cable equalization in the receiver. Thus DiiVA’s receiver eye diagram and jitter measurement (jitter tolerance measurement) are performed using a reference equalizer, shown in Figure 16.

Figure 16 Frequency Characteristics of Reference Cable Eq

The AC peak is 8dB and located at 2.25GHz, which is half of the maximum data rate of DiiVA. The AC peak amount and gain slope in the lower frequency region is designed to compensate for the frequency characteristics of commonly available C

5.4.1.3 SSC

To reduce EMI/EMC issue, DiiVA transceiver shall be able to handle 0.0modulation with 30kHz to 33kHz modulation frequency

5.4.2 Hybrid Link Transmitter Specification



2, Level 4 (8kV contact)

One of DiiVA’s objectives is to enable the use of long, inexpensive cables. To achieve thireceivers must be capable of handling the high levels of signal degradation created by such cables. This is most commonly accomplished through the use of cable equalization in the

eye diagram and jitter measurement (for the purpose of receiver jitter tolerance measurement) are performed using a reference equalizer, the behavior of which is

Frequency Characteristics of Reference Cable Equalizer

The AC peak is 8dB and located at 2.25GHz, which is half of the maximum data rate of DiiVA. The AC peak amount and gain slope in the lower frequency region is designed to compensate for the frequency characteristics of commonly available Cat6a.

To reduce EMI/EMC issue, DiiVA transceiver shall be able to handle 0.0 to 33kHz modulation frequency.

Hybrid Link Transmitter Specification

the unabridged version of this document.>


One of DiiVA’s objectives is to enable the use of long, inexpensive cables. To achieve this goal, receivers must be capable of handling the high levels of signal degradation created by such cables. This is most commonly accomplished through the use of cable equalization in the

for the purpose of receiver the behavior of which is

ualizer

The AC peak is 8dB and located at 2.25GHz, which is half of the maximum data rate of DiiVA. The AC peak amount and gain slope in the lower frequency region is designed to compensate for

to 0.5% frequency


Table 5 Hybrid Link Transmitter Specifications

Symbol Parameter Min Nom Max Unit Comments

UIHL-S1Unit Interval for Hybrid Link at S1

926 ps S1 is 1.08Gbps





VHTX-DIFF-pp

Differential Peak to Peak Output Voltage

1.0 1 1.20 V VHTX-DIFF-pp=2*|VHTX-D+-VHTX-D-|

AHL-pre-emp Output Voltage of Pre-emphasized Bit

3dB 20 * log10 { (2*|VHTX-D+-VHTX-D-|)pre-

emphasized /VHTX-DIFF-pp }

AHL-de-emp Output Voltage of De-emphasized Bit

-3dB 20 * log10 { (2*|VHTX-D+-VHTX-D-|)de-

emphasized/VHTX-DIFF-pp }

5.4.3 Hybrid Link Receiver Specification


The reference equalizer in Section 5.4.1.2 shall be applied if not specified otherwise.


Table 6 Hybrid Link Receiver Specifications



1,852 ps S0 is 540Mbps


926 ps S1 is 1.08Gbps.





5.4.4 Video Link Transmitter Specification


The following specifications apply to all VO ports.


Table 7 Video Link Transmitter Specifications


UIVLUnit Interval for Video Link

1/(10* tsymbol)

40.0 ns tsymbol is determined by video resolution

VTX-DIFF-pp

Differential Peak to Peak Output Voltage without Pre-emphasis

1.00 1 1.2 V VTX-DIFF-pp=2*|VTX-D+-VTX-D-|

Apre-emp Output Voltage of Pre-emphasized Bit

3dB 20 * log10 { (2*|VTX-D+-VTX-D-|)pre-emphasized

/VTX-DIFF-pp }

Ade-emp Output Voltage of De-emphasized Bit

-3dB 20 * log10 { (2*|VTX-D+-VTX-D-|)de-

emphasized/VTX-DIFF-pp }


5.4.5 Video Link Receiver Specification


The following specifications apply to all VI ports. The reference equalizer in Section 5.4.1.2 shall be applied if not specified otherwise.


Table 8 Video Link Receiver Specifications


UIVLUnit Interval for Video Link

1/(10* tsymbol)

40.0 ns tsymbol is determined by video resolution

VRX-DIFF-pp

pp_wo_eq

Differential Peak to Peak Output Voltage Without Reference Equalizer

0.11 VVRX-DIFF-pp=2*|VRX-D+-VRX-D-|without reference equalizer

VRX-DIFF-

pp_w_eq

Differential Peak to Peak Output Voltage With Reference Equalizer

0.24 V VRX-DIFF-pp=2*|VRX-D+-VRX-D-| after applying reference equalizer

TRX-EYE Rx Eye Width 0.5 UIVLMeasured with reference equalizer in case of long cable



6 Link Layer – Video Link

This chapter describes the DiiVA Link Layer defined to support the video data type.

6.1 Video Data Flow of Video

Figure 17 shows the data flow transmitter and a Hybrid Link transceiverLink strictly partitioned. While the operation is blocks, this partitioning is informative

While the data flow of the Video Link and is assisted by the Hybrid Link for video link training communications.

Figure 17 Logical Pipe Order of Link Layer

The video stream includes the video timing signals (e.g., VSYNC, HSYNC, and DE) andpixel, three color components (e.g., RGB or YCbCr). several. If the Video Stream is YCbCr, its format

To accomplish the transmissionthe following building blocks:



Video Source

data flow of a Video Source’s VO port, composed of transceiver, with the data flow of the Video Link and

While the operation is shown in Figure 17 (and Figure 18informative, so different implementations are also possible.

Video Link and the Hybrid Link are separated, control of Hybrid Link for video stream management, video metadata transmission and

link training communications.

Logical Pipe Order of Link Layer and Physical Layer of Video

video timing signals (e.g., VSYNC, HSYNC, and DE) andthree color components (e.g., RGB or YCbCr). The bit width of each pixel can be one of

Video Stream is YCbCr, its format is either YCbCr 4:4:4 or YCbCr 4:2:2.

of an uncompressed video stream, the Video Link



composed of a Video Link Video Link and the Hybrid

18) using building so different implementations are also possible.

, control of the Video Link video stream management, video metadata transmission and

Video Source

video timing signals (e.g., VSYNC, HSYNC, and DE) and, for each he bit width of each pixel can be one of

either YCbCr 4:4:4 or YCbCr 4:2:2.

Video Link makes use of


6.1.1 Color Component Packer

The Color Component Packer is used to pack three color components (e.g., Red, Green, and Blue) into the enabled Video Lane(s). Since the bit width of a pixel can be one of several and the number of enabled lanes of the Video Link can be either 1, 2, or 3, several packing rules are used and are described in Section 6.4.4.

Through this packing process, Video Byte Streams (i.e., VB0, VB1, and VB2) are generated.

6.1.2 Video Link Transport Assembly

To add video timing information, the Video Link Transport Assembly adds control sequences to the Video Byte Streams, resulting in Video Transport Streams (i.e., VT0, VT1, and VT2) containing both data symbols and control symbols.

6.1.3 Scrambler

All data symbols in the Video Transport Streams that are used for video pixel data and inactive stream data (always 8h’00) are scrambled to avoid repetitive patterns. Control sequences are not scrambled. The details of the scrambler are described in Chapter 5.

6.1.4 ANSI 8b10b Encoder

ANSI 8b10b, specified in IEEE 802.3-2000, clause 36 and ANSI X3.230-1994, is used to encode the data symbols and control symbols. The details of the encoder are given in Chapter 5.

6.1.5 10-bit to 1-bit Serializer

The stream of 10-bit symbols is serialized to a 1-bit stream at a corresponding rate.

6.2 Video Data Flow of DiiVA Sink

As shown in Figure 18, a DiiVA Sink is also composed of a Video Link receiver and Hybrid Linktransceiver, where the Video Link receiver performs the inverse function of the Video Link transmitter while its Hybrid Link transceiver is the same as the mated device’s Hybrid Linktransceiver.


Figure 18 Logical Pipe Order of Link Layer

6.3 Video Transport

The Video Link transports the video data as a stream composed of video framesFigure 19. Each video frame corresponds to one frame in the progressive mode and one field in the interlaced mode. Instead of VSYNC and HSYNC, control Sequence) are used to indicate the video timing and detection of the symbols.

<This information is available in the una

Figure

6.3.1 Control Sequences


6.3.2 Timing Information Byte



Logical Pipe Order of Link Layer and Physical Layer of DiiVA

Video Link transports the video data as a stream composed of video framesvideo frame corresponds to one frame in the progressive mode and one field in

aced mode. Instead of VSYNC and HSYNC, control sequences (i.e., SOF and SOH) are used to indicate the video timing and are repeated four times


Figure 19 Video Frame in Video Link


Information Byte (TIB)



DiiVA Sink

Video Link transports the video data as a stream composed of video frames, as shown invideo frame corresponds to one frame in the progressive mode and one field in

(i.e., SOF and SOHpeated four times to ensure robust


Table 9 Timing Information Byte (TIB) Definition

Bit(s) Description

6.3.3 Field Info Packet (FIP)


Table 10 Field Information Packet Definition

Byte# Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0


Table 11 Field Information Packet Format for HDCP 2.0


6.3.4 Start of Subsidiary Packet (SOS)

To allow the Video Frame to be extended in the future, the SOS (Start of Subsidiary Packet)control sequence is defined with the data following will be used as a Subsidiary Packet. The contents of the Subsidiary Packet will be defined in the future.

A Subsidiary Packet shall not be transmitted by any Video Source.

For compatibility with future Source devices that do transmit Subsidiary Packets, all devices shallignore the contents of any received Subsidiary Packet but shall always forward such packets in the video data stream whenever the video stream is being relayed to devices downstream.

6.4 Video Packing and Lane Selection

6.4.1 Pixel and Color Component Bit Widths and Pixel Encoding

Each visible pixel is described by three color components, either R, G and B or Y, Cb and Cr. On the DiiVA video link, this data is transmitted in groups of two or three color components, with two color components used when the pixel encoding scheme is YCbCr 4:2:2 and three color components used when the pixel encoding scheme is either RGB or YCbCr 4:4:4. The bit width of each color component (i.e., bits per component, “bpc”) can be one of several.

Thus, the bit width of a single pixel (i.e., bits per pixel, “bpp”) is determined by the combination of the bit width of a single color component and the pixel encoding scheme, as shown in Table 12.

Whenever the actual color component has fewer bits than the packed component word size, additional LSbs with a value of 1’b0 shall be added to the component as needed.


Table 12 Relationship Between Pixel Encoding and Components

Bit width of a pixel

(bpp)

Bit width of a component (bpc)

RGB YCbCr 4:4:4 YCbCr 4:2:2

16 bits N.A. N.A. 8 bits

24 bits 8 bits 8 bits 12 bits

30 bits 10 bits 10 bits N.A.

36 bits 12 bits 12 bits 18 bits

48 bits 16 bits 16 bits N.A.

6.4.2 Pixel and Symbol Frequencies

For any given video resolution (e.g., 640x480p @ 60Hz), the corresponding pixel frequency (i.e., Freq PIXEL) can be found in CEA-861-E. For example,

25.2 MHz is used for 640x480p @ 60Hz. 27 MHz is used for 720x480p @ 59.97Hz. 74.25 MHz is used for 1280x720p @ 60Hz. 148.5 MHz is used for 1920x1080p @ 60Hz.

Given a pixel frequency, the bit width of a pixel, and the number of enabled lanes, the corresponding symbol frequency (i.e., Freq SYMBOL) can be calculated as follows:

Freq = bpp num_lane × 8 × Freq To simplify the implementation of a PLL, there are two exceptions: the first is bpp = 16 and num_lane = 3, and the second is bpp = 30 and num_lane = 2. The details are shown in Table 13.

Table 13 Symbol Frequency vs. Pixel Frequency

Bit Width of a Pixel (bpp)

Symbol Frequency (Freq SYMBOL )

num_lane = 1 num_lane = 2 num_lane = 3

16 bits 2.0 x Freq PIXEL 1.0 x Freq PIXEL 0.75 x Freq PIXEL(1)

24 bits 3.00 x Freq PIXEL 1.50 x Freq PIXEL 1.00 x Freq PIXEL

30 bits 3.75 x Freq PIXEL 2.25 x Freq PIXEL(2) 1.25 x Freq PIXEL



(1) In DiiVA Sources, each 8-bit component of YCbCr4:2:2 shall be expanded into a 9-bitcomponent by padding a 1-bit dummy value (i.e., 1’b0) into LSb. A DiiVA Sink may choose to discard LSbs as appropriate for its application.

(2) In DiiVA Sources, each 10-bit component shall be expanded into a 12-bit component by padding a 2-bit dummy value (i.e., 2‘b00) into the LSb. Therefore, in DiiVA Sinks, the lower 2 bitsshall be discarded.

6.4.3 Number of Lanes


6.4.4 Color Component Packing



6.4.5 Pixel Packing Examples


6.4.6 Other (16/36/48-bpp) Pixel Packing

16/36/48-bpp pixel packing also follows the rules in Section 6.4.1.

6.4.7 Video Colorimetry

Table 14 shows the DiiVA video colorimetry, including information on pixel encoding, bits per pixel (bpp), bits per color component (bpc), dynamic range of a color component, and the support requirement (i.e., mandatory (M) vs. optional (O)).

Table 14 DiiVA Video Colorimetry Support Requirement

Pixel Encoding

bpp bpc

Dynamic Range

M/OFull Range Limited Range(5)

Black White Black/Min White/Max

RGB

24 8 0 255 16 235 M

30 10 0 1023 64 940 O

36 12 0 4095 256 3760 O

48 16 0 65535 4096 60160 O

YCbCr 4:4:4

24 8 N.A. (3) N.A. 16 (235,240,240) (4) M (1)

30 10 N.A. N.A. 64 (940,960,960) O

36 12 N.A. N.A. 256 (3760,3840,3840) O

48 16 N.A. N.A. 4096 (60160,61440,61440) O

YCbCr 4:2:2

16 8 N.A. N.A. 16 (235,240,240) M (2)

24 12 N.A. N.A. 256 (3760,3840,3840) O

36 18 N.A. N.A. 16384 (240640,245760,245760) O

xvYCC (6)

(1) This mode is mandatory if YCbCr 4:4:4 is supported. Otherwise, this mode is optional.(2) This mode is mandatory if YCbCr 4:2:2 is supported. Otherwise, this mode is optional.(3) N.A. denotes ‘Not Available’.(4) The values of this triplet represent the values of Y, Cb, and Cr, respectively.(5) Limited Range shall follow the range defined in the CEA-861-E.(6) The dynamic ranges in xvYCC shall follow IEC 61966-2-4.

6.4.8 xvYCC Support

IEC 61966-2-4 defines xvYCC (i.e., Extended Gamut YCC color space), where the colorimetry of xvYCC601 is defined in ITU-R BT.601-5 and the colorimetry of xvYCC709 is defined in ITU-R BT.709-5. When xvYCC (i.e., either xvYCC601 or xvYCC709) is used, the corresponding gamut boundary metadata shall be transmitted through the Hybrid Link.

The detail of the packet format for the gamut boundary metadata is found in Chapter 8.


7 Link Layer – Hybrid Link

This chapter describes the DiiVA Link Layer defined to support the hybrid data type.

7.1 Hybrid Link Overview

The Hybrid Link provides bi-directional (halfpayloads and fixed-sized headers and tails. The underlying physical data link is pointfrom a VI port on one device to a side of the link, each of these two portsside is in receiver mode. While the underlying physical layer is inherently unialternating direction of transmission allows the Hybrid Link to provide a logically bi(i.e., half-duplex) data service.

The Hybrid Link is used to carry command/status information, audio streams and USB and Ethernet data.

7.2 DiiVA Device Address (DDA)

Figure

Each DiiVA device has a single DDA, which is a unique 48

The Vendor ID (the most significant 24 bits) is used to identify the manufacturer of the product employing the DiiVA device.mechanism defined by DiiVA Licensing, LLC.

The Device ID (the least significant 24 bits) is assigned by the manufacturer to each DiiVA device it employs in a product. Each Device ID that the manufacturer assVendor ID shall be unique. All Device ID values are permitted.

In addition to the broadcast address 48address, 48h’FFFFFFFFFFFE, which shall be used in the Destination DDA field to send a Hybrid Link packet to the device connected to a transmitting Hybrid Link port. This address is useful when the neighboring device’s DDA is not yet known or difficult to retrieve.

With the sole exception of certain special DiiVA test equipment, a DiiVA devsame DDA, on all DiiVA ports, whenever operating.

7.3 Subchannels

7.3.1 Audio Subchannel

The Audio Subchannel carriesSubchannel has the highest priority among the Hybrid(isochronous) data unless there is avariable-length payload with a minimum size of 32 bytes and a maximum of 192 bytes.

7.3.2 Command Subchannel

The Command Subchannel carries data with lopackets use the Command Subchannel. The


Hybrid Link


directional (half-duplex) data service in packets with variablesized headers and tails. The underlying physical data link is point

one device to a VO port on another. In exchanging data packets with the other of these two ports takes turns being in transmitter mode while the other

side is in receiver mode. While the underlying physical layer is inherently uniansmission allows the Hybrid Link to provide a logically bi

The Hybrid Link is used to carry command/status information, audio streams and USB and

DiiVA Device Address (DDA)

Figure 20 DiiVA Device Address Format

Each DiiVA device has a single DDA, which is a unique 48-bit value made up of 2 parts:

The Vendor ID (the most significant 24 bits) is used to identify the manufacturer of the product employing the DiiVA device. Vendor IDs are assigned to a vendor through a mechanism defined by DiiVA Licensing, LLC.

The Device ID (the least significant 24 bits) is assigned by the manufacturer to each DiiVA device it employs in a product. Each Device ID that the manufacturer assigns for a given Vendor ID shall be unique. All Device ID values are permitted. In addition to the broadcast address 48h’FFFFFFFFFFFF, DiiVA has designated the neighbor address, 48h’FFFFFFFFFFFE, which shall be used in the Destination DDA field to send a Hybrid Link packet to the device connected to a transmitting Hybrid Link port. This address is useful when the neighboring device’s DDA is not yet known or difficult to retrieve.

With the sole exception of certain special DiiVA test equipment, a DiiVA device shall use the whenever operating.

carries Downstream Audio and/or Upstream Audio. The Audio Subchannel has the highest priority among the Hybrid-Link Subchannels as it con

unless there is an urgent request from other Subchannels. The packet has a length payload with a minimum size of 32 bytes and a maximum of 192 bytes.

Command Subchannel

The Command Subchannel carries data with low-latency requirements. For instance the DCL packets use the Command Subchannel. The Command Subchannel usually follows below the



duplex) data service in packets with variable-length sized headers and tails. The underlying physical data link is point-to-point

hanging data packets with the other takes turns being in transmitter mode while the other

side is in receiver mode. While the underlying physical layer is inherently uni-directional, the ansmission allows the Hybrid Link to provide a logically bi-directional

The Hybrid Link is used to carry command/status information, audio streams and USB and

bit value made up of 2 parts:

The Vendor ID (the most significant 24 bits) is used to identify the manufacturer of the Vendor IDs are assigned to a vendor through a

The Device ID (the least significant 24 bits) is assigned by the manufacturer to each DiiVA igns for a given

FFFFFFFFFFFF, DiiVA has designated the neighbor address, 48h’FFFFFFFFFFFE, which shall be used in the Destination DDA field to send a Hybrid Link packet to the device connected to a transmitting Hybrid Link port. This address is useful when the neighboring device’s DDA is not yet known or difficult to retrieve.

ice shall use the

Downstream Audio and/or Upstream Audio. The Audio Link Subchannels as it contains real-time

The packet has a length payload with a minimum size of 32 bytes and a maximum of 192 bytes.

latency requirements. For instance the DCL ommand Subchannel usually follows below the


Audio Subchannel in transmission priority. The packet has a variable-length payload with a minimum size of 0 bytes and a maximum of 64 bytes.

7.3.3 Guaranteed and Best Effort Data Subchannel

The two Data Subchannel are bi-directional channels which carry bulk data. Ethernet traffic is relayed over the Best Effort Data Subchannel as the Ethernet packet can be dropped in congestion. USB traffic is relayed over the Guaranteed Data Subchannel as the USB packet should not be dropped during the relay. The Data Subchannels usually fall below the Command Subchannel in transmission priority. The packet has a variable-length payload with a minimum size of 0 bytes and a maximum of 1984 bytes, where the size is a multiple of four bytes.

7.3.4 Transmission Terminals for Each Subchannel

Each Subchannel in a device has two logical transmission terminals, i.e., a transmitting terminal and a receiving terminal.

Figure 21 Transmission Terminals for Each Subchannel in Hybrid Link

7.4 Packet Format

As shown in Table 15, the packet used to transmit data over the Hybrid Link consists of a header, a payload, and a tail. The header is fixed in size and consists of initiator and destination addresses and transmission parameters. The payload consists of user data, which is variable in size, up to a maximum of 1984 bytes. The tail is a 32-bit CRC which is calculated from the header and payload, very much like the FCS of the Ethernet packet. Table 15 shows the general Hybrid Link Packet format. Byte 0 of Word 0 is sent first.


Table 15 Hybrid Link Packet Format

Byte0 Byte1 Byte2 Byte3

Word 31 24 23 16 15 8 7 0

0 Reserved CH_ID DEST_SID DEST_DDA[47..32]

Hea

der

1 DEST_DDA[31..0]

2 Reserved Reserved INIT_SID INIT_DDA[47..32]

3 INIT_DDA[31..0]

4

5

6

7

8

Pay

load9

…

N

N + 1 Tai

l


7.4.1 Device Addressing (DEST_DDA, INIT_DDA)

DEST_DDA (48-bit) denotes the DDA of the device that will consume the packet and INIT_DDA(48-bit) denotes the address of the device that initially transmitted the packet.

DEST_DDA with the upper 8 bits equal to 8h’FF have the following meanings:

DEST_DDA of 48h’FFFFFFFFFFFF indicates a broadcast transmission to all connected devices.

DEST_DDA of 48’FFFFFFFFFFFE indicates a transmission to the immediate neighbor device only.

All other values are reserved for future extension.

7.4.2 Subchannel ID (CH_ID) and Service ID (SID)

CH_ID (4-bit) denotes which Subchannel is used for the packet. Subchannels are defined as shown in Table 16. Different Subchannels have different transmission and prioritization characteristics.

Packet types are grouped according to the Subchannel: LINK, AUDIO, CMD, and DATA (encompassing both GData and BEData packets).

Each Subchannel can support multiple services, where each service has its own service ID in the Subchannel, as shown in Table 16.


Table 16 Subchannel IDs and Service IDs

CH_ID Subchannel Service ID (_SID) Service

0 Link Control0 IDLE Packet

1 to 15 (Reserved)

1 Audio Subchannel0 Audio

1 to 15 (Reserved)

2 Command Subchannel

0 DCL

1 to 14 (Reserved)

15 TEST (Debugging Purpose)

3 Guaranteed Data Subchannel

0 USB #0

1 USB #1

2 to 15 (Reserved)

4 Best Effort Data Subchannel

0 Ethernet

1 to14 (Reserved)

15 General Purpose Bulk Data

INIT_SID (4-bit), i.e., Initiator Service ID, denotes which service is related in the transmitting device while DEST_SID (4-bit), i.e., Destination Service ID, denotes which service is related in the receiving device.

In most cases, INIT_SID is same as DEST_SID (e.g., a DCL service of the transmitting device sends DCL packets to a DCL service of the receiving device). SSINFO (32-bit), i.e., Service Specific Information, has supplementary data with a different meaning for each service in DEST_SID. Its detailed usage is found in the section for each service.

7.4.3 Flags

Table 17 shows positions and meanings of the flags in the Flags field.

Table 17 Flags Field

Bit(s) Flag Meaning

7..6 RSP Response Flag (see section 7.4.3.1)

5 S Packet Sequence (see section 7.5)

4 Reserved (Reserved)

3..0 Reserved (Reserved)

7.4.3.1 Response Flag Types (RSP)

Each packet shall carry one of three types of Response Flag:

0 = ACK

1 = NACK

2 = NRDY

3 = (Reserved)


7.4.3.2 ACK Response

If a packet (i.e., one of AUDIO/CMD/DATA/IDLE Packets) is received without an error (i.e., the CRC-32 check passes) or resource problems (i.e., there is enough room in the receiving buffer), the ACK Response Flag shall be set on the next packet to be transmitted on that same port. When the transmitter of the previous packet receives the ACK Response Flag, the buffered packet may now be released as there is no longer the possibility that it will need to be retransmitted.

7.4.3.3 NACK Response

NACK is set by a receiver to indicate to the transmitter of a packet that the packet has an error and needs to be retransmitted:

If a port receives any packet that fails the CRC-32 check, the port shall set the NACK Response Flag on the next packet to be transmitted.

If a port receives a NACK Response Flag, the previously-sent packet shall be immediately retransmitted, prior to any other packets.

7.4.3.4 NRDY Response

If there were insufficient resources to receive a packet (i.e., one of AUDIO/CMD/DATA Packets), the NRDY Response Flag shall be set on the next packet to be transmitted.

When the transmitter of a packet receives the NRDY Response Flag, the packet shall be re-arbitrated with the lowest priority before retransmission. The re-arbitration shall be delayed until the corresponding CH_RDY flag is clear (see section 7.4.5) to prevent excessive NRDY response. Additional delay control is optional and is implementation-specific.

7.4.4 Time-to-Live (TTL)

There is some possibility that end users or devices may inadvertently create loops in the Hybrid Link topology, thereby resulting in packets being delivered multiple times to the same destination. To prevent such issues, the TTL field shall be set to a non-zero value by the initiator of the packet and decremented by each subsequent transmitter. While a value of 8’d16 is recommended in most home environments, a bigger value can be used in complex environments.<TBD Who decides and based on what algorithm? Explicit 8 is used for Heartbeat packet. Which is it?>

Packets arriving at a device with a TTL of zero shall not be retransmitted. But, if the packet is an IDLE Packet and the receiving device is in PoD mode, the packet shall be treated as a PoDPacket, so that the TTL field shall be set to a value of 8’d16 and the packet shall be handed over to the other neighbor device. The details can be found in the PoD section, Chapter 11.

7.4.5 Receiver Readiness (CH_RDY)

The NRDY Response Flag of RSP informs the Transmitter to delay packet transmission for a while because the corresponding Receiver is not ready to receive. In this kind of protocol, it is hard to determine the optimal waiting time for the next re-transmission. A short waiting time will generate too many retransmissions while a long waiting time will increase the packet delivery latency.

In order to solve this problem, CH_RDY (8-bit) is used to deliver the Receiver’s readiness to the Transmitter. The bits of CH_RDY[7..0] have the following meanings:

CH_RDY[0] is reserved

CH_RDY[1] is 1 when the next AUDIO Packet can be received without NRDY

CH_RDY[2] is 1 when the next CMD Packet can be received without NRDY

CH_RDY[3] is 1 when the next Guaranteed DATA Packet can be received without NRDY


CH_RDY[4] is 1 when the next Best Effort DATA Packet can be received without NRDY

CH_RDY[7..5] are reserved

As the readiness of a receiving terminal could change after sending CH_RDY, the value of CH_RDY shall be used as informative in the arbitration. The completeness of the packet transmission shall be checked by using RSP, not CH_RDY.

7.4.6 Payload and Payload Length (PAYLOAD and LEN)

LEN (16-bit), i.e., Payload Length, specifies the number of bytes of user data to be transferred in the following payload, as shown in Figure 22 Since the size of PAYLOAD shall be a 4-byte multiple, one to three bytes of any value shall be padded if the user data is not multiple of 32 bytes. For instance, if a 15-byte user data is transferred, LEN is 15 and one extra byte is padded after the user data. The LEN field shall be 0 to 384 (inclusive).

PAYLOAD (0 to 1984 bytes) is a payload whose size shall be a 4-byte multiple, where a maximum of 1984 bytes are big enough to store a maximum-sized Ethernet or USB packet in a payload.

Figure 22 Definition of LEN [15..0] in Packet

7.4.7 CRC-32

Every packet shall have a CRC-32 checksum (i.e., CRC-32-IEEE 802.3) calculated over the header and the payload and appended to the end of the packet after the payload, as shown in Figure 23.

Figure 23 Location of CRC-32

The CRC-32 polynomial is x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1. The initial value 32h’FFFFFFFF is used. The output value of the polynomial shall be bit-wise bit-location swapped (e.g., MSb becomes LSb) and the bit-wise value inverted (e.g., 0 becomes 1 while 1 becomes 0) before being used as the CRC. Table 18 shows examples of CRC-32 calculation.

Table 18 Examples of CRC-32

Data Byte Sequence (LSB first) CRC-32 Byte Sequence (LSB first)

8h’00 (LSB) 8h’8D, 8h’EF, 8h’02, 8h’D2 (MSB)

(LSB) 8h’00, 8h’01, 8h’EF, 8h’08, 8h’00, 8h’00 (MSB) (LSB) 8h’C5, 8h’88, 8h’AD, 8h’0C (MSB)


7.5 Packet Flow Control

The S (1-bit), i.e., Sequence Bit, denotes a two-stage sequence, alternating with each packettransmitted over each Subchannel. The sequence number is used to check whether the current packet is a retransmitted packet or not. In the Hybrid Link, a packet could be redundantly duplicated because the packet retransmission scheme is used to increase the link reliability. Asthe sequence number in the Hybrid Link is 1-bit and the value becomes 0 and 1 alternately, the sequence number is called the Sequence Bit. If the Sequence Bit of the currently-received packet is the same as that of the previously-received packet, the currently-received packet is redundantly retransmitted, so that the packet should be disregarded. On the transmitter side, the Sequence Bit shall be changed only after the confirmation of a successful transfer, i.e., the receipt of an ACK response. On the receiver side, it shall maintain its own Sequence Bit to be compared with the Sequence Bit of the incoming packet. When the incoming packet has been received without any error and Sequence Bits are the same, the receiver side shall toggle its own Sequence Bit for the next incoming packet. Therefore, the change of Sequence Bit on the transmitter side implies that a packet is completely sent over a Subchannel, and the change of Sequence Bit on the receiver side implies that a packet is completely received over a Subchannel.

Packet types are therefore defined using CH_ID and S as follows:

IdlePkt0 (CH_ID = 4’b0000, S = 0)

IdlePkt1 (CH_ID = 4’b0000, S = 1)

AudioPkt0 (CH_ID = 4’b0001, S = 0)

AudioPkt1 (CH_ID = 4’b0001, S = 1)

CmdPkt0 (CH_ID = 4’b0010, S = 0)

CmdPkt1 (CH_ID = 4’b0010, S = 1)

GDataPkt0 (CH_ID = 4’b0011, S = 0)

GDataPkt1 (CH_ID = 4’b0011, S = 1)

BEDataPkt0 (CH_ID = 4’b0100, S = 0)

BEDataPkt1 (CH_ID = 4’b0100, S = 1)

Thus, AudioPkt0 and AudioPkt1 are the packet types transmitted over the Audio Subchannel. If there is no link error, AudioPkt0 and AudioPkt1 are alternately transferred. In a similar way, CmdPkt0 and CmdPkt1 are the packet types transmitted over the Command Subchannel. GDataPkt0 and GDataPkt1 are the packet types transmitted over the Guaranteed Data Subchannel. BEDataPkt0 and BEDataPkt1 are the packet types transmitted over the Best Effort Data Subchannel. IdlePkt0 and IdlePkt1 are the packet types transmitted when the above Subchannels are not used.

7.5.1 IDLE Packet

When there is no data to transfer in the Audio/Command/Data Subchannels, an IDLE Packetshall be transferred to change the direction of transmission. As the IDLE Packet (i.e., CH_ID = 4’b0000) is only for the point-to-point connection, DEST_DDA shall be ignored.

In normal operation, an IDLE Packet without a payload is usually used for the direction change. But, IDLE Packet with a payload can be used for special purposes (e.g., the link management). Furthermore, the IDLE Packet is also used to access PoD-related functions in PoD mode.

The Hybrid Link will alternate the direction of transmission after the completion of each packet transfer, as shown in Figure 24.


Figure 24 Examples of Packet Flow

7.5.2 State Diagram for Sender/Receiver Mode Change

The Hybrid Link is a half-duplex channel. The direction of the transmission alternates between the Downstream direction and the Upstream direction.

Following Hybrid Link Initialization, the VO port shall assume the role of the Sender and the VI port shall assume the role of the Receiver. The role of Sender and Receiver switches with every packet transfer in a ping-pong style. When this alternating behavior is stalled for some reason(e.g., if the Receiver fails to detect the incoming packet, both the VO and VI ports end up in Receiver mode with a resulting deadlock), the VO port shall detect this situation by using a timeout counter and shall switch into Sender mode after the timeout triggers.

The timeout counter waits for the start of the incoming packet (i.e., SOP) after entering Receiver Mode. If an SOP is not detected for 256-symbol time, a timeout shall occur. Also, the timeout counter waits for the end of the incoming packet (i.e., EOP) after receiving the start of the packet. If an EOP is not detected for 3072-symbol time, a timeout shall occur.

The implementation doesn’t have to be the same as the state diagram in Figure 25, but the external behavior should be the same.


Figure 25 State Diagram for Sender/Receiver Mode Change in Hybrid Link

7.5.3 Basic Packet Flow

This section has several examples to illustrate the packet flow when there is no link error.

7.5.3.1 Transfer of a Single Packet

Figure 26 shows an example in which an AUDIO packet (#1) is transferred from a VO port (e.g., on a Source) to a VI port (e.g., on a Sink). Figure 27 shows an example in which an AUDIO


packet is transferred from the Sink to the Source. This scheme is also used for CMD packets andDATA packets, as shown in Figure 28.

Figure 26 Example of Packet Flow when the DS Audio Subchannel is Used

Figure 27 Example of Packet Flow when the US Audio Subchannel is Used

Figure 28 Example of Packet Flow when the US Command Subchannel is Used

7.5.3.2 Packet Transfer with both DS and US Packets

Figure 29 shows an example in which two AUDIO Packets (#1 and #3) are transferred from the VO port of a Source to the VI port of a Sink and a CMD Packet (#2) is transferred from the Sink to the Source at the same time.


Figure 29 Example of Packet Flow when both the DS Audio Subchannel and the US Command Subchannel are Used

7.5.3.3 Packet Transfer with Packet Arbitration

Figure 30 shows an example in which multiple transmitting terminals (e.g., AudioTx and CmdTx)in a device send requests (#1 and #2) at the same time. The Link shall arbitrate the requests according to the Subchannel priority.

Figure 30 Example of Packet Flow with Arbitration

7.5.3.4 Packet Transfer when Receiving Terminal is Not Ready to Receive

Figure 31 shows an example in which the NRDY Response Flag is returned when a receiving terminal is not ready to receive the packet. The Link that received the NRDY signal shall send the previously-sent packet after a certain time elapses to prevent excessive NRDY Response. This delay control is not mandated by the DiiVA specification and is implementation-specific. The other Subchannels (e.g., the Command Subchannel and the Data Subchannel) can be serviced while the Subchannel (e.g., Audio Subchannel) of the packet is on hold.


Figure 31 Example of Packet Flow when Receiving Terminal is not Ready

As shown in Figure 31, multiple re-transmissions are required because the sender cannot know the readiness of the receiving terminal. This multiple re-transmission will waste channel bandwidth. In order to prevent multiple retransmissions, the CH_RDY of the packet header can be utilized, as shown in Figure 32.

Following an NRDY response, CH_RDY shall be used by the Sender to decide whether to retry the transmission of a new packet to the Receiver.

Figure 32 Example of Packet Flow when Receiving Terminal is not Ready

7.5.4 Packet Flow for Link Error Recovery

This section has several examples that illustrate how to recover from a link error.


7.5.4.1 Retransmission after Receiving NACK

As shown in Figure 33, when a packet is transferred over the Hybrid Link, the receiving port shall check whether the packet is received without an error. For this check, CRC-32 is used. If the received CRC is not the same as the calculated CRC a packet with NACK (i.e., the RSP of the packet is NACK) is returned to the sender. If an HL port receives a packet with NACK, it shall send the most-recently-sent packet again.

Figure 33 Example of Packet Flow when CRC Doesn’t Match

7.5.4.2 Retransmission After Timeout Occurs

As shown in Figure 34, when a packet is transmitted, the sender shall re-send the packet if itfails to receive another packet after a timeout period. This might occur when a packet is lost (‘lost’ meaning that the start of the packet has not been detected properly and the decoding of the packet format has failed completely).

Figure 34 Example of Packet Flow when Timeout Occurs

7.5.4.3 Packet Drop After Sequence Bit Doesn’t Match

As shown in Figure 35, when a packet is transferred from a VO port to a VI port or vice versa, the Receiver shall check whether the Sequence Bit of the currently-received packet is the same as that of the previously-received packet. If the two Sequence Bits are the same, the Receiver shall drop the currently-received packet in order to prevent duplicate transmission of the packet.


Figure 35 Example of Packet Flow when Toggle Bit Mismatches

7.6 Quality of Service

The Hybrid Link is composed of multiple logical Subchannels. Each Subchannel requires a different QoS (Quality of Service), as shown in Table 19.

Table 19 Required QoS for Each Subchannel

Subchannel Required QoS

Audio Subchannel High reliability and real-time streaming are required

Command Subchannel High reliability and low-latency are required

Data Subchannel High reliability and high-bandwidth are required

In order to achieve high reliability, a 32-bit CRC code and a 1-bit Sequence Bit are used for error detection, and a packet retransmission is used for error recovery.

To make multiple Subchannels share the bandwidth of the Hybrid Link, a priority-based arbitration scheme can be used. The details are explained elsewhere.

7.6.1 Reliable Transfer: Error Detection

7.6.1.1 CRC-32 Check

As described in section 7.4.3.3, packet errors detected using CRC-32 are retransmitted.

7.6.1.2 Sequence-Bit Check

The Sequence Bit is used to detect redundantly-duplicated packets. The Sequence Bit represents the value of a 1-bit sequence number for one direction of a Subchannel. IDLE Packet also requires Sequence Bit to detect the duplication because IDLE Packet can be used to transfer some information between the adjacent devices or to access devices in PoD mode. Thus, in the current version, the Hybrid Link has ten 1-bit sequence numbers: one bit for each directional Subchannel (i.e., the DS Audio, US Audio, DS Command, US Command, DS Guaranteed Data, US Guaranteed Data, DS Best Effort Data, and US Best Effort DataSubchannels), and one bit for each directional IDLE Packet (i.e., DS IDLE Packet and US IDLE Packet).

If a packet with S = 0 (e.g., AudioPkt0) is used to transmit data, a packet with S = 1 (e.g., AudioPkt1) will be used next time there is data to transmit over the same Subchannel (e.g., Audio Subchannel).


Conversely, if a packet with S = 0 (e.g., AudioPkt0) is received, the previously-received data packet must have been a packet with S = 1 (e.g., AudioPkt1). Furthermore, a packet with S = 1 (e.g., AudioPkt1) is expected in the next data packet over the same Subchannel (e.g., Audio Subchannel).

7.6.1.3 Timeout Check

If a VO port has not received a packet within <TBD>ms after completing the transmission of the previous packet, it shall time-out and retry the previously-transmitted packet. VI ports may have a similar internal time-out mechanism for diagnostic purposes but shall not retransmit packets based on any factor other than RSP and CH_RDY flags.

When a timeout occurs frequently, the link status shall be reported to the link management layer.

7.6.1.4 Link Statistics (INFORMATIVE)

Table 20 shows example statistics that can be used to monitor the link state. The details of link statistics are not mandated by the DiiVA specification.

Table 20 Parameters for Link Statistics

ParameterVO

PortVI

PortDescription

TIMEOUT_CNT O X This value increases by 1 whenever Timeout happens.

CRCERR_CNT O O This value increases by 1 whenever CRC Mismatch happens.

NACK_CNT O O This value increases by 1 whenever a packet with NACK is received.

AUDIO_NRDY_CNT O OThis value increase by 1 whenever the previously sent packet is AUDIO Packet and the RSP of the currently received packet is NRDY.

CMD_NRDY_CNT O OThis value increase by 1 whenever the previously sent packet is CMD Packet and the RSP of the currently received packet is NRDY.

DATA_NRDY_CNT O OThis value increase by 1 whenever the previously sent packet is DATA Packet and the RSP of the currently received packet is NRDY.

AUDIO_ACK_CNT O OThis value increase by 1 whenever the previously sent packet is AUDIO Packet and the RSP of the currently received packet is ACK.

CMD_ACK_CNT O OThis value increase by 1 whenever the previously sent packet is CMD Packet and the RSP of the currently received packet is ACK.

DATA_ACK_CNT O OThis value increase by 1 whenever the previously sent packet is DATA Packet and the RSP of the currently received packet is ACK.

These statistics can be interpreted as follows:

The sum of TIMEOUT_CNT, CRCERR_CNT, and NACK_CNT represents the number of retransmissions due to link errors. This value is useful in determining the link integrity.

The sum of AUDIO_NRDY_CNT, CMD_NRDY_CNT, and DATA_NRDY_CNT represents the number of retransmissions due to the non-readiness of the receiving terminals in the communicating device.

The sum of TIMEOUT_CNT, CRCERR_CNT, NACK_CNT, and AUDIO/CMD/DATA_NRDY is the total number of retransmissions.

The sum of AUDIO_ACK_CNT, CMD_ACK_CNT, and DATA_ACK_CNT represents the number of successfully transferred packets over each Subchannel.

7.6.2 Subchannel Arbitration and Priority

As discussed in the description of the Subchannels, in most cases the Audio Subchannel should receive the highest priority in the arbitration for access to the link during the transmission phase (between the alternating receiving phase). When there is no AUDIO Packet to send, the Command Subchannel sends its queued CMD Packets. The Data Subchannels, with the lowest


priority, are scheduled for transmission when there are no packets queued for the Audio and Command Subchannels. If there is no DATA Packet, an IDLE Packet will be used to fill up the remaining bandwidth.

When the above default priority order cannot meet the system requirement (e.g., a certain DATA Packet is required to be transmitted within a limited time), some adjustments are acceptable if it does not hurt the QoS of each Subchannel.

Consequently, the sum of the bandwidth for the Audio and Command Subchannels should not exceed a reasonable share of the total transmission bandwidth, to ensure usable bandwidth for the Data Subchannels.

Furthermore, when NACK is received or a timeout occurs, a previously-sent packet (e.g., a DATA Packet) shall be transmitted before any other packets (e.g., an AUDIO Packet). Thus, new packet transmission arbitration shall be done only after the RSP and CH_RDY flags for the received packet are handled.

The above default behavior can be summarized by using priority, as shown in Table 21.

Table 21 Packet Transfer Priority

Priority Packet Description

HighestA previously sent packet (i.e., one of AUDIO/CMD/DATA/IDLE) if NACK is received or timeout happens

A previously sent and pending AUDIO Packet that received an NRDY Response

A new AUDIO Packet

A previously sent and pending CMD Packet that received an NRDY Response

A new CMD Packet

A previously sent and pending DATA Packet that received an NRDY Response

A new DATA Packet

Lowest IDLE Packet

7.7 Command Subchannel

As shown in Table 16, the Command Subchannel supports two services, i.e., DiiVA Control Layer (DCL) and TEST for Debugging. They use the CMD Packet as shown in Figure 36, where both DCL and TEST use a 32-byte payload to represent the command and response for the services.

When Service ID is 4’b0000 (i.e., DCL) in the Command Subchannel, SSINFO [31..0] is used as follows:

[31..0]: See DCL Section for details.

When Service ID is 4’b1111 (i.e., TEST) in the Command Subchannel, SSINFO [31..0]

can be used for any debugging purpose. Devices should route such packets to the destination address.


Figure 36 CMD Packet Format for the Command Subchannel

7.8 Data Subchannel

As shown in Table 16, the current DiiVA specification supports two Data Subchannels, i.e., Guaranteed Data Subchannel and Best Effort Data Subchannel. Each Data Subchannel has different characteristics as follows:

Guaranteed Data Subchannel: This channel guarantees the packet transfer without any packet drop even in congestion. This channel shall be used to relay the USB packet because the USB protocol is not robust to the packet drop. And, this channel will also support General Purpose Bulk Data which is used to transfer the DiiVA internal bulk data.

Best Effort Data Subchannel: In this channel, a packet can be dropped if the total channel

bandwidth is fully occupied by the other subchannels. This channel shall be used only to packet-drop-tolerant protocols, e.g., Ethernet.

They use the DATA Packet as shown in Figure 37, where a variably-sized payload represents the command and response for the services. As the maximum size of an Ethernet packet is 1518bytes and the maximum size of a USB packet is 1027 bytes, the 1984-byte payload capacity of DATA Packet is big enough to encapsulate either an Ethernet packet or a USB packet.

Figure 37 DATA Packet Format for the Data Subchannel


8 DiiVA Control Layer (DCL)

This chapter describes the DiiVA Control Layer (DCL), which utilizes the Command Subchannel of the Hybrid Link.

8.1 Hybrid Link Addressing

The DDA uniquely and globally identifies each DiiVA device in the DiiVA cluster of connected devices.

Static, non-volatile and unique 48-bit value, which shall not be all 1’s or all 0’s or have eight MSbs all 1’s. No other DiiVA device may share the same DDA value.

Entire DDA is used in the HL header address fields and for routing tables in DiiVA systems.

DDA that is all 1’s (48’FFFFFFFFFFFF) is a Broadcast address. Any device which receives a packet with Broadcast DDA in the Destination field transmits the same packet to all the other Hybrid Link ports.

8.2 Examples of a DiiVA Network

8.2.1 Source and Sink Only

Figure 38 Basic DiiVA Devices

In this most basic DiiVA configuration, the data paths are simple. There is a single video stream and a single audio stream from the Source device to the Display device. The Hybrid Link data from each device may only be addressed to the other device.

VO Port

VI Port

Video Stream

Hybrid Link


8.2.2 Daisy Chain Device

Figure 39 DiiVA Daisy Chain Device

A daisy-chain device has both VO and VI ports. Such a device is responsible for switching the video source from pass-through to internally-generated content, as directed by the user. If it is the source of the video data, then the video switch is connected to the video source of the device. If an upstream device is the Source, the video data is ‘passed through’ the device, with the video switch in ‘pass through’ mode.

For the Hybrid Link data, the daisy-chain device shall perform packet-switching duties based on the Destination DDA. Any Hybrid Link packet being sourced from the device or packets entering the device from either a VI or VO port shall have their destination address examined to decide if the packet is to be consumed (i.e., it has reached its destination), transmitted out to either of the Hybrid Link ports or is to be discarded (no routing information available for specified destination).


8.2.3 DiiVA Switch

Figure 40 DiiVA Switch Device

A DiiVA switch as having more than one DiiVA port. It uses the same packet switching techniques to route the Hybrid Link packets and establish the path for video data from Source to display. It may have more than one VO port.

8.3 Device Discovery


8.3.1 Capabilities List Structure

The Heartbeat Packet contains a bit field which shows the functions of the device. The 32 bits are represented in payload bytes 4 through 7 and ‘1’ indicates availability of the function.

Table 22 Capabilities (Caps) List Format in Heartbeat Packet


8.3.2 Routing Table Management

The routing table entries are created when a Heartbeat broadcast packet with INIT_DDA not in the current table is received. The entry is associated with the Hybrid Link port on which the


packet was received. All future attempts to route packets with Destination DDA matching this entry shall use the associated Hybrid Link port to transmit the packet.

Any device receiving any packet where INIT_DDA matches its own DDA shall discard the packet without forwarding to any port.

8.3.3 Network Topology

The TTL (TimeToLive) field in the HL Header of Heartbeat Packet can be used to determine the number of hops between the sender of the Heartbeat and the receiver. The TTL value shall start at 8 and count down at each transmitter until it reaches zero, at which time it shall be discarded. The number of hops is calculated as 8-TTL. This limits the number of hops allowed between any two devices in the connected cluster to 8 In addition, the number of VI and VO ports in the Caps list will identify the device topology.

8.4 DiiVA Control Layer Overview

DCL (DiiVA Control Layer) is an application layer that uses the Hybrid Link Command Sub-Channel for the following functions:

Heartbeat broadcast Physical link configuration Capability/status retrieval Remote control devices Video, Audio, data service, Connection Management Copy Protection Management

8.4.1 DCL Packet Format

Table 23 DCL Packet Format


Word 31 24 23 16 15 8 7 0

0Reserved

CH_ID

(=2)

DEST_SID

(=0)DEST_DDA[47..32]

1 DEST_DDA[31..0]

2Reserved

INIT_SID

(=0)INIT_DDA[47..32]

3 INIT_DDA[31..0]

4

5

6

7

8

9

…

15

A DCL packet is transferred through the Command Sub-channel (CH_ID=2) with Service ID (DEST_SID and INIT_SID) 0. It is mainly used for information and configuration exchange of small size between DiiVA devices. Destination and Source Address are the 48-bit DiiVA Device Addresses. Service Specific Info at word offset 5 consists of 8-bit DCL Opcode [31..24] and 24-bit DCL Opcode Specific Info [23..0]. Payload Length for the DCL Packet shall be 32 bytes but each DCL Opcode shall determine which part of the payload data is relevant.


The following tables are a summary of the DCL Packets, Opcode, and packet-specific parameters.


Table 24 Basic DCL Packets

Basic DCL Packets OpCode Opcode Info Parameters (bytes) PayloadSize

Table 25 Video Circuit Management Packets

Video Connection Management DCL Packets

OpCode Opcode Info Parameters (bytes) PayloadSize

Table 26 Audio Connection Management Packets

Audio Connection Management DCL Packets



Table 27 USB Connection Management Packets

USB Connection Management DCL Packets


8.5 Basic DCL Packets


8.6 Capability Sections



9 Audio/Video Application Layer

9.1 Video

9.1.1 Video Format Requirements

DiiVA supports the video formats specified in CEA-861-E. In addition, DiiVA can support any vendor-defined format.

Source Requirements

A DiiVA device that is capable of playing back in-device or remote A/V or video-only content, and that is capable of outputting that video across any analog or uncompressed digital video output shall be capable of outputting that video onto DiiVA, acting as a DiiVA Video Source.

A DiiVA Source shall support at least one of the following video format timings:

640x480p @ 59.94/60Hz

720x480p @ 59.94/60Hz

720x576p @ 50Hz

If a DiiVA Source fails in its attempt to read the Capability Section of a DiiVA Sink, the Source shall use one of the above three formats using YCbCr 4:2:2 at 8 bits per component.

A DiiVA Source that sends 60Hz video formats, and that supports HDTV capability, shall support 1280x720p @ 59.94/60Hz or 1920x1080i @ 59.94/60Hz video format timings.

A DiiVA Source that sends 50Hz video formats, and that supports HDTV capability, shall support 1280x720p @ 50Hz or 1920x1080i @ 50Hz video format timings.

A DiiVA Source that is capable of transmitting any of the following video format timings using any other component analog or uncompressed digital video output shall be capable of transmitting that video format timing across the DiiVA interface at the same bits-per-pixel depths.

1920x1080p @ 59.94/60Hz

1920x1080i @ 59.94/60Hz

1280x720p @ 59.94/60Hz

720x480p @ 59.94/60Hz

1920x1080p @ 50Hz

1920x1080i @ 50Hz 1280x720p @ 50Hz

720x576p @ 50Hz

A DiiVA Source shall support YCBCR 4:2:2 color space at 8 bits per component or RGB 4:4:4 color space at 8 bits per component for all supported video format timings.

Sink Requirements

A DiiVA device that is capable of receiving uncompressed video signals using any other component analog or digital video input and rendering or processing that video, shall be capable of receiving video across the DiiVA interface, acting as a DiiVA Video Sink.

A DiiVA Sink that accepts 60Hz video formats shall support the 640x480p @ 59.94/60Hz and 720x480p @ 59.94/60Hz video format timings.

A DiiVA Sink that accepts 50Hz video formats shall support the 640x480p @ 50Hz and 720x576p @ 50Hz video format timings.


A DiiVA Sink that accepts 60Hz video formats, and that supports HDTV capability, shall support 1280x720p @ 59.94/60Hz and 1920x1080i @ 59.94/60Hz video format timings.

A DiiVA Sink that accepts 50Hz video formats, and that supports HDTV capability, shall support 1280x720p @ 50Hz and 1920x1080i @ 50Hz video format timings.

A DiiVA Sink that is capable of receiving any of the following video format timings using any other component analog or uncompressed digital video input shall be capable of receiving that video format timing across the DiiVA interface at the same bits-per-pixel depths.

1920x1080p @ 59.94/60Hz

1920x1080i @ 59.94/60Hz 1280x720p @ 59.94/60Hz

1920x1080p @ 50Hz

1920x1080i @ 50Hz

1280x720p @ 50Hz

A DiiVA Sink shall support YCBCR 4:2:2 color space at 8 bits per component and RGB 4:4:4 color space at 8 bits per component for all supported video format timings.

9.1.2 Enhanced Colorimetry Support

9.1.2.1 Gamut Packet and Gamut Boundary Description (GBD) Info

When the 1-bit GAMUT_VALID of the Video Link is 0, the colorimetry and Gamut of the current video frame shall follow the previously-transmitted AVI InfoFrame. <TBD need DCL equivalent of AVI InfoFrame, and then remove all references to AVI InfoFrame>.

When GAMUT_VALID is 1, the 3-bit GAMUT_NUM of the Video Link denotes which GBD Info of the Sink should be used for the upcoming video frames.

The 3-bit GAMUT_NUM of the Hybrid Link denotes which GBD Info of the Sink shall be updated with this packet. When multiple Gamut Packets are required for a single GBD, a sequence of Gamut packets is distinguished by using GAMUT_START and GAMUT_END as follows:

The first Gamut packet: GAMUT_START = 1 and GAMUT_END = 0 The intermediate Gamut packets: GAMUT_START = 0 and GAMUT_END = 0 The last Gamut packet: GAMUT_START = 0 and GAMUT_END = 1

If a single GBD is represented by a single Gamut packet, the packet is represented as follows:

A single Gamut packet: GAMUT_START = 1 and GAMUT_END = 1

9.1.3 Video Stream Management


9.2 Audio

9.2.1 Audio Format Requirements

Source Requirements

A DiiVA device that is capable of playing back in-device or remote A/V or audio-only content, and that is capable of outputting that audio across any line-level audio output or digital audio output shall be capable of outputting that audio onto DiiVA, acting as a DiiVA Audio Source.

A DiiVA Audio Source that is capable of transmitting any of the following audio formats using any other analog or digital audio output shall be capable of transmitting that audio format across the


DiiVA interface for the same number of audio channels supported by the other audio outputs at the same sample size bit depth.

L-PCM @ 192 kHz

L-PCM @ 176.4 kHz

L-PCM @ 96 kHz L-PCM @ 88.2 kHz

L-PCM @ 48 kHz

L-PCM @ 44.1 kHz

Compressed Bitstream (IEC-61937) @ 192 kHz


Compressed Bitstream (IEC-61937) @ 48 kHz Compressed Bitstream (IEC-61937) @ 44.1 kHz

DSD – all formats supported by other audio outputs

DST – all formats supported by other audio outputs

A DiiVA Audio Source shall support at least one of the following audio formats:

2-channel L-PCM @ 48 kHz with a sample size of at least 16 bits

2-channel L-PCM @ 44.1 kHz with a sample size of at least 16 bits

If a DiiVA Audio Source fails in its attempt to read the Capability Section of a DiiVA Audio Sink, the Audio Source shall use one of the above two formats.

A DiiVA Audio Source that is capable of transmitting DSD data across the DiiVA interface shall support the following format:

Fs @ 44.1 kHz corresponding to a bit rate of 2.8224 MHz

A DiiVA Audio Source that is capable of transmitting DST data across the DiiVA interface shall support at least one of the following formats:

DEST_Normal rate transmission with sampling frequency of 64*44.1kHz (2.8224MHz)

DEST_Double rate transmission with sampling frequency of 64*44.1kHz (2.8224MHz)

A DiiVA Audio Source shall have an audio sample rate within ±1000 ppm of the targeted sample rate.

Sink Requirements

A DiiVA device that is capable of receiving audio signals using any other line-level analog or digital audio input and amplifying or otherwise preparing that audio for conversion to sound, shall be capable of receiving audio across the DiiVA interface, acting as a DiiVA Audio Sink.

A DiiVA Audio Sink that is capable of receiving any of the following audio formats using any other digital audio output shall be capable of receiving that audio format across the DiiVA interface for the same number of audio channels supported by the other audio inputs at the same sample size.

L-PCM @ 192 kHz

L-PCM @ 176.4 kHz

L-PCM @ 96 kHz

L-PCM @ 88.2 kHz


L-PCM @ 48 kHz

L-PCM @ 44.1 kHz


Compressed Bitstream (IEC-61937) @ 96 kHz Compressed Bitstream (IEC-61937) @ 48 kHz

Compressed Bitstream (IEC-61937) @ 44.1 kHz

DSD – all formats supported by other audio outputs

DST – all formats supported by other audio outputs

A DiiVA Audio Sink shall support all of the following audio formats:

2-channel L-PCM @ 48 kHz with a sample size of at least 16 bits

2-channel L-PCM @ 44.1 kHz with a sample size of at least 16 bits

A DiiVA Audio Sink that is capable of receiving DSD data across the DiiVA interface shall support the following format:

Fs @ 44.1 kHz corresponding to a bit rate of 2.8224 MHz

A DiiVA Audio Sink that is capable of receiving DST data across the DiiVA interface shall support all of the following formats:

DEST_Normal rate transmission with sampling frequency of 64*44.1kHz (2.8224MHz)

DEST_Double rate transmission with sampling frequency of 64*44.1kHz (2.8224MHz)

A DiiVA Audio Sink shall support any audio sample rate within ±1000 ppm of the targeted sample rate.

9.2.2 Audio Subchannel

9.2.2.1 PAYLOAD Format for Audio Subchannel

As shown in Table 16, the Audio Subchannel supports a service, i.e., Audio. The service uses the AUDIO Packet as shown in Figure 41, where Audio Control uses a 32-byte payload to hold the audio control information while Audio Data uses a variable-size payload (32 to 192 bytes) to hold the audio data stream.

In order to decode the Audio Data for play back, the receiving device should know which audio format and encryption scheme are used. The information is delivered through a field (i.e., SSINFO [31..0]) of a packet header.

When Service ID is 4’b0000 (i.e., Audio) in the Audio Subchannel, SSINFO [31..0] is used asfollows:


Table 28 SSINFO Field Definitions in AUDIO Packet

Bits Description

31..18 Reserved

17Audio Mute

If set, the audio shall be muted regardless the content of audio stream.

16 Reserved

15

Encryption Indicator

0 = Not-encrypted

1 = Encrypted by using the specified Content Protection Scheme

14..8

Content Protection Scheme

0 = Content Protection is not enabled.

1 = China CP is enabled for Audio.

2 = HDCP 2.0 is enabled for Audio.

Others are reserved

7..0

Payload Format

0 = IEC (IEC 60958, IEC 61937) Audio Data is used

1 = Packed IEC 61937 Audio Data is used

2 = DSD (Direct Stream Digital) Audio Data is used

3 = DST (Direct Stream Transport) Audio Data is used

15 = Audio Control is used

Others are reserved

The information on the audio configuration (e.g., audio sampling frequency) is transferred using DCL (i.e., Audio InfoFrame).

The regeneration of the audio clock for playback is implementation-specific.

Figure 41 AUDIO Packet Format in the Audio Subchannel


9.2.2.2 Audio Data Size Constraints

If a high sampling rate (e.g., 192 KHz) multi-channel (e.g., 8 channel) audio stream is transferred with small-size (e.g., 32-byte) Audio Data, many small AUDIO Packets are required and they will degrade the Service Quality of other Subchannels; large AUDIO Packets should be used to avoid this situation. But large AUDIO Packet will suffer from the increased transfer latency. To address these factors together, there are recommendations for the Audio Data Size, as shown in Table 29 and Table 30.

Table 29 Recommended Audio Data Size for PCM

fs = Sample Frequency 2 CH PCM 4 CH PCM 6/8 CH PCM 10/12/14/16 CH PCM

32 KHz 32 Bytes 64 Bytes 128 Bytes 192 Bytes

44.1 KHz 32 Bytes 64 Bytes 128 Bytes 192 Bytes






Table 30 Recommended Audio Data Size for Non-PCM

Bit rate Non-PCM

< 1Mbps 32 Bytes

1 to 5 Mbps 64 Bytes

> 5 Mbps 192 Bytes

9.2.2.3 IEC Audio Data Format

When the IEC (IEC-60958, IEC-61937) Audio Data Format is used in Audio Data, every 8 bytes are formatted as shown in Figure 42, where up to 16 channels can be represented.

Figure 42 Audio Data Format for Linear PCM

The definition of each field is as follows:


Table 31 Field Definitions in IEC Audio Data Format

Field Description

CH [2..0]

Channel Indicator

0 = DATA0 is for Ch0, and DATA1 is for Ch1.


…


BStart of Block

If set, PCM0 is the first Sub-frame in a block that is defined in IEC-60958/61937.

P0 Parity Bit for DATA0

C0 Channel Status Bit for DATA0

U0 Under Data Bit for DATA0

V0 Validity Bit for DATA0

PCM0 [23..0] 24-bit data. This corresponds to Sub-frame 1 in IEC-60958/61937.

P1 Parity Bit for DATA1

C1 Channel Status Bit for DATA1

U1 Under Data Bit for DATA1

V1 Validity Bit for DATA1

PCM1 [23..0] 24-bit data. This corresponds to Sub-frame 2 in IEC-60958/61937.

* The definitions of P0, C0, U0, V0, P1, C1, U1, and V1 are same as IEC-60958.

9.2.2.4 Packed IEC-61937 Audio Data Format

When Packed IEC-61937 Audio Data Format is used in Audio Data, every 4 bytes are formattedas shown in Figure 43.

Figure 43 Audio Data Format for Non-PCM


Table 32 Field Definitions in Packed IEC-61937 Audio Data Format

Field Description

DATA0 [15..0] 16-bit data. This corresponds to the 16-bit data in Sub-frame 1 in IEC-61937.

DATA1 [15..0] 16-bit data. This corresponds to the 16-bit data in Sub-frame 2 in IEC-61937.

9.2.2.5 Direct Stream Data (DSD) Audio Data Format

When DSD (also known as One Bit Audio) Audio Data Format is used in Audio Data, every 8 bytes are formatted as shown in Figure 44.


Figure 44 Audio Data Format for DSD


Table 33 Field Definitions in DSD Audio Data Format

Field Description

CH [2..0]

Channel Indicator



…


V

Validity Bit for DATA0 and DATA1

0 = DATA0 and DATA1 do not contain any useful data

1 = DATA0 and DATA1 contain useful data

DATA0 [27..0],

DATA1 [27..0]

DATA0 is a 28-bit data for an even channel (e.g., Ch0), and DATA1 is a 28-bit data for an odd channel (e.g., Ch1).

The most significant bit (i.e., DATA0[27] and DATA1[27]) corresponds to the first bit of the 28-bit part of the DSD Audio Stream.

9.2.2.6 Direct Stream Transport (DST) Audio Data Format

When DST (as also known as Compressed DSD) Audio Data Format is used in Audio Data, every 32 bytes are formatted as shown in Figure 45.

Figure 45 Audio Data Format for DST



Table 34 Field Definitions in DST Audio Data Format

Field Description

SStart of a DST Frame

Set to 1 to indicate the start of a DST Frame.

V

Validity Bit for DATA’s

0 = DATA’s do not contain any useful data

1 = DATA’s contain useful data

D

Double Rate

0 = The transfer rate is equal to the sample rate.

1 = The transfer rate is double of the sample rate.

DATA0 [7..0], …

DATA30 [7..0]8-bit data

9.2.2.7 Audio Control Format

Audio Control has a general format as shown in Table 35.

Table 35 Audio Control General Format


0

TYPE

0 = Reserved

1 = AV_SEQ

2 = HDCP 2.0 Link Synchronization

Others are reserved

1 to 31 TYPE-dependent format

Table 36 shows the Audio Control format when TYPE is 1 (AV_SEQ).

Table 36 Audio Control Format for AV_SEQ



Table 37 shows the Audio Control format when TYPE is 2 (HDCP 2.0 Link Synchronization).


Table 37 Audio Control Format for HDCP 2.0 Link Synchronization



9.2.2.8 Audio Sink Clock Recovery Scheme


9.2.2.9 Sample Rates

An audio source shall not use, nor shall an audio sink indicate support for any sampling frequency not shown in Table 38. The audio source shall only transmit audio with an audio sampling frequency within +/- 1000 ppm of one of the specified sampling frequencies. The audio sink shall support any audio sampling frequency within +/- 1000 ppm of any supported sampling frequency. The audio playback capability of a DiiVA device shall be represented in the Capabilities ROM.

Table 38 Supported Audio Sampling Frequencies

fs = Sample Frequency(1),

Frame Rate

Channel Status Bit(2)

bit24 – bit27L-PCM(3) (2CH, 16CH)

Compressed Audio (2CH, 16CH)

32 KHz 1100 Support Support

44.1 KHz 0000 Support Support






768 KHz 1001 Not Support Support(1) Compared with the sampling frequency of IEC 60958, three cases (i.e., 22.05 KHz, 24 KHz, and Sampling frequency not indicated) are not included.


9.2.3 Audio Stream Management


9.2.4 Packets for Audio Stream Management


9.3 A/V Synchronization


9.4 DiiVA A/V Content Protection Options

9.4.1 Content Protection Recommendation

It is recommended that DiiVA devices implement content protection such as HDCP 2.0 for streams of uncompressed digital audio and video display data. Furthermore, DiiVA Source and Sink devices with Ethernet capability are encouraged to implement content protection such as DTCP-IP for distribution of compressed file contents.

9.4.2 HDCP 2.0

The HDCP 2.0 video encryption/decryption block is an interface block between the Video Link layer and Video Link PHY layer. As Video and Audio DiiVA packets are simultaneously sent over the Video Link and Hybrid Link respectively in a DiiVA port, Audio data requires a dedicated HDCP 2.0 encryption/decryption block in the Hybrid Link.

A DiiVA device that supports HDCP shall adhere to “HDCP For DiiVA Specification, Rev. 2.0”.

9.4.3 DTCP-IP

DTCP-IP implementations for DiiVA Source and Target Devices shall adhere to DTCP Volume 1 Supplement E Mapping DTCP to IP, Revision 1.2.

The Hybrid Link enables DTCP-IP over DiiVA networks by sending and receiving encapsulated Ethernet frames through DiiVA Data endpoints. For better switching of Ethernet frames over the DiiVA network, it is recommended that DiiVA devices support multiple QOS priorities for Ethernet frames.

Note that DiiVA devices do not support Jumbo or SuperJumbo Ethernet frames.

The Application Layers of Sources and Targets are responsible for implementation and execution of DTCP-IP.

9.5 DiiVA Equipment Control (DEC)

9.5.1 DEC Interoperability Rules

Requirements – DEC

A DiiVA device shall support the following DEC features:


9.5.2 DEC Overview

DiiVA Equipment Control (DEC) is a DiiVA Control Layer service for remotely requesting the types of operations commonly performed with handheld remote controls. The DEC command packet uses the payload portion of the DCL packets Remote Device Control Request and Remote Device Control Response. Not all Request packets require a response.


9.5.3 DEC Packet in DCL Packet

The DEC packet is a variable-length packet that is 2 to 32 bytes long. Each DEC code and sub-code pair may have up to 30 bytes of parameters based on the type of command, or it may have none.

Table 39 DEC Packet Bytes Description

Byte Description

0 DEC Code : Command Groups

1 DEC Sub-code: DEC Command

2 DEC Parameters [byte 0]

… DEC Parameters [bytes 1..28]

31 DEC Parameters [byte 29]

The Remote Device Control Request and Response are defined in the DCL Chapter and is reprinted here for reference.

9.5.3.1 Remote Device Control Request (Opcode 8h’06)

Table 40 Remote Device Control Request Packet Description

Function DiiVA Equipment Control

DEST_DDA Target device to perform the Control Request

INIT_DDA Requestor sending the packet

DEC Code DiiVA Equipment Control Code

Parameters Control code dependent parameters from 0 – 28 bytes

Table 41 Remote Device Control Request Packet Format


Word 31 24 23 16 15 8 7 0

… …

5 8h’06 Reserved

… …

8 DEC Code DEC Sub-code DEC Parameters [bytes 0..1]

9 DEC Parameters [bytes 2..5]

… …

15 DEC Parameters [bytes 26..29]


9.5.3.2 Remote Device Control Response (Opcode 8h’07)

Table 42 Remote Device Control Response Packet Description

Function DiiVA Equipment Control

DEST_DDA Target device to perform the Control Request

INIT_DDA Requestor sending the packet

Result 0 indicates success, non-zero is failure error code

DEC Code DiiVA Equipment Control Code

Parameters Control code dependent parameters from 0 – 31 bytes

Table 43 Remote Device Control Response Packet Format


Word 31 24 23 16 15 8 7 0

… …

5 8h’07 Reserved Result

… …

8 DEC Code DEC Sub-code Result Parameters [bytes 0..1]

9 Result Parameters [bytes 2..5]

… …

15 Result Parameters [bytes 26..29]

9.5.3.3 Error Response

When the DiiVA device is unable to perform the request, a non-zero Result code shall be returned to the requestor (INIT_DDA) with the original DEC packet.

Table 44 Error Response Description

Result Description

0 No Error (Not all DEC requests require response)

1 DEC Request in Code/Sub-code not supported

2 Device Internal Error

3 Invalid Parameters

4 Invalid current context for command

9.5.4 DEC Packets



Table 45 DEC Command Groups

Group code

Command Groups Description

0 General commands All devices

1 Navigation commands All devices

2 Tuner commands Tuner Devices (TV, Set-top)

3 Recorder commands AV Recorder Devices (Set-top, DVR)

4 Playback commands AV Player Devices (DVD, Set-top, DVR)

5 Audio commands Audio Playback Devices (TV, AVR)

254 User defined commands User/CE-Vendor defined commands

9.5.4.1 General Commands

Table 46 DEC General Commands

Sub-code

General (=0) commands Description and Parameters Mandatory

9.5.4.2 Navigation Commands

Table 47 DEC Navigation Commands

Sub-code

Navigation (=1) commands

Description and Parameters Mandatory


9.5.4.3 Tuner Commands

Table 48 DEC Tuner Commands

Sub-code

Tuner (=2) commands Description and Parameters Mandatory

9.5.4.4 Recorder Commands

Table 49 DEC Recorder Commands

Sub-code

Recorder (=3) commands Description and Parameters Mandatory

9.5.4.5 Player Commands

Table 50 DEC Player Commands

Sub-code

Player (=4) commands Description and Parameters Mandatory

9.5.4.6 Audio Commands

Table 51 DEC Audio Commands

Sub-code

Audio (=5) commands Description and Parameters Mandatory


9.5.4.7 Closed Captioning Commands

Table 52 DEC Closed Captioning Commands

Sub-code

TBD Description and Parameters Mandatory


10 USB Application Layer

10.1 Requirements – USB

A DiiVA Video Sink that has a USB ”Host” port shall support making USB devices connected to that port available to the selected DiiVA Video Source or other appropriate DiiVA device. A DiiVA Video Source that has a USB “Host” port shall support connection of USB devices through DiiVA of the same types that are supported using its local USB port.

10.2 USB Relay Support

USB-Relay support by DiiVA is a means to extend the USB connection from the USB-Host located at one of the DiiVA source devices to the USB-device or USB-Hub located at the DiiVA sink device. DiiVA Source and Sink devices shall intercept UTMI packets exchanged between USB-PHY device and the USB-Host or USB-Hub and ‘relay’ them over the connection.

The USB-relay packet switched connection shall be established by the DiiVA Source device (the PC in the example below), broadcasting HL_Cmd_USB_Active_Host and HL_Cmd_Active_Hub_Request packets. The Sink device, TV, shall respond with HL_Cmd_USB_Active_Hub, creating the bi-directional data connection.

Figure 46 USB Relay Packet Switched Connection

10.3 USB Data Service

DiiVA Hybrid Link extends the USB connection through the DiiVA network. The USB in DiiVA connects USB Host to USB Device seamlessly and transparent to DiiVA network. The DiiVA network behaves as if there is only a USB cable between a USB Host and a USB Device. And whole DiiVA network including a USB Device behaves as if there is only a USB Device connected to USB Host through a USB cable and USB Upstream-facing port.


Figure 47

USB connection in DiiVA is illustrated in devices, one connected to USB Host and the other connected to USB Device. In Host is connected to USB Upstreamto USB Downstream-facing portUpstream-facing ports or multiple

USB PHY

UT

MI

orU

LPI

USB Upstream

Module

USB Host

USB Cable

DiiVA Device A

USB PHY

UTM

IorU

LPI

USB Upstream

Module

USB PHY

UTM

Ior

ULP

I

USB Downstream

Module

USB Upstream Port

USB Downstream Port

Figure



47 USB Ecosystem with DiiVA Network

USB connection in DiiVA is illustrated in Figure 47. A USB connection requires twdevices, one connected to USB Host and the other connected to USB Device. In

USB Upstream-facing port of DiiVA device A and USB Device is connected facing port of DiiVA device B. Any DiiVA device can have multiple

s or multiple USB Downstream-facing ports.

DiiVANetwork

DiiVA Device A

USB PHY

UT

MI

orU

LPI

USB Downstream

Module

DiiVA Device B

DiiVAHybrid

Link

DiiVAHybrid

Link

USB PHY

UTM

IorU

LPI

USB Downstream

Module

USB PHY

UTM

Ior

ULP

I

USB Upstream

Module

Figure 48 USB Block Diagram in DiiVA



. A USB connection requires two DiiVA devices, one connected to USB Host and the other connected to USB Device. In Figure 48, USB

of DiiVA device A and USB Device is connected DiiVA device can have multiple USB

USB Device

USB Cable


11 Ethernet Application Layer

11.1 Requirements – Ethernet

A DiiVA device that has Ethernet capability using any other external (wired or wireless) connection shall be capable of carrying Ethernet across the DiiVA interface.

11.2 Ethernet Data Service



12 Power over DiiVA (PoD)

12.1 PoD Overview

This section describes the power delivery mechanism in DiiVA. This mechanism is termed PoD(Power over DiiVA). Via PoD, DiiVA is capable of providing basic operational power to devices on the network.

12.1.1 Power States

This section defines and uses the following System Power States and Power States for the DiiVA devices:

Table 53 DiiVA Power States

System Power State Local Power Available PoD Power Available DiiVA Power State


12.2 DiiVA Topologies and PoD Domains

The DiiVA architecture allows DiiVA networks to be created in virtually unlimited topologies as shown in Figure 49. The figure shows a three room configuration with various Display devices, Repeaters, Switches, Transmitters and Daisy-Chain Devices. This figure allows data from any source device to be routed to a display device. This topology also allows the distribution of Ethernet to all of the DiiVA connected devices.


Figure 49 Sample DiiVA Interconnections


Figure 50 Sample DiiVA PoD Interconnect

12.3 PoD Implementation


Display

SinkDaisy Chain

SourceSource VIVI VOVO DiiVA

LinkDiiVALink

Display A

VI

Ethernet Link

Room A

VI

Display B Display C

VI

Room B Room C

Source A-1

VOVI

Source A-2

VO

Source A-4

VOVI

Source A-5

VOVI

DIVA Link

R R

Source B-2

VO

Source B-4

VOVI

Source B-5

VOVI

Source C-2

VO

Source C-4

VOVI

Source C-5

VOVI

Source A-1

VOVI

Source A-1

VOVI

SwitchA

VO

VO

VI

VI VI VI

SwitchB

VO

VO

VI

VI VI VI

SwitchC

VO

VO

VI

VI VI VI

VO Source C-3

Source B-3

VOSource A-3

VO

Source A-6

VOVI

Source B-6

VOVI

Source C-6

VOVI

R R


12.3.1 Board Level Implementation

Board level implementation is the actual power source for the PoD. The following sections describe the power delivery and extraction mechanism at the board level.

12.3.1.1 Block Diagram


12.3.2 Link Level Implementation

The following sections describe the Link Level implementation of PoD.

12.3.2.1 HL Routing in PoD mode

In normal HL operations, each node has a unique DDA and it actively participates in receiving, decoding, servicing and routing of packets as needed. In PoD mode, the HL interface operates very much the same as On mode, but it attempts to conserve as much power as possible by disabling various internal datapaths that are inactive.


13 Connectors and Cable Assemblies

This chapter defines form, fit and function of the DiiVA connectors and cable assemblies. Itcontains the following:

Connector mating interfaces Cables and cable assemblies Electrical requirements Mechanical and environmental requirements

The intention of this chapter is to enable connector, system, and device designers and manufacturers to build, qualify, and use DiiVA connectors, cables, and cable assemblies.

13.1 Physical Specifications

13.1.1 Pin assignment

Table 54 Connector and Cable Assembly Pin assignment

Pin Signal Assignment

1 GND

2 VL2+

3 VL2-

4 GND

5 VL1+

6 VL1-

7 GND

8 VL0+

9 VL0-

10 GND

11 GND

12 HL+

13 HL-

13.1.2 Contact Sequence

Table 55 Connector Contact Sequence

Connection Signals

First Mate Connector shell

Second Mate GND

Third Mate Data and Hybrid channels


13.1.3 Connectors

All dimensions are in millimeters.

13.1.3.1 Receptacle Connector

Figure 51 Receptacle Connector Interface Dimensions


Figure 52 Reference Receptacle Connector Footprint (Informative)


13.1.3.2 Plug Connector

Figure 53 Plug Connector Interface Dimensions (Part 1)


Figure 54 Plug Connector Interface Dimensions (Part 2)


Figure 55

Figure 56 Fully Mated Space between Receptacle and Plug Overmold


55 Plug Connector with Active Latches

ted Space between Receptacle and Plug Overmold


ted Space between Receptacle and Plug Overmold


DiiVA Receptacle and Plug rules:

The Receptacle shell shall have springs for activated by the corresponding retentionsprings are required on the ReceptacleEMI reduction.

Active Latches on the Plug are recommended. If Active Latches are employed, a manuamechanism accessible from the top of the Plug overmold area is required to release the Plug.


Figure 57 Cable Bend

DiiVA Receptacle and Plug rules:

shell shall have springs for retention. The spring property for retentionding retention hole or dimple of the Plug shell.

on the Receptacle. Side springs are recommended on the Receptacle for

Active Latches on the Plug are recommended. If Active Latches are employed, a manuamechanism accessible from the top of the Plug overmold area is required to release the Plug.


retention shall be . Top and bottom

recommended on the Receptacle for

Active Latches on the Plug are recommended. If Active Latches are employed, a manual release mechanism accessible from the top of the Plug overmold area is required to release the Plug.


13.1.4 Cable Construction

A specific cable construction is not mandated cable construction that is appropriate foresulting cable assembly shall satisfy described in this document. It is recommended that cable vendors consider theof their applications when designing illustrated below are examples of cable constructions that maycable assemblies.

a. FTP Cable

Figure 58 Bulk Cable Construction

Signal Pairs: The cable constructthe performance of the cable constructionassembly, inclusive of the 2 plug connectors as defined in section Figure 60. The three differential pairs assigned to Gbps data rate at a bit error rhybrid link, shall support up to S3 speed or 4.32

Conductor AWG is not specifiedspecification in Table 59.

Insulation material is not specified. better performance.

Shielding on signals pairspecification in Table 59.

Shielding: Cable shielding is not specified

helpful in meeting EMI requirements

Jacket: An overall jacket shallcomponents, such as shielding.

Safety Ratings: The cable shallapplication (e.g. UL) for electric device / equipment external connectionfollowing requirements:

Temperature: 80℃ minimum

Flame retardant: VW-1 or better Voltage: 30V ac minimum


cable construction is not mandated in this document. Cable vendors may choose appropriate for the cable length required by the application

shall satisfy all electrical, mechanical, and environmental specificationIt is recommended that cable vendors consider the

applications when designing the cable construction. FTP and STP cable structures as below are examples of cable constructions that may be appropriate for use with

b. STP Cable

Bulk Cable Construction Examples (Informative)

The cable construction shall have four differential pairs (eight conductorscable construction shall be measured over the complete cable

sive of the 2 plug connectors as defined in section 13.1.3.2hree differential pairs assigned to the video link shall each support up to 4.5

at a bit error rate of less than 10-9. The fourth differential pairshall support up to S3 speed or 4.32 Gbps at a bit error rate of less than

onductor AWG is not specified. The cable assembly insertion loss

nsulation material is not specified. Low relative permittivity is recommended to obtain

pairs is not specified. The cable assembly crosstalk

able shielding is not specified. Cable vendors may find cable shielding to be requirements of their application.

shall encase all the signal pairs and other cable construction shielding.

shall be recognized or listed by the appropriate agency for the for electric device / equipment external connection

minimum

1 or betterVoltage: 30V ac minimum


. Cable vendors may choose a the application. The

and environmental specificationsEMI environment

FTP and STP cable structures as appropriate for use with DiiVA

eight conductors) and over the complete cable

13.1.3.2, as shown in support up to 4.5

. The fourth differential pair, assigned to the at a bit error rate of less than 10-12.

he cable assembly insertion loss shall meet the

ow relative permittivity is recommended to obtain

he cable assembly crosstalk shall meet the

may find cable shielding to be

cable construction

by the appropriate agency for the for electric device / equipment external connection, including the


13.1.5 Wire Assignment

Table 56 Cable Wire Assignments

Wire Number Signal Name Reference Color

1 VL2+ Brown

2 VL2- White (Brown)

3 VL1+ Orange

4 VL1- White (Orange)

5 VL0+ Blue

6 VL0- White (Blue)

7 HL + Green

8 HL - White (Green)

DiiVA Cable Wire Assignment rules:

It is recommended that cables be constructed with wires matching the wire number with the colors noted above. It is recommended that White-colored wires include a stripe with the color noted in parentheses above.


13.1.6 Cable Wire Connection

Figure 59 Plug Connector

Table 57 Cable Wire Connection

*Wire color and number are recommendation

DiiVA Cable Wire Connection rules:

It is allowed to connect GND pins together in a cable assembly.

It is allowed to leave all GND pins unconnected in a cable assembly.


13.2 Electrical Requirements

13.2.1 Connector and Cable Assembly Electrical Performance

Table 58 shows the electrical performance requirements for a DiiVA external connector.

Table 58 Connector Electrical Performance

Item Test Condition Requirement

Contact Resistance Mated connectors,

Contact : measure by dry circuit,

20 mVolts max., 100mA.

Shell : measured by open circuit,

5 Volts max., 100mA.

(ANSI/EIA-364-06B)

Contact: Initial contact resistance excluding conductor resistance: 70m max.

(Target design value)

Shell: Initial contact resistance 30m max. for a mated connector

Dielectric Strength Unmated connectors: apply 350 Volts AC (RMS) between adjacent contacts.

Mated connector: apply 200 Volts DAC (RMS) between adjacent contacts.

(EIA 364-20B, Method B)

No Breakdown

Insulation Resistance Unmated connectors: apply 350 Volts DC between adjacent contacts.

(EIA 364-21C)

100 mega ohms minimum

Mated connectors, apply 150 Volts DC between adjacent terminal or ground

10 mega ohms minimum

(mated)

Contact Current Rating Conduct a temperature rise vs. current test

(EIA 364-70A, Method 2)

0.5 A per pin minimum.

The temperature rise above ambient temperature shall not exceed 30C

The ambient condition is still air at 20C

Applied Voltage Rating 40 Volts AC (RMS.) continuous maximum, on any signal pin with respect to the shield.

No Breakdown

Electrostatic Discharge Test each unmated connector from 1 kVolt to 8 kVolts in 1 kVolt steps using 8mm ball probe

(IEC-801-2)

No evidence of Discharge to Contacts at 8 kVolts

13.2.2 Cable Assembly Signal Integrity Requirements

Table 59 lists the signal integrity performance requirements for a DiiVA cable assembly. Testing methods include both time domain and frequency domain measurements. The cable assembly test points are located at the board-end connectors at both ends of the test fixtures as illustrated in Figure 60.


Figure 60 Cable Assembly Test Points

Table 59 Cable Assembly Signal Integrity Requirement

Items Test Condition / Comments Requirement

Differential Impedance TDR Rise time:

100 ps (20% - 80%)<TBD Raw Cable +/- 10 ohms?>

Mated Connector

100 ±15 ohms

Cable Termination

100 ±15 ohms

Raw Cable

100 ± TBD ohms

MDFEXT Measured up to 6.75 GHz

Multiple Aggressors with power sum calculation (see equation below)

< -20 dB

NEXT Measured up to 6.75 GHz, between bi-direction link and the adjacent data link

See Figure 61

Attenuation Measured up to 6.75 GHz See Figure 62

Return Loss Measured up to 6.75 GHz See Figure 63

Intra-pair skew Measured at 50% of rise time < 150 ps

Pair to pair skew Measured at 50% of rise time 5 ns

Notes: 1. Frequency domain parameters are defined up to the third harmonic of the highest DiiVA data rate at 4.5 Gbps.

2. MDFEXT equation: n fFEXT n

fMDFEXT1

)10

)((

1010*10)( log


Figure 61 NEXT Requirement

Figure 62 Attenuation Requirement

NEXT

(6.75GHz ; -10db)

(2.25GHz) ; -20db)

-25

-20

-15

-10

-5

0

0 1 2 3 4 5 6 7

Frequency (GHz)

NE

XT

(d

b)

Attenuation

(0.1GHz ; -9db)

(1.5GHz ; -27db)

(2.25GHz ; -34db)

(6.75GHz ; -66db)

(5.5GHz ; -57db)

(4.5GHz ; -50db)

(3.5GHz ; -43db)

-70

-60

-50

-40

-30

-20

-10

0

0 1 2 3 4 5 6 7

Frequency (GHz)

Att

en

uat

ion

(d

b)


Figure 63 Cable Return Loss Requirement

13.3 Mechanical and Environmental Requirements

13.3.1 Mechanical Performance

Table 60 specifies the mechanical performance requirements for a DiiVA external cable assembly.

Return Loss

(6.75GHz ; -3db)

(2.25GHz ; -10db)

-12

-10

-8

-6

-4

-2

0

0 1 2 3 4 5 6 7

Frequency (GHz)

Ret

urn

Lo

ss (

db

)


Table 60 Connector and Cable Assembly Mechanical Performance


Vibration Amplitude : 1.52mm P-P or 147m/s2 {15G}

Sweep time: 50-2000-50Hz in 20 minutes.

Duration : 12 times in each

X, Y, Z axes (total: 36 times).

Feed DC100mA during the whole test.

(ANSI/EIA-364-28C, Condition III)

Appearance No Damage

Contact Resistance

Contact : 20mΩ max. change from initial value

Shell Part : 50mΩ change max. from initial value

Discontinuity 1 μsec maximum

Shock Pulse width: 11 millisecond

Waveform : half sine,

490m/s2 {50G}, 3 strokes in each X.Y.Z. axes

(ANSI/EIA-364-27B,

Condition A)


Contact Resistance

Contact : 20mΩ max. change from initial value



Durability 2500 cycles at 100 ± 50 cycles per hour

(ANSI/EIA 364-09B)

Contact Resistance

Contact : 20mΩ change max. from initial value


Insertion /

Withdrawal Force

(Plug without Active Latches)

Insertion and withdrawal speed : 25mm/minute.

(ANSI/EIA-364-13B)

Withdrawal force 10N minimum

40N maximum

Insertion force 44N maximum

Insertion /

Withdrawal Force

(Plug with ActiveLatches)

Insertion and withdrawal speed : 25mm/minute.

(ANSI/EIA-364-13B)

Withdrawal force 40N minimum.

No maximum. Manual release mechanism shallbe employed with Active Latches.

Insertion force 44N maximum

Cable Pull-Out Hold an axial load of 50N for a minimum of 1 minute.

(EIA 364-38B, Method A)

Appearance No physical damage

Cable Flex X = 3.7 x Cable Diameter.

(ANSI/EIA-364-41C,

Condition I)

100 cycles


Dielectric

Withstanding

Voltage and

Insulation

Resistance

Conform to item of

dielectric withstanding

voltage and insulation

resistance


13.3.2 Environmental Performance

Table 61 shows the environmental performance requirements for a DiiVA external cable assembly.

Table 61 Connector and Cable Assembly Environmental Performance


Thermal Shock 10 cycles of:

a) -55℃ for 30 minutes

b) +85℃ for 30 minutes

(ANSI/EIA-364-32C)


Contact Resistance



Humidity A Mated connectors:

Temperature range: +25 to +85°C Relative Humidity : 80 to 95% Duration : 4 cycles (96 hours)

Specimens shall be conditioned at ambient room for 24 hours, before taking any measurement.

(ANSI/EIA-364-31B)


Contact Resistance



B Unmated connectors:

Temperature range: +25 to +85°C Relative Humidity : 80 to 95% Duration : 4 cycles (96 hours)

Specimens shall be conditioned at ambient room for 24 hours, before taking any measurement.

(ANSI/EIA-364-31B)


Dielectric

Withstanding Voltage and Insulation Resistance

Conform to item of Dielectric Withstanding Voltage and Insulation Resistance.

Thermal aging Mated connectors:

Temperature: +105 ±2°C

Time: 250 hours.

Specimens shall be conditioned at ambient room conditions for 1 to 2 hours, before taking any measurement.

(ANSI/EIA-364-17B, Condition 4, Method A)


Contact Resistance



diiva specification 1.1 draft a informational version ...diiva specification 1.1 draft a -...

Documents