Bitec HDMI IP Core User Manual · 2019-10-25 · In addition, with HDMI 2.0 the TMDS and TERC4 data...

Bitec 2017

Bitec DSP Solutions for Industry & Research

HDMI IP Core

Version 2.9

Page 2

Bitec 2017

Revision history .............................................................................................................. 5

About the HDMI IP Core ................................................................................................ 6

Features ..................................................................................................................... 6

Device Family Support ............................................................................................... 6

Core Distribution ............................................................................................................ 7

Core Usage ..................................................................................................................... 7

Resource Utilization ................................................................................................. 10

HDMI coding ................................................................................................................ 10

HDMI Core Overview ................................................................................................... 11

HDMI Transmitter .................................................................................................... 12

Video data port .................................................................................................... 15

Auxiliary Data port ............................................................................................... 18

Auxiliary Video Information (AVI) InfoFrame ...................................................... 20

HDMI Vendor Specific InfoFrame (VSI) ................................................................ 21

Audio Input Port ................................................................................................... 22

Audio Metadata (AM) .......................................................................................... 26

Audio InfoFrame (AI) ............................................................................................ 27

Mode selection .................................................................................................... 28

HDCP Encryption (Optional) ................................................................................. 28

Page 3

Bitec 2017

Status and Control Data Channel (SCDC) Interface ............................................. 28

Version Number Constant ................................................................................... 29

Parameterization ................................................................................................. 29

HDMI Receiver ......................................................................................................... 30

Alignment and De-skew ....................................................................................... 35

Video data port .................................................................................................... 35

Error detection counters ...................................................................................... 36

Auxiliary data port................................................................................................ 36

Auxiliary Packet register interface ....................................................................... 37

Auxiliary Video Information (AVI) InfoFrame ...................................................... 40

HDMI Vendor Specific InfoFrame (VSI) ................................................................ 41

Audio Output Port ................................................................................................ 41

Audio Metadata (AM) .......................................................................................... 45

Audio InfoFrame (AI) ............................................................................................ 46

HDCP Decryption (Optional) ................................................................................ 46

Status and Control Data Channel (SCDC) Interface ............................................. 47

Parameterization ................................................................................................. 47

DVI Mode of operation ................................................................................................ 49

Dual-Link DVI operation ........................................................................................... 49

Page 4

Bitec 2017

DL-DVI Source ...................................................................................................... 49

DL-DVI Sink ........................................................................................................... 50

HDMI IP Core Design Implementation ......................................................................... 52

HDMI Core Transceiver instantiations ............................ Error! Bookmark not defined.

Clocking Trees .............................................................................................................. 53

Page 5

Bitec 2017

Revision history

Version Comment

V1.0 First release

V2.0 Added TX Audio Interface

V2.1 Added MSB enable to InfoFrame Inputs

V2.2 Added HDMI 2.0 Features

V2.3 Added MST and 3D audio support

V2.4 Replaced audio_de with single bit

V2.5 Added Error Detection in Sink

V2.6 Added 420 color format

V2.7 Added I2C_CLK_NS on RX Core

V2.8 Added Scrambler_Enable port to RX

V2.9 Added details on DL-DVI implementation

Page 6

Bitec 2017

About the HDMI IP Core

The HDMI standard specifies a digital communications interface for use in both internal

connections, such as interfaces within a PC or monitor, and external display connections,

including interfaces between a PC and monitor or projector, between a PC and TV, or

between a device such as a DVD player and TV display.

The Bitec HDMI IP core supports the version 1.4b and 2.0 standards. The core consists of

both source and sink with standard hs-sync video input and output ports.

Features

The Bitec HDMI IP core offers the following features

Support for Transmitter and Receiver on a single device Transceiver Quad

Video support for 8, 10, 12 and 16-bpc Deep Colour operation

Supports pixel clocks to 600Mhz (4k@60)

Support for RGB and YCbCr colour modes

Accepts standard h/v/d/rgb input video format

Compatible with DVI and Dual Link DVI

Supports Audio including MST and 3D formats (IEC 60958 or IEC 61937)

Supports single, double or quad pixel-per-clock

Optional HDCP Support Available

FPGA Device Family Support

The HDMI IP core is designed to work with the following Devices

Cyclone IV, V GX

Arria II, V, 10 GX

Page 7

Bitec 2017

Stratix II, IV, V GX

Core Distribution

The core is distributed with the following directory structure.

The IP Core consists of the following files found in the IP directory.

File name Description

bitec_hdmi.qip Quartus IP file

bitec_hdmi.sdc SDC file to constrain the Core logic. This file gets included

automatically in the qip

bitec_hdmi_tx.bsf Block Symbol file for the TX core

bitec_hdmi_rx.bsf Block Symbol file for the RX core

bitec_hdmi_tx.ocp OpenCore Plus file for the TX core

bitec_hdmi_rx.ocp OpenCore Plus file for the RX core

bitec_hdmi.v Main Encrypted Verilog Core File

Core Usage

The Bitec HDMI IP Core is included in user designs via a simple instantiation. The

instantiation can be either a graphical component or a RTL component. For block diagram

based designs there is a component symbol in the IP core root directory for either the

source or sink. For RTL entry designs a typical Verilog instantiation template is given in

Table 1 and Table 2.

Page 8

Bitec 2017

In order for Quartus to correctly determine the file locations it is necessary to include the

bite_hdmi.qip file in the active Quartus project. It may also be necessary to add the ip

directory to the Quartus library search path.

Page 9

Bitec 2017

Table 1 Verilog HDMI TX Instantiation Template

Table 2 Verilog HDMI RX Instantiation Template

bitec_hdmi_tx #(

.SUPPORT_32CHAN_AUDIO (),

.SUPPORT_AUDIO (),

.SUPPORT_AUXILIARY (),

.SUPPORT_DEEP_COLOR (),

.SYMBOLS_PER_CLOCK (),

.SUPPORT_SCDC ()

) bitec_hdmi_tx_i(

.version (),

.reset (),

.vid_clk (),

.ls_clk (),

.out_b (),

.out_r (),

.out_g (),

.out_c (),

.vid_data (),

.vid_vsync (),

.vid_hsync (),

.vid_de (),

.vid_ready (),

.ctrl (),

.aux_data (),

.aux_valid (),

.aux_sop (),

.aux_eop (),

.aux_ready (),

.mode (),

.audio_CTS (),

.audio_N (),

.audio_clk (),

.audio_data (),

.audio_de (),

.audio_info_ai (),

.audio_metadata (),

.audio_format (),

.gcp (),

.info_avi (),

.info_vsi ()

.Scrambler_Enable (),

.TMDS_Bit_clock_Ratio ());

bitec_hdmi_rx #(

.SUPPORT_32CHAN_AUDIO (),

.SUPPORT_AUDIO (),

.SUPPORT_AUXILIARY (),

.SUPPORT_DEEP_COLOR (),

.SYMBOLS_PER_CLOCK (),

.SUPPORT_SCDC (),

.I2C_CLK_NS (),

) bitec_hdmi_rx_i (

.version (),

.reset (),

.vid_clk (),

.ls_clk (),

.in_b (),

.in_r (),

.in_g (),

.in_lock (),

.err_count_b (),

.err_count_g (),

.err_count_r (),

.mode (),

.locked (),

.vid_valid (),

.vid_de (),

.vid_data (),

.vid_vsync (),

.vid_hsync (),

.vid_lock (),

.ctrl (),

.aux_data (),

.aux_valid (),

.aux_ready (),

.aux_sop (),

.aux_eop (),

.aux_error (),

.aux_pkt_data (),

.aux_pkt_wr (),

.aux_pkt_addr (),

.audio_CTS (),

.audio_N (),

.audio_data (),

.audio_de (),

.audio_info_ai (),

.audio_metadata (),

.audio_format (),

.gcp (),

.info_avi (),

.info_vsi (),

.scdc_i2c_clk (),

.scdc_i2c_addr (),

.scdc_i2c_rdata (),

.scdc_i2c_wdata (),

.scdc_i2c_r (),

.scdc_i2c_w (),

.in_5v_power (),

.in_hpd (),

.TMDS_Bit_clock_Ratio (),

.Scrambler_Enable ());

Page 10

Bitec 2017

