多核SOC系统整合过程中的FPGA软处理器应用:多核处理器
时间：2019-01-20 03:32:10 来源：柠檬阅读网 本文已影响 人 
摘要:当代SOC设计流程的核心环节逐步转向将成熟的IP整合为一个更大的芯片系统。随着芯片系统规模越来越大,各种IP之间相互的影响也越来越复杂,甚至导致整个芯片系统无法协同工作。本文提出了一种利用多核软处理器进行SOC软硬件系统分析和动态调试的方法,大大加速了SOC的开发质量和速度。
关键词:SOC软硬件系统 FPGA软处理器 芯片系统
现代的SOC芯片系统,典型的如手机芯片,不断变得越来越复杂,功能越来越强大――通讯,多媒体,网络,照相摄影设备等等不断丰富,使gtsOC芯片的设计难度不断上升。除了外在的芯片规模在不断上升之外,我们发现,芯片的设计正在变得越来越“软”,这个“软”主要表现在以下方面:
(1)SOC芯片的主体已经从传统的硬逻辑电路,逐步演化为各种各样处理器相互通过片上总线系统相互连接。这些处理器软件的编程逐步取代硬件逻辑设计成为SOC设计中最耗费人力的环节。
(2)一个SOC团队中,软件人员的数量超越硬件逻辑设计人员,目前,典型的比率是6:1
(3)软件设计必须和芯片硬件设计几乎同时开始,而不是象以前那样拿到了芯片才开始软件开发
(4)软件的功能划分,调试环境的能力,继承性和兼容性成为影响硬件IP选择的重要因素
(5)软硬件协同后,各个IP模块之间的影响变得特别复杂,越发难以分析验证,也就越发难以选择各个IP模块
在传统的芯片设计过程中,芯片的硬件行为是通过工作站上的软件来仿真的,但对SOC而言,一方面各个处理器IP已经越来越复杂,精确仿真处理器模型的建立越来越费劲,甚至根本就没有;一方面系统规模膨胀速度指数级增长,越来越大,严重挑战了仿真软件的性能,目前主流的工作站,在当前规模的SOC软件仿真条件下,系统的运行能力不到lHz是非常正常的,而由于应用的复杂,嵌入式操作系统的流行,使得SOC系统光启动操作系统什么都没干,就至少需要数千万个时钟周期,在这样的运行性能下,进行软件调试也成了不可能的任务了。大规模现场可编程器件(FPGA)的出现,为系统验证和开发提供了有力的手段,目前,大量的EsLit件,采用了将部分设计在FPGA里仿真,部分软件在工作站里运行的方法来加快软硬件协同开发的速度,但从实践上来看,几乎很少成功案例。主要的原因就是各种处理器的多样性,导致在工作站端同时要仿真多种处理器运行的巨大代价,以及ESL仿真的精确性仍然难以控制,因此实用性并不高。大多数开发者还是采用将整个设计映射到多颗大容量FPGA的方法,然后使得系统运行在比真实系统慢数十倍的条件下调试软件,并且在有可能的条件下尽量提供多套平台供软件开发者并行工作。当软硬件开发协同进行时,软件开发人员与硬件开发人员的不同开发目标和路线,又造成了新的挑战,主要的矛盾表现在以下方面:
(1)精度要求不同,硬件逻辑设计人员常常关心的是,内存带宽是否得到了有效利用,挂接在总线上的各个IP的数据吞吐量和效率是否冲突,解决冲突能容忍的延迟是否在系统的可接受范围之内,他们关心整个系统在时钟级别的系统运行架构,任何时钟级别的失误,可能导致各个硬件模块的冲突导致系统崩溃或者性能严重下降,典型的是你有可能出现听MP3的时候,手机就接不到的现象。而软件设计人员,更关心的是高级软件级别的模块和信号传递流程是否失误,一个函数,只要能正确完成,软件人员通常并不在乎它多花了几个时钟周期,也不太在意其他功能单元是否会影响到自身流程的完成。
(2)对原型系统运行要求不同,硬件逻辑设计人员常常采用重启系统的方法来反复比对和排查硬件信号出现故障的地方,常常改变信号抓取,信号抓取深度浅,但宽度大,每次调整信号抓取,就可能耗费数个小时来重新配置FPGA。而软件设计人员则很少重启系统,但常常重新设置程序断点,又常常更换程序断点位置,且可能在一个调试中多次调用同样的程序模块都设置断点,而且可能随时在中断后又设置新的断点甚至单步运行。
(3)现有调试工具的不足。于是,现有的调试工具出现了困境,硬件设计人员常常使用内部逻辑分析仪(ILA)来抓取异常信号,但内部逻辑分析仪常常使用FPGA内部稀缺的SRAM资源,而SRAM存储的数据有限,并且只能实现单次抓取,且只能在系统每次重启之后就开启而不是从任意位置启动抓取,就会因为相同动作提前触发而错失了错误发生点。当软硬件系统出现故障时,硬件设计人员必须重启整个系统,但若软件运行没运行到同一位置,异常就无法定位,而每次等软件运行到同一位置,则可能耗时巨大也很难重复。通常软件的运行和调试常常是通过软件调试工具自动生成的代码加入到设计代码中完成,会消耗一定的计算资源,当计算资源有剩余的时候常常不是什么问题,而SOC软件开发常常缺乏对应的自动调试代码生成工具,又运行在计算资源相当紧张的环境下,调试代码常常会影响到其他IP的运行影响整个系统的稳定,而ILA的抓取结果,却非常不直观,使得程序员又回到了直接用二进制代码检查程序的低效率时期,ILA有限的抓取深度,常常使得程序员无法定位故障位置。
在上述挑战下,设计出软硬件适配良好的SOC难度是相当巨大的。即使采用了比较良好的规划,从小IP集成开始实现增量设计,也非常可能出现为了满足不断出现的新应用,导致整个芯片构架不堪重负而重构的局面,而重构出新架构的性能分析也会由于采用了传统的分析工具效率极为低下,导致调整新架构的效率极为低下。因此上述开发过程需要新的方法,既要实现硬件调试精度要求,又满足软件调试的弹性工作方式。
FPGA厂家新技术的成熟,有可能为解决上面的需求提供了可能。FPGA厂家一方面不断提供了更大容量的器件,使得更复杂的IP能够集成到FPGA中进行验证,一方面试图提供FPGA内部的软CPU系统,又称为SOPC来取代部分传统ASIC的应用,从而扩大FPGA的应用范围。其中,Altera公司的软CPU(NIOS)及其配套的总线系统AVALON,是首先能实现的多核并行计算架构。在当前最新的大容量FPGAStratix4上面,理论上能够接近提供1000个软CPU同时运行,通过自动连接的AVALON总线,这些软CPU还可以实现相互通信。于是我们可以想到,可否用多处理器的软CPU群系统来调试复杂的多处理器系统呢?
显而易见,对硬件逻辑设计者而言,他们最关心共享资源,比如内存带宽,总线上的运行,因此,配合可编程的计数器和相联比较器单元对这些资源的使用情况进行监听,就能统计出任何特定动作或者动作组合的频率和占用率,软处理器只要能配置这些计数器和相连比较器就可,不需要很强的性能。而对软件设计者而言,通过监听处理器程序地址的方法,就能了解程序的执行状况,甚至精确到任何模块耗费的时钟周期,通过设定监听处理器程序地址,软件程序员能知道每个模块的使用率,甚至通过一定手段,强制程序暂停 或者继续前进,而无需将调试代码实现在软件中。配置这些监听地址,也只需要很弱的软CPU就能实现。由于软CPU之间能通过Avalon总线相互通讯,Avalone的通讯速度在FPGA上能达到200Mhz以上,远远超过一般原型系统的能力,所以软硬件调试间甚至可以设置极为复杂的软硬件条件触发组合来定位系统要修正的是软件还是硬件。由于NIOSllAvalon系统都由Ahera公司进行商业化维护,SOPC系统自动生成需要的多核调试构架,而成熟的部分,又可以去掉调试系统,因此,能适应不断变化的调试需求,当所有硬件调试资源能够去除的时候,硬件逻辑的设计就基本成熟了,而当所有软件调试资源都不需要的时候,带调试的处理器软件也基本成熟了。反复迭代,软硬件协同的SOC就可以完成。下面就给出实施这个调试过程的步骤。
(1)调试硬件逻辑部分的设计。这部分逻辑是为了将要监控调试的硬件信号组合挂接在软处理器系统上,一般来说,内存系统和总线系统是硬件逻辑人员关心的对象,而内存系统和总线系统通常是工业标准,因此对内存和总线系统的调试逻辑常常可以复用到其他设计中去。这些设计的主体基本是可清零的时钟计数器,一定长度和宽度的相联比较器,这样可以将连续的硬件信号动作作连续比对,并将比较结果计数。这两种设备都以AvMon接口方便NIOS系统挂接。
(2)调试软件逻辑部分的设计。这部分逻辑是为了监听各处理器内部的程序运行状况,一般处理器的宽度在4~64位之间,因此,监控处理器内部PC的监听比较器位数也只用64位以下,并且可以配置为各种宽度运行,每次处理器内部PC的程序地址与监听比较器一致时候,计数器就触发。软件逻辑常常要统计处理器对外设寄存器的访问,因此,挂接寄存器监听器也并不复杂,通过它,我们能了解处理器什么时候访问外部设备进行通讯,以及访问次数。
(3)时钟控制和待调试系统的全局复位。如果需要在特定的场合暂停系统,或者启动待验证系统,这两个部件就有用了。在大多数情况下,我们很需要能单独重置待调试系统而保持调试系统的运作,所以不需要重置整个FPGA
(4)输入输出模块,我们可以用一个软处理器作整个系统的输入输出,利用一个软处理器挂接在系统的输入输出上,能模拟复杂的系统输入与输出条件。
(5)PC通讯模块,为了实现在PC上监控所有的调试过程,软处理器群需要实现与PC工作站的通讯,为了简单,我们使用USB芯片与Pc芯片通讯。
(6)调试系统整合,根据要调试的需求,生成多软核的调试系统。
(7)将调试系统与待调试系统整合起来,这一步可以在网表级别实现,Ahera提供了VQM的格式,类似Verilog可读格式,因此可以手动或者采用语法分析工具,将两部分合并成一个VQM网表。编译生成FPGA的配置文件
(8)编写软处理器软件。每个软处理器模块只需要挂接一个外设,做简单的配置和参数回读,而整个系统的协调运行则通过PC通讯模块,南PC端来协同。
(9)PC端编程,使得调试人员能直观看到各个模块并将各种信号组合转化为预定义事件模型,并能逐步配置和触发。
从以上步骤可以看出,除了第6步可能需要人工干预决定要调试的模块数目,第7步需要指出要监控的模块外,其他各部分的通用性是非常高的,因此可以制作为通用EDAI,具和库文件来方便其他使用者重复使用,此外,由于大型设计常常被分割在多个FPGA内运行,我们常常在第7步中插入一个待调试系统的分割步骤,分割好的各部分再与调试软处理器系统分别合成。并且能同时提供给软件开发者和硬件开发者使用,方便开发团队的协调,从而提高团队设计的开发进程。
