在MStar的LTE研发记忆碎片

收到MStar Offer

        在Mstar面试后的两天，收到公司HR Fannie打来的电话，说可以给我Offer，我那时正好从面试另外的路上回家，是在地铁上，所以专门下地铁找了一个卖书的地方，然后听清楚了Offer的内容，工资是在面试的时候谈的工资，比我原来的工资还是能涨40%以上的，然后承诺给的股票也会写在Offer里，本来想要再多一点的，可是毕竟当时只有这一个Offer在手，万一黄了那可就麻烦了，要知道，因为晶晨半导体的Offer，一个月前，我就已经跟领导提出了离职了，如果再不拿到Offer，那就可能会变成裸辞了，当时可以还有50万的房贷在压着呢。

        后来也接到了中航电子的Offer，国企吗，猜到了，工资不是很给力，然后上班的地方又太远，在紫竹，要知道我那时可以住宝山的啊，那就算是不加班，我也得摸黑起，摸黑回啊。所以，虽然打电话的哥们拿户口，事业编制等开导我，还是没让我改变主意。 

    开始在MStar的工作

        一开始的一个月，是在浦西春申路这边上班。 公司整体正在做3G TDS/WCDMA（硬件是一套）的开发，已经开始到外场开始做现网测试，但还存在很多问题，并且一时半刻解决不了的样子，只有我们Team是例外，主要是和英国人合作一起在做LTE，MStar以前一直是做电视芯片的，做手机芯片是从收购TTPCom开始的，2G是直接拿来主义，3G是原有TTPCom的基础上加以修改，但因为可能考虑到成本的原因，后来从ARM平台转到了MIPS平台，据说这浪费了很长的时间，我也是进公司后来听前辈门说的。然后，LTE这一块是完全新开发的，硬件和算法是法国人在做，协议栈是我们这边和英国人一起做，英国人主要负责L2，我们组主要负责L3，但因为可能是后续打算接手过来，所以我们这边也开始招L2的人，我进去主要是负责PDCP和RLC这一块的，而MAC则由另外一位同事负责。当时，有位女同事请产假了，暂时没来。她以前是做TDS的L2的，回来后也将加入LTE L2团队。第一个月主要是在给PDCP做UT测试，找到了一两个Bug，老大也对我的VC调试过程赞赏有加。

    英国人的代码风格

    

        一个多月后，就搬到了浦东新办公楼，工作还是继续，L2主要是Review英国人写的代码，并且找出问题，英国人写的代码不像中国人，一上来就想把一个模块的事情做完，然后在下一个模块这样，他们会先把整体代码框架搭好，然后，慢慢写，在他们看来，不出错比赶进度重要的多，所以Review他们的代码，很少能找到逻辑上的问题，

         

         印象还比较深的是他们对硬件的了解，好像他们在写代码的时候时时刻刻都在思考如何才能使这段代码的运行效率更高，比如，因为L2的Memory都是不进Cache的，所以每操作一次Memory都会导致一次EMI的读或写，所以它们的代码会想办法把尽量把读和写EMI的操作集中在一起，比如，我们写代码时，可能会读一个字节，然后进行一下与或者非等的操作，然后再写回Memory，他们不是的，他们是一次读四个字节到一个寄存器，等这四个字节的操作都完成后，才会写回去。

        

        还有，另外一点，在我现在看来觉得不是好习惯，就是他们喜欢把一个函数写得很长，就是说它们认为没有必要时，它们不会把一个函数拆开来的，这样做确实有一个好处是减少了压栈出栈的操作，会提高效率，但是会让一个函数实现太多功能，比较难以理解。我是喜欢一个小函数，一个小宏，实现一个功能这样的，所以有很多时候，我经常会把代码提练提练出来的。

        另外，不得不提的是，MStar有一个个人认为比较牛B的自动化测试工具，叫ADZ/Borg，应该是从TTPCom继承下来的，它保证了我们每次提交的代码都是正确的代码，就是说，每次我们在库上提交新代码前，我们都需要先把代码提交到一台运行测试程序的服务器上（多台中的任意一台），这个测试程序（叫ADZ)就是把我们已经写好的UT/IT自动化的跑一遍，在收到了这台服务器发送了的Pass报告后，我们才能把相应的代码提交上库，以保证不会改错。谁要是未过ADZ就把代码提交，导致库上代码异常的话，那可是要受到部门经理及别以上的批评的。所以，这点很重要。

    要做L2, L3的GCF测试，开始了解L3内容

        协议栈的代码在2012年年初的时候，其实PC上的版本，在功能上已经基本上能测试GCF起来了，因为36.509中描述到的LoopBack模式也已经搭好了，而且那时候也从仪表厂商（不记得是哪一家了）买了一个软件版本的GCF测试，就是底层走的是网线，有一套基于TCP/IP的上层协议，然后再上层走的协议栈，这样的话，可以在硬件和RF未Ready之前，把协议栈的逻辑可以得到充分的测试。

        我本来应该是只负责L2部分的测试的，但是老大喜欢把整个GCF测试交给一个人来统一管理，我相信他的原意是想让我看看哪些失败了，然后直接分派给相关Owner的，但是那时候L3实在太忙了，然后，我又是那种充满好奇心的人，所以那时候L3就算出了什么问题，我也会先自己去跟踪出错内容和协议去分析，这样一来二去，一回生二回熟的，我对L3的Case，尤其是测量这一块(因为它出错最多）也开始比较熟洛起来了，甚至他们在讨论相关问题时，我也能参与进去了，甚至还发现了测量这一块的一个Bug。

        PDCP的加解密和完整性保护

        这边虽然板子虽然还是没有准备好，但PDCP的加解密和完整性保护其实已经做的差不多了，老外，还用System C这种类似的语言在VC的底层模拟了类似的加解密和完整性保护硬件，包括寄存器读写，完整性检查的输出等跟真实的HW是一模一样的。这里又再一次不得不夸老外几句了，他们各个都是多面手，连System C 这种一般是硬件工程师才会用的（后来百度了一下才知道）语言也信手黏来。由于有这个软件仿真的硬件，所以在协议栈的控制代码就可以在将来真实硬件Ready时，可以无缝移值的。顺便插一句，中兴的时候其实也有类似的想法，但是相对而言做的就没有这么优雅，只是把协议上的加解密算法搬过来，然后加了很多打桩代码。

       

        再说说MStar的LTE用户面软硬件方案，首先，上行，PDCP从上层这边得到IP数据后，把它链在PDCP链表里，但这个时候PDCP不组包，也不计算SN等内容，等到MAC知道组包时间点到了，并且有Grant来组包了，它才直正去组包，然后, 在从MAC一步一步往上走，MAC要求RLC在某个逻辑信道上组包，RLC要求PDCP在某个SRB，DRB上组包，每一个组到的包或分段都会链在一起，然后里面还确定是需要加密，还是需要完整性保护或者两者都要，这个链表，也就是MAC包，会一次性的通过DMA送给加解密和完整性保护硬件，硬件通过设定的参数，知道哪些包要加密，哪些包要完整性保护，完成后，再通过DMA把对应的数据发送给对应的Encoder。这个方案不同于中兴方案的地方在于，中兴方案需要把数据搬运两次，而这个方案只需要搬运一次，中兴的DMA比较弱，没有Gather和Scatter功能，也就是我这里说的链表功能，个人觉得差距就在这儿。（VIA方案的DMA也是有类似的功能的）

    

       然后，下行，那就跟中兴方案区别不怎么大了，都是在PDCP这一层只经过了一次搬运，但是，有一个问题，就是因为下行和上行有的是同一套硬件，而LTE又是一个如此大数据量的系统，所以两者要使用的时候点撞在一起是再正常不过的事情了，MStar这边提供的方案是，上行优先，但上行正在用的时候，下行正在等，等上行用完了，下行才能用，而如果上行要用的时候，下行已经在用了，那么上行可以抢占它，让下行暂停，HW本身是提供这种暂停机制的，上行用完了以后，会有中断出来，然后下行再继续。 中兴那边的方案是不是也有这个问题，说实话，我不太记得了。

       ROHC头压缩还没开始做

       ROHC其实一直是没做的，一是因为那时候认为头压缩应该只会在VOLTE才会用到的，那时才2011年，不会那么早上马VOLTE的，二是因为也没有相关人力来做这件事，三是认为头压缩只需要软件实现，所以只要投入人力，风险不会太大。但是，我们老大老喜欢把事情做在前头（也有可能看我那时候比较闲），所以他让我开始学习ROHC,只记得那时候看了RFC3095， RFC4995， RFC5225等文档，然后，写了个PPT，把里面主要描述的三个模式（U-Mode， O-Mode， R-Mode） 三个状态（IR状态，FO状态，SO状态），详细的描述了一遍。由于没有实际编写任何代码，所以现在也就印象只有一点点。

   

      RLC状态包的发送的优化

       之所以要写这样一小节，是因为这件事情确实印象比较深。因为RLC状态包的发送是跟授权有关的，然后，有时候因为授权不够时，RLC状态包是要被切掉一部分的，但是也不是随便切的，一般是切掉后面的部分。英国人在写这部分代码时，没有考虑应用历史数据，也就是说，它先按完全的方式来组状态包，把所有需要放到RLC状态包的内容都放进去，然后，到后面发现授权不够，需要切时，它没有用已经组过的RLC状态包信息，而是完全重新来一遍，然后我就觉得这个是比较浪费时间的，所以就提出了一个利用完全状态包来组Truncated状态包的想法，并提供了对应的修改给英国人Review，但是他们没有立马表态，因为快要来这边出差，所以提出到这边来跟我当面讨论。

       MStar被收购， LTE协议栈的交接。

       也就在上面RLC的事情不久后，突然一天（6月十几号）晚上接到同事的短信，说我们公司被MTK收购了，当时我是一万个不信的，因为我们两家公司，一直是以死对头的形式展现在业界的，说两家老总掐架我信，说他们合并，我认为是不可能的，但是，网上一查，没想到还真是千真万切。39亿美金，MTK收购MStar，待大陆批准。第二天上班后，同事们一个个都开始不淡定了，接下去要怎么做，我们会被裁吗？ 我们的LTE还需要研发吗？ 我们的3G外场还需要测试吗？ 然后，MStar的总经理来上海了，讲了一大堆，大意是，我们恰恰是因为太强了，威胁到MTK了，他才会收购我们，所以他们需要我们，我们不会被裁的，让我们放心之类的话。

     但说实话，这已经让人很难相信了，所以收购后，还是走了很多人的，包括我们上海这边的总经理。AP部门还算不错，因为一时半刻找不到事情让他们做，所以把他们外包给阿里巴巴，后来干脆直接等于是卖给他们了，但阿里巴巴也不傻，也不是全盘接收，而是需要通过面试，考核，然后，给你开一个Offer，你爱来不来，不过，很大一部分人还是过去了，据说，过去的人，后来都分到阿里的股票了，所以还是印证了那句老话，赛翁失马，焉知非福。哎，可怜我们Modem部门就直接被安排做快要退出历史舞台的CDMA了。

        由于6月份已经宣布被收购了，所以七月初的所谓LTE的交接也就变成形式主义了，英国人从NAS，L4，L3，L2总的都介绍一遍，我们问了无数问题后，并且把RLC状态包的事确定后（经讨论，嘿嘿，证明我是正确的），就算是交接给我们了，但其实交接给我们后，我们也没有能继续下去。只是一直在学习，学习MTK可能会交给我们做的事，如LTE Advance（那时候老大也还太天真，以为我们还是核心呢），CDMA2000等。

     总结在MStar的这一年

    在MStar的这一年，第一，不得不说，还是学到了不少东西的，以前学LTE，都还主要是L2，对整个LTE架构还不甚了解，到了这边学习才比较系统，从开机，找网，收系统消息，驻留，重选，随机接入，切换，重建，PDN的建立，安全性等等，包括L2本身的PDCP，RLC，MAC，都有更深层次的理解。

    第二，HR真的是没有骗我们，MStar真的在待遇方面还是很给力的，才进去不到一年，就有不少年终奖，还有股票，要知道那些股票，在被收购后，可是涨了有一倍都不止啊。

    第三，感觉老大还是很器重我的，很多新的重要的事情都交给我做，年底给我的考评也还不错。在这里，真的找到了一个资深工程师的感觉。

    第四，跟英国人合作算是挺愉快的，也从他们身上学习到了不少东西。