Resource Utilization

The following table gives the resource usage of the HDMI IP Core.

TBD

HDMI coding

Based on the TMDS encoding, the HDMI protocol allows the transmission of both Audio

and Video data between source and sink devices. A HDMI interface consists of 3-color

channels accompanied with a single clock channel. Each colour line is used to transfer

both individual RGB colours and auxiliary data.

TMDS encoding is based on an 8-bit to 10-bit algorithm which attempts to both minimize

data channel transmissions yet maintain sufficient such that a sink device is able to lock

reliably to the data stream. The HDMI protocol is shown in Figure 1.

Figure 1 HDMI video stream data

Activevideo

Activevideo

Active

A

ux/A

ud

io

Data Islan

dp

ream

ble

Vid

eo

P

ream

ble

Data Island Guard band

Video Guard band Video Guard band

Video guard bandcase (TMDS Channel Number):

0:q_out[9:0] = 10’b1011001100;1:q_out[9:0] = 10’b0100110011;2:q_out[9:0] = 10’b1011001100;

endcase

Data Island guard bandcase (TMDS Channel Number):

0:q_out[9:0] = 10’bxxxxxxxxxxx;1:q_out[9:0] = 10’b0100110011;2:q_out[9:0] = 10’b0100110011;

endcase

Video Preamble{c3, c2, c1, c0} = 4’b0001

Data Island Preamble{c3, c2, c1, c0} = 4’b0101

vid_de

aux_de

Page 11

Bitec 2017

There are two data streams associated with HDMI one is used to transport colour data,

shown in green, and the second is used to transport auxiliary data, shown in dark blue.

The video data is a packed representation of the video pixels clocked at the source pixel

clock. The auxiliary data is used to transfer Audio data along with a range of auxiliary data

packets which are used by sink devices for the correct reconstruction of video and audio

data.

The video data is encoded using the TMDS 8b/10b algorithm while auxiliary data is

encoded using the TERC4 encoding algorithm. For more information on the encoding

algorithms see the appropriate HDMI standard documentation. Each data stream section

is preceded with guard bands and pre-ambles. These allow for accurate synchronization

with received data streams.

In addition, with HDMI 2.0 the TMDS and TERC4 data streams are scrambled. Details

regarding the scrambling can be found in the HDMI 2.0 specification.

HDMI Core Overview

The HDMI IP core is designed for direct connection to the Altera HSSI components via a

10-bit or 20-bit parallel data path. The transmitter core provides four 10-, 20- or 40-bit

data paths corresponding to the 3 colour channels and the clock channel. The receiver

core provides three 10-, 20- or 40-bit data input paths corresponding to the colour

channels.

Page 12

Bitec 2017

HDMI Transmitter

The HDMI transmitter is shown in Figure 2

Figure 2 Transmitter block diagram

There are four port groups driving the core.

1. Video data. This port is the main video input to the core.

2. InfoFrame Data ports. These ports enable the core to transmit the basic

InfoFrames required by HDMI. For other InfoFrames, the Auxiliary Data Port can be

used

3. Auxiliary Data port. This port allows arbitrary Auxiliary Packets to be transmitted.

4. Audio Data port. This port provides the main Audio data input to the core. Various

audio formats are supported.

TMD

S[0]

Blue[15:0]

vid_de

aux_data[71:0]

vid_hs

vid_vs

Green[15:0]

Red[15:0]

vid_clk

Blue

aux

TMD

S[1]

Green

aux

TMD

S[2]

Red

aux

Chan0[9:0]

Chan1[9:0]

Chan2[9:0]

Chan3[9:0]

de

de

de

gcp[5:0]

aux_ready

aux_valid

aux_sop

aux_eop

Re-sam

pler

AU

X P

acketizer

Clo

ckgen

AuxiliaryData port

VideoData port

TMDSdata

mode

HD

CP

1.4

Blue

aux

Green

aux

Red

aux

de

de

de

keys

HDCP Avalon-MS Register interface

MU

X

Au

dio

Enco

der

GCP gen

CTS[19:0]

N[19:0]

audio_data[255:0]audio_deaudio_clk

AudioData port

info_vsi[61:0] VSI gen

info_avi[112:0] AVI gen

Audio InfoFrames

InfoFrameData port

SCDC Control

Scramb

ler

HD

CP

2.2

keys

audio_format[4:0]

vid_ready

Page 13

Bitec 2017

The core port definitions are shown in Table 3. The port sizes are shown for 1, 2 and 4-

symbols per clock.

Table 3 TX Core port definitions

Port name Size

1/2/4-pix

Description

version 32 Core version number constant

reset 1 Main asynchronous reset input

ls_clk 1 Link speed clock input. Typically 8/8, 10/8, 12/8 or

16/8 times the vid_clk according to color depth.

Typically, this signal is connected to the transceiver

output clock.

vid_clk 1 Video data clock input. In single mode this clock is the

video pixel clock. In double mode this clock is half the

pixel clock.

Video Data port

vid_data 48/96/192 Video 48-bit pixel data input port. In two-symbol mode

this port accepts two 48-bit pixels per clock. In 4-

symbold mode four, 48-bit pixels are input.

vid_de 1/2/4 Video datavalid input

vid_hsync 1/2/4 Video horizontal sync input

vid_vsync 1/2/4 Video vertical sync input

vid_ready 1/2/4 Output to qualify the video input data cycles.

ctrl 6/12/24 DVI Control side-band outputs

TMDS Data

out_b 10/20/40 TMDS encoded blue channel output. This port is

clocked at the ls_clk rate.

out_g 10/20/40 TMDS encoded green channel output. This port is

clocked at the ls_clk rate.

Page 14

Bitec 2017

out_r 10/20/40 TMDS encoded red channel output. This port is clocked

at the ls_clk rate.

out_c 10/20/40 TMDS encoded clock channel output. When in single

symbol mode this port is bit duplicated

Auxiliary Data Port

aux_ready 1 Auxiliary data channel ready output

aux_valid 1 Auxiliary valid channel ready input

aux_data 72 Auxiliary data channel data input

aux_sop 1 Auxiliary data channel start-of-packet input

aux_eop 1 Auxiliary data channel end-of-packet input

Encoder control port

mode 1 Encoding mode input. 1=HDMI, 0=DVI

Audio Port

audio_CTS 20 Audio CTS value input

audio_N 20 Audio N value input

audio_clk 1 Audio clock input

audio_data 256 Audio data input, 8-channels.

audio_de 1 Audio data valid input

audio_info_ai 49 Audio InfoFrame input bundle

audio_format 5 Audio format input

audio_metadata 166 Audio Metadata packet bundle

Auxiliary Control Port

gcp 6 General control packet input

info_avi 113 Auxiliary Video Information InfoFrame input

info_vsi 62 Vendor Specific Information InfoFrame input

SCDC Interface

Scrambler_Enable 1 When enabled the core will scramble the data prior to

TMDS/TERC4 encoding

Page 15

Bitec 2017

TMDS_Bit_clock_Ratio 1 When asserted the clock output uses 1/40th clocking

Video data port

The video data port consists of the 16bpc triple and control lines. Data is clocked in to the

video port using the vid_clk input. The pixel data format for RGB4/YCbCr4:4:4 is shown in

Figure 3. When the actual colour depth is below 16bpc, the unused LSBs are set to zero.

Figure 3 Transmitter pixel data input format RGB/YCbCr 4:4:4

When operating in 4:2:2 sub-sampled colour space the output format is shown in Figure 4.

As with the 4:4:4 colour mode, the unused LSB of the colour data are set to zero.

Figure 4 Transmitter pixel data input format YCbCr 4:2:2

HDMI 2.0 introduces YCbCr 4:2:0 color spaces. The parallel data output pixel packing is

shown in Figure 5. Each line alternates the Cb and Cr color components.

Figure 5 YCbCr 4:2:0 pixel data color mapping

47 32 0151631

24BPP RGB/YCbCr444 (8bpc)



48BPP RGB /YCbCr444 (16bpc)

vid_data[47:0]

Y[3:0]

47 40 8152431 vid_data[47:0]

Cb/Cr[3:0]

1112

Cb/Cr[11:4] Y[11:4]

47 40 8152431 vid_data[47:0]

Cb

8

