HDMI回顾

    今天有空看了一下MStar的HDMI Transmitter的source code。两个月前用过了SIL的HDMI Transmitter9030，正好有个机会做个比较。

    一般来说芯片商建议的HDMI Transmitter player方案主要是由是一块MCU+一块Transmit芯片，其中那块MCU是用来配置HDMITX，以及与player的解码主chip进行通讯的。在播放过程中，我们可以通过主动和被动的模式来配置HDMI的输出，主动地模式是由那块MCU与player的MPEG decoder通过异步通讯等到更新的video resolution和audio referenceclock，从而对Transmit芯片进行配置。被动模式则由MCU去读取HDMITX内部的一些寄存器，例如Pixel Clock的值和Video resolution的值(640X480,720X480等)，以及Sync的极性，根据变化来配置HDMITX,而HDMITX则是从输入信号上采样等到这些数值，用于进行HDMI输出编码。

     因此不管做哪一个方案，我得到的sourcecode都是51单片机的代码，老YU说看别人的代码是长经验的(同意)，这次我也总算温习了一把忘得差不多的单片机coding技术了。

所以先讲一点51的基本知识，也算是自己回顾一下

1.MCU51内部有4K的程序存储器，如果在实际运用中内存不够的话，可以在此基础上扩展到64K大小，对于程序员来讲，无论是内部的EPROM，还是扩展的程序存储器是没有什么区别的，在MCU内部有一个十六位的程序记数器PC可以寻址片内及片外的EPROM。

 

2.MCU51有128字节的RAM(data变量)，也可以外接RAM电路，是数据存储器的容量达到64K字节

 

3.8051 特有的数据类型的定义

 

code    以 MOVC @A+DPTR 读取的程式

看到这个熟悉的DPTR寄存器。让我想到了80386中的GDTR跟LDTR，当然后两个是CPU中的段描述表寄存器，是在段式内存管理中用来查询段描述表指针跟段寄存器的，而DPTR则是由DPH(8bit)跟DPL(8bit)组成的16bit直接寻址寄存器。

 

data    可以直接存取的內部RAM

        固定指前面0x00-0x7f的128个RAM，可以用acc直接读写的，速度最快，生成的代码也最小。而从0x80开始到0xff的RAM都被定义成了MCU的设备寄存器，例如P0,P1之类的

idata    以 Mov @Rn 存取的內部RAM

固定指前面0x00-0xff的256个RAM,其中前128和data的128完全相同，只是因为访问的方式不同。idata是用类似C中的指针方式(我们用来声明程序段内的局部变量，因此是用寄存器Rn来存取)

bdata    可以位元定址（Bit Addressable）的內部RAM

         个人认为像C中struct里面的位元定址

xdata    以 MOVX @DPTR 存取的外部RAM

一般指外部0x0000-0xffff空间，所以要用DPTR的16位寻址(我们用来存放大量的全局变量，放在外部的扩展mem内)

pdata    以 MOVX @Rn 存取的外部RAM

         指外部扩展RAM的低256个字节，据说C51对这个有Bug，不推荐使用

 

4.还有一些特殊的地方就是

 srf,定义一个8位的设备。

srf16,定义一个16位的设备。

sbit,定义一个位的设备。

用这些语句定义后，就可以在C中象汇编一样使用这些硬件设备。

 

讲完前面的一大段“荡~~~气回肠”的介绍之后，我来谈谈自己对使用这两款芯片的体会。

首先要感慨一下美帝的强大，SIL的芯片模块清晰，使用起来如石上清泉，松间明月般沁人心脾,80pin的PQFP封装，薄薄的一小片低功耗chip提供了强劲的从480i到1080i，从32KHz到192KHz,Video/Audio编码加密的功能。

而且比较有特色的是它的内部集成了一个I2C的逻辑，接管了DDC总线的通讯，加上那些secret keys都是存在片内的memory内，从而在进行HDCP(High-bandwidth Digital Content Protection System)的密钥的计算和交换时变得更加方便与安全。

回头看看Mstar 的TX，由于集成了一个video ADC在里面，芯片的体积大了很多(估计因为模拟的逻辑很占面积)。增加Video ADC的优点在于使模拟输入->HDMI输出成为了可能，从而可以提供更多的方案供player的生产商选择，但是缺点也很明显，模数转换部分的加入打乱了整体的结构，光看register map就给人一种乱哄哄的感觉。不过最让人faint的是它的cipher keys calculation部分竟然是放在chip外面来做的，而且将那一堆secret keys放在一个外部的RAM里面，丫也不怕被人拿去做破解用（虽说肯定是再次加过密的），且不说这些，光那些key的选取、计算，都要耗去多少MIPs，实在是对系统资源的无情的榨取。

再看看代码，更加体现出SIL作为HDMI标准的制定者之一的优势来。那个在SIL写code的俄罗斯老头思路清楚，代码简洁，通篇甚至看不到指针的使用，程序的流程非常直观(不过有个很明显的逻辑bug被我发现，不知道给我的是不是full released版本)。而MStar的代码就有点乱了，全局variable、struct一大堆,判断条件很多都是if(condition1&& condition2&& condition3…)，sigh,这咋让人整啊，给人的印象是对HDMI理解不是很深刻，require strong intellect of HDMI。

不过作为一家台湾的design house，在那么短的时间内，设计出可以商业应用的HDMITX，赶上美日，我为自己的中国同胞感到自豪。赞，希望他们tapeout的下一版能越来越好，越来越强。

最后谈一下HDMI的输出效果，可能这也是大家最关心的部分，通过在一台2000美刀的带HDMI输入的Panasonic LCD上数周的调试，与分量端子输入相比较，我可以很确定的告诉大家,HDMI输出很清晰，价格也很贵，普及还需时日。

 

注:关于HDCP，顾名思义，它是一个用来对数字信号进行加密的系统，在我看来老外们实在是放心不下他们版权，挖空心思想出这种高级的算法来，就是为了防止高清的视音频的信号在传输过程中被抓取，直接灌成盗版。在DVI接口设计的时候就有了该系统，但是只是一个optional的功能，现在则被强制加到了新一代的高清数字接口HDMI上，作为一个HDMI标准的一部分。想当初模拟的时候有MacroVision一样，保护版权就像是他们的立命根深一般。

HDCP的基本原理是这样的，每个HDMI的设备有一独一无二的KSV(Key Selection Vector),通过该vector从一个Device key array中得到自己的唯一的Secret Device key,再通过该key生成一系列encrypt keys来进行加密(是对每个pixel进行加密哦)，然后每隔2s左右还要变换一次encrypt keys，DDC bus的作用就是协调这些密钥的更替与交互。