- [SoC芯片设计验证详解]
- https://aijishu.com/a/1060000000417616
Perface
芯片的功能安全曾是非常小众的领域,只有少数汽车、工业、航空航天和其他类似市场的芯片与系统开发商关注。然而,随着汽车行业过去几年各类应用的兴起,情况已经发生巨大变化。
同时,除了汽车外,还有很多其他行业也能从电子器件的增加受益,当然保障功能安全是大的前提。本文讨论SOC芯片设计验证、验证计划和策略以及验证方法。它定义了功能模拟、功能覆盖、代码覆盖以及设计验证中使用的重要术语。本文还涉及FPGA验证及其在SOC验证中的作用。
01. 验证的重要性
由于开发和制造成本过高,一次成功是SoC设计的首要要求。几十年来,人们一直致力于提高SoC验证的有效性和效率。评估验证有效性的最有效指标是SoC设计通过现场测试的次数。
除此之外,SoC设计越来越复杂,需要有效的验证方法来改善这些统计数据。这种对ASIC/SoC设计的有效验证的需求在2000年出现,开始设计许多创新的方法来验证SoC设计,但仍有更多的空间。
SoC验证是用于确认SoC设计的功能正确性的过程。典型的SoC设计周期(从规格开始到设计流片)从六个月到三年不等,具体取决于技术、系统的复杂性以及SoC设计构建模块的可用性。
制造过程、封装、ATE测试和获取工程样品进行现场验证(芯片交付给客户进行产品试验)通常需要6个月的时间。
因此,所有的SOC只有在工程样品在确定的产品用例场景中被验证之后才可用于生产。如果这是成功的,SoC设计被考虑用于批量生产。
这是设计的一次成功。开发周期中任何一个步骤的失败都会成倍地影响设计时间,有时需要新的金属流片和设计修正。
使设计一次成功的另一个驱动因素是纳米技术的制造成本。采用40纳米CMOS FinFET技术的36平方毫米芯片设计的典型制造成本约为80万至100万美元。SoC工程样品开发期间产生的高额非经常性工程(NRE)和制造成本将在大量生产中摊销。
因此,如果NRE要求对工程样品进行多次流片,那么它可能会对业务产生很大影响,在商业上根本不可行。因此,在片上系统开发中,一次成功是绝对必要的。
SoC设计验证的可行性取决于在预硅阶段确定系统的一组“最常见的用例场景”。这是一个非常复杂和具有挑战性的现象,因为可能有无数的用例场景。例如,人们可以很容易地想象智能手机移动SoC的无数用例场景,其主要功能是通话电话。但是智能手机被用于许多应用,例如发送信息、购物、跟踪人体健康、银行和信息娱乐。
将会有大量的应用场景来测试和验证移动SoC对这些应用场景的设想来识别和验证它们。
在开发周期中,随着设计从一个阶段进入下一个阶段,调试SoC问题的成本会增加10倍。也就是说,设计阶段的验证成本比在晶片阶段验证相同功能的成本低10倍,比在芯片阶段验证的成本低10倍。这比在客户现场进行验证要便宜十分之一。
这是因为与开发的高级阶段相比,设计人员在设计阶段获得了更高的调试权限和工具支持。因此,在预芯片阶段,一组接近实际应用用例的关键场景将被识别和瞄准,以获得SoC首次成功的良好信心。
SoC设计是通过集成不同类型的设计模块或IP核(软、硬核)来完成的,这进一步挑战了设计验证。
SoC设计过程还包括从RTL到网表再到布局结构的一系列设计转换,然后转换为掩模数据。
当设计经历这些转换时,需要验证设计意图在所有层次上都得到了保留,直到完成为止。
总而言之,验证对SoC设计如此重要的原因如下:
- 过高的制造成本要求首次成功,因为多次重复可能使其在商业上不可行。
- 随着开发周期中设计的进展,验证成本增加10倍。因此,早期验证将增强首次获得正确SoC设计的信心。
- 由于SoC设计涉及到使用EDA工具对数据库进行一系列转换,因此有必要验证这些转换是否正确实现,这需要通过验证来完成。
02. 验证计划和策略
为了SoC设计的一次成功(当它第一次被制造时,SoC按预期工作),在设计阶段采用许多验证方法是重要的。所使用的不同类型的验证技术是基于仿真的验证、形式验证、时序验证、FPGA验证以及硬件仿真和验证。仿真验证是过去唯一采用的技术。但是随着系统的日益复杂,有必要使用一切可能的方法来验证SoC设计。
很难定义完成设计验证的条件,因为几乎不可能模拟SoC设计的所有设计场景。考虑具有两种状态的单个触发器的设计示例:测试触发器所需的测试模式的数量是4,ARM Cortex M4内核采用65纳米技术,具有65 K个门,这些门可以有多个输入输出。为了简化讨论,假设所有的门只有两种状态,想象一下测试ARM cortex M4内核所需的模式数量,将是65 × 1000 × 4 = 0.26万个图案。仅仅模拟所有这些(不考虑从主要输入-输出访问它们的问题,为它们中的每一个寻找测试模式,等等)在不同的设计阶段实际上是不可能的。
在系统层面,识别所有场景也是非常具有挑战性的。这可能是因为无法预测和可视化用例场景本身,或者可能是因为环境中需要更多的模型或模块来实现它。它可以是完整的软件堆栈,也可以是移植整个设计数据库的硬件平台,或者是用于仿真的计算系统基础设施。因此,需要将可实现的场景定义为验证测试环境和一组测试用例,作为预芯片验证的范围。这可以通过多种方式实现:
- 自上而下的方法
- 自下而上的方法
- 平台级验证
- 系统级或交易级验证(TLV)
自上而下的方法
在这种方法中,SoC从接口层级的最高层开始验证,然后继续到层级的下一个较低层,直到最小的叶级设计元素被验证。传统上,当SoC设计有一个或两个层次时,这种方法被用作验证计划。
自底向上的方法
这是设计验证中最常用的方法。它从验证较小的设计块开始;验证小块是简单而实用的。此外,在块级模拟中,查找错误并修复它们更容易。这是因为在较小的