Y01 Y00

47 40 8152431 vid_data[47:0]

Cb

8

Y11 Y10

Line 0

Line 1

Page 16

Bitec 2017

Deepcolor modes can also be used in YCbCr 4:2:0 color spaces. The pixel data output

alternates the chrominance component as with 8-bit however the parallel data output

fields are representative of the Deepcolor mode. This is shown in Figure 6

Figure 6 Deepcolor modes used with YCbCr 4:2:0

The vid_clk in YCbCr 4:2:0 format is ½ the pixel clock frequency. This also applies to all

Deepcolor modes.

The pixel data ports are always 16bpc. When lower colour depth is required, the LSB of

the pixel data must be set to zero. For colour depths greater than 8bpc the core operates

in “Deep Colour” mode. The core will automatically generate the “General Control” packet

required for Deep Colour. The gcp[5:0] is used in the packet generation. The bit fields for

the gcp port are shown in Table 4. All other fields for the General Control Packet are

calculated automatically inside the core.

Table 4 General Control Packet input fields

Bit field Name Comment

gcp[3:0] Colour Depth (CD) CD3 CD2 CD1 CD0 Colour Depth

0 0 0 0 Colour depth not indicated

0 0 0 1 Reserved

0 0 1 0 Reserved

0 0 1 1 Reserved

47 81531

24BPP

30BPP

36BPP

48BPP

vid_data[47:0]

Page 17

Bitec 2017

0 1 0 0 24bpp

0 1 0 1 30bpp

0 1 1 0 36bpp

0 1 1 1 48bpp

Reserved

gcp[4] Set_AVMUTE See HDMI 1.4b Specification

gcp[5] Clear_AVMUTE See HDMI 1.4b Specification

The video data is re-sampled from the vid_clk in to the ls_clk domain according to the

inputs on gcp[3:0]. The ls_clk clock has the following relationship with the vid_clk as a

function of the Deep Colour mode sown in Table 5.

Table 5 Link Speed clock to vid_clk relationship

Deep colour mode ls_clk relationship

8 Bpc 1 x vid_clk

10 Bpc 1.25 x vid_clk

12 Bpc 1.5 x vid_clk

16 Bpc 2 x vid_clk

Alternatively, the vid_clk can be a fixed value which is equal or greater than the highest

expected pixel clock. In this situation the vid_ready output will assert on those clock cycles

for which the core needs video data. When de-asserted, the video interface data is

ignored. This mode of operation removes the need to maintain a separate ls_clk with the

required ratios of Table 5.

The ls_clk would normally originate from the device HSSO component.

Page 18

Bitec 2017

When parameterized for double symbol mode, the core accepts two pixels and sync

signals per video clock. In this situation, the vid_clk to the core must be half the actual

video clock.

The core also outputs the DVI Control Side-band signals. The Core will override the input

signals in order to send necessary control and synchronization data. The control signals

are synchronous to the ls_clk.

Auxiliary Data port

The Auxiliary data port is used to transfer packet data including audio. All data is

transferred in packets of 28-bytes (PB0..PB27) with three header bytes (HB0..HB2). The

BCH FEC codes are calculated inside the core and appended to the outgoing packet. The

port signal behaviour is shown in Figure 7 where data is clocked using the Link Speed clock

(ls_clk). The case for 1-symbol and 2-symbol per clock is shown.

Selective filtering is applied to AUX InfoFrame packets to facilitate direct connection to an

upstream Sink AUX. This feature avoids internally generated InfoFrame packets to be

duplicated with packets entering the AUX port. This mechanism uses the ACTIVE bit of the

respective InfoFrame input port situated in the MSB. When de-asserted the InfoFrame

packet is generated by the core and the respective InfoFrame packet at the AUX input port

is filtered and discarded. When asserted, the respective InfoFrame packet is neither

generated by the core nor discarded from the AUX input port.

Page 19

Bitec 2017

Figure 7 Auxiliary data port signals

The Auxiliary data port is a packetized stream port with back-pressure. The core will

assert the ready signal when Auxiliary data can be transmitted on blanking regions. The

core assumes the packet is continuous and hence the valid signal must remain asserted

during the complete 4-cycle packet transfer. Where packets are smaller than 28-bytes,

zero padding must be used.

For a detailed description of the various packets see the HDMI 1.4a specification.

HB

0P

B0

PB

1P

B7

PB

8

HB

1P

B2

PB

3P

B9

PB

10

HB

2P

B4

PB

5P

B11

PB

12

0P

B6

0P

B13

0

PB

14P

B15

PB

21P

B22

PB

16P

B17

PB

23P

B24

PB

18P

B19

PB

25P

B26

PB

200

PB

270

BCH block 3

BCH block 2

BCH block 1

BCH block 0

0 - - 8 - - 16

Phase 0 Phase 1 Phase 2

- - 24

Endofpacket

Startofpacket

Ready

Clock

Cycle 1-symbol

Phase 3

Phase 0 Phase 1 Phase 2 Phase 3

0 - - 4 - - 8 - - 12Cycle 2-symbol

Input data

Byte[0]

Byte[8]

-

-

-

-

-

-

-

Page 20

Bitec 2017

Auxiliary Video Information (AVI) InfoFrame

The core accepts a user supplied AVI InfoFrame which is sent once per field. The bit fields

for the AVI InfoFrame port bundle is given in Table 6. For a complete description of the bit-

fields see the HDMI 1.4b specification. If the checksum input to the port is zero a default

value is used by the core. If the most significant bit is asserted the core is prevented from

sending the AVI InfoFrame packet. The signal bundle is clocked by the ls_clk.

Table 6 Auxiliary Video Information (AVI) InfoFrame bit fields


7:0 Checksum

9:8 S Scan Information

11:10 B Bar Info Data Valid

12 A0 Active Information Present

14:13 Y RGB or YCbCr indicator

15 Reserved Returns 0

19:16 R Active format Aspect Ratio

21:20 M Picture Aspect Ratio

23:22 C Colorimetry (ITU BT.601, BT.709 etc)

25:24 SC Non-uniform picture scaling

27:26 Q Quantization range

30:28 EC Extended Colorimetry

31 ITC IT Content

38:32 VIC Video Format Identification Code


43:40 PR Picture repetition factor

45:44 CN Content Type

47:46 YQ YCC Quantization Range

63:48 ETB Line Number of End of Top Bar

Page 21

Bitec 2017

79:64 SBB Line Number of Start of Bottom Bar

95:80 ELB Pixel Number of End of Left Bar

111:96 SRB Pixel Number of Start of Right Bar

112 ACTIVE When asserted the InfoFrame is never sent by the core

HDMI Vendor Specific InfoFrame (VSI)

The core transmits a HDMI Vendor Specific InfoFrame once per field. The bit fields for the

VSI InfoFrame are given in Table 7. For a complete description of the bit-fields see the

HDMI 1.4b specification. If the checksum input to the port is zero a default value of zero is

used for each bit field. If the most significant bit is asserted the core is prevented from

sending the VSI InfoFrame packet. The signal bundle is synchronous to the ls_clk.

Table 7 HDMI Vendor Specific InfoFrame bit-fields


4:0 Length Length=Nv

12:5 Checksum

36:13 IEEE 24-bit IEEE Registration Identifier (0x000C03)

41:37 Reserved All 0

44:42 HDMI_Video_Format HDMI Video Format

52:45 HDMI_VIC/3D_Structure HDMI proprietary Video Format Identification Code

when Video Format == 1

3D_Structure field when Video Format == 2


60:57 3D_Ext_Data 3D Extended Data

61 ACTIVE When asserted the InfoFrame is never sent by the

core

Page 22

Bitec 2017

Audio Input Port

When operating in HDMI mode the Bitec HDMI Source core is able to send audio data. The

HDMI Audio encoder is shown in Figure 8. The core can accept up to 32-channels of audio.

The core supports various audio formats which are described below.

Four auxiliary packet types are needed to transport Audio data. These packet types are

the Audio Info Frame, the Audio Time Stamp, Audio Metadata and Audio Sample Data

packets. The encoder includes a general Audio Info Frame packet generator with all fields

at default values. The default values use the “Refer to Stream Header” as defined in the

CEA-861 specification. The Audio Metadata packet is required when Multi-Stream or 3D

