基于ARM的SoC设计入门

4.自己设计的连接在AMBA总线上的IP如何验证？
如果我们确实要自己设计连接在AMBA总线的IP，那么熟悉AMBA的总线标准是必须的。但是设计往往不是问题，问题是如何验证我们的IP能符合所有AMBA标准定义的行为 呢？
作为一个IP的验证，我们常常会使用所谓的Component-Based Verification，具体做法如图-2所示：


图2
在图2中我们要验证的是一个USB的IP，这个USB模块直接连到AHB总线上，在我们的testbench中需要如图中所示的各种VIP（Verification IP），如图中所示的BFM，Bus Monitor，才能够模拟一个USB模块会在真实的总线结构中会遇到的全部情况。这些VIP可以由EDA vender提供，也可以由工程师自己编写，但通常这些VIP不会使用HDL语言编写，而是使用HVL(Hardware Verification Language)语言。例如：e®, Vera等语言，当然同时也要使用支持这些语言的工具，如Verisity®的Specman®。由于系统高速总线（通常是AHB或AXI）上的行为比较复杂，所以我建议这样的VIP不要由工程师自己开发，而尽量使用EDA vender提供经过了完善测试的VIP。对于低速外设总线（APB）或SPI，I2C，USB等总线，则自己开发BFM模型和Monitor是可行的。

5. 搭建好的平台如何验证？
我们选择了适合的ARM core和总线结构，挑选了合适的IP，然后搭好了积木，TOP完成了，问题也来了，TOP该如何验证？
关于SoC的验证确实是个大题目，特别是在以IP为基础的SoC设计方法出现以后，在工程师的设计能力和验证能力中间出现了差距，也就是我们能在短时间内完成设计，却需要化数倍于设计的时间和人力来验证。最消耗时间的工作一般来说发生在软硬联仿(SW/HW Co-simulation/Co-verification)的阶段。
大家知道，抽象级越高的仿真越快，反之越慢，所以如果在我们的TOP文件中所有的模块都是RTL或Gate level的（包括ARM core），那么仿真的速度是谁也无法接受的，所以现实一点的方法是使用ARM core的DSM（Design Simulation Model）模型。具体方法如图-3所示：


图3
我们在图3中可以看到，对于内核(Processor)和Memory Controller我们都使用了使用高级语言编写的行为模型，并在这些行为模型和真正的RTL之间使用PLI(Program Language Interface)语言编写的接口。当然，所有别的外设IP和总线结构都还是使用RTL(因为我们就是要验证这些RTL)。DSM模型大多由IP提供商提供，如果使用的是ARM core，当然就由ARM提供了。软件由ARM提供的开发工具(ADS，RealView)编译好，产生bin文件，然后储存的Memory的模型中。
这时我们已经可以开始仿真了，ARM的DSM模型会在仿真的过程中产生一个log.eis文件，这个文件顺序记录了ARM core曾经执行过的所有指令，通过这个文件，我们就可以对软件进行debug了。
当然，使用这个文件对软件进行debug是很痛苦的，因为工程师不仅不能中断、跟踪、单步执行软件，更不能使用Semihosting功能进行文件操作和调试信息传递。如果可以使用AXD或Realview Debugger来对软件进行debug将给工程师带来极大的方便，所以EDA公司也推出了相关的产品，例如Mentor Graphics®公司的Seamless®以及我们前面提到的Axys®公司的Maxsim®等工具都能提供与AXD或者Realview Debugger协同仿真的接口。这样我们就可以象在目标板上调软件一样在仿真平台上调试软件了。
在这个抽象级别的仿真速度比纯RTL平台要快一些，大约能够做到1～100指令每秒的速度。在这样的平台上进行驱动程序和启动代码验证是可行的，但是如果要进行应用程序的全功能验证，特别是有操作系统的应用，这样的平台还是太慢了。比如在这样的平台上启动一个uClinux™，往往需要化数周的时间。显然，在这样的速度下验证应用程序还是不现实的。
解决这个问题我们有两个个选择：
(1) 使用硬件加速器
某些EDA vender会提供相关的解决方案，例如Cadence®公司的PALLADIUM® Accelerator/Emulator 和Mentor Graphics®的VStationPRO® Emulation system。这些都是能够加速我们仿真的加速器，但是一般价格昂贵，所以对大多数的Design House来说，这个方法不但性价比不高，而且也没有必要。
(2)使用FPGA原型进行测试
这个方法对于大多数公司来说是比较现实的。这正是我们的下一个问题。

