DP1.2 spec 阅读笔记（二）链路层

最新推荐文章于 2024-07-19 12:31:38 发布

not_lubao

最新推荐文章于 2024-07-19 12:31:38 发布

阅读量1.3k

点赞数 22

分类专栏： DP1.2 文章标签：笔记 fpga开发

本文链接：https://blog.csdn.net/qq_69954392/article/details/135821635

版权

DP1.2 专栏收录该内容

3 篇文章 4 订阅

订阅专栏

2.2 在SST模式下的同步运输服务

链路层的同步传输服务提供以下内容：

与主链路通道之间的流数据的映射

打包与拆分（Packing and unpacking ）

填充与去除（Stuffing and unstuffing）

构建与解构（Framing and unframing）

信道间倾斜和去除倾斜（Inter-lane skewing and de-skewing）

数据流时钟恢复

主数据流属性数据的插入

可选的插入带有ECC的辅助数据包

音频流包

CEA861-E信息帧包

ECC：Error Correcting Code，错误纠正码

2.2.1 发射端设备中的主数据流到主链路信道映射

主链路必须有一、二或四个信道，每个信道能够为每个链路符号时钟（link symbol clock ，LS_Clk）传输8位数据。主数据流的数据（未压缩的视频流）在链路层数据映射以用于在主链路上传输之后且将其切换到PHY层之前，必须被打包、填充、构建，并与辅助数据进行多路复用和通道间倾斜。数据流的数据必须以原始数据流时钟（stream clock，Strm_Clk）的速率进入链路层，并且必须在此映射之后以LS_Clk的速率传输到PHY层。

PHY：Physical Layer，物理层，由逻辑和电气子块组成。物理层将数据传输电气规范与显示端口链路层解耦。

图2-8和图2-9分别显示了发送（uPacket TX）和接收（uPacket RX）设备中的数据映射。

图2-8：DP uPacket TX主链路数据路径高层框图

注意：

a）逻辑方框图。实际的实施情况可能会有所不同。

b）ECC和CP加密块都是可选的。为了支持辅助数据包，需要ECC。

CP：Content Protection，内容保护

SR：Scrambler Reset，扰码器重置符号。

TBC：时基转换器。认为是某种用于数据跨时钟域处理的电路。

P-to-S converter：并变串的转换器。

Strm_Clk时钟域中，辅助数据源、信息数据包编码器和主数据流源经过跨时钟域处理进入LS_Clk时钟域中；数据再通过总线steering给每个信道分配辅助数据包、分隔符/填充物和主数据包，并加入主数据流源传输的DE、H/Vsync时钟信号作为选择器的控制信号；以通道0为例，先后进行插入SR、加密块、通道间倾斜插入、扰码器、编码器和并变串的转换器。

图2-9：DP uPacket RX主链路数据路径高层框图

注：

a）逻辑方框图。实际的实施情况可能会有所不同。

b）ECC和CP解密块都是可选的。为了支持辅助数据包，除了扩展的辅助数据包（第2.2.5.4节）外，还需要ECC。

TBR：时间基础恢复单元。

TG：时钟生成器。

PHY层中，以通道0为例，先后进行串变并的转换器、解码器和解扰器；然后进入链路层，先后进行通道间倾斜去除、解密块并根据内容进行拆分，再分别进行辅助数据包流和主数据流的解打包；再通过总线的反steering和跨时钟预处理从LS_Clk时钟域进入Strm_Clk时钟域中，分别给辅助数据接收器和主数据接收器加入辅助数据包TBR和TBR/ TG，生成可用的时钟。

主链路数据映射应按以下顺序进行：

主流数据的打包、填充和框架构建

可选的辅助数据框架和多路复用

2.2.1.1 框架（framing）控制符号：默认框架模式

此处对数据类型进行简单扩展（计算机网络领域的解释，不太清楚这里是不是这个意思）

数据帧（frame data）就是数据链路层的协议数据单元，它包括三部分：帧头，数据部分，帧尾。其中，帧头和帧尾包含一些必要的控制信息，比如同步信息、地址信息、差错控制信息等；数据部分则包含网络层传下来的数据，比如IP数据包，等等。

包（Packet）是TCP/IP协议通信传输中的数据单位，一般也称“数据包”。在局域网中，“包”是包含在“帧”里的。在包交换网络里，单个消息被划分为多个数据块，这些数据块称为包，它包含发送者和接收者的地址信息。这些包然后沿着不同的路径在一个或多个网络中传输，并且在目的地重新组合。

对于框架数据（framing data，或许是帧数据？由于不确定，下文皆翻译为框架），必须使用以下9个控制符号：

BS（Blanking Start，空白开始）