audio is used. When not required the inputs can be zero.

Figure 8 HDMI Transmitter Audio encoder

The audio encoder automatically generates the Audio Timestamp Packet (ATS). The ATS

packet requires a user supplied 20-bit CTS and N value which corresponds to the current

audio sample clock. Typical values for the CTS and N values can be found in the HDMI

specification.

N[19:0]

audio_data[255:0]

audio_de

audio_clk

DC

FIFO

CTS[19:0]

ATS

genA

IFgen

Packetizer

MU

X

audio_info_ai[47:0]

AIF

genaudio_metadate[165:0]

audio_format[4:0]

audio_aux

Page 23

Bitec 2017

Up to 8, 32-bit audio sample data words are written into the encoder using the audio

sample clock (audio_clk) depending on which audio format is in use. A valid signal is also

included to qualify valid sample data clock cycles. A single data valid is used. Valid samples

are qualified by the valid bit (bit-24) for each sample value (see Figure 9). The core will

automatically adapt the audio sample packing for 2-channel or more than two channels by

interrogating the valid signal.

The audio format is determined by the audio_format input. The definition is given in Table

8. The audio_format bundle is synchronous to the audio_clk.

Table 8 Definition of Audio Format bits 3:0

Value Name Comment

0 LPCM Payload data is transported using HDMI packet type 2

1 One-Bit Audio± Payload data is transported using HDMI packet type 7

2 DST Audio± Payload data is transported using HDMI packet type 8

3 HBR Payload data is transported using HDMI packet type 9

4 3D (LPCM)* Payload data is transported using HDMI packet type 11

5 3D (One-Bit)* ± Payload data is transported using HDMI packet type 12

6 MST (LPCM)* Payload data is transported using HDMI packet type 14

7 MST (One-Bit)* ± Payload data is transported using HDMI packet type 15

4-15 Reserved

* HDMI 2.0 format only

±Not supported

Bit-4 of the audio_format input is the 3D Start strobe as described later in the 3D audio

section.

L-PCM Input Format 0

The 32-bit audio data is packed in an IEC-60958 type as shown in Figure 9 . The least

significant word is the left channel sample.

Page 24

Bitec 2017

Figure 9 Audio data packing

The audio sample bit fields are designed for direct interface to the Bitec DisplayPort IP

Core as well as down-stream Bitec HDMI IP Cores. As such, some of the fields in the data

are not relevant to HDMI audio transport and can be left at zero. The fields are defined as

SP- Sample present (Not used)

X- Not used

B- Start of 192-bit IEC 60958 Channel Status

P- Parity bit

C- Channel Status

U- User data bit (Not used)

V- Valid bit

The Valid bit (V) is ignored if the channel audio_de is not asserted.

For a more detailed description see the DisplayPort Specification.

In Format 0, the core can accept between 2 and 8 channels. The core will automatically

adjust the sample packets according to the number of channels written. The audio

interface uses the audio_de input vector to establish how many channels are being

transmitted.

HBR Audio Input Format

When the audio input format is HBR the sample packet data is identical to the L-PCM

format. In HBR mode there are always 8-samples transmitted per clock. HBR audio packets

are transmitted using AUX packet header number 9.

SP x x B P C U V Audio data

31 24 0

Page 25

Bitec 2017

3D Audio Input Format

When the audio format is in 3D mode the audio interface can send up to 32-audio

samples. To do so it consumes up to 4-writes of 8-samples. To indicate the first of the 32-

samples the MSB bit of the audio_format is asserted. The audio input sample format for

3D is identical to the L-PCM format.

Figure 10 shows three examples of 3D audio. The examples indicate a full 32-channels, 24-

channels and 12-channels. In the 12-channel example it can be seen that the 4, most

significant sample data of the last beat are zero.

Figure 10 Example of 3D-audio format

Multi-Stream Audio Input Format

When the audio input format is MST the sample packet data is identical to the L-PCM

format. MST mode enables a source to send up to 4 streams of audio to a sink device.

audio_format[4]

audio_de

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

17

CH

18

CH

19

CH

20

CH

25

CH

26

CH

27

CH

28

CH

5C

H6

CH

7C

H8

CH

13

CH

14

CH

15

CH

16

CH

21

CH

22

CH

23

CH

24

CH

29

CH

30

CH

31

CH

32

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

17

CH

18

CH

19

CH

20

CH

5C

H6

CH

7C

H8

CH

13

CH

14

CH

15

CH

16

CH

21

CH

22

CH

23

CH

24

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

5C

H6

CH

7C

H8

00

00

32-channel 24-channel 12-channel

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

5C

H6

CH

7C

H8

00

00

Sample[n] Sample[n+1]

Page 26

Bitec 2017

Figure 11 shows three examples of valid MST audio format. The source can send 2-, 3- or

4-streams. When less than 4-streams are sent the input sample fields should be set to

zero.

Figure 11 Examples of MST audio format

Audio Metadata (AM)

The Audio Metadata packet is introduced in HDMI 2.0. It is used to manage the Multi-

Stream and 3D audio packets. The layout of the Metadata packet is given in Table 9.

Complete definitions for the mnemonics can be found in the HDMI 2.0 standard.

Table 9 Audio Metadata bundle bit fields


0 3D_AUDIO =1 when transmitting 3D audio. =0 for MST

2:1 NUM_VIEWS Indicates the number of views for an MST stream

4:3 NUM_AUDIO_STR Number of audio streams

164:5 Payload data Corresponds to PB0 to PB19 of the Metadata packet

165 ACTIVE When asserted the Metadata is never sent by the core

ST2-

L

ST1-

LST

1-R

ST3-

LST

3-R

ST2-

R

Unused samples set to zero

ST2-

LST

2-R

ST1-

LST

1-R

ST1-

LST

1-R

ST0-

LST

0-R

ST0-

LST

0-R

ST0-

LST

0-R

00

00

00

2-Stream3-Stream4-Stream

Stream-1

Stream-0

Page 27

Bitec 2017

The Metadata payload data PB[0] to PB[19] vary according to the audio format. A

complete description of the payload can be found in the HDMI 2.0 specification. The signal

bundle is synchronous to the ls_clk.

Audio InfoFrame (AI)

The core transmits an Audio InfoFrame once per field. The signal bit fields are defined in

Table 10. For a complete description of the bit fields see the HDMI 1.4b Specification. If

the checksum input to the port is zero a default value is used by the core. If the most

significant bit is asserted the core is prevented from sending the VSI InfoFrame packet.

The signal bundle is synchronous to the ls_clk.

Table 10 Audio InfoFrame bundle bit fields


7:0 Checksum

10:8 CC Channel count

11 reserved Returns zero

15:12 CT Audio format type

17:16 SS Bits-per-audio sample

20:18 SF Sampling Frequency

23:21 Reserved Returns zero

31:24 CXT Audio format type of the audio stream

39:32 CA Speaker location allocation FL, FR

41:40 LFEPBL LFE playback level information, dB

42 Reserved Returns zero

46:43 LSV Level Shift Information, dB

47 DM_INH Down-mix inhibit flag

48 ACTIVE When asserted the InfoFrame is never sent by the core

Page 28

Bitec 2017

Mode selection

The HDMI TX Core is DVI 1.0 compliant. In order to operate with a DVI 1.0 sink the HDMI

TX core must be prevented from sending video and data guard bands. This is accomplished

using the mode input signal. De-asserting the mode signal removes guard band data and

prevents the core from generating the Auxiliary control signals associated with HDMI data

streams.

It is necessary for the user design to determine if a connected sink is either an HDMI

compatible sink or DVI 1.0 (or 1.1a). This is done by interrogating the EDID data in the sink.

For HDMI compliant sinks, the EDID structure will contain certain indicator fields as

described in the HDMI 1.4b specification.

HDCP Encryption (Optional)

The core supports HDCP 1.4 encryption. This optional feature is supplied upon request.

Unlike the receiver, the HDMI transmitter requires an external processor to perform the

Authentication via an i2c master. The HDCP MM slave interface presents the standard

HDCP Port registers and addresses as described in the HDCP Specification.

Status and Control Data Channel (SCDC) Interface

The Core supports HDMI 2.0 scrambling. According to the HDMI 2.0 specification, all data