6. 如何完成FPGA原型验证？
完善的FPGA验证对芯片功能验证是非常必要的，同时正如我们在上一个问题中提到的，要完成完整的功能验证，没有FPGA原型的帮助是非常困难的。具体到基于ARM的SoC，我们可以选择以下的一些方法：
(1) 由ARM公司提供的Integrator® prototyping board
ARM提供了一套名叫Integrator®开发套版，使工程师能够在这个套版上搭建和设计芯片尽量一致的验证平台。简单来说，ARM提供了Integrator® CT (Core Tile)来实现相应的ARM Core的功能和行为；使用Integrator® LT(Logic Tile)来实现我们芯片中除了ARM Core以外的所有数字逻辑（Integrator® LM上有个FPGA），使用Integrator® IM(Interface Module)连接模拟器件，再把这三个板作为子板统统插接到Integrator® AP（ASIC development Platform）。这样我们就像装电脑一样装出了一个SoC。在这个平台上，基本上所有的功能验证都可以做到，只要你对频率的要求不是太高（比如在你的应用中ARM core要跑在100MHz），这个平台是可以完成实时测试的。
(2) 由第三方供应商提供的FPGA验证平台
例如ALDEC®公司的Riviera-IPT FPGA verification system。这个系统的硬件是一块PCI接口的板卡，这个板卡的核心的一个FPGA，我们的数字逻辑还是放在这个FPGA中。同时，在这个母板上可以插上不同的ARM core的Integrator® CM，这样就完成了数字部分的搭建了。这个系统同样能提供与ARM的方案差不多的性能，但是它比ARM的方案有更多一些的灵活性。
Riviera提供了一个能让ARM core， FPGA中的已综合逻辑和未综合的RTL三方协同仿真的功能。这个功能的好处的我们可以复用原来在工作站环境下仿真时使用的Testbench、激励和参考输出，并可以把RTL象搬积木一样一块一块的搬到FPGA中。也就是说，在开始时所有RTL和Testbench都可以在PC机上进行仿真（当然是使用Riviera提供的仿真器），这时仿真的速度是比较慢的；一旦工程师觉得哪一块的RTL已经OK了，那么他就可以将这一块RTL综合到FPGA中，随着越来越多的模块进入FPGA，仿真的速对会越来越快。最后，所有的数字逻辑都综合到了FPGA中。在RTL仿真和FPGA之间建立交互还有一个好处是在FPGA debug的时候给我们带来了很多方便。调试过FPGA的工程师常常有着痛苦的回忆，由于FPGA内部的信号不可见，FPGA的debug往往非常耗时，Riviera在提供RTL和FPGA联仿的同时，还可以提供观察FPGA内部信号的功能，类似Xilinx®的CHIPSCOPE。详细资料请参照网页：
http://www.aldec.com/products/riviera-ipt/pages/coverification/
(3) 自己开发FPGA原型板
当然，如果自己设计FPGA原型板，那么工程师就会拥有最大的灵活性，自己的开发板上可以放置任何需要的器件。选用的FPGA可以尽量贴近实际SoC的运行速度，如果有Analog IP对应的Analog器件，那么功能验证的覆盖率将会非常小，最大程度减少投片不成功的风险。这个方案的代价是设计和调试验证板的时间，有时这个时间还会超过芯片设计的时间，同时也需要工程师拥有设计高速PCB的相关知识。
ARM core的测试样片是验证板的核心，这个测试样片实际上就是直接将内核拿去流片得到的（当然还要加上必要的PLL）。通常，ARM授权的Foundry会提供这样的测试样片，需要注意的是这个测试样片是否能达到应用所要求的速度，如果不能，那么实时测试将不可能实现。
另外一个需要注意的问题是FPGA的容量。在做AMBA总线结构FPGA综合的时候工程师会发现以AMBA总线为基础的RTL对FPGA资源的消耗非常惊人，有时一个150K Gate Count的数字逻辑会无法综合到一个150万门的FPGA中（如Xilinx®的XC2V1500），所以在验证板的规划初期一定要选择一个留有余量的FPGA（或几个FPGA组成阵列）。