原创 通信SDR处理器漫谈

整理2011年3月和8月的两篇日记，形成此文，随意分享，说得不对，多多包涵。

 多core多线程，矢量处理器内核，这些似乎是目前SDR的通信用处理器的一条殊途同归之路。

放眼看去，ceva，Tensilca，cognovo以及Sandbridge的号称用于4G的SDR的处理器，都有这样的基本特征。（由于涉及知识产权问题，此处不好将他们的系统架构图，内核架构图贴出来了。且以上公司大多被收购了，品牌不知道还能否保留住。但咱们还是尊重他们的知识产权，不在此透露太多技术细节。）

当然这些都是可以看到。还有那些不能轻易看到细节的，比如说高通的。

其实这样的一个结构的趋势，主要还是基于对4G的基础系统的分析，即对OFDM系统的基础处理流程的分析。OFDM系统本身就是一个可以有很高并行度的处理的系统，才把SDR的内核的处理器架构引向了这个方向。

终究还是有了多年的通信系统信号处理的工程背景，和在芯片设计公司沾染芯片架构设计的一些浅薄认知。感觉到这个SDR的处理器的设计，指令集的设计，算法的编写的曲折与趣味。

先来看看都是些什么人在做这些事情。

最终芯片的内核必然还是那些个做内核设计的人来完成的，肯定都是一些绝顶聪明之人。

而通信系统的分析必然还需要那些个做通信信号处理的人来完成，也必不是等闲之辈。

而这两个领域不能完全说风马牛不相及，但毕竟还是隔行如隔山，水深水浅，只有行内人才知道。理解对方领域的东西，互相取挑剔，去磨合，去思考，再回来思考自己的行内的内容，进一步循环再循环，最后演进出咱们看到每一代的SDR的处理器。

而真的能够做到尽善尽美，需要付出多少的代价。就比如说TI这样的大公司，多少各个方面的专家和大师呢？而TI的DSP芯片的份额却还是在日渐萎缩的。而自称是多线程处理器架构的鼻祖的SB3500的这个处理器。其中FFT的运算，居然没有考虑每一级运算之间的scale。估计他们的通信专家们都是和做内核，做指令集以及做算法库的人交流也并不很畅通吧。也许根本没有通信信号处理的专家，而只是自认为已经充分掌握通信系统需求的一帮人自娱自乐罢了。

DSP这样的有着特殊处理器结构的内核的东西，确实是跟着系统分析走的，有着很强烈的系统适用性的特征。而不同的人对系统的理解都不一样，导致的各个DSP的细节设计上出入很大。于是要想编译器能自动生成很高效的代码，在我看来也真的是很搞笑的。所以要想在不同的DSP之间做到代码的一个很好的可移植性，其实也是相当难的。诸如说intrinsic这样的东西，已经很大程度上表达了编译器的大师们尽量减少用户使用时候，平台移植工作量的问题了。但是还是有太多的细节要求DSP软件工程师永远要纠结在每个DSP的细节里面。不过这何尝不是DSP设计者与DSP软件工程师间交流的一种方式呢？

说到intrinsic，就再多废话几句。

我要说intrinsic是个骗子，compiler guys肯定会跳起来，把我骂个狗血淋头。呵呵。

intrinsic就是长得比较好看一点，对于DSP的程序来说，整个看起来还是遵循着C的规则。而真正的一颗DSP，例如有强大的vector engine的DSP处理器，期待就用标准的C代码，compiler能自动变成并行的指令，这只是一个传说。所以，DSP工程师必须学会用intrinsic，其实就是把汇编用看起来跟C一个规则的外表包起来的东东。要真正写好DSP的处理算法，不了解DSP的内核有多少种多少个register是不可能；不掌握DSP的指令集是不可能的；不掌握每个intrinsic也是不可能的。期待着compiler帮助你做着所有的事情，只是天方夜谭。

intrinsic也有他的好处。就是他毕竟将汇编指令封装了一层，所以对于指令集的升级维护等工作会比较方便一点。但是对于指令集升级，真正的工作源于它为什么要升级---哈，对了，肯定是DSP内核发生了改变，例如从8MAC升级到了16MAC甚至64MAC甚至128MAC；而遇到这样的case，你原来的算法的代码肯定期待提高并行度，所以你还是必须要用新的intrinsic。哈，所以问题还是又转回来了。所有DSP工程师们就是在这里挣扎了，也在这里享受乐趣。不再写汇编代码，写intrinsic，用汇编的思路和汇编的手法。