transmitted above 3.6Gbps must be scrambled. To enable the scrambler the

Scrambler_Enable input port must be asserted.

Also, for data rates exceeding 3.4Gbps, the TMDS clock signal must send a quarter pixel

clock. To enable this, the TMDS_Bit_clock_Ratio input must be asserted.

Page 29

Bitec 2017

Version Number Constant

The Core version and revision number constant is a 32-bit port. The output is a fixed

constant with the format shown


15:0 Revision Number This is the revision number corresponding to the

number found in the bitec_hdmi_tx.qip file

23:16 Minor revision

number

Typically 0

31:24 Major revision

number

Typically 2

Parameterization

The core accepts the following parameters. The parameters allow optimization for

applications which do not require the full HDMI feature set.

Parameter Description Default value

SUPPORT_AUXILIARY Determines if Auxiliary channel encoding

is included. 0=no Aux, 1=Aux

1

SUPPORT_DEEPCOLOR1 Determines if the core will encode deep

color formats. 0= no Deepcolor,

1=Deepcolor

0

SYMBOLS_PER_CLOCK Determines how many TMDS symbols

and pixels are processed per clock. 1, 2 or

4 symbols per clock are valid

1

SUPPORT_AUDIO1 When asserted the core will support 2-

channel audio

1

Page 30

Bitec 2017

SUPPORT_8CHAN_AUDIO1 When asserted the core will support 8-

channel audio

1

SUPPORT_32_CHAN_AUDIO1,2 When asserted the core will support 32-

channel audio

1

SUPPORT_SSDC2 When asserted the core includes the

scrambling logic required for HDMI 2.0.

0

SUPPORT_HDCP13 Determines if HDCP1.4 encryption logic is

included in the core. 1=yes, 0=no

0

SUPPORT_HDCP23 Determines if HDCP2.2 encryption logic is

included in the core. 1=yes, 0=no

0

1These parameters require SUPPORT_AUXILIARY

2Only supported in HDMI 2.0

3Requires Optional HDCP licenses

HDMI Receiver

The HDMI Receiver core is shown in Figure 12. The core can be parameterized to accept

either 10-, 20- or 40-bit HSSI data from the transceiver. The data streams are then

decoded in to their respective colour components and the aligned through a series of

DCFIFOS. The DCFIFOS are also used to synchronize all three data channels to the channel

0 clock. This clock is then used throughout the core for decoding both video and auxiliary

data including the decoded audio data. Video data streams are then re-sampled according

to the current colour depth. The ls_clk and vid_clk must be derived using a device GPLL

according to the Mode (see Table 5). This may require either GPLL reconfiguration or clock

switching.

The core will automatically adapt to DVI or HDMI encoding. The current encoding format

is indicated by the mode output.

Page 31

Bitec 2017

Figure 12 HDMI IP Receiver Core

The Receiver port descriptions are shown in Table 11. Port size indicates 1, 2 and 4-

symbols per clock

Table 11 Receiver Core Port signals

Port name Size

1/2/4-pix

Description

version 32 Core version number constant

reset 1 Main asynchronous reset input

ls_clk 3 Link speed clock inputs. These clocks

correspond to the in_r, in_g and in_b

TMDS encoded data inputs.

Video Port

vid_clk Video data clock input. Typically, 8/8,

8/10, 8/12 or 8/16 times the ls_clk

TMD

S[0]

Blue[15:0]

vid_de

aux_data[71:0]

vid_hs

vid_vs

Green[15:0]

Red[15:0]vid_clk

Blue

aux

TMD

S[1]

Green

aux

TMD

S[2]

Red

aux

Chan0[9:0]

Chan1[9:0]

Chan2[9:0]

de

de

de

gcp[5:0]

aux_valid

aux_sop

aux_eopR

e-samp

lerA

UX

de-P

acketizer

AuxiliaryData port

VideoData port

TMDSdata

aux_error

HD

CP

1.4

Blue

aux

Green

aux

Red

aux

de

de

de

keys

HDCP Avalon-MS Register interface

Au

dio

deco

der

GCP cap

CTS[19:0]

N[19:0]

audio_data[255:0]audio_de

AudioData port

info_vsi[61:0]VSI cap

info_avi[112:0]AVI cap

Audio InfoFrames

InfoFrameData port

SCDC Avalon-MSRegister Interface

De-Scram

bler

HD

CP

2.2

keys

audio_format[4:0]

SCDC Registers

Align

men

t and

de-skew

ls_clk

vid_lock

in_locked[2:0]

mode

Error Counters

vid_valid

Page 32

Bitec 2017

according to color depth (see GCP

output).

vid_data 48/96/192 Video 48-bit pixel data output port. In

two symbol mode this port outputs

two 48-bit pixels per clock and in 4-

symbol mode four 48-bit pixels

vid_de 1/2/4 Video datavalid output for

vid_hsync 1/2/4 Video horizontal sync output

vid_vsync 1/2/4 Video vertical sync output

vid_lock 1 Asserted when the received video data

is determined to be stable and

repetitive.

vid_valid 1 Asserted when the received video data

is valid

ctrl 6/12/24 DVI Control side-band signals

TMDS port

in_b 10/20/40 TMDS encoded blue channel input.

When in single symbol mode this port

is bit duplicated. This data is clocked by

ls_clk[0]

in_g 10/20/40 TMDS encoded green channel input.



ls_clk[1]

in_r 10/20/40 TMDS encoded red channel input.



ls_clk[2]

Page 33

Bitec 2017

in_locked 3 Must be asserted for each input

channel when data is stable. Typically

driven by a transceiver ready signal

locked 3 Asserted when associated channel is

both byte and word aligned to

incoming data.

Error Detection Counters

err_count_b 16 Link error rate (Blue channel)

err_count_g 16 Link error rate (Green channel)

err_count_r 16 Link error rate (Red channel)

Auxiliary Data Port

aux_valid 1 Auxiliary valid channel ready output

aux_data 72 Auxiliary data channel data output

aux_sop 1 Auxiliary data channel start-of-packet

output

aux_eop 1 Auxiliary data channel end-of-packet

output

aux_error 1 Auxiliary data channel CRC error

Auxiliary packet register interface

aux_pkt_addr 7 Auxiliary packet memory buffer

address output

aux_pkt_data 72 Auxiliary packet memory buffer data

output

aux_pkt_wr 1 Auxiliary packet memory buffer write

strobe output

Audio Port

audio_CTS 20 Audio CTS value output

audio_N 20 Audio N value output

Page 34

Bitec 2017

audio_clk 1 Audio clock input

audio_data 256 Audio data output, 8-channels

audio_de 1 Audio data valid output

audio_info_ai 48 Audio InfoFrame output bundle

audio_metadata 165 Audio Metadata packet bundle

Auxiliary Control Port

gcp 6 General control packet output

info_avi 112 Auxiliary Video Information InfoFrame

output

info_vsi 61 Vendor Specific Information InfoFrame

output


scdc_i2c_clk 1 i2c interface clock

scdc_i2c_addr 8 i2c interface address

scdc_i2c_rdata 8 i2c interface read data

scdc_i2c_wdata 8 i2c interface write data

scdc_i2c_r 1 i2c interface read strobe

scdc_i2c_w 1 i2c interface write strobe

in_5v_power 1 Reflects the 5V input voltage presence

in_hpd 1 Reflects the HDP state.

TMDS_Bit_clock_Ratio 1 Asserted when >3G data rate clocking

required

Scrambler_Enable 1 Asserted when Scrambler is enabled

Page 35

Bitec 2017

Alignment and De-skew

Alignment and channel de-skew is implemented using a pattern match algorithm. The

pattern match algorithm is capable of locking to the incoming data at the first occurrence

of a control period. The fast locking is of benefit for HDMI 2.0 data streams as an

unscrambled control sequence is present only once per frame.

The channel de-skew implementation allows for up to 8-symbol skew in between

channels. The HDMI specification calls for inter-channel skew of less than 1-symbol for

compliance. Allowing up to 8-symbols of skew accommodates any phase compensation

clock crossing logic in the data path to the IP core.

Video data port

The video pixel data interface is always 16-bit regardless of selected mode. When

operating at modes below 16bpc, the least-significant bits will be set to zero. The video

