DP/eDP协议学习－－视频传输格式

接上篇文章control symbols插入规则
协议里面关于对这部分还是讲的很清楚，但如果真的要实现，也没那么容易，因为支持得格式太多了。这里还是要简单介绍一下，不然总感觉漏了一部分。

视频数据流传输格式

如下图所示，不同的lane数量和像素的传输有一定的关系，如:使用4条lane，4N像素职能在lane0传输，即使在10ppc时，也不能把剩余的bit放在lane1传输，这个规定实际上简化了Tx和Rx的实现。

协议中规定BS后面必须跟着VBID+MVID+MAUD，VB-ID的定义如下图所示：

根据该定义可知，VB-ID可能随时在变化，最少vertical blanking区域和vertical display区域是不一样的，这里实现直接用组合逻辑就行：

always@(*)begin
	vbid[0]=逻辑；
	vbid[1]=逻辑；
	。。。。
	vbid[7]=reserved；
end 

还有一个重要规则是，无论使用几条lane，BS+VB-ID+Mvid+Maud都要发送4遍。这个规则应该就是增强鲁棒性，大家看视频的时候应该能体会到，人感知音频比视频敏感，所以后面协议介绍音频数据传输是有校验的，视频数据是没有校验的。同理，这些控制位要是出错了，那RX就别想解对数据。协议后面还讲到lane数据之间要有skew，也是为了增强鲁棒性，防止高频脉冲把同一时刻的所有数据都影响了。
另外这个还涉及到一个功能的实现-------在无视频传输的情况下，每条lane上，每8192个symbols要插入一个BS（上篇文章讲过），也就是每8188个symbols插入一个“BS+VB-ID+Mvid+Maud”

8bpc RGB/YCbCr 4:4:4 (24 bits per pixel)

相信大家都喜欢这种规则的排序

可是现实如果都是这么简单，DP协议的逼格何在！！！

10bpc RGB/YCbCr 4:4:4 (30 bits per pixel)

For YCbCr 4:4:4, replace R with Cr, G with Y, and B with Cb

我所接触项目的色深也就这两种，也是现在大部分视频的色深吧。
这里还有一个实现技巧：
就是无论色深是多少，先把有效像素截位，然后按照要求顺序拼在一起送你FIFO，这要读的时候按照8bit截取就好了。
！！！最重要的提示：
协议中规定，link_clk是链路速率的10分之一，也就是说当链路速率是5.4Gbps时，link_clk就是540MHz。但是DP1.4a中，当链路速率为8.1Gbps时，link_clk时810MHz，这个即使在14nm工艺下，芯片的时序也是难以承受的。所以可以在一个时钟周期产生4个symbols，这样link_clk就时链路速率的40分之以一，即使链路速率到了20Gbps，500MHz对于芯片时序还是完全可以接受的。

8bpc YCbCr 4:2:2 (16 bits per pixel)

10bpc YCbCr 4:2:2 (20 bits per pixel)

YCbCr444和YCbCr422区别请参考YCbCr444和YCbCr422区别

8bpc YCbCr 4:2:0 (12 bits per pixel）

YCbCr420这个比较有意思，一般情况下DP的视频数据接口是48bit的，对于420来说有些浪费，所以在实现的时候，可能Tcon的数据是Cb+Y0+Y1，这个时候像素时钟是减半的。

FS/FE的插入

diFS与FE时为了像素输入速率与发送速率的平衡，像素的打包速率只能小于等于发送速率，如果时小于，那么肯定要插入FS/FE。
这里面讲了TU中active symbol的计算协议简介

Inter-lane Skewing

inter-lane skewing就是在最终输出时，每条lane要有两个时钟的skew，其目的就是防止高频噪声的干扰。