用C语言加速程序进而加速硬件速度

好事不怕多

　　如果要更进一步地优化，就要增加在每条扩展指令执行时处理的数据点数量，因为集成了可编程逻辑，才让灵活的实现变成了可能，所以不需重新设计，就可对扩展指令加以修订，提高执行效率。相比之下，基于ASIC或FPGA的架构就需要彻底改造、调整，并调试修改过的功能。ASIC与FPGA的设计源于独立且明显不同的开发环境，通常需要硬件方面的专门技术，并由第二个开发团队来协助工作，因此，为实现硬件加速而进行的修改或重分配，在结果未被准确评估之前，会遇到人们心理上的抵抗。

　　当把硬件分离出作为软件时，生成程序代码的同一编译器也能为可编程逻辑生成相应的配置。这样，编译器也能有效地管理资源和依赖性，并使性能达到最优化。另外，因为硬件的实现是由编译器自动生成的，所以只需一个开发团队就行了，这不但降低了把设计移交给另一个团队时的复杂性，而且在不需要投入更多开发时间进行人工优化的前提下，给予了充分的自由来测试和评估多种实现。

　　举例来说，FIR转换器就可通过减少调用扩展指令的次数，来进一步地优化，不但减少了调度扩展指令的麻烦，也减少了调用扩展指令时系统整体的开销。

　　如果把并行MAC的数目增加到16，性能上会有多大提高呢？图3中，需计算一个4×4的数据区域，而计算这些数据点，至少对一个FIR转换器来说，需要4个系数与7个数据点，与16个系数与16个数据点的实现相比，后者从单一的斜行中就可计算出部分和，这提高了总线带宽的利用率，其使用更少的带宽，却可执行更多的计算，这是通过把4个部分和存储在状态寄存器中，以便扩展指令下一次迭代时使用来达到的。最优化性能，其实就是在优化使用可编程资源之间取得一个平衡。

图3：一个4×4的数据点区域

　　每条扩展指令可执行16-MAC，在性能上可比8-MAC的实现提高一倍，所需时钟周期减少至981,对未实现加速的版本来说，性能上提高了30倍。如果要更进一步地提高性能，可能要分配更多的可编程资源以执行32-MAC（见图4）。在这种配置下，扩展指令需要4个系数与11个数据样本，从一条指令到下一条指令，期间需保存8个部分和。关于此实现所需的时钟周期，理论上最小值为501,相对于直接用C的实现，效率大约提高了58倍。

图4：分配更多的可编程资源以执行32-MAC