data format is shown in Figure 3 and Figure 4.

The gcp[5:0] port represents the “General Control” packet data captured by the core. The

definition of the gcp port is shown in Table 4. The CD[3:0] fields are used to determine the

correct vid_clk clock generation according to Table 5.

Alternatively, the vid_clk can be a fixed value which is equal or greater than the highest

expected pixel clock. In this situation the vid_valid output will assert on those clock cycles

for which the core video data is valid. When de-asserted, the video interface data can be

ignored. This mode of operation removes the need to maintain a separate ls_clk with the

required ratios of Table 5.

When parameterized for double symbol mode the video data ports double in size. For

each vid_clk the core will output two pixel and sync signals.

Page 36

Bitec 2017

The core also outputs the DVI and HDMI control side-band signals. There are synchronous

to the ls_clk.

A mode output signal identifies the type of encoding being received. When asserted

indicates the incoming data is encoding using HDMI. When de-asserted the incoming data

is DVI encoding. The mode signal will de-assert after 30 video frames in which no data

island is detected.

Resampled video geometry checking is performed inside the core. The video checking

logic measures vertical and horizontal active and blanking regions and signals. When

repetitive, stable video is detected the core will assert the vid_lock output. This signal can

be used to drive and external watchdog circuit.

Error detection counters

A mechanism for link error-rate detection was introduced in the HDMI 2.0 specification.

The Error Link-Rate outputs the number of errors detected over a 10ms period. In order to

determine a 10ms count interval the scdc_i2c_clk input frequency must be set to 10Mhz.

The Error detection counter interface is intended as a debug feature. Typically, the

registers are read via the SDCD interface from an upstream source.

Auxiliary data port

The Auxiliary data is output on the 72-bit aux data when available. This data stream is

qualified by the aux_valid signal. The port data packet is always 36-bytes comprising of

three header bytes (HB0..HB2) and an associated parity byte (HBP) followed by 28-bytes

packet data (PB0..PB27) and four parity bytes (BCH1..BCH3). The output data sequence is

shown in Figure 13 for 1-symbol and 2-symbol per clocks.

Page 37

Bitec 2017

Figure 13 Auxiliary data output format

The BHC code groups are described in the HDMI 1.4b specification. For applications

requiring forward error correction (FEC) user downstream logic is required.

The Auxiliary Packet decoder performs CRC error checking. If the received packet contains

an error, the aux_error signal will assert in the same cycle as the EOP to indicate the error

detection. The Auxiliary Data Port is synchronous to the ls_clk.

Auxiliary Packet register interface

To aid in system design the HDMI Sink Core has a memory mapped register write

interface. This interface is designed to write received packet data in to an external register

HB

0P

B0

PB

1P

B7

PB

8

HB

1P

B2

PB

3P

B9

PB

10

HB

2P

B4

PB

5P

B11

PB

12

0P

B6

BC

H0

PB

13B

CH

1

PB

14P

B15

PB

21P

B22

PB

16P

B17

PB

23P

B24

PB

18P

B19

PB

25P

B26

PB

20B

CH

2P

B27

BC

H3

BCH block 3

BCH block 2

BCH block 1

BCH block 0

0 - - 8 - - 16

Phase 0 Phase 1 Phase 2

- - 24

Endofpacket

Startofpacket

Valid

Clock

Cycle 1-symbol

Phase 3

Phase 0 Phase 1 Phase 2 Phase 3

0 - - 4 - - 8 - - 12 Cycle 2-symbol

Output data

Byte[0]

Byte[8]

-

-

-

-

-

-

-

Page 38

Bitec 2017

bank. Typically, this port would be interfaced to one port of a dual-port 72-bit wide on-

chip memory component. The second dual port can then be accessed by an external MCU

processor or an HDMI Source core for packet interrogation as shown in Figure 14. In this

example the header bytes are not presented to the MCU thus keeping the interface to 64-

bits. The Packet Register Interface is synchronous to the ls_clk.

Figure 14 Typical AUX Packet register interface usage

The address map as seen from the MCU Memory Master interface is shown in Figure 15.

Data[71:0]

On

chip

mem

ory

HDMI Sink IP Core

Addr[6:0]

wr

Data[71:8]

Addr[6:0]

rd

From 64-bit Nios II

Avalon-MM

Page 39

Bitec 2017

8 7 6 5 4 3 2 1 0

0 PB22 PB21 PB15 PB14 PB8 PB7 PB1 PB0 HB0



3 BCH3 PB27 BCH2 PB20 BCH1 PB13 BCH0 PB6 HBCH0

























































































UNUSED

Dynamic Range and Mastering

InfoFrame*

Source Product Descriptor InfoFrame

Audio InfoFrame

MPEG Source InfoFrame

ISRC1 Packet

ISRC2 Packet

One Bit Audio Sample Packet 5.3.9

DST Audio Packet

High Bitrate (HBR) Audio Stream Packet

Gamut Metadata Packet

AddressPacket Name

Vendor-Specific InfoFrame

AVI InfoFrame

Byte Offset

NULL PACKET

Audio Clock Regeneration (N/CTS)

Audio Sample

General Control

ACP Packet

3D Audio Sample Packet (L-PCM format

only)*

One Bit 3D Audio Sample Packet*

Audio Metadata Packet*

Multi-Stream Audio Sample Packet*

One Bit Multi-Stream Audio Sample

Packet*

Figure 15 Auxiliary packet memory map (* indicates HDMI 2.0 packets).

Page 40

Bitec 2017

The packet fields (PB0-PB26) are described in the HDMI 1.4b Specification.

Auxiliary Video Information (AVI) InfoFrame

The core outputs the captured AVI InfoFrame to simplify user applications. The bit fields

for the AVI InfoFrame port bundle is given in Table 12. For a complete description of the

bit-fields see the HDMI 1.4b specification. The signal bundle is synchronous to the ls_clk.

Table 12 Auxiliary Video Information (AVI) InfoFrame bit fields


7:0 Checksum

9:8 S Scan Information

11:10 B Bar Info Data Valid

12 A0 Active Information Present

14:13 Y RGB or YCbCr indicator


19:16 R Active format Aspect Ratio

21:20 M Picture Aspect Ratio

23:22 C Colorimetry (ITU BT.601, BT.709 etc)

25:24 SC Non-uniform picture scaling

27:26 Q Quantization range

30:28 EC Extended Colorimetry

31 ITC IT Content

38:32 VIC Video Format Identification Code


43:40 PR Picture repetition factor

45:44 CN Content Type

Page 41

Bitec 2017

47:46 YQ YCC Quantization Range

63:48 ETB Line Number of End of Top Bar

79:64 SBB Line Number of Start of Bottom Bar

95:80 ELB Pixel Number of End of Left Bar

111:96 SRB Pixel Number of Start of Right Bar

HDMI Vendor Specific InfoFrame (VSI)

The core outputs the captured HDMI Vendor Specific InfoFrame to simplify user

applications. The bit fields for the VSI InfoFrame are given in Table 13. For a complete

description of the bit-fields see the HDMI 1.4b specification. The signal bundle is

synchronous to the ls_clk.

Table 13 HDMI Vendor Specific InfoFrame bit-fields


4:0 Length Length=Nv

12:5 Checksum

36:13 IEEE 24-bit IEEE Registration Identifier (0x000C03)


44:42 HDMI_Video_Format HDMI Video Format

52:45 HDMI_VIC HDMI proprietary Video Format Identification Code


60:58 3D_Ext_Data 3D Extended Data

Audio Output Port

The core will decode the audio data and present this as a parallel IEC-60958 type data. The

bit-fields for the audio data port are the same as the HDMI source and can be seen in

Page 42

Bitec 2017

Figure 9. The audio port also provides the CTS and N values used in clock recovery. This is

useful for looping through audio data from a sink to source.

The core is capable of receiving various audio formats. The actual audio format is

indicated by the audio_format output. The definition is given below

Table 14 Definition of Audio Format bits 3:0

Value Name Comment

0 LPCM Payload data is transported using HDMI packet type 2

1 One-Bit Audio± Payload data is transported using HDMI packet type 7

2 DST Audio± Payload data is transported using HDMI packet type 8

3 HBR Payload data is transported using HDMI packet type 9

