提高验证性能

(本文编译自Semiconductor Engineering)


如果不对方法进行革新,验证团队将无法有效应对日益复杂且广泛的验证任务,单纯依赖工具已无法解决问题。


随着验证任务的规模不断突破工具的发展速度,设计团队被迫探寻更优策略,以整合和利用现有的工具。然而,随着验证团队技能的提升,以全面应对他们被分配到的任务,他们所使用的工具清单也不断增加。而且,由于很少有公司能雇得起验证专家,验证工程师唯有持续学习才能保持竞争力,这无疑加剧了寻找足够多的熟练人才的难度。


应对如此规模的问题需要众多解决办法,而且这些方法可以通过多种方式进行整合。西门子EDA数字验证技术部解决方案管理总监Bryan Ramirez归纳了三种整合方式:“首先,我们如何助力他们扩展验证规模?这包括提升引擎性能及提供更多自动化手段,使他们能以更少的投入做更多的事。其次,是数据驱动验证,即他们如何充分利用现有数据,并引入人工智能等技术,以更智能的方式解决问题。最后是关联认证,我们如何更紧密地将形式验证与软件仿真结合?如何将其与硬件仿真或原型设计无缝对接?又如何与其他相关领域,如测试与实施,实现更紧密的结合?”


新思科技所提供的整合方式略有不同。新思科技战略项目与系统解决方案执行董事Frank Schirrmeister是这样对它们进行分类的:“首先,引擎的基础速度正持续攀升。其次,我们称之为‘更智能的验证’,这涉及到方法学以及正确的范围。在IP层面解决的问题,并不总能直接转变成SoC层面或系统层面的问题。最后,则是自动化与人工智能。这三者构成了一个稳固的三脚架——加速验证流程,实现更智能的验证方法(也就是方法学方面),然后在此基础上实现自动化。”


问题范围不断变化


过去,验证团队的职责主要聚焦于芯片的功能性验证。然而,这一范畴现已有所拓宽。首先,芯片已不再是孤立的存在,它已经变成了一个涉及芯片、电路板乃至整个系统的问题。其次,芯片的其他关键属性,诸如功耗、热管理以及可靠性,正日益凸显其重要性。第三,系统层面的考量因素,包括安全性、保密性、测试及软件等,对于众多产品领域而言,也变得愈发关键。


这正促使越来越多的企业开始全面审视这一问题。Cadence产品管理部总监Matt Graham指出:“以散热问题为例,它不仅关乎IC层面,还牵涉到电路板及机箱等层面。这已远远超出了单纯验证的范畴,成为了一个系统性的挑战。因此,众多公司正积极关注数字孪生技术。行业亟需明确设计的极限所在,以及我们正在规划、设计的最终产品形态。这要求在既定的功耗、散热及成本下,提供最大的持续性能。从验证的角度来看,我们需要探索如何高效且切实地将这些考量因素纳入流片前的阶段,以便在制造之前获取更多有价值的信息。”


仍有许多壁垒有待打破。西门子公司的Ramirez表示:“我们面临的挑战不仅在于设计复杂性的增加,还在于这些设计所要求的验证范围的扩展。审视这一问题的视角应超越单纯的功能性需求,还应包括安全性、保密性、可靠性等日益增长的需求,以及DFT验证、约束验证等新型要求。在设计时,对功耗有更强的意识,这一需求已经超出了消费级设备的范畴。此外,软件定义一切的趋势正迫使客户以一种全然不同的方式进行思考,即软件先行,而非事后才考虑软件。”


验证团队需持续发展。新思科技的Schirrmeister表示:“验证方法虽已有所发展,但仍需进一步完善,以模拟设计流程中的做法,包括芯粒等前沿技术的进展。这正是测试生成自动化的重要性所在,它是验证的下一个关键阶段。在功能层面,通过便携激励(PSS),你会有一个约束求解器,能够生成所有可能的测试变体。在功耗方面,有专业人员会分析活动情况,帮助识别热点、关注点和潜在的功耗问题。这些任务涉及不同领域的专业人员,验证需求也因此而多元化。”


随着问题的相互关联性增强,设计与验证也必须实现相互关联。Cadence的Graham表示:“企业已意识到需要对系统进行端到端的管控,以确保软件工作负载在散热和功耗方面具有可重复性。他们必须掌握软件情况,了解电网在实际工作负载下是否会故障。软件是否会陷入那些极端情况?能否编写出既高效又能为用户提供所需全部功能,同时还能避开那种极端情况的软件呢?”


这需要对“最大”这一概念进行深入思考。新思科技高级工程总监Bernie Delay提出一个问题:“即便不考虑散热影响,最大功率场景究竟是怎样的?”他强调:“你需要能够找出最大应力场景的自动化手段,因为仅凭个人是难以想象出来的。验证工程师必须分析最大功率值,这与实际场景中的功率不同,实际场景中还需考虑软件负载并进行计算。”


散热问题使情况变得更复杂。Ramirez表示:“我们发现,功耗和散热问题往往在实时运行30分钟后才显现,而在硬件仿真中解决这些问题可能需要数天甚至数周时间。业界已意识到,我们需要更好的工作负载类型来对器件更精准地施加压力,以便暴露这类问题。这个问题尚未得到解决。在功耗方面,我们已有不错的基础解决方案,能够测量和分析不同引擎的功耗,这是一个良好的开端。但如何获取正确的激励以利用这些基础技术呢?这可能是下一步创新的方向所在。”


