微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 微波和射频技术 > 微波射频仿真学习讨论 > ARM Soc芯片验证手记 --基于Xilinx Virtex-5

ARM Soc芯片验证手记 --基于Xilinx Virtex-5

时间:10-02 整理:3721RD 点击:
1. 引子    近些年,随着工艺的进步以及技术的发展,FPGA在越来越多的领域发挥这非常重要的作用。本篇博客,我主要描述的是在ARM Soc芯片的软硬件协同验证中,FPGA的所扮演的角色。本篇博客以作者亲身经历的ARM Soc项目为背景来进行介绍,通过全面介绍ARM Soc软硬协同验证的全部过程,对比vcs仿真环境与FPGA环境的不同特点作用以及各种的利弊,来和大家分享一些我的经验和教训,已经和大家进一步探讨如何提高芯片验证的效率和质量。为了避免泄密所导致的法律纠纷,这里隐去了公司名称以及项目名称。QingYangOS为作者于07年公布的一款嵌入式内核。后来在芯片验证中,发挥了非常重要的作用,这里介绍这款内核,主要是为了说明软硬件协同验证的方法和过程。
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来工作的逻辑,可以达到相当的一致性和稳定性。





好资料!
顶起来!
希望做电子的朋友路过不要错过!

非常不错,支持下

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top