微软公司宣布不再支持你正在使用的 IE浏览器,这会严重影响浏览网页,请使用微软最新的Edge浏览器
厂商专区
产品/技术
应用分类

基于验证FPGA设计:模拟,仿真,还是碰运气?

2013-10-14 11:42 来源:电源网 编辑:娣雾儿

曾几何时,要验证 FPGA 的逻辑设计,可以先编译、写入,然后按下评估板上的复位按钮。但是,随着FPGA规模的增大,这种被Xilinx公司软件产品营销总监Hitesh Patel 称为“blow and go”(逃生法)的验证方式已不能满足要求。要做出一个近乎完美的有百万个门的设计,达到可以从封装引脚就可以调试的地步,成功的机会非常之渺茫。因此,FPGA设计组也开始采取ASIC设计组已使用多年的方法,采用基于软件的设计模拟

但是这种方法也引出了一系列重要的问题: FPGA设计中模拟的作用应该跟在ASIC设计中一样吗?验证人员是否还是要在某个时刻将设计装入产品FPGA并马上开始测试它?如果是这样,这个时刻是在什么时候?为了弄清设计团队现在都在做什么,我们询问了一些工作中与FPGA用户关系最紧密的人。作为参考,我们还询问了几个在验证过程中采用FPGA原型来进行ASIC设计团队,以了解他们的意见。

优点和缺点

多数人讨论验证流程时,首先会比较模拟和在FPGA内验证的优劣。尽管有经验的读者可能会觉得乏味,本文也还是采用类似的模式。

模拟的一个很大的优点自然是它的访问能力。该方法可以以时钟周期分辨率观察RTL (寄存器传输层)设计中任何信号。只要有必要,对设计状态的控制可以达到任何水平。达到可观性和可控性的唯一限制就是对RTL的了解程度和对模拟环境的掌握程度。你可以在有限的设计领域交互式地工作,也可以构建运行好几天的大型试验。构建的模拟项目运行相对较快,所以可以快速地对很多东西进行试验。

既然FPGA有这么多优点,您可能会觉得疑惑:直接将编好的核装入FPGA、为它编写一个试件(test fixture),然后开始测试 ,这样做会有什么问题呢?这个问题的答案在于FPGA的一些缺点。

FPGA的缺点

最明显的突出的问题是可见性。理论上说, FPGA中每个逻辑元件都可以通过芯片的调试接口观察。但是,厂商估计只有一半的FPGA用户在设计中加入了调试接口并将其用于验证。考虑到内置调试口提供的功能是如此强大,这非常令人吃惊。Xilinx公司的Patel认为,随着FPGA规模变大,人们会更普遍地使用调试接口。

因此,在多数情况下,如果想观测设计中的某个信号,就必须先把它引出到一个引脚,然后用逻辑分析仪分析它。由于逻辑分析仪的特点,可能还需要引出大量其他信号,如内部时钟。这样做就会有很多额外的工作,另外,如果要观测的信号是一个与I/O块相隔甚远的快信号,可能还必须降低FPGA上的时钟频率。因此,一些经理认为:在原始验证方案中包括对FPGA信号可观性的要求是很重要的。

访问信号所需的附加设计工作是该方法的一个缺点。芯片内部节点的激励和观测还涉及另一个问题,那就是需要修改设计、重建和重新综合测试,因此有可能导致设计和测试部分不能清楚地分割开。如果不能仔细地将调试代码和设计代码分开和切实做好版本控制,就可能无法跟踪这些修改,有可能发生类似于外科医生把手术工具留在患者体内的情况。

另外,建立测试的时间也是个弱项。规模较大的设计中,综合时间并不短,而插入测试设备、重建、重新综合和重新绘图的时间也会是个重要因素,可以影响到是否进行某个试验。这里采用增量综合(Incremental-synthesis)工具会有所帮助,但是对于有2千万个门的设计,构造和合成过程可能需要一晚上的时间。

最后,将测试平台从模拟环境转向FPGA环境也有问题。此时,激励模块需要有电路,而非一组模拟命令。观测某个节点需要的不仅是命令,还需要有电路和物理仪器。尽管基于断言的验证被越来越多的人接受,但似乎还没人开发出哪种方法可以系统性地将断言从模拟环境移植到FPGA。 “现在还没有可以自动将断言移植到FPGA的解决方案,但是我们收到的对该功能的要求在不断增加,” Simpson说。


对电路内方法的讨论

FPGA 内验证方法的优劣与模拟正好相反。首先, 显然FPGA 很快。人们经常可以以全速运行设计。不过,在某些情况下,这样做就意味着时序收敛问题会较多,超乎设计早期预期的程度。另外,与模拟不同,将多个模块综合到设计中时,FPGA 并不会降速。这样就可以测试整个设计,而非单个块,并且可以以大量的实际数据集来运行测试,而不是采用精心编制的测试用例。

由于FPGA速度较快,而且它的I/O部件就是实际应用所需要的I/O部件,所以也可以采用系统中测试设计:可以在装入目标系统的FPGA开发板上测试,或者,如果目标PCB(印刷电路板)可以用的话,就在目标PCB上测试。这样的测试可以消除测试用例是否能够如实反映设计工作环境的疑虑。另外,在实际使用的电路板上测试设计可以暴露出I/O方面的问题——例如电气问题、信号完整性问题,或是在高速串行协议下不兼容问题。这些问题用其他方法几乎无法检测,而系统内测试则会形成一个软件测试平台,带来额外的好处。


