HDBaseT Contribution

Abstract: Technical proposal for HDBaseT link specification 2.0 is described.
Purpose: Provide ground base for Spec 2.0 development Release: Valens Confidential, Contributed Pursuant to Section 3.1 of the HDBaseT Alliance Bylaws.
HDBaseT Contribution
• Network Objectives
– Downstream sub link
– Upstream sub link
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens Semiconductor
• Support in parallel, over the same, home span cabling infrastructure, high quality networking of:
– Time sensitive data streams such as
• HDMI 1.4 streams with their associated controls
• S/PDIF streams
• USB streams
– Ethernet data
• Provides transparent network attachment for legacy devices/interfaces – HDMI, Ethernet, USB and S/PDIF
• Provides transparent network attachment for future supported devices/interfaces – Generalized core network services
• Self installable - HDBaseT devices do not have to be individually configured in order to operate correctly over the network
• Enable pure Ethernet devices to function as a HDBaseT Network Control Points
• Enable low cost solutions for the CE price points
3
• Downstream sub link:
– Local Retransmission - new mechanism for per hop retransmission to improve robustness and performance margin
• Upstream sub link:
– 300Mbps 25Msymbol/sec PAM16 symbols DC Balanced - double the throughput of Spec 1.0 upstream sub link
• 200Mbps bi-directional shared between USB 2.0, S/PDIF, IR and UART
• 100Mbps bi-directional Ethernet – same as Spec 1.0
• Support fallback to 100BaseTX as in Spec 1.0
• Support backward compatibility with Spec 1.0 devices
Proposed Link Spec 2.0 Features (1)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens Semiconductor 5
• Multi Stream support: At the same time, over a single link, support of up to:
– 8 HDMI 1.4 down streams
– 12 USB or S/PDIF bi directional streams
– 8 IR and 8 UART bi-directional streams
• Support for general framing to enable future protocols/interfaces clients for the HDBaseT network (see the rest of the presentation for more explanations about the concept)
• Support for T-Network services (see the rest of the presentation for more explanations about the concept)
• Support LPPF #1 as in Spec 1.0 and add support for IR and UART during LPPF #1
• Support the option for LPPF #2 as in Spec 1.0
• Support Wake UP / stand By HLIC commands for device power management
• Support link management HLIC commands
Proposed Link Spec 2.0 Features (2)
• A local, single, packet retransmission mechanism comprises the following steps:
– Each protected packet contains additional Packet ID (PID) as part of its header, PIDs are transmitted in sequential order
– The receiver detects a CRC error in a received packet with an expected PID or the receiver receives a good packet with gap in its PID
– The receiver sends a proper retransmission request to the sender
– The sender retransmit the packet back to the receiver
• In order to implement such mechanism without violating the packets sequential order (of the video data for instance) it is clear that the receiver must use packets buffer that will introduce latency on all protected packets good or bad
• When ever a retransmitted packet is received it will be inserted into its original location in the receiver packets buffer keeping the packets order
• The sender must also use a packets buffer to be able to save transmitted packets in case it will need to retransmit them
Local Retransmission Mechanism
Retransmission Conceptual Drawing – Bad CRC case
PhyDS Scheduler
Retrns Module
Retrns Module
PhyDS Scheduler
Retransmission request PID: 2
request PID: 2
Step 1: Sink detects CRC error on PID 2 and request Retransmission
Step 2: Source fetches PID 2 and Retransmit
Step 3: Sink receives the retransmitted PID 2 and place it in the right location in the buffer
0 -1
Retransmission Conceptual Drawing – Packet Loss/Corrupt Case
PhyDS Scheduler
Retrns Module
Retrns Module
PhyDS Scheduler
Retransmission request PID: 2
request PID: 2
Step 1: Sink detects that PID 2 lost and request Retransmission
Step 2: Source fetches PID 2 and Retransmit
Step 3: Sink receives the retransmitted PID 2 and place it in the right location in the buffer
5
• If a downstream packet was transmitted as participating in the retransmission mechanism, it will travel the rest of its downstream network path (per each network hop) as part of the retransmission mechanism
• Per session the T-Adaptor, may pre select to use retransmission protection for all packets, with certain packet types, or not to use it for all packets of these types (it shall not flip its selection during that session)
• Usage of retransmission introduces additional fix latency (of 7uS) per hop but shall not introduce more latency variation
• PAM16 packets will be protected using, per hop, single retransmission of equivalent PAM8 packets carrying the same data (the max payload length for retransmission protected, PAM16 packets, will be limited to 190 tokens)
• PAM8 and PAM4 packets will be protected using, per hop, single retransmission of the same packet
– Reception of a protected PAM4 packet, with bad CRC, will not cause retransmission since packet’s header modulation is the same as the payload therefore have equivalent probability to be erroneous
– Only gap detection will cause PAM4 retransmission
Packet Retransmission and Payload Modulation Relations
• An 8 bits retransmission header token will be added to such packets header, before the Length token
• For such packets, the CRC field is extended to 32 bits
• b4 at the Packet Type token will represent the presence of a retransmission header token (RTS Head) and a trailing CRC-32
• Total packet overhead increased by 4 TokD8 tokens
Packet Retransmission Changes to the Packet Format
Stream ID CRC-8 Idle… Payload
TokD8 TokDxx
Stream ID Idle… Payload
Payload Length TokD8 TokCrcTokCrcTokCrc
Packet Type and RTS Header Tokens
b7
b3:b0 -Packet type code is a 4 bits value which contains the packet type 0 to 15
b4 – when set to 1, is marking that this packet is part of the retransmission mechanism
b6:b5 - S4d Type is a two bits field marking the Payload’s s4d symbols type:
00 – s4dP16
01- s4dP8
10 – s4dP4
b7 - when set to 1 is marking that the extended header option is used and the next symbol is an extended info symbol
b6
b7
b6:b0 - Packet ID is a 7 bits sequential cyclic value continuously attach to each transmitted packet which is part of the retransmission mechanism (shared among all packet types)
b7 – RTSEnable
when set to 1, upon reception, this packet can cause a retransmission request and is inserted to the fix latency packets buffer
when set to 0 this packet is a retransmitted packet and therefore shall not cause a retransmission request
b6
Payload Length TokD8 TokCrcTokCrcTokCrc
• The HDBaseT network core provides general, packet based, T-Network services for the different clients attach to it:
– Highest level of, over the network, Transfer-Quality for packet headers
– Three levels of, over the network, Transfer-Quality for packet payloads translating into different packet error rate figures per quality level
– Three levels of, over the network, packet Scheduling-Priority translating into different latency and latency variation figures per priority level
– Clock measurement service, enabling the client to measure the frequency offset between the originating client clock and the target client clock to enable proper clock regeneration for mesochronous applications such as video
– Bad CRC notification, propagation to the End Node, enabling the end node to treat this packet according to its special application
– Nibble Stream service supporting split and merge of packets going in and out of the upstream links on their network path
HDBaseT T-Network Services
Quality and Priority
• For each HDBaseT packet type there are Transfer-Quality and Scheduling-Priority properties associated with it according to the requirement of the data type being carried by this packet
• Current packet types (Link Specification ver 1.0 and ver 2.0) will have, pre define, Quality and Priority association
• Future packet types/protocols (Link Specification ver 3.0 and higher) will carry their Quality and Priority in the extended type token, within each packet header
• Packet type’s, Quality and Priority properties, will be use, by the switches, along the network path to insure the proper service is provided, for this packet type
Transfer-Quality Codes
• The per packet type, Transfer-Quality property, creates differentiation in the service provided by the network, for different data types, in terms of target max Packet Error Rate (PER)
• For packets with higher Transfer-Quality, their payload will be transmitted using lower order modulation utilizing more channel bandwidth per info unit
• The HDBaseT Link will set the actual payload modulation order according to the channel condition and the required Transfer-Quality
Quality Code Max Allowed Packet Error Rate
Remark
1 (01) 1e-9 Normal Quality – Data transfer using this quality code shall be transfer with at least 1e-9 (PER)
2 (10) 1e-12 High Quality – Data transfer using this quality code shall be transfer with at least 1e-12 (PER)
3 (11) 1e-16 Very High Quality – Data transfer using this quality code shall be transfer with at least 1e-16 (PER)
Scheduling-Priority Codes • The per packet type, Scheduling-Priority property, creates differentiation in the service provided by the network, for different data types, in terms of target max latency and max latency variation over the full network path
• Packets with higher Priority will be schedule, for transmission over the HDBaseT network hops, before packets with lower Priorities
• Per stream, packets transmitted with the same Priority Code, will arrive to their destination, at the same order as they were transmitted
Priority Code
Target Max Latency Variation [DS, US]
Max BW per stream
1 (01) [100uS, 50uS] [10uS, 40uS] Large (DS BW)
Normal Priority – provides low latency variation for large BW Down streams such as video
2 (10) [100uS, 30uS] [10uS, 20uS] Medium (US BW)
High Priority – provides lower latency variation for mid BW Up streams such as S/PDIF
3 (11) [10uS, 20uS] [5uS, 10uS] Small Very High Priority – provides low latency for small BW, latency sensitive, data types such as DDC
Current Packet Types (Spec 1.0 and Spec 2.0) Pre Defined Quality and Priority Codes
Packet Type Packet Type Code
Quality Code Priority Code
Remarks
General Status 0 3 3 Non AV stream related status and control see
Ethernet data 1 2 2
Clock Info 2 3 2 Original Packet is generalized in Spec 2.0 to provide clock measurement service
Stream Control 3 3 3 DDC, CEC, HPD, 5V indication
HDMI-AV Control Data (CC) 4 3 1 Control period, no guard band
HDMI-AV Control Data (CG) 5 3 1 Control Period, ends with guard band
HDMI-AV Control Data (GC) 6 3 1 Control Period, starts with guard band
HDMI-AV Control Data (GCG) 7 3 1 Control Period, starts and ends with guard
HDMI-AV Active Pixels Data 8 1 1 Active Pixels Data
HDMI-AV Data Island Data 9 3 1 Data Island
USB Data 10 2 1 USB Data, new packet type, define in Spec 2.0
S/PDIF Data 11 2 2 S/PDIF Audio Data, new packet type, define in Spec 2.0
CIR / UART Data 12 3 3 Consumer IR and UART Data, new packet type, define in Spec 2.0
Reserved 13 2 2 Reserved packet type, define in Spec 2.0
Quality and Priority Data Types Plain
Priority Quality
Normal 1
High 2
High 2 USB
General Status Stream Control
Future Packet Types (Spec 3.0 and on) Will Use the Optional Extended Type Token
Bad CRC
Quality Priority
b7 b0
b3:b0 – New Packet type code is a 4 bits value which contains the packet type 0 to 15 there are 16 types per Quality and Priority
b4 – when set to 1, is marking that this packet should be protected by the retransmission mechanism
b6:b5 – are set to 11 which is not valid S4d Type
b7 - set to 1 is marking that the extended type symbol is following
b6
b7 b0b6
Extended Type
b1:b0 – S4d type same as the token Type field in the non extended packet type
b3:b2 – Priority Code of this type
b5:b4 – Quality Code of this type
b6 – Bad CRC propagation bit marking that this packet suffers a bad CRC in at least one of the network hops
b7 - when set to 1 is marking the presence of an additional Extended Info Symbol
b3b4b5
• Future packet types will carry the Transfer-Quality and Scheduling-Priority, properties in their extended type token:
Spec 2.0 Dynamic S4D Modulation per Transfer- Quality and HDBaseT Link Quality
• Per packet type, Per network hop, an HDBaseT downstream transmitter will determine, the proper s4d modulation to be use according to the quality of this next HDBaseT hop and the Transfer-Quality associated with this packet type
• Downstream receivers will periodically report (to the downstream transmitters) the quality of the HDBaseT link, using the Idle subtype tokens, transferred through the upstream link
• The downstream transmitter will use these reports to assign the proper s4d modulation according to the required Transfer-Quality
• Usage of retransmission, in conjunction with s4d modulation, is also a key factor for achieving the proper Transfer-Quality in the downstream link
• At the upstream link the s4d modulation is according to the Transfer-Quality:
– Sub packet types with Transfer-Quality Codes 1 and 2 uses s4dP16B symbols for their payloads
– Sub packet types with Transfer-Quality Code 3 uses s4dP8B symbols for their payloads
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens Semiconductor Valens Confidential
20
Usage of The Extended Control Info Token • While mapping a given set of information bits into different s4d symbols with different number of bits, represented per symbol (quantization per s4d symbol), there may be a need to use MSB zero padding in order to fit, the reminder of the information bits, into the last payload token
• When a payload of a packet may dynamically change its modulation it is important to mark, those MSB zero padding bits, to be able to reconstruct correctly the information
• The Extended Control Info token mark these cases:
• Extended Info is marked, as Extended Control Info, by Info Code (b5) equal 1
• b3:b2 are marking the number of MSB zero padding nibbles conveyed in the last payload token. If Control Info token do not exists, no padding is assumed
• Sync bit (b4), if set, is marking that the beginning of this frame is a sync point for an HDBaseT NibbleStream
Sync Bad CRC
Upstream Fixed Packet FormatUpstream Fixed Packet Format
• Upstream packet composed of 46 tokens (@ 25Mtokens/sec):
– Header (TokHdB)
– CRC (TokCrcB)
– IDLE (TokIdlB)
– Other Subpackets:
• Subheader : 5 bit type, 3 bit length (can be extended) modulated using PAM8B
• Payload: 8 or 12 bit tokens according to type modulated using PAM8B or PAM16B
– IDLE Subheader tokens are fillers
– Example:
21
Upstream Packet HeaderUpstream Packet Header
Field Value
Description Remarks
0 Training The rest of the Tokens are Idle tokens (TokIdlB) containing the scrambler's content
1 Ethernet Full 3x65 bits over 17 tokens, followed by extra payload
2 Ethernet Partial 2x65 bits over 11 tokens, followed by extra payload
3 No Ethernet First token will be a sub packet header
4-13 TBD
14 P2P Proprietary Vendor specific for point to point applications
15 IDLE The rest of the Tokens are Idle tokens (TokIdlB) containing the scrambler's content
22
Upstream Sub Packet HeaderUpstream Sub Packet Header
23
Sub header divided into: • Extension bit – Used to extend the sub header • Subtype – specifies sub packet type
– Subtype codes are the same as the downstream packet type codes – Some, downstream only, packet type codes, are used for special purposes over
the upstream sub link
• Length+1 = #payload tokens (not including Sub header and SID where applicable)
Spec 2.0 Upstream SubtypesSpec 2.0 Upstream Subtypes
Subtype Description Priority Upstream Modulation
Remarks
0 HLIC 2.5 PAM8B Followed by message (8 bit tokens)
1 Ethernet N/A PAM16B Followed by Ethernet Data (12 bit tokens)
2 Clock 2.5 PAM8B Followed by SID, clock type (1 token), clock (8bit tokens)
3 HDMI Controls 3 PAM8B Followed by SID, message (8-bit-tokens)
4 Extended ID 00 Ext = 1 (Ext = 0 Undefined)
8 Retransmission 2.5 PAM8B Followed by retransmission PIDs
9 Reserved 3 PAM8B for future US only subtypes
10 USB 1 PAM16B Followed by SID, message (12 bit-tokens)
11 S/PDIF 2 PAM16B Followed by SID, message (12 bit tokens)
12 CIR/UART 3 PAM8B Followed by SID, message (8-bit-tokens)
13 Reserved 2 PAM16B for future US/DS subtypes
14 Reserved for DS for future DS only types
15 IDLE (Ext=0) Ext. Length (Ext=1)
Length field indicates DS link quality
24
Future Upstream Subtypes (Spec 3.0 and on) will Future Upstream Subtypes (Spec 3.0 and on) will use the Optional Extended Subtype Tokenuse the Optional Extended Subtype Token
25
Asserting the extension bit together with subtype value of 4-7, Followed by an extended subtype token, is the method used to transmit future subtypes:
The extended subtype token defines subtype behavior on both US and DS link hops:
•Extension bit – can be used for additional subtype information •Bad CRC – Asserted if subpacket was subjected to CRC error somewhere along the network same as DS and also propagated to/from DS links
•Quality – same codes as DS Transfer-Quality defines subpacket payload modulation: – 1,2 – PAM16B – 3 – PAM8B
•Priority – same codes as DS Scheduling-Priority defines the sub packet priority
•{ID3,ID2,ID1,ID0} – provides up to 16 future types for each quality and priority combination same codes as for DS
Clock Measurement Service
• In mesochronous applications such as video the target T-Client is require to regenerate the App Clock as was present in the source T-Client
• The source T-Client measures the App Clock with its own reference clock and send this information into the T-Network marked in a special packet type
• Each hop in the T-Network operates at a master slave clocking scheme where the downstream transmitter is the master and the downstream receiver (and the upstream transmitter) “lock” on their “master” clock
• When a packet propagate to the next hop on its network path its transmitting symbol rate is retimed according to the master clock of this next hop
• On this special packet type the T-Switch “correct” the clock measurement data, conveyed in this packet, according to the frequency offsets between the symbol rate of the ingress hop and the symbol rate of the egress hop (or the reference clock of the T-Client if the packet reaches its target)
HDBaseT Contribution: Link Specification 2.0 Company Name: Valens Semiconductor Valens Confidential
27
Propagation of Bad CRC Notification
• T-Packets headers and tails are transmitted using the highest quality level therefore normally they are transmitted using lower order modulation than their packet payload
• In these cases upon detection of bad CRC at the receiver, the probability that the error is at the payload is much higher than that the header/tail is erroneous
• In theses cases the packet continues its way on its network path, propagating the fact that it suffers from a bad CRC along the path
• At a high probability this packet will reach its proper target T-Client which can decide what to do with this erroneous packet according to the information carried in the packet header and the protocol it conveys
• For certain applications the header information is important such as the amount of data transferred or extended info within the header carrying sync points or other controls and for other applications, such as video, even the payload data is useful (assuming only few payload symbols are erroneous)
Downstream Bad CRC Indication Bit
• The Bad CRC indication bit is located at the first extended token within the packet header. The lack of extended token is also marking “good” packet
• For Spec 1.0 and Spec 2.0 packet types:
• For future packet types:
Upstream Extended Subtype InfoUpstream Extended Subtype Info
29
Asserting the extension bit with subtype other than 4-7 (or in an extended subtype token), followed by an extended subtype info token, is used to provide additional info to the subtype, format is the same as in DS:
•Extension bit – can be used for additional subtype information •Bad CRC - Asserted if subpacket was subjected to CRC error somewhere along the network •Info Code –
– 0 – Specific use per type. Meaning is according to the packet type, switching devices just pass through
– 1 – Control info
HDBaseT Nibble Streams • In order to facilitate packet synchronization and to reduce framing overhead, the HDBaseT upstream link operates using fix size packets which carries a plurality of sub packets of different data types
• Since the upstream channel is also very limited in BW, it is important to use its packets efficiently and to minimize the number of its unused symbols slots
• An upstream transmitter should be able to split and merge sub packets, of the same sub type and stream ID, according to the upstream packet utilization
• HDBaseT NibbleStream is a general service which the T-Network provides enabling a T-Client to send its information, over the T-network, encoded as a sequence of nibbles (4bit units), with some sync points spread along the stream
• The T-Network can split or merge packets payloads, carrying NibbleStrems data, going into or out from the upstream links on their network path
• The T-Network commits to reconstruct the original sequence of nibbles, including its sync points, in their exact location, at the target T-Client
NibbleStreams Sync Points • All upstreams with data types of priority codes 1 and 2 should support HDBaseT NibbleStream and assumes that, along the upstream path to their destination, their original sub packets payload may be split and/or merge
• Streams which allows mix path (combination of downstream and upstream links on their network path) shall also use this method on their downstream packet headers and shall assume split and merge along the upstream path
• Streams which uses NibbleStream shall use the Extended Control Info token in some DS packets / US sub packet headers, to mark Sync Points
• The frequency of transmitting Sync Points, is data type depended, preferably scarce, and their location is preserve across all splits and merges
• If a packet / sub packet is marked as a Sync Point its payload can not be merged with a previous packet’s payload and the Sync Point is at the beginning of the data conveyed in this packet’s payload
Sync Bad CRC
NibbleStreams Users • For HDBaseT Ver 2.0 the only NibbleStream users are USB and S/PDIF
• They will use NibbleStreams on all kinds of network paths: pure DS, pure US and mix path
• NibbleStream payload split and merge is not supported over pure DS paths such packets will travel intact all the way to their destination end node
• Future data types may use NibbleStreams using the same mechanism
• HDBaseT Port Device may be of the following types:
– Fixed A-Symmetric : port device is a downstream input or downstream output
– Bi-Functional A-Symmetric: same port device can function as a downstream input and as a downstream output but not at the same time
• A relatively long function changing period is assumed so it shall not be consider as a practical half duplex communication but rather two functional modes which can be dynamically configure and/or resolved according to the link partner
– Symmetric: same port device can function as a downstream (high throughput) input and as a downstream (high throughput) output at the same time
• Bi-Functional ports must interoperate with Fixed A-Symmetric ports and Symmetric ports must interoperate with Bi-Functional and Fixed A-Symmetric ports
• All port devices must interoperate with Spec 1.0 Fixed A-Symmetric port devices
HDBaseT Port Device Directionality
• Each HDBaseT port shall first create a connection with its link partner using HDSBI Info frames as part of LPPF #1 or #2 operation modes
• Then the port exchanges more HLIC transactions to understand the abilities of its link partner and to report its own capabilities
• The port now can set its active functional mode and reports its capabilities and current active mode to the Control Point
– Fixed AS to Fixed AS will be resolve to Fixed AS
– Bi-Func/Symm to Fixed AS will be resolve to Fixed AS
– Symm to Symm will be resolve to Symm
– Bi-Func/Symm to Bi-Func is the only non-trivial scenario and will be resolve according to switch/devices preferences. The control Point / switch may dynamically change the directionality of the port if require and possible
Resolving Port Device Directionality
Local Retransmission Mechanism
Packet Retransmission Changes to the Packet Format
Packet Type and RTS Header Tokens
HDBaseT T-Network Services
Quality and Priority
Transfer-Quality Codes
Scheduling-Priority Codes
Current Packet Types (Spec 1.0 and Spec 2.0) Pre Defined Quality and Priority Codes
Quality and Priority Data Types Plain
Future Packet Types (Spec 3.0 and on) Will Use the Optional Extended Type Token
Spec 2.0 Dynamic S4D Modulation per Transfer-Quality and HDBaseT Link Quality
Usage of The Extended Control Info Token
Upstream Fixed Packet Format
Upstream Sub Packet Header
Spec 2.0 Upstream Subtypes
Future Upstream Subtypes (Spec 3.0 and on) will use the Optional Extended Subtype Token
Clock Measurement Service
Upstream Extended Subtype Info

Documents

HDBaseT Contribution