ARM Soc芯片验证手记 --基于Xilinx Virtex-5
2. 项目整体介绍
公司准备上马一款高性能的解码视频引擎，采用当前流行的ARM体系结构，使用ARM926-ejs内核。经过前期的系统评价，架构设计，以及必要的IP 购买，再加上公司自有的一些IP,已经基本具备ARM Soc芯片开发所需要的条件，再加上台湾某著名的后端公司和流片公司的支持，芯片很快进入了实际的开发阶段。在芯片中，采用了支持Full HD的H.264解码IP，以及高性能的2D引擎IP，Sprite描画引擎IP，以及支持LVDS的Display引擎，DDR2 SDRAM等。当然，芯片中还有很多其他的IP，但是，由于与我们的验证话题无关，这里不再详细介绍。其中，一部分IP需要我们自己开发，而购买的IP则需要进行各种验证。各个IP的单元验证，不是我们讨论的主要内容。由于IP很多，不可能在单元验证中，就使用FPGA来进行，只能通过仿真环境，通过各种 Test Bench来完成。FPGA的验证方法，主要用于芯片的整体验证，而这种方法，最终证明是非常正确的。
做过芯片的朋友，都会有这个体会，那就是永远与时间为敌。首先要考虑竞争对手的研发速度，其次自身芯片结构相当的复杂，芯片的验证相当的困难，而时间则是总是显的那么的不够，特别是进入TapeOut倒计时之后，更是如此。在进行一些IP的开发和单体验证的同时，必须建立整体验证环境，双管齐下，并行进行。而这里，我们重点介绍整体验证环境的建立过程。3. 整体验证平台
整体验证方法，主要有两种，一种是基于仿真工具(比如Synopsys的vcs)以及ARM DSM(Design Simulation Model)的仿真模型(也有些公司使用基于RTL的ARM Core，但是不如DSM好用)，建立起来的一套仿真环境平台。另外一种，就是使用FPGA的验证平台。
这两种环境，各有优缺点。在实际的项目中，必须两种方法都是不可或缺的，必须相互参考相互补充，才能较好的完成硬件的验证工作。
基于VCS和DSM的仿真环境，主要是一些服务器的设置，脚本编写的工作。之后，依赖于仿真环境以及各种IP的仿真模型，来达到系统验证的目的。他的主要优点，是能够看到芯片中，每一个器件的运行情况，每一根信号线的变化，而缺点，则是速度太慢，在真实芯片中，一秒钟的时间，在仿真环境里面，则通常要2，3个小时。而这个数值，是使用相当高端的64位服务器来加速运算的前提下得到的数字。真有天上一天，地上一年的感觉。另外，一些硬件的仿真模型，无法与实际的物理器件完全的一致，所以无法保证仿真结果的准确性。
而基于FPGA的验证环境，则为我们提供了一个真实的运行环境。速度快，更加贴近实际的芯片的运行情况。而缺点，这里我们先卖个关子，到后面再慢慢道来。这里，我想说的一点，就是以我们的芯片400万门电路的规模来说，能够满足我们验证需求的FPGA实在屈指可数。这里，我们不得不佩服FPGA的发明者--Xilinx的优秀技术。最终，我们选择了采用Xilinx的Virtex-5系列的FPGA验证平台HAPS54以及HAPS51。HAPS54负责全体芯片的总验证，几块HAPS51作为备用，可以用于一些特定IP的特殊验证。HAPS系列验证平台，为Synplicity公司开发，现在已经被Synopsys公司收购，采用65nm工艺制造的Virtex-5 LX330芯片，支持1.25GHz的差分I/O，以及800Mbps的单端I/O，可以支持多达200百万门电路。这一切，都使得FPGA的验证看起来更加的美好。
4.建立FPGA验证环境
HAPS54/51板子一到，我们就迅速进入了FPGA验证环境的搭建工作。
最初的搭建工作，是使用HAPS51，建立一条ARM Core -> AHB Bus -> Bridge -> High Speed Internal Bus -> DDR2C -> DDR2 SDRAM通路。
ARM Core我们是购买了几块HAPS配套的带有ARM926-EJS芯片的板卡。这种ARM Core芯片是专用芯片，生产的数量非常的少，因此可以算是天价。
另外的一个难点，算是DDR2 Controller了。由于无法将我们芯片实际使用的DDR2 Controller直接放入FPGA中，因此使用了Xilinx提供一个DDR2 Controller的模型。这里的主要问题，是DDR2C的PHY的问题。这种纯模拟的器件，是很难使用FPGA来进行验证的，因为在真正芯片进行后端合成的时候所生成的逻辑，根本是无法放到FPGA里面进行验证，而只能用Xilinx提供的DDR模块。即使是这样，调通DDR2 Controller也是花费了很多的气力，幸好设备还算精良，总算可以得到满意的结果。另外，这里要说的是，我们芯片里面主要有两个地方使用了内部PHY，一个是这个DDR2 Controller，另外一个是LVDS。由于FPGA无法验证这些PHY，在最终的芯片中，都出现了比较严重的问题，这里有天灾也有人祸。我们一共做了4次ECO才算是彻底修复，而且基本是仰仗负责后端那边的公司出色的技术实力。从此，对做模拟芯片的公司，也多了一层敬意。
经过一顿折腾，这条通路终于完成，通过ICE可以成功读写DDR中的数据，并且，可以通过ARM执行代码。于是，我们总算可以松了一口气。
但是，接下来发生的问题，难倒了几乎所有的人，也使我彻底明白什么叫做FPGA的Utility。
Utility说白了，就是烧进FPGA里面的Gate数，占FPGA总体Gate数的比例。一般的FPGA都使用LE(逻辑单元)作为其容量的衡量单位，但是在验证领域，还是更喜欢使用Gate这个单位，因为芯片的规模是以Gate来衡量的。
FPGA中，如果Utility在10%以下，这个FPGA可以跑在Full Speed，但是随着Uitility的提高，timing就越来越无法满足要求，因为无论是逻辑还是走线，在FPGA中，都要靠LUT来实现，使得规模越大，延迟就越大。而如果Utility超过60%，那么基本就无法满足实际使用的要求。
我们的芯片除去RAM，共有400万Gates，其中H.264 140万门，2D/Sprite Display大概120万门。而一块Virtex-5 LX330芯片，最大可以支持到200万门，那么如果把H.264放入里面，Utility将达到140mil/200mil=70%。这样的Utility，根本无法用于验证。而2D/Sprite和Display也达到了60%，堪堪能够满足要求。由于这个问题的出现，使得整个团队，都笼罩在一种非常沉默的氛围中。
经过一周的讨论，最终的方案，是把H.264按照功能画分成两个部分，分别放到不同的FPGA中，两部分逻辑通过板间信号进行通讯。拆分H.264的过程是异常痛苦的，好好的一个IP，就这样被一分两段。但是随后的问题接踵而至。H.264这两个被分开的部分占用了过多的FPGA pin，使得本来充裕的I/O资源，一下子成为了紧缺资源，而且无论怎么规划都不够用。使得FPGA验证环境的搭建工作，再次陷入僵局。
但是，我们的架构师，还是找到了解决方法－－那就是共享pin。简单来说，就是在两个FPGA之间，通过一些握手信号，id标识以及数据线，使得几个不同的模块，可以共享使用这组pin,来进行通讯。这样，本来是并行通讯的信号，就变成了串行。这种并变串的思路，在当今的硬件设计中比比皆是，像USB就是一个很好的例子。这里，我们活学活用，通过并变串来解决I/O资源不足的问题。而且，前面提到，这款FPGA可以支持1.25GHz的差分I/O，以及800Mbps的单端I/O，因此I/O的速率基本不成问题。
最终，我们很好的解决了I/O资源不足的问题，成功建立了FPGA的验证环境。
但是，这样的结构，使得FPGA的验证环境，无法达到当初预想的速度，甚至连1MHz的Clock都无法到达.因此，只能采样FPGA验证环境，进行Function Test，而无法进行Performance Test。不得不成为一种遗憾。
5. 基于VCS仿真环境和FPGA验证环境的软硬协调验证
就在FPGA验证环境搭建成功大概相同的时间，vcs的仿真环境也基本完成。下面的所面临的问题，就是这两个验证环境，到底如何协调工作，相互配合，从而取得验证的最佳效果。在整体验证环境，使用软件测试程序，成为了必须的选择，也就是必须进行软硬件协调验证。后面的验证实践也充分证明，仅仅在单体验证中跑Test Banch的测试，根本无法覆盖所有的问题，无论这个Test Banch设计的如何全面。特别是不同模块之间的衔接部分，更加需要在整体的验证环境来测试。而统一VCS仿真环境与FPGA验证环境的最佳手段，是软件层的统一。也就是VCS仿真环境和FPGA运行环境，尽量运行相同了逻辑，相似的框架，这样当出现问题时，可以快速判断到底是软件问题还是硬件问题，进而明确问题点。前面提到VCS验证环境，速度非常的慢，因此只能运行简单的软件测试Vector，而无法运行任何大型的软件代码。而FPGA则运行速度较快，可以跑一定复杂的代码，可以提高发现硬件Bug的概率。因此在验证的初期，我们使用FPGA为主，VCS为辅的策略。
在验证初期，我们就导入了QingYangOS(www.qingyangos.org)的软件平台。平台包含了Easy kernel和Main kernel。两个内核，具有相同的架构，相似代码，Easy kernel用于VCS的仿真环境，Main Kernel则用于FPGA验证。Easy Kernel结构非常简单，可以缩短VCS的仿真时间，而Main Kernel则包含更多的功能，包括shell，Task Fork以及一些时间测量等实用的功能，来方便验证人员的操作。与此同时，无论是Easy Kernel和Main Kernel，都可以运行通一套验证代码，这样一旦在FPGA中发现问题，马上可以把相同的代码，拿到VCS环境中运行。相反VCS环境的代码，也可以拿到FPGA环境中运行。此外，这些验证代码，一旦验证成功，很快就可以变成类Linux的驱动程序，因为Main Kernel提供了类Linux的驱动框架。
在实际的验证中，FPGA验证所发现的问题点，大概占到了硬件Bug的80%以上。在实际验证中，起到了非常重要的作用，特别是一些隐藏的很深的问题点，都是首先由FPGA首先发现的。可以说FPGA验证成为了芯片验证的眼镜和耳朵。但是FPGA只能发现问题，而无法准确的定位问题的根源，和找到解决问题的方法。此时，就需要用到VCS仿真环境，来精确定位问题。一般的验证，除了代码逻辑需要共享之外，还需要一些数据的共享。有时数据很大，仿真往往要跑几个小时，甚至十几个小时。之后在浩如烟海的数据中，去发现导致问题的具体地点。有时需要在VCS中，采样更加抽象的仿真模型，才能更去伪存真。但是无论如何，都离不开对软硬件系统的理解和把握。
6.结束语
经过大家的努力，最终芯片非常成功的TapeOut，并且经过FPGA验证过的部分，出现问题的比率几乎为零。但是，由于各种限制，没有验证到的部分，特别是前面提到的两个PHY，则多少出现了一些问题。但是由于没有什么重大的设计缺陷和验证漏洞，经过几次ECO之后，芯片基本100％达到了设计要求。
另外，前面说过FPGA无法进行Performance Test，但是，通过留片回来的芯片与VCS仿真环境的对比，发现VCS仿真环境下测试所得到的性能结果，与实际芯片的性能结果，几乎一致，也说明了数字电路，依靠clock来工作的逻辑，可以达到相当的一致性和稳定性。
好资料！
顶起来！
希望做电子的朋友路过不要错过！
非常不错，支持下