标签: 系统架构

通常来讲，“一个好汉三个帮”，一个完整的嵌入式系统中由单独一个FPGA使用的情况较少。通常由多个器件组合完成，例如由一个FPGA+CPU来构成。通常为一个FPGA+ARM，ARM负责软件配置管理，界面输入外设操作等操作，FPGA负责大数据量运算，可以看做CPU的专用协处理器来使用，也常会用于扩展外部接口。常用的有ARM+FPGA，DSP+FPGA，或者网络处理器+FPGA等种种架构形式，这些架构形式构成整个高速嵌入式设备的处理形态。 不得不说的是，随着技术的进步，现在CPU中集成的单元也随之增加，例如TI的“达芬奇”架构的处理器内部通常由ARM+DSP构成。同时异构的处理器形态业逐渐流行，如ARM9+ARM7的结构。这类一个主要处理系统(ARM9)外带辅助处理系统(ARM7)的设计，同样成为现在处理器设计的流行方向。主处理系统运行嵌入式操作系统，而辅助处理单元则专注某一些的专用领域的处理。这些系统的应用减少了FPGA作为CPU协处理单元的领域。因为毕竟FPGA相比ARM等流行嵌入式处理器价格要相对较高。 在这种情形下，FPGA的厂商似乎也感受到了压力，不约而同推出了带ARM硬核的FPGA，例如ALTERA的和XILINX的ZYNQ和ALTERA的SOC FPGA。这是即是互相竞争的需要，也是同众多CPU厂商一掰手腕的杰作。即使在这两种在趋势下，经典的处理器+FPGA的设计仍然可看做为高性能嵌入式系统的典型配置。 经典的处理器+FPGA的配置中有多种的架构形式，即多个处理器单元,可能是ARM，MIPS,或者DSP，FPGA也可能是多片的配置，具体架构形式于具体处理的业务相关和目标设备的定位也相关。因为FPGA作为简单业务流大数据量的处理形态仍然是CPU无可比拟的优势，FPGA内部可以开发大量业务数据并行，从而实现高速的数据处理。 在实现高速处理方面，CPU的另一个发展趋势是多核，多核处理器也能处理大数据量的业务的并行，例如业界TERILA已推出64核的多核处理器，采用MIPS处理器，通过二维MASH网络连接在一起，形成NOC的结构。在性能上已经和现有的高速FPGA的处理能力上不相上下。但是多核处理器的不得不说的问题就是，同一业务流分配到多核处理上后，如需交互，例如访问同一资源，就会造成读写的缓存一致的问题，解决的这一问题的天然思路是加锁，即在变量访问上加自旋锁，但是带来的问题就是处理性能的急剧下降。而FPGA无论并行处理和同一变量的访问，都可以变成工程师的设计水平的问题，没有原理性的挑战。 【分页导航】 第1页： FPGA的系统架构组成 第2页： FPGA的几种热门应用 第3页： FPGA与各组成器件之间互联 FPGA的几种热门应用 没有一种器件可以满足全人类的众多需求，因此不用担心FPGA没有用武之地。必定是一系列产品的组合。下面主要介绍一下FPGA可以作为现今热门场景的几种应用。 （1）网络存储产品，特别是现在的NAS，或者SAN设备上，其存储的时间、接口、安全性等都要求较高，而FPGA无论处理性能还是扩展接口的能力都使其在这一领域大有作为。现在高端FPGA单片就可以扩展32个或者更多4G或者8G的FC接口。并且其协议处理相对的固定，也使FPGA在这一领域有大量的可能应用。 （2）高速网络设备，现在高速网络设备10G、40/100G以太网设备领域，同样FPGA也是关键的处理部件。特别是IPv6的商用化及大数据对于基础设施的高要求，都使这一领域的处理应用会逐渐广泛，这一领域通常是高速网络处理器（NP）+FPGA的典型架构。 （3）4G等通信设备，对于新一代通信基站的信号处理，FPGA+DSP阵列的架构就是绝配。特别是在专用处理芯片面世之前，这样的架构可以保证新一代通信基础设施的迅速研发和部署。 没有完美的架构，只有合适的组合，各种芯片和架构都是为应用服务，互相的渗透是趋势，也是必然。FPGA相对处理器的可编程领域，仍然属于小众（虽然人数也不少）。但是正像一则笑话所说：大腿虽然比根命根子粗，但决没有命子重要。这算开个玩笑。FPGA的实现为以后的芯片化留下了许多可能和想象空间，从而在应用大量爆发时通过芯片化来大幅降低成本，这这也正是其他可编程器件所不能比拟的。 【分页导航】 第1页： FPGA的系统架构组成 第2页： FPGA的几种热门应用 第3页： FPGA与各组成器件之间互联 FPGA与各组成器件之间互联 系统架构确定，下一步就是FPGA与各组成器件之间互联的问题了。通常来说，CPU和FPGA的互联接口，主要取决两个要素： （1）CPU所支持的接口。 （2）交互的业务。 通常来说，FPGA一般支持与CPU连接的数字接口，其常用的有EMIF，PCI,PCI-E,UPP,网口（MII/GMII/RGMII），DDR等接口。作为总线类接口，FPGA通常作为从设备与CPU连接，CPU作为主设备通过访问直接映射的地址对FPGA进行访问。根据是否有时钟同步，通常总线访问分为同步或异步的总线，根据CPU外部总线协议有所不同，但数据、地址、控制信号基本是总线访问类型中总线信号所不能省略的。CPU手册中会对信号定义和时序控制有着详细的说明，FPGA需要根据这些详细说明来实现相应的逻辑。同时CPU还可以对访问时序进行设置，比如最快时钟，甚至所需的最小建立时间和保持时间，这些一般CPU都可以进行设置，而这些具体参数，不仅影响FPGA的实现，也决定总线访问的速度和效率。对于同步总线，只需要根据输入时钟进行采样处理即可，但对于异步总线，则需要的对进入的控制信号进行同步化处理，通常处理方式是寄存两拍，去掉毛刺。因此用于采样的时钟就与CPU所设置的总线参数相关，如采样时钟较低，等控制信号稳定后在译码后输出，一个总线操作周期的时间就会相对较长，其处理的效率也相对较低；假如采样时钟过快，则对关键路径又是一个挑战，因此合理设定采样频率，便于接口的移植并接口的效率是设计的关键点和平衡点。 对于总线型的访问来说，数据信号通常为三态信号，用于输入和输出。这种设计的目的是为了减少外部连线的数量。因为数据信号相对较多一般为8/16/32位数据总线。总线的访问的优势是直接映射到系统的地址区间，访问较为直观。但相对传输速率不高，通常在几十到100Mbps以下。这种原因的造成主要为以下因素（1）受制总线访问的间隔，总线操作周期等因素，总线访问间隔即两次访问之间总线空闲的时间，而总线操作周期为从发起到相应的时间。（2）不支持双向传输，并且FPGA需主动发起对CPU操作时，一般只有发起CPU的中断处理一种方式。这种总线型操作特点，使其可以用作系统的管理操作，例如FPGA内部寄存器配置，运行过程中所需参数配置，以及数据流量较小的信息交互等操作。这些操作数据量和所需带宽适中，可以应对普通的嵌入式系统的处理需求。 对于大数据流量的数据交互，一般采用专用的总线交互，其特点是，支持双向传输，总线传输速率较快，例如GMII/RGMII、Upp、专用LVDS接口，及SERDES接口。专用SERDES接口一般支持的有PCI-E，XAUI，SGMII，SATA，Interlaken接口等接口。GMII/RGMII,专用LVDS接口一般处理在1GbpS一下的业务形式，而PCI-E，根据其型号不同，支持几Gbps的传输速率。而XAUI可支持到10Gbps的传输速率，lnterlaken接口可支持到40Gbps的业务传输。 对于不同所需的业务形式及处理器的类型，则可选择相应的接口形式，来传输具体的业务。现今主流FPGA中都提供的各种接口的IP。选择FPGA与各型CPU互联接口，一般选择主流的应用交互方案，特殊的接口缺少支撑IP，导致开发、调试、维护和兼容性的成本都较大，同时注意系统的持续演进的需要，如只在本项目使用一次，而下一项目或开发阶段已摒弃此类接口，则需提前规划技术路线。毕竟一个稳定、高效的接口互联是一个项目成功的基础。 不是所有的嵌入式系统都需要“高大上”的接口形式，各类低速的稳定接口也同样在FPGA的接口互联中有着重要的角色，其中UART、SPI、I2C等连接形式也非常的常见。毕竟，一个优秀的设计不是“高大上”的堆积，而是对需求最小成本的满足。适合的才是最美的。 转载请注明来源于： 阿昏豆，EDNC BLOG http://bbs.ednchina.com/BLOG_ARTICLE_3022276.HTM 【分页导航】 第1页： FPGA的系统架构组成 第2页： FPGA的几种热门应用 第3页： FPGA与各组成器件之间互联