4 3D (LPCM)* Payload data is transported using HDMI packet type 11

5 3D (One-Bit)* ± Payload data is transported using HDMI packet type 12

6 MST (LPCM)* Payload data is transported using HDMI packet type 14

7 MST (One-Bit)* ± Payload data is transported using HDMI packet type 15

4-15 Reserved

* HDMI 2.0 format only

±Not supported

Bit-4 of the audio_format output is the 3D Start strobe as discussed later in the 3D audio

section.

Data is clocked out of the core using the link clock (ls_clk[0]). An audio_de signal is

provided to determine which ls_clk cycles carry valid audio data. Typically, with an audio

source clock of 48kHz, the audio_de strobe will assert once every 1/48kHz seconds

regardless of the link clock. Each member of the audio_de port represents the associated

audio channel. The audio_de bits assert such that there is a corresponding audio sample

present on that channel and the sample valid bit, V (see Figure 16) is asserted.

Page 43

Bitec 2017

L-PCM Output Format

The 32-bit audio data is packed in a IEC-60958 type as shown in Figure 16. The least

significant word is the left channel sample.

Figure 16 Audio data packing

The audio sample bit fields are designed for direct interface to the Bitec DisplayPort IP

Core as well as up-stream Bitec HDMI IP Cores. As such, some of the fields in the data are

not relevant to HDMI audio transport and can be left at zero. The fields are defined as

SP- Sample present (Always zero)

X- Not used (Always zero)

B- Start of 192-bit IEC 60958 Channel Status

P- Parity bit

C- Channel Status

U- User data bit (Always zero)

V- Valid bit

For a more detailed description see the HDMI Specification.

In Format 0, the core can receive between 2 and 8 channels. The core will automatically

adjust the sample packet decoding according to the packet layout. The audio interface

uses the audio_de output vector to indicate which channels carry audio data.

HBR Audio Output Format

When the audio output format is HBR the sample packet data is identical to the L-PCM

format. In HBR mode there are always 8-samples transmitted per clock. HBR audio packets

are transmitted using AUX packet header number 9.

SP x x B P C U V Audio data

31 24 0

Page 44

Bitec 2017

3D Audio Output Format

When the audio format is in 3D mode the audio interface can receive up to 32-audio

samples. To do so it yields up to 4-writes of 8-samples. To indicate the first of the 32-

samples the MSB bit of the audio_format is asserted. The audio input sample format for

3D is identical to the L-PCM format.

Figure 10 shows three examples of 3D audio. The examples indicate a full 32-channels, 24-

channels and 12-channels. In the 12-channel example it can be seen that the 4, most

significant sample data of the last beat are zero.

Figure 17 Example of 3D-audio format

Multi-Stream Audio Output Format

When the audio format is MST the sample packet data is identical to the L-PCM format.

MST mode enables a sink to receive up to 4 streams of audio.

Figure 11 shows three examples of valid MST audio format. The sink can receive 2, 3 or 4-

streams. When less than 4-streams are sent the input sample fields will be set to zero.

audio_format[4]

audio_de

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

17

CH

18

CH

19

CH

20

CH

25

CH

26

CH

27

CH

28

CH

5C

H6

CH

7C

H8

CH

13

CH

14

CH

15

CH

16

CH

21

CH

22

CH

23

CH

24

CH

29

CH

30

CH

31

CH

32

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

17

CH

18

CH

19

CH

20

CH

5C

H6

CH

7C

H8

CH

13

CH

14

CH

15

CH

16

CH

21

CH

22

CH

23

CH

24

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

5C

H6

CH

7C

H8

00

00

32-channel 24-channel 12-channel

CH

1C

H2

CH

3C

H4

CH

9C

H1

0C

H1

1C

H1

2

CH

5C

H6

CH

7C

H8

00

00

Sample[n] Sample[n+1]

Page 45

Bitec 2017

Figure 18 Examples of MST audio format

Audio Metadata (AM)

The Audio Metadata packet is introduced in HDMI 2.0. It is used to manage the Multi-

Stream and 3D audio packets. The layout of the Metadata packet is given in Table 9.

Complete definitions for the mnemonics can be found in the HDMI 2.0 standard.

Table 15 Audio Metadata bundle bit fields


0 3D_AUDIO =1 when transmitting 3D audio. =0 for MST

2:1 NUM_VIEWS Indicates the number of views for an MST stream

4:3 NUM_AUDIO_STR Number of audio streams

164:5 Payload data Corresponds to PB0 to PB19 of the Metadata packet

The Metadata payload data PB[0] to PB[19] vary according to the audio format. A

complete description of the payload can be found in the HDMI 2.0 specification.

ST2-

L

ST1-

LST

1-R

ST3-

LST

3-R

ST2-

R

Unused samples set to zero

ST2-

LST

2-R

ST1-

LST

1-R

ST1-

LST

1-R

ST0-

LST

0-R

ST0-

LST

0-R

ST0-

LST

0-R

00

00

00

2-Stream3-Stream4-Stream

Stream-1

Stream-0

Page 46

Bitec 2017

Audio InfoFrame (AI)

The core outputs the received Audio InfoFrame to simplify user applications. The signal bit

fields are defined in Table 16. For a complete description of the bit fields see the HDMI

1.4b Specification. The signal bundle is synchronous to the ls_clk.

Table 16 Audio InfoFrame bundle bit fields


7:0 Checksum

10:8 CC Channel count

11 reserved Returns zero

15:12 CT Audio format type

17:16 SS Bits-per-audio sample

20:18 SF Sampling Frequency

23:21 Reserved Returns zero

31:24 CXT Audio format type of the audio stream

39:32 CA Speaker location allocation FL, FR

41:40 LFEPBL LFE playback level information, dB

42 Reserved Returns zero

46:43 LSV Level Shift Information, dB

47 DM_INH Down-mix inhibit flag

HDCP Decryption (Optional)

The Core supports HDCP 1.4 decryption. This optional feature is supplied upon request.

HDCP decryption is fully automated in the receiver. The HDCP MM slave interface

presents the standard HDCP Port registers and addresses as described in the HDCP

Specification. Typically, this port would be driven by and external i2c slave component.

Page 47

Bitec 2017

During this Authentication, the core requires access to a valid HDCP key-set via a memory

interface.


For applications using the HDMI 2.0 feature set the core provides a memory slave port to

the SCD registers. The address map for the registers can be found in the HDMI 2.0

specification. Typically, this port will be connected to an i2c slave component.

The TMDS_Bit_clock_Ratio output from the SCDC interface indicates when ¼ clocking is

required. This bit has a direct connection to its corresponding field in the SCDC registers.

Assertion of the Scrambler_Enable output indicates when scrambling has been enabled.

The HDMI 2.0 specification requires the core to respond to the presence of the 5V input

from the connector and also the state of the HPD signal. These are used in the register

update mechanism updates. The signals are synchronous to the scdc_i2c_clk clock

domain. Also, a 100ms delay on the HPD signal must be created externally to the core.

The scdc_i2c_clk frequency is used by the Error Detection logic to measure 10ms intervals

as discussed earlier. As such, it should be set to 10Mhz to ensure correct operation.

Parameterization

The HDMI Receiver core accepts the following parameterizations.

Parameter Description Default value

SUPPORT_AUXILIARY Determines if Auxiliary channel decoding

is included. 0=no Aux, 1=Aux

1

SUPPORT_DEEPCOLOR1 Determines if the core will decode deep

color formats. 0= no Deepcolor,

1=Deepcolor

0

SYMBOLS_PER_CLOCK Determines how many TMDS symbols 1

Page 48

Bitec 2017

and pixels are processed per clock. 1, 2

or 4 symbols per clock are valid

SUPPORT_AUDIO1 When asserted the core will support 2-

channel audio

1

SUPPORT_8CHAN_AUDIO1 When asserted the core will support 8-

channel audio

1

SUPPORT_32_CHAN_AUDIO1,2 When asserted the core will support 32-

channel audio

1

SUPPORT_SSDC2 When asserted the core includes the

descrambling logic required for HDMI

2.0.

0

I2C_CLK_NS Nanosecond period of I2C clock. This is

used to determine real-time internal

counters. Valid range is 1/1Mhz to

1/100Mhz

1/10Mhz