对于DPCD版本为1.2或更高的uPacket RX，在以SST模式运行时，必须使用下一节（第2.2.1.2节）中描述的增强框架模式。上游设备与DPCD版本1.2或更高版本的下游设备互操作必须启用增强框架模式。其中，空白开始点由每个信道上的四个符号序列组成。

在垂直显示期间的最后一个活动像素之后插入。

在垂直消隐期间以与垂直显示期间相同的符号时间插入。

这个帧符号必须定期（每213或8192个符号）插入，为没有主视频流数据发送的活动链接。在这种情况下，BS符号后面是VB-ID，其NoVideoStream_Flag设置为1。（有关VB-ID的更多信息，请参阅第2.2.1节）此链接符号模式称为“空闲模式”。

VB-ID：Vertical Blanking ID，垂直空白ID。数据符号，表示视频流是否处于垂直消隐间隔，是否传输视频流，是否要静音音频。

BE（Blanking End，空白结束）

仅在垂直显示期间立即插入直线的第一个活动像素之前。

FS（Fill Start，填充开始）

在传输单元中填充符号的开头插入。

注：传输单元详见第2.2.1.4.1节。

当只有一个填充符号时被FS省略。在这种情况下，插入FE（填充端）而没有插入FS。

当只有两个填充符号时，FS和FE之间没有填充数据符号。

FE（Fill End，填充结束）

插入到传输单元内的填充符号的结尾。

SS（Secondary-data Start，辅助数据开始）

在辅助数据的开头插入。

SS（Secondary-data End，辅助数据结束）

在辅助数据的结尾插入。

SR （Scrambler Reset，扰码器重置）

对于DPCD修订版为1.2或更高版本的uPacket RX，在SST模式下运行时，必须使用下一节（第2.2.1.2节）中描述的增强框架模式。上游设备与DPCD版本为1.2或更高版本的下游设备互操作，必须启用增强帧模式。在增强型帧模式下，扰码器重置由每个信道上的四个符号序列组成。

每第512个BS符号必须用uPacket TX替换为SR符号，以重置扰码器的LFSR。

LFSR：Linear Feedback Shift Register，线性反馈移位寄存器。

扰码：扰码就是对原始的用户数据进行扰乱，得到随机化的用户数据。连续扰码两次就能得到原始数据，通常是发送电路在发送数据时先对数据进行随机扰乱，接收电路使用相同的扰乱算法（解扰器）就可以重新恢复出原始的数据。

CPBS（Content Protection BS，内容保护BS）

对于DPCD修订版为1.2或更高版本的uPacket RX，在SST模式下运行时，必须使用下一节（第2.2.1.2节）中描述的增强框架模式。上游设备与DPCD版本为1.2或更高版本的下游设备互操作，必须启用增强框架模式。在增强型框架模式下，内容保护BS由每个信道上的4个符号序列组成。

由CP系统使用。在第2.2.1.2节中描述的增强型框架模式中，称为“CP”符号。

CPSR（Content Protection SR，内容保护SR）

对于DPCD修订版为1.2或更高版本的uPacket RX，在SST模式下运行时，必须使用下一节（第2.2.1.2节）中描述的增强框架模式。上游设备与DPCD版本为1.2或更高版本的下游设备互操作，必须启用增强框架模式。在增强型框架模式下，内容保护SR由每个信道上的4个符号序列组成。

由CP系统使用。CPSR会像SR一样重置扰码器的LFSR。在第2.2.1.2节中描述的增强型框架模式中，称为“BF”符号。

这些控制符号必须插入到同一LS_Clk周期中的所有信道中（在它们在进入PHY层之前被信道间倾斜2个LS_Clk周期之前）。链接层必须将这些控制符号与数据符号区分开来，以便物理层能够使用“特殊字符”正确地编码这些控制符号。

例如，链路层可以使用第9位来指示所伴随的8位数据是表示控制符号还是数据符号。链接层有许多方法可以实现这种区别，所使用的方法是特定于实现的，并且超出了本文档的范围。

2.2.1.2 框架控制符号：增强型框架模式

BS、SR、CPBS和CPSR符号必须更换，如表2-61所示。只有当显示端口的uPacket TX和uPacket RX都支持它时，才会启用增强的框架模式。

显示端口uPacket RX表示它在DPCD的uPacket RX功能字段中的ENHANCED_FRAME_CAP位的支持。如表2-75所述，通过在DPCD的链接配置字段中写入1到ENHANCED_FRAME_EN位（地址101h的位7）来实现它。一旦启用，BS、SR、CPBS和CPSR符号必须替换为表2-61中的四个符号序列：不管主链路的信道计数如何。

表2-1：框架中的控制符号

这些控制符号与ANSI 8B/10B特殊字符的映射详见第3章。

当显示端口的uPacket TX在增强框架模式下运行正在传输Idle Pattern时，uPacket TX必须每8,192（2^13）个符号插入BS（或SR）的四个符号序列。换句话说，在BS（或SR）的四个符号序列的最后（第四）符号和下一个四个符号序列的第一个符号之间必须有8,188个符号。