近来读到网友的不少文章，例如《驱动IC成LED显示屏技术创新关键》、《驱动IC与控制系统相互协作，推动LED显示屏技术创新》，有自己的看法。 LED显示屏在过去10年左右的时间里，系统架构上并没有太大的变化，可以肯定说这是一种经典的作品。并不代表没有人想改变他，技术革新者大有人在。 做技术的工程师都会有一种幻想，用技来改变格局，引起行业关注，这也是很多技术人员从商失败的主因数。 从控制到传输、再到显示都改变，其实是在改变LED显示屏行业。一个非常成熟，产业配套整齐的产业，非易事。在一定的经济条件下，技术正好落在演进过程中，市场不可能完全按照我们的思路去发展。 不是太认同市面上推出的PWM(脉冲宽度调制)功能的显示屏驱动IC，被市场认可的观点。 这些年，TI、聚积、点晶曾经推出过类似IC，均没有得到批量，事实证明是失败的规格定义。价格不是主因，不能批量价格自然也不会低。 究其原因是内置PWM灰度IC只能适用设计静态LED屏幕，而市面上批量大部分是扫描方式驱动LED屏幕。 PWM是IC内部产生时钟无法获得PWM整体扫描显示同步，从原理上是没问题的，技术上均能实现，但是生意场上可不讲这个，性价比是市场说了算。LED亮度不断提高，价格直线下降，显示像素密度要求越来越高，采用静态驱动方式设计屏更加的少，扫描驱动方式应用增多，因此内置PWM灰度不是终端设计所需要的解决方案。   LED电子显示屏和主板之间的数据传输一般采用的都是串行式数据传输方式(SPI)，再通过信号包复用技术同步传送显示数据和控制数据。原因还是之前的答案，大部分LED显示屏是扫描方式设计，必须要继续采用这种数据传输方式，这种数据传输方式在这里使用就是最合适的。只要没有新的技术可以彻底解决扫描方式，这种数据传输方式还是会继续延续使用下去，至少在可预见的未来5年内都不会有太大的改变。   无论再先进的数据传输方式也解决不了LED驱动的问题。 LED显示屏驱动IC之间的数据传输不能拿网络数据传输概念来看待。网络数据传输容易实现MHz、GHz速率，有一个致命问题是都不能实现实时同步。虽然我们播放的视屏都是连续的，要是1千个网络终端在一个地方播放视屏，会有1千个时间点，绝对做不到帧及像素显示同步。会经常遇到观看同一场现场直播时，不同的电视台会相差好几秒，这就是数据在网路中的延时不同造成的。   LED显示屏不是网络传输，每帧画面，每个像素显示必须要绝对同步，数据不能压缩，半点虚假都不行。显示屏IC是LED驱动，是直接点亮LED开关，他需要来至多方面的同步，而不是仅仅是时钟和数据。因此，不管网络传输发展到任何高度，都不能在LED驱动上派上用场。控制器设计类似网络传输，实质也有很大区别。   LED屏幕制造厂家认为扫描驱动LED设计屏是未来趋势，而技术研究人员都是从静态驱动方式考虑的，这是多年来设计出一堆又一堆IC也没能够改变LED屏幕设计，然而还是这颗规格。 