SUPPORT_HDCP13 Determines if HDCP 1.4 encryption logic

is included in the core. 1=yes, 0=no

0

SUPPORT_HDCP23 Determines if HDCP 2.2 encryption logic

is included in the core. 1=yes, 0=no

0

SCDC_IEEE_ID IEEE ID Number used in the SCDC

interface

0

SCDC_DEVICE_STRING Manufacturer's IEEE_OUI. See HDMI 2.0

Specification for details

0

SCDC_HW_REVISION Hardware Revision. See HDMI 2.0

Specification for details

0

1 These parameters require SUPPORT_AUXILIARY

2Only supported in HDMI 2.0

3Requires Optional HDCP licenses

Page 49

Bitec 2017

DVI Mode of operation

The HDMI Core is compatible with both DVI source and sink devices. The HDMI Sink core

has a mode output signal which, when de-asserted, indicates the TMDS data is DVI

encoded. The HDMI Source core has a mode input signal which, when asserted, forces the

source to generate DVI encoded TMDS data. When DVI encoded TMDS data is being used

no data islands or guard-bands are transmitted.

Dual-Link DVI operation

Both the HDMI source and sink can be used in Dual-Link DVI operation. This is achieved by

instantiating two HDMI cores in a design. The two HDMI cores correspond to the DL-DVI

Master and Slave. The slave interface vertical and horizontal timing information is ignored.

DL-DVI Source

An implementation of a DL-DVI Source is shown in Figure 19. Identical HDMI Source

instantiations are designated as master and slave. The horizontal and vertical sync pulses

are used in the master link only. Deepcolor is not supported in DVI mode and as such the

ls_clk and vid_clk are the same frequency.

Only a single TMDS clock is used over the DL-DVI link. This single clock is taken from the

master link as shown.

Page 50

Bitec 2017

Figure 19 DL-DVI Source implementation

DL-DVI Sink

An implementation of a DL-DVI Sink is shown in Figure 20. As with the source, the Master

link is used for horizontal and vertical sync data. The single DL-DVI clock is sued to drive

both master and slave interfaces.

Transceiver Quad

Transceiver Quad

HDMI Source Core(Slave)

PLL

HDMI Source Core(Master)

vid_clk

R_odd

G_odd

B_odd

R_even

G_even

B_even

de

de

h

v

DV

I Co

nn

ecto

r

FPGA

ls_clk vid_clk

ls_clk vid_clk

R_odd

G_odd

B_odd

R_even

G_even

B_even

Clock

Page 51

Bitec 2017

Figure 20 DL-DVI Sink implementation

As there will be channel skew between the Master and Slave interfaces, alignment logic is

necessary. A suggested alignment circuit is shown in Figure 21. A Single-Clock FIFO is used

to remove any skew between the Master and Slave channel. The exclusive-OR gate logic

ensures the respective SCFIFO is only read when both master and slave video stream de

signal is aligned. There are various techniques available to implement de-skew which may

be application specific.

Transceiver Quad

Transceiver Quad

HDMI Sink Core(Slave)

Alignment

R_odd

G_odd

B_odd

R_even

G_even

B_even

PLL

HDMI Sink Core(Master)

DVI CLOCK Vid_clk

R_odd

G_odd

B_odd

R_even

G_even

B_even

de

de

h

v

de

h

vDV

I Co

nn

ecto

r

FPGA

ls_clk vid_clk

ls_clk vid_clk

Page 52

Bitec 2017

Figure 21 Example of Master-Slave alignment implementation

HDMI IP Core Design Implementation

The HDMI Core requires minimal external components for correct interfacing. The

Receiver core requires external AC coupling capacitors. Optionally, the receiver may

employ an external Adaptive Cable equalizer component for added robustness and device

protection. The receiver interface is shown below in Figure 22. The HDMI clock channel is

used to drive a dedicated clock input. This input may require external termination

resistors.

SCFIFO

R_odd

G_odd

B_odd

R_even

G_even

B_even

de (Slave)

hv

de (master)

data q

rdwrclk

vcc

SCFIFO

data q

rdwrclk

vcc

R_odd

G_odd

B_odd

de (Slave)

R_even

G_even

B_even

hv

de (master)

de (master)

de (slave)

Page 53

Bitec 2017

Figure 22 HDMI Receiver physical implementation

The Transmitter core requires an external TMDS level shifter component to convert the

native transceiver LVPECL to the TMDS CML standard. Again, series AC coupling capacitors

are required as shown in

Figure 23 HDMI Transmitter physical implementation

Clocking Trees

The Receiver clocking is shown in Figure 24. The Transceiver 20-bit data is clocked in to the

core using the three CDR clocks (ls_clk[2:0]). All TMDS and TERC4 decoding is done at link-

speed clock. The pixel data is then re-sampled and presented at the output of the core at

the video pixel clock (clk). The pixel data clock is dependent on the video format in use.

The HDMI specification allows for either 8, 10, 12 or 16bpp corresponding to clocks of 1,

1.25, 1.5 and 2 times the link speed clock. The diagram shows how these different clocks

can be selected for the core.

FPGA

HD

MI C

on

ne

ctor

Ad

aptive

cable

eq

ualize

r

CLK_p/n

GXB

GXB

GXB

HD

MI C

on

ne

ctor

FPGA

TMD

S Leve

l Shifter

GXB

GXB

GXB

GXB

Page 54

Bitec 2017

Figure 24 Receiver clocking Tree

The transmitter clocking tree is shown in Figure 25. Pixel data is clocked in to the core at

the pixel clock (clk). This same clock is used to derive the required link-speed clock (ls_clk)

which is used to drive the Transceivers CMU PLL input. The ls_clk is dependent on the

color bits per pixel (bpp). The core ls_clk should be connected to the transceiver clock

output which is used to perform the TMDS and TERC4 encoding. Auxiliary data is clocked

in to the core at the ls_clk rate.

HSSI[0]

CDR PLL

TMDS(TERC4)Decoder

Re-Sampler

FIFO

HDMI CLK

WRCLK RDCLK

WRCLK

Chan[0]

VideoData

Transceiver

SYNC

HSSI[0]

WRCLK RDCLKChan[1]

SYNC

HSSI[0]

WRCLK RDCLKChan[2]

SYNC

RDCLK

SwitchGPLL

ls_clk[0]

ls_clk[1]

ls_clk[2]

AUXData

VideoData

clk

bpp

x1.25

x1.5

X2.0

X1.0

HDMI Core

Page 55

Bitec 2017

Figure 25 Transmitter Clocking Tree

ls_clk

SYNC

SYNC

SYNC

SYNC

WRCLK RDCLK

WRCLK RDCLK

WRCLK RDCLK

WRCLK RDCLK

HSSO[0]

HSSO[1]

HSSO[2]

HSSO[3]

CMU PLL

Re-sampler

FIFO

WRCLK RDCLK

Pixel data

TMDS

(TERC4)Encoder

Clk

Chan[2]

Chan[1]

Chan[0]

AUX Data

Transceiver QUAD

clk

clk

SwitchGPLLx1.25

x1.5

X2.0

X1.0

bpp

HDMI Core

Page 56

Bitec 2017

Bitec

Edificio Diz

C/ Guadiaza 25

San Pedro Alcantara,

Malaga 29670 Spain

Tel : +34 91 632 69 66

Fax : +34 91 790 50 27

E-mail: [email protected]

Internet: www.bitec-dsp.com

All information and data contained in this data sheet are

without any commitment, are not to be considered as an

offer for conclusion of a contract, nor shall they be

construed as to create any liability. Any new issue of this

data sheet invalidates previous issues. Product availability

and delivery are exclusively subject to our respective order

confirmation form; the same applies to orders based on

development samples delivered. By this publication, Bitec

does not assume responsibility for patent infringements or

other rights of third parties, which may result from its use.

Further, Bitec reserves the right to revise this publication

and to make changes to its content, at any time, without

obligation to notify any person or entity of such revisions

or changes. No part of this publication may be reproduced,

photocopied, stored on a retrieval system, or transmitted

without the express written consent of Bitec.

Date post:	28-Jul-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Bitec HDMI IP Core User Manual · 2019-10-25 · In addition, with HDMI 2.0 the TMDS and TERC4 data...

Documents