转眼到了年底，芯原的bit文件出来后，我们持续进行测试。
芯原是大公司，遇到问题习惯性怀疑是我们这里的操作有毛病，于是反复的对比试验和扯皮开始了。
“fpga发现接收数码相机fir信号出现帧错误，因为出现80ns脉冲？”
芯原立马说这个脉冲是错误的。
我只能给对方看datasheet上的冗余度，告诉他们这种情况是在容错范围内的。
同时在开发板上换上EG的芯片，抓到同样的80ns脉冲的情况，EG能识别的现象给他们看。
假如说我这里遇到问题需要求助的话——
“小叶：
上次提到的芯片有时侯发送会把整个bank发送出来的问题，产生原因我现在还没发现什么规律，最近又经常发现了，有时侯还会有没有发送出来的情况．
请给我一些寄存器配置方面的建议
我现在是这样配置的：
......
”
对方就会回答：
“
elber，你好！
从你下面所列出的寄存器配置来看，我觉得应该没有什么问题，所以我目前也没什么建议可以提供。
我个人感觉，这个问题应该跟芯片工作稳定性有关。你最好在出现这种情况的时候，确认一下配置是否正常。（比如相关寄存器是否被正确写入）
”
基本上很难指望对方能帮得上忙，一切都得靠自己。
这段时间经常要去上海出差，现场解决问题。
FPGA验证持续了月余，其实时间是比较紧的，如果这时候不把问题都测出来，等到流片下去，就是一大笔钱。
而有些问题，我们的确认，是有风险的。
比如说，信号的时钟不准导致的偏差，这里面有个冗余度的问题。
冗余度太大，会引起错的frame识别不出来, 冗余度太小，会识别不了正确的frame，这个是需要反复测试的.
这个问题又和数据有一定关系，假如那个字节里有0的话一般不会出问题，时钟会重新锁定，假如哪个字节里有连续的1的话，就有可能出问题。
协议上并没有规定冗余度，所以不好保证设置好的冗余度能支持所有手机，我们只能用手上所持有的手机试了。
所有的手机通过就认为Pass，当然，风险就来源于手机库里的手机太少，不像我以前的客户，sanyo财大气粗，库里有几百台手机。
FPGA结束后，去中芯国际流片，wafer的芯片又要进行测试。
这一测，又是一堆问题。
“芯片在附近有手机信号或者日光灯直射的时候出现大量frame error。而FPGA没有。
而中午光线较好时无这种现象。清晨和黄昏以及阴雨天是红外线最强的时间。”
芯原回复，“请提供详细对比试验的数据。”
测试这项工作枯燥而无趣，最关键的部分在于，从大量的数据中，提取出有用的信息，并总结出来。
好在芯片总算在2009年的春节前新鲜出炉了。
达真方面也如约发来正式邮件：
“
Dear Peter&Elber,
通知一聲，已接獲Foxconn通知，Sharp案正式開案，
請再幫忙確認貴公司module能支持：
IRDA/IRSS......
”
Sharp案已經正式kick off，第一階段要在3/4前完成Module的driver porting。
这是我们的第一个项目，我们俱是摩拳擦掌，准备大干一场。
进入第二阶段，联合调试阶段，开始了漫长的煎熬。
因为这次协议的提供方是台湾的另一家公司ACTISYS，我们无需提供协议，只需要根据对方的要求写好底层的API接口就可以。
ACTISYS也是一家大公司，是红外协会的会员，负责接口的工程师是印度人Suresh，特点是遇到问题就发很长很长的英文邮件，大体意思无非两类。
一、这个问题肯定是SP的问题。
二、明天是周末，本人绝对不加班，有问题周一再搞。
芯片提供方ITE是联阳科技，位于台湾新竹，也是一家大公司，他们的付总一口官腔，遇到问题也是往SP身上推。
这种多方合作的项目，有很多问题是很难定位的。
所以，这段时间，Sharp方的日本经理经常在电话会议里发飙，指名道姓要elber 出来解释。
在问题没弄清楚之前，我只得忍气吞声。
这段时间我发的邮件必须有理有力有节，既要提供证据，又要维护大公司的颜面，毕竟以后还要合作下去，撕破脸皮不好。
比如说有一次，台湾ACTISYS方面开始测试协议，我们提供的API发现不能用，数封邮件来回后没有解决问题，我只能出差到深圳，最后抓了波形，发现问题在ITE的spi驱动。
于是还得发邮件向ACT解释：
“
Dear Suresh,
Please update the attached file for testing the IrSS Driver.
It includes these file as follow:
sdk\src\spi\mmp_spi.c
dpf\irphy.c
dpf\irdrv.c
We find a problem in SPI API.......
”
有时候遇到的问题简直百口莫辩。
ACTISYS有个设备叫做IR9200的测试仪，类似压力测试的东西，用来测大量发送数据时的误码率，过红外认证，必须过这么个测试。
大体原理是测试仪对我们发一帧数据，我们必须回复一模一样的帧回去，如此往复。
结果，一开始用EG的芯片可以过测试，而用我们的芯片则不行。
仪器显示我们的芯片会产生CRC 错误。
这下人赃俱获，跑不了了吧。
刚获知这个消息的时候，我一度也怀疑是自己芯片的问题。
结果后来debug后发现问题在于上层调用API的方式，在上层加锁后解决此问题，不然回复数据的时候有时候延时太大。
ITE的人立刻跳出来反对。
“elber你不要捣浆糊，你说是我们调用的问题，如果仅仅是延时了，IR9200也不应该报CRC错误！”
“我的话还没说完，这里面其实是有两个问题，你那边的软件导致回复变慢，IR9200其实也有bug，我接下来会发邮件详细解释这个bug。”
——
“
Dear all,
In our test, we found that every time when the IR9200 show CRC error of the frame sended by DPF,there is a large silence time. That will result in a fail recorded by IR3200.The root cause has ......
”
如此一番折腾，沉冤得雪。