/********************************************************************************* * Filename: 一线研发之声：嵌入式C编程经验 之 全局变量猛于虎 * Author：SedateFire          E-mail:SedateFire@126.com * Version：1.001                 Time: 2012-01-05 * key: 嵌入式  os-less  全局变量  单片机 **********************************************************************************/       工作也有些年头了，从一位技术新人成长到现在自诩小牛级别的人物，少不了要自己寻找资料阅读。论坛上、书店里、杂志上......要嘛是些菜鸟浅薄的自炫处女贴，要嘛是高屋建瓴云里来雾里去的概念文，好不容易遇到个实践型高手写的文章，却在渐入佳境之际嘎然而止。本是隔靴搔痒，看完后心中更是郁结不已。也罢，今日且强装回大牛，献丑谈一谈嵌入式C编程中全局变量问题。           嵌入式特别是单片机os-less的程序，最易范的错误是全局变量满天飞。 这个现象在早期汇编转型过来的程序员以及初学者中常见，这帮家伙几乎把全局变量当作函数形参来用。在.h文档里面定义许多杂乱的结构体，extern一堆令人头皮发麻的全局变量，然后再这个模块里边赋值123，那个模块里边判断123分支决定做什么。每当看到这种程序， 我总要戚眉变脸而后拍桌怒喝 。没错，就是怒喝。我不否认全局变量的重要性，但我认为要十分谨慎地使用它，滥用全局变量会引申带来其它更为严重的结构性系统问题。   诸位看官，且听我细细道来。   1. 它会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。   2. 它会导致软件分层的不合理， 全局变量相当于一条快捷通道，它容易使程序员模糊了“设备层”和“应用层”之间的边界。 写出来的底层程序容易自作多情地关注起上层的应用。这在软件系统的 构建初期的确效率很高 ，功能调试进度一日千里，但到了 后期往往bug一堆 ，处处“补丁”，雷区遍布。说是度日如年举步维艰也不为过。   3. 由于 软件的分层不合理 ，到了 后期维护 ，哪怕仅是增加修改删除小功能， 往往要从上到下掘地三尺地修改 ，涉及大多数模块，而 原有的代码注释却忘了更新修改 ，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。   4. 全局变量大量使用，少不了 有些变量流连忘返于中断与主回圈程序之间 。这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。           无需多言，您已经成功得到一个畸形的系统， 它处于一个神秘的稳定状态！ 你看着这台机器，机器也看着你，相对无言，心中发毛。你不确定它什么时候会崩溃，也不晓得下一次投诉什么时候道理。   然后，我告诉大家现实层面的后果是什么。   1.“老人”气昂昂， 因为系统离不开他，所有“雷区”只有他了然于心。当出现紧急的bug时，只有他能够搞定。 你不但不能辞退他，还要给他加薪。 2. 新人见光死， 但凡招聘来维护这个系统的，除了改出更多的bug外，基本上一个月内就走人，到了外面还宣扬这个公司的软件质量有够差够烂。 3.随着产品的后续升级，几个月没有接触这个系统的原创者会发现，很多雷区他本人也忘记了，于是每次的产品 升级维护周期越来越长 ，因为修改一个功能会冒出很多bug，而 按下一个bug，会弹出其他更多的bug 。在这期间，又会产生更多的全局变量。终于有一天他告诉老板，不行啦不行啦，资源不够了，ram或者flash空间太小了，升级升级。 4. 客户投诉不断，售后也快崩溃了，业务员也不敢推荐此产品了 ，市场份额越来越小，公司形象越来越糟糕。          要问我的对策吗，只有两个原则： 1. 能不用全局变量尽量不用 ，我想除了系统状态和控制参数、通信处理和一些需要效率的模块，其他的基本可以靠合理的软件分层和编程技巧来解决。 2. 如果不可避免需要用到，那能藏多深就藏多深。 1)如果只有某.c文件用，就static到该文件中，顺便把结构体定义也收进来； 2)如果只有一个函数用，那就static到函数里面去； 3)如果非要开放出去让人读取，那就用函数return出去，这样就是只读属性了； 4)如果非要遭人蹂躏赋值，好吧，我开放函数接口让你传参赋值；5)实在非要extern强奸我，我还可以严格控制包含我.h档的对象，而不是放到公共的includes.h中被人围观，丢人现眼。           如此，你可明白我对全局变量的感悟有多深刻。悲催的我，已经把当年那些“老人”交给我维护的那些案子加班 全部重新翻写 了。你能明白吗，不要让人背后唾弃你哦。   2011-12-29 续篇          承蒙小编抬爱，推荐了本博文，感激之余心中惶恐，特地详细看了下回复。这个主题最早是在论坛发表的，我发现那里的回复还是比较热烈的，也很高兴能够听到不同的声音。对于一些网友 提到的，如果大量使用局部变量也会容易造成栈溢出的问题，还提到程序模型的概念。言之有理。所以特地来补充一下意见： 1.全局变量是不可避免要用到的 ，每一个设备底层几乎都需要它来记录当前状态，控制时序，起承转合。但是尽量不要用来传递参数，这个很忌讳的。 2.尽量把变量的作用范围控制在使用它的模块里面 ，如果其他模块要访问，就开个读或写函数接口出来，严格控制访问范围。这一点，C++的private属性就是这么干的。这对将来程序的调试也很有好处。C语言之所以有++版本，很大原因就是为了控制它的灵活性，要说面向对象的思想，C语言早已有之，亦可实现。 3.当一个模块里面的全局变量超过3个(含)时，就用结构体包起来吧。 要归0便一起归0，省得丢三落四的。 4.在函数里面开个静态的 全局变量 ， 全局 数 组，是不占用栈空间的。 只是有些编译器对于大块的全局数组，会放到和一般变量不同的地址区。若是在keil C51，因为是静态编译，栈爆掉了会报警，所以大可以尽情驰骋，注意交通规则就是了。 5. 单片机的os-less系统中，只有栈没有堆的用法，那些默认对堆分配空间的“startup.s”，可以大胆的把堆空间干掉。 6.程序模型？如何分析抽象出来呢，从哪个角度进行模型构建呢？很愿意聆听网友的意见。本人一直以来都是从两个角度分析系统 ，事件--状态机迁移图 和 数据流图，前者分析控制流向，完善UI，后者可知晓系统数据的缘起缘灭。 这些理论，院校的《软件工程》教材都有，大家不妨借鉴下。只不过那些理论，终究是起源于大型系统软件管理的，牛刀杀鸡，还是要裁剪一下的。