目前可用的工具


EDA公司投入了大量时间与精力试图优化基础引擎,然而这些引擎已达到高度优化的状态,难以通过移植至大规模并行架构实现其他算法所展现的显著性能飞跃。“我们不能单纯依赖CPU运行速度的提升,”Graham指出,“算法与模拟器均已经过优化,即便进一步对它们进行优化,也无法实现两到四倍的性能提升。功能验证面临的最大挑战在于,我们缺乏热力学模拟或计算流体动力学(CFD)中那样的算法,这些算法在GPU上运行能实现数量级乃至更高的性能提升。对此,我们无能为力。我们有很多大型的稀疏矩阵,这就是问题所在。当矩阵又大又稀疏时,它们对GPU会有一定响应,但我们不会像在其他领域那样看到显著的性能提升。”


硬件仿真技术是一种专为功能验证打造的大规模并行处理引擎,它仅是众多解决方案之一。“目前,在验证领域有一系列很不错的引擎,涵盖了从虚拟原型设计,到静态验证、形式验证、软件仿真,直至硬件辅助验证的各个阶段,”Ramirez介绍道,“关键在于,如何有效使用每种工具。你不会一开始就直接采用FPGA原型,因为为了RTL代码稳定下来而进行调试的周转时间会很长。我们正在摸索在这些不同的验证领域之间更好地转换的方法,而且从更广泛的意义上来说,是在半导体开发的各个环节之间更好地转换,因为如今已经超越了单纯的功能验证范畴。”


这种工具交互有几个例子。“形式验证正在左移,于测试台开发前即被投入使用,”Graham补充道,“因此,形式回归的概念日益凸显。仿真器不仅运行速度越来越快,容量与适用性也在不断扩展。最近,我们在仿真器中引入了四态仿真与实数建模功能,使得那些在模拟领域无法继续推进的问题能够转移到仿真环节来解决。”


EDA公司一直在探索提升所有引擎性能的方法。“首先是将引擎分为两类:一类是可扩展引擎,其性能相对较低;另一类是小型引擎,这类引擎性能经过优化,但难以达到最大规模,”Schirrmeister表示,“这对产品组合产生了影响,高端解决方案可扩展至300亿个门电路,是处理超大型设计的主力产品。而对于数十亿门电路的中型设计,我们提供了其他经过性能优化的解决方案,其速度更快,但目前无法以该速度扩展至300亿个门电路。”


验证可以通过模拟设计来提高速度。“随着设计向3D-IC迁移,我们可采用不同技术对其进行模拟,”新思科技产品营销总监Bradley Geden表示,“我们可为每个芯粒创建不同的可执行文件,每个芯粒在不同机器上运行,只要具备低延迟的协议级通信,就能实现出色的性能扩展。UCIe可在实际物理接口上运行,也可通过PCIe连接分布式引擎。”


但存在物理方面的限制。“从芯粒或3D-IC角度来看,我们在规模上存在一个根本性问题,”Graham表示,“系统仅仅是启动模拟就需要数太字节的RAM。我们必须找到解决这一问题的方法学及解决方案。这不是速度或够不够全面的问题,而是‘我们根本做不到’的问题。如果不采取措施,那我们在这个领域就完全是在盲目行事,甚至无法确定两块芯粒之间是否能相互通信,而不仅仅是验证接口处的两个IP能否通更别说仅仅验证接口处的两个IP之间能否相互通信了。”


这导致了两个层面的问题。首先是获取准确的场景。“理想的激励应与实际工作负载相匹配,”Ramirez指出,“这样你才能确保测试的是现实中真正会发生的情况。问题在于,获取真实世界的激励、那些实际的工作负载有多难?你是否能在项目或芯片完成前得知?理解实际工作负载的难度日益增加,而且当我们转向系统级时,情况更为复杂。多数公司不再是单纯的芯片公司,而是系统级公司。这让它们对自身在该系统内的工作负载情况有了一定了解,但同时也增加了工作负载的复杂性。”


问题的第二个部分是针对除全系统验证之外的情况,对这些工作负载进行转换和划分。“我们缺乏将高级别工作负载(系统级工作负载)抽象或细化为适用于模块级工作负载的能力,”Ramirez补充道,“如果仅进行模块级验证,则无需运行如此庞大的测试。模块级验证的关键在于快速、高效地完成验证,并覆盖该IP的使用环境。而且有时候,对于不同的配置,你并不清楚自己必须要验证的相关情况。”


结语


验证引擎正在缓慢改进,但问题空间正在以更快的速度扩大,并进入多学科领域。任何新的验证引擎出现的可能性极小,这意味着更好地利用现有的引擎是唯一的出路。曾经局限于特定引擎的问题正在向性能更高的引擎迁移,这一进程正在取得进展。但尽管这可能是一个陈词滥调,但问题不是通过更努力地工作来解决的,而是通过更聪明地工作来解决的。这将在后续故事中讨论。


验证引擎的改进步伐缓慢,而问题空间则以更快的速度扩张,并跨越多个学科领域。新验证引擎的出现几率极低,这意味着充分利用现有引擎成为唯一出路。原本局限于特定引擎的问题正逐步向性能更高的引擎迁移,并已经取得了一些进展。尽管这可能听起来有些老套,但问题的解决方案不在于更加努力地工作,而在于更加明智地工作。


END