一种可为大家接受的方法

根据与FPGA厂商和用户的讨论,我们可以看到对模拟和仿真(图1)混合验证流程大家基本达成一致意见。这种流程首先对设计开始元件块级的模拟——不是传统上ASIC所用的那种穷举式的力求完美的模拟,而更像是对实际情况进行检查。其目标是验证元件块可用、引脚工作基本正确、在实验环境中可满足FPGA 的时序需要。

仿真1

在此阶段,很多开发组将某个版本的块转入FPGA并开始更为彻底的电路中测试。如果此电路块(如视频编解器)需要很长的高速数据流来验证功能或是包括高速I/O功能,则该方法尤为常见。在其他情况下,继续对块进行模拟工作,直到所有问题都经过验证,可以进行集成为止。

根据大家的一致意见,当开发组开始将块集成时——建立试验系统时——FPGA 才真正被更多人使用。这里,可能就是因为设计太大才无法进行快速模拟,或是对于已知可正常工作的块,在FPGA上解决集成问题可能要比在模拟器上效率更高点。

但是,根据大家的意见,从模拟转到仿真并不是单步的可逆步骤。正如软件开发中并行进行模拟一样,模拟工作在系统仿真期间也在继续。多数开发组利用FPGA 仿真捕捉和隔离缺陷,然后将其送回模拟组诊断。在FPGA上做详细诊断是非常痛苦的工作。

这里先总体叙述当前的情况,然后指出该方法的几个严重缺点。首先,在两个环境间来回传送测试平台数据很困难。似乎还没有方法可以将创建测试的模拟指令自动映射到实施同一测试的 FPGA 结构。第二,各大 FPGA 厂商都可提供的嵌入式RISC核资源似乎远没有得到充分利用,它可以管理数据和控制测试,但是又是与模拟测试平台分开的。理论上说,模拟组可以将其转为嵌入式处理器核的C代码,而不是转为FPGA的RTL。第三,没有简单的途径可以将FPGA 试验中开发组收集的数据送回模拟平台。最后,随着模拟领域基于断言的验证工作不断增多,FPGA 侧急需一种类似的基于断言的工具。

基于 FPGA的仿真系统销售厂商对这些问题提出了应对措施,证明了这些问题是确实存在的。这里的例子有Eve公司的系统;模拟加速器,如GateRocket;以及“big-iron”(大型的)仿真盒,如Cadence的Palladium。至于这个基础平台会发展为FPGA验证领域常见的那种专用板卡级仿真平台,还是仍然会是昂贵的加速器和仿真系统的一种变形,我们尚无法知道。


解决覆盖空隙的一些思路

人人都喜欢FPGA内仿真的速度。但是在FPGA中建立系统、控制和观测试验的难度过大,这常常迫使人们将费力费时的测试工作转回到模拟环境中。在实际中,有些人会搭建一个验证平台,结合FPGA执行速度高和模拟方法易于构造和访问数据的优点。毫不奇怪,有些厂商已经瞄准了这个目标。

首次这么做还是ASIC时代早期的事,这也就是 “big-iron”逻辑仿真系统。从效果上说,这些系统就是一组专用的巨型计算机,其中由定制微处理器或定制可编程元件分别模拟仿真逻辑操作。这类系统的代表是Cadence Palladium。此系统执行速度为模拟的很多倍,同时其厂商声称它对被测设计的访问能力至少与模拟相当。但是,这些系统的容量有限,不会比通常模拟的块规模大很多——除非你有非常多的钱。这些设备是主要的耗资设备,因此多数最终设计面向FPGA的设计团队都无力支付高昂的费用。

近年来,有大量系统进入市场(例如Eve等公司的产品),这些系统可以在使用商业FPGA的简单环境下进行逻辑仿真。这类系统具有不同的特点,有些是小型化巨型机仿真系统,有些基本上就是带支持调试软件的FPGA评估卡。在所有情况下,它们都试图提供一个设计中逻辑开销低于big-iron仿真系统的FPGA执行环境。由于逻辑开销较低,通常基于FPGA的系统运行速度可以比巨型机仿真系统快一到几个数量级。总的来说,运行速度越快,保留的模拟的方便性就越少。但是,当单个FPGA的设计(包括调试开销)变得过大时,它们就会表现出局限性。将设计分区是很复杂的,而且经常涉及到FPGA间信号的多路复用,这会将所有工作都拖慢。

标签: 仿真 FPGA设计

声明:本内容为作者独立观点,不代表电源网。本网站原创内容,如需转载,请注明出处;本网站转载的内容(文章、图片、视频)等资料版权归原作者所有。如我们采用了您不宜公开的文章或图片,未能及时和您确认,避免给双方造成不必要的经济损失,请电邮联系我们,以便迅速采取适当处理措施;欢迎投稿,邮箱∶editor@netbroad.com。

相关阅读

微信关注
技术专题 更多>>
研发工程师的工具箱
智慧生活 创新未来

头条推荐

电子行业原创技术内容推荐
客服热线
服务时间:周一至周五9:00-18:00
微信关注
获取一手干货分享
免费技术研讨会
editor@netbroad.com
400-003-2006