在默认框架模式和增强型框架模式中，每第512个BS（或CPBS)符号都必须替换为SR（或CPSR)。必须使用SR的四个符号序列（或启用内容保护时的CPSR）的最后一个符号来重置扰码器。

当在Idle Pattern传输和数据流传输之间切换时，发射端设备必须避免BS、SR、CPBS和CPSR的四个符号的任何重叠。

显示端口uPacket TX和具有HDCP功能的显示端口uPacket RX必须支持增强的框架模式。

HDCP：High-bandwidth Digital Content Protection，高带宽数字内容保护，显示端口链路的内容保护系统选项之一。

注意： HDCP不是显示端口标准的一部分。

2.2.1.3 主视频数据流的数据打包

链路层必须首先以信道内像素的方式引导（Steer）像素数据，如表2-2所示。

表2-2：进入主连接车道的像素转向（Steering）

这些规则适用于视频，而不管视频流的颜色空间/像素位深度如何。如下图所示，一行的第一组活动部分像素数据必须遵循控制符号BE。

图2-10：一个四通道主链路的主视频流数据打包示例

当没有音频流传输时，Maud [7:0]必须被清除到00h。当没有视频流传输时，Mvid [7:0]必须设置为00h。

Maud：M value for audio，音频的M值。

在一行像素数据的最后一个符号时间内，可能没有足够的像素数据来提供该链路的所有通道上的数据。显示端口的uPacket TX必须为这些位发送零（零填充位）。

紧接一行数据的最后一个符号周期之后，控制符号必须插入链路的所有通道的BS。

接收端设备，知道每条水平线的活动（active）像素数（从主数据流属性），必须丢弃零填充的位，因为“并不在乎”。上图显示，新行必须始终以通道0上的像素0开始。

所有车道上的BS都必须遵循VB-ID、Mvid [7:0]和Maud [7:0]。

四个通道都由BE开始，然后传输第N行的像素数据，从左到右从上到下填充，最后一行空余部分使用0填充；然后四个通道都先后传输BS、VB-ID、Mvid [7:0]和Maud [7:0]；最后是大量无意义的虚拟符号（可用音频数据包代替）。

VB-ID必须携带以下信息：

主视频流是处于垂直显示期间还是处于垂直消隐期间。

主视频流是交错还是是非交错（渐进式progressive）。

交错视频的主视频流是在奇数场还是偶数场。

是否要将音频静音。

是否在没有视频流传输时插入BS。此时，通过主链路传输的符号如表2-3所示。

交错视频由两个扫描场组成，这两个扫描场构成了每一个视频帧。每一个扫描场都包含一帧中一半数量的水平线，上部扫描场（或奇数场）包含所有奇数线，下部扫描场（或偶数场）则包含所有偶数线。交错视频显示器（如电视机）先绘制一个扫描场中的所有线再绘制另一个扫描场中的所有线，从而显示每一帧。扫描场顺序指定先绘制哪个扫描场。

例如PAL接口协议中，规定第一帧只扫描刷新奇数线，第二帧只扫描刷新偶数线，因此60Hz实际上相当于非交错刷新的30Hz。

表2-3：VB-ID位定义

Bit0：垂直消隐标志。这个位必须在视频帧的最后一条活动的行的末尾设置为1，并在垂直消隐期间保持为1。发射端设备可以在视频帧的第一条活动行之前（即视频帧的第一活动帧的第一个BS）之后或在VB-ID中清除该位。接受端设备必须能够处理任何一种情况。当没有视频流时，该位也被设置为1（如第3位设置为1所指示）。

Bit1：FieldID标志。此位必须设置为：

0，在顶部Field中的最后一条活动行之后。

1，在底部Field中的最后一条活动行之后，顶部和底部Field的定义参见2.2.2.2。

对于渐进（非交错）视频，没有底部Field，此位保持为0。

Bit2：交错标志。当主数据流是一个交错的视频时，此位必须设置为1。对于非交错视频或无视频，此位必须保持为0。

Bit3：无视频流标志。没有传输视频流的情况下插入前面的BS时，此位必须设置为1。当Bit3=1时，Mvid [7:0]值没有意义。注：即使没有传输主视频流，也可以传输音频流。

Bit4：音频静音标志。当音频被静音时此位必须设置为1。

Bit5：HDCP同步检测。使用HDCP功能显示端口uPacket RX检测CP锁状态。请参考HDCP规范1.3-显示端口的修正案

Bit[6:7]：保留位。全为0。

Mvid [7:0]

是视频流的时间戳值M的最不显著的8位。当没有视频流传输时，设置为00h。

时间戳必须用于数据流时钟恢复，其主题见第2.2.3节。