原创 协议栈与物理层在芯片上的分布

2011-12-27 记录

曾经有个同学在MSN上问我，为什么协议栈软件总是跑在ARM上，为什么物理层软件跑在DSP上呢？

呵呵，好像从咱们开始做终端软件那天起，就是这样子设计的。为什么呢？

我简单的回答了一下：因为软件的结构不同。

协议栈软件基本上都是基于状态机的，有很多层次结构，需要很多个不同优先级的task来运行。他的总体结构是需要一个RTOS来做调度的多个task可以通信，互相抢占式的。

物理层软件基本上是算法流程的，没有那么多的层次结构。重在算法本身的并行处理上面。DSP内核也是基于这些算法的特征来设计的。于是对于中断的响应上面往往比较差，甚至现在的vector engine的DSP就不响应中断。

于是，不同的芯片内核应不同的应用场景而生。而不同的软件结构就运行在了不同的芯片内核上而已。如此配合才可以做到系统的最优。

这位执着的同学继续问：那么协议栈能否直接跑在DSP上，这样不是节省一颗ARM吗？

这个问题问得蛮好的。

那么咱们得看这整个系统的需求了。不同的系统需求是完全不一样的。协议栈有多少层次，有多少模块，多少状态要处理，整个软件结构会怎么划分，会有多大的代码量，需要多少运算量，会有怎样的抢占关系，实时性的要求是怎样的。

这是一个系统设计的问题，不能单纯的用一种通用的想法来约束系统设计。如果只是一个简单的协议。例如就是基于物理层做了一层协议，那么直接就做在一起，用一颗DSP就处理了有何尝不可。记得十年前刚刚工作的时候，我就设计了一个协议，用于SCDMA的基站与基站之间的一种透明的点到点的通信的协议，也就是直接跟声码器等软件跑在一颗DSP上。

而如果要谈到复杂的协议栈，如GSM/GPRS这样的，你一定要弄到一颗DSP上去做，那就是自讨苦吃了。当然如果是如C64X这么强悍的DSP，另当别论了。GSM、GPRS这样的协议栈，主要是逻辑关系太过于复杂，模块多，层次多。这样的软件跟物理层软件混在一起，会严重影响其实时性。而且代码量大，要放在带cache的系统上运行才是合适的。cache适合这种数据间有一定相关性，又不是剧烈相关的应用场景。如果剧烈相关，那么用sratch的memory可能更合适一点。

而如LTE这样的协议栈又是另外的话题了。首先数据面和控制面的需求就完全不同，最好时分在不同的core上。

细说起来，花很长。总之是需要根据具体的系统需求来做方案的，要考虑到关键点的细节，就好选择了。