
1. SST协议基础DP协议中的关键角色第一次接触DP协议时我被它复杂的传输机制搞得晕头转向。直到把SSTSecondary Stream Transport协议拆开来看才发现这套机制设计得相当精妙。简单来说SST就像是DP协议中的快递员专门负责视频、音频这些次要数据流的传输工作。与主数据流不同SST采用了更灵活的打包方式通过TU传输单元这个标准化的集装箱来运送数据。在实际项目中我遇到过显示器花屏的问题最后发现是SST协议中的BS符号插入位置不对。这让我意识到理解这些看似枯燥的控制符号有多重要。举个例子当你的4K显示器出现画面撕裂时很可能就是BE符号没有正确标记有效像素的起始位置。2. 关键控制符号详解视频传输的交通信号灯2.1 BS与BE画面显示的起止标记BSBlanking Start和BEBlanking End这对搭档控制着视频显示的节奏。BS就像是下课铃告诉显示器这行像素显示完了该休息了。在代码中它用K28.5表示8hBC这个特殊字符能让接收端快速识别。我在调试HDMI转DP的转换器时发现如果BS插入位置偏差超过3个像素时钟就会导致画面右移。正确的插入规则是垂直消隐期在最后一个有效像素后立即插入水平消隐期每行最后一个有效数据后插入无视频数据时每隔8192个符号强制插入一个BSBE8hFB/K27.7则相反它像是上课铃宣告新一行像素的开始。设计规范要求必须在每行第一个有效像素前准确插入误差必须小于1个时钟周期。2.2 SR符号加扰器的复位开关SRScrambler Reset这个K28.08h1C符号特别有意思。它就像是给加扰器按了个重启键每512个BS符号就必须用SR替代一次。为什么要这样设计我在测试中发现如果不定期复位加扰器长时间传输后误码率会明显上升。实际应用中有一个坑内容保护模式下的CPSR符号8hDC和普通SR长得不一样。有次我做内容保护测试时因为没注意这个区别导致解密模块一直报错。3. TU单元设计数据传输的精妙容器3.1 TU的结构与填充机制TU传输单元是SST协议中最让我惊艳的设计。每个TU固定64字节大小就像标准化集装箱。但真正巧妙的是它的填充机制当数据不足时会用FSFill Start8hFE/K30.7和FEFill End8hF7/K23.7这两个符号来垫空间。这里有个实用技巧如果只需要填充2个符号应该直接插入FSFE如果只需填充1个符号则省略FS只插FE。我在Verilog代码中是这样实现的if (fill_num 1) begin tx_symbol FE; end else if (fill_num 2) begin tx_symbol FS; next_symbol FE; end3.2 有效数据量计算计算TU中有效数据符号数量的公式看起来简单有效符号数 (packed_data_rate / link_symbol_rate) * 64但packed_data_rate这个参数经常让人困惑。经过实测对于4:2:0的4K60Hz视频packed_data_rate 像素时钟 × 每像素位数link_symbol_rate 链路速率(Gbps) / 10 × 8比如使用HBR38.1Gbps传输时link_symbol_rate 8.1 / 10 * 8 6.48 Gsymbol/s packed_data_rate 594 MHz × 24bit 14.256 Gbit/s 有效符号数 (14.256/6.48) × 64 ≈ 141最后一个TU经常需要补零。有次调试发现画面底部有噪点就是因为没处理好这个补零操作。4. 实战中的设计考量4.1 多协议协同工作SST不是独立工作的它需要和主数据流完美配合。MSAMain Stream Attribute信息必须传输4次无论链路数量多少。这个设计保证了不同设备间的兼容性。在开发多屏显示系统时我遇到过MSA传输次数不对导致副屏无信号的问题。后来用逻辑分析仪抓包发现某厂商的DP芯片会偷偷修改MSA计数不得不加了个强制重传机制。4.2 音频数据的特殊处理音频数据在进入MUX前会被加上SSStart of Stream8h5C/K28.2和SEEnd of Stream8hFD/K29.7这对标记。有意思的是音频包可以跨TU边界存放这点和视频数据完全不同。有个容易忽略的细节当音频采样率超过192kHz时SS符号的插入间隔需要调整。某高端DAC芯片就因为这个问题导致爆音后来通过修改SS间隔寄存器才解决。4.3 时序容限测试经验在CE认证测试中SST符号的时序要求特别严格。根据实测经验BS/BE的位置偏差必须小于±2个像素时钟SR间隔必须在512±5个BS范围内FS到FE之间的填充符号不能有跳变建议用带协议分析功能的示波器比如Keysight UXR系列来验证这些时序。普通逻辑分析仪可能抓不到K符号的特殊编码。