原创 FPGA到底能做什么

FPGA到底能做什么

         初学者爱问这个问题，我的新书中会告诉你：逻辑粘合是FPGA早期的任务，实时控制让FPGA变得有用武之地，FPGA实现的各种协议灵活度很高，信号处理让FPGA越来越高端，片上系统让FPGA取代一切……

         但是，这几天的特权很纠结，一直在问自己“FPGA到底能做什么”。事情源于马上要启动的DVR项目，视频搞定了，也显示了，下一步要存储，传输带宽和存储容量放出话来了“必须要压缩”。那么，图片要JPEG，视频要H.264。各种方案虽然只是初步的了解一些，但是发现这方面虽然有类似SOPC概念的海思和TI双核解决方案，而且是专门干这个的，不过发现这玩意是有门槛的，用我们经理的一句话是“一般人搞不定”，成本不仅仅是money的问题，还有工程师熟悉一个新的高复杂度的开发环境的时间和精力投入。那么退而求其次，貌似一个DSP也很难搞定，市场上常见的是DSP+FPGA，或者也有一些专用的ASIC能够胜任诸如H.264的编码，不过看看芯片价格只能用“死贵死贵”来形容了。

         折衷下来，上午我还寻思着就再来一个DSP吧，也看好了ADI的blackfin，准备下一步慢慢筹备我的DSP之旅。但是，也许这几天一直萦绕在我脑子里的问题越发强烈起来“FPGA到底能做什么”。很显然，如果要在通用控制器或处理器和FPGA之间做一些比较，特权会很快的送上图1和图2（图3）。

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

图1 基于控制器或处理器的一般处理流程

图2 基于FPGA的并行处理流程

图3 基于FPGA的流水线处理流程

         很显然，图1中的一般控制器或处理器由于软件固有的顺序特性，决定了它的工作必须是按部就班，一个输出的4个步骤完成才能接着开始下一个输出的4个步骤，那么它完成4个输出就需要20个步骤单位时间（假定输出也算一个步骤，一个输出需要5个步骤）。虽然现在很多的DSP中也带有功能强大的硬件加速引擎，如简单搬运数据的DMA等，但是它所做的工作量，或者说和软件并行执行的工作量其实是很局限的，这里说的局限是指他的灵活性上很差，协调性不够好也会让处理速度大打折扣。

         而反观图2和图3的FPGA处理，先说图2，并行处理方式很好很强大，是前面的软件处理速度的4倍。并行是FPGA最大的优势，只不过需要用大量的资源来换速度，通俗的说就是要用大量的money换性能，我想这并不是人人都能够承受的解决方案。而看图4，是一个不错的折衷方案，流水线处理是FPGA乃至整个信号处理领域最经典的一种方法。能够在基本不消减处理速度的前提下只用了并行处理方法的1/4资源就完成任务了。

         那么话题回到JPEG和H.264的压缩上来，其实FPGA足以胜任，网络上一搜一箩筐这样的解决方案。其实退一万步来讲，算法再复杂，实时性要求再高，FPGA都是足以胜任的，尤其是采用流水线方法，也许第一个数据输出的时间需要很长（一般系统是许可的），但是这并不妨碍后续数据的实时输出。我想，这就是成本（器件资源）和性能最好的折衷办法。

         那么，这些复杂的算法中无外乎存储和运算。实时处理中的存储其实很大程度上是要依赖器件的片内存储器资源的，外扩的存储器无论从复杂度和速度上都会只会减低处理性能。加减乘除好办，内嵌的乘法器或是各种各样专用的DSP处理单元就能搞定；但是开方求幂等比较无奈的运算就只能靠查表来解决了。

         如此这般下来，其实FPGA就是要干这个的——算法，越是大家搞不定的问题我FPGA统统不在话下。话说到这，发现不对劲，有人要拍砖了。其实真没有FPGA干不了的活，但是有FPGA不适合干的活，个人认为那些顺序性很强的活，比如文件系统那种很折腾的活，就算简单的SD卡文件系统的管理也是要不停的折腾，数据这里读那里写的，FPGA代码就很难写，一个偌大的状态机也许能够解决问题，但是很容易让设计者深陷其中晕头转向。