验证一个片上系统（SOC）的复位方案是非常重要的用以确保器件可以从任何情况下被复位到正常状态。现在，随着许多IP模块被集成在一个SOC中，复位方案可能就变得非常复杂，即使引入了电源管理设计，这个问题仍然是很复杂的。这对于验证一个SOC系统的复位方案来说是一个重大的挑战。

在低功耗设计中上电复位（POR）失败是一个经常被发现的问题。一旦这个问题被发现在真正的芯片上，唯一解决这个问题的办法是禁用电源门控，但这会造成巨大的功耗性能降级。解决这个问题的另一种方法是重新流片（respinning）。然而，无论哪种方式都是痛苦的。因此，我们提出一种自动化的解决方案用于提取的POR（Power-on Reset）断言，然后在功率控制仿真中去识所有没有被复位的寄存器。采用这种解决方案，我们可以在早期的RTL（Register Transfer Level）仿真中使用提取POR断言发现许多真实的POR失败。下面就分为五部分进行叙述。

一：简介

电源管理设计由于延长了电池寿命，对于移动设备是必不可少的。先进的低功耗设计技术，例如功率门控，在实现显著降低功耗的同时，还引入显著设计和实现复杂性。因此，低功耗设计如果没有被正确的验证的话将具有很高的风险。然而，传统的功能验证没有考虑到设计的功耗意图（被定义为UPF技术），而且在验过程中，功能验证不能覆盖到设计的电源管理方面的存在的问题。因此，低功率验证在低功耗SoC设计中起着重要的作用。低功耗验证能够验证覆盖到上电复位（POR）的序列，这包括了电源模式切换、不同场景下IP模块和电源域被的开启关闭。此外，低功耗验证计划也应包括产生用于检查各种控制信号的断言。对于验证人员来说，潜在目标是电源控制序列、门控时钟逻辑、以及上电后进行复位等等。

对于所有的SoC系统设计来说POR是一种关键的功能序列。POR被期望能够让系统从任何状态回到正常状态。对于最终真正的芯片来说，任何未被发现的POR缺陷都可导致严重的灾难。在RTL/GL 仿真过程中，复位逻辑的复杂性将会给验证工程师带来挑战。而且随着上电复位逻辑的复杂性的不断增加，SOC系统的规模和设计的的复杂性也在不断的增加。导致复位逻辑复杂性不断增加的因素总结如下：

1. 通常有一些全局复位的来源，诸如上电复位，硬件复位，软件复位，并门狗定时器复位。

2. 集成在SoC系统中的IP模块数目不断增加。

3. 在不同的IP模块中复位策略可能会有所不同（同步复位，异步复位，基于扫描复位，部分复位，完全复位，或不可复位的触发器）。

4. SoC中的复位控制器逻辑必须满足所有数字模块，模拟模块以及PLL（Phase Locked Loop）模块复位的要求。

5. 由于通过SoC  Pads提供的值被配置成各种各样的操作模式，这进一步增加了设计的复杂性。

6. 由于要针对不同的应用情况下，被定义的复杂的电源模式以及相互之间的转换将会导致另一个设计上的复杂性。

7. 当保持寄存器（retention）被引入时，复位方案可能会变得更加复杂。

在资源和SoC系统中的执行处理时间都受限的情况下，对于验证来说复位逻辑的复杂性引起了各种各样新的挑战，主要的验证挑战列举如下：

1. SoC系统的复位序列生成用于不同的模块的复位信号。接下来这个序列应该确保所有的模块可以被返回到一个正常的状态。因此，验证需要去确保不同模块的工作模式之间的各种组合被覆盖和检查。

2. 在POR采样逻辑中使用不可复位的触发器，由于未初始化触发器，可能在RTL和GLS仿真过程中会导致X未知态的传播。因此，为了验证像这样的触发器，我们必须使用force/deposite with defined/random values去初始化它们在复位时刻让仿真去处理。

3. 基于来自于pad的值所支持的各种各样的功能配置需要被彻底验证。不同的覆盖所有模式的功能场景需要在SoC系统级被运行去确保所有的配置都能按照预期的去工作。

4. 顶层的复位信号应该被连接到设计中的所有可复位触发器上，也即当全局复位信号被断言时，设计当中的所有可复位触发器都应该被复位。事实上，一个缺失的复位连接或者复位信号在不同的电源域之间传播过程中被阻塞都能够很容易造成漏检。

目前，大多数为复位验证所提出的工作都集中在连接性检查。然而在一个低功耗设计中POR失败的最根本原因是多种多样的，其中有些是“静态”的而且通过检查设计的结构可以被捕获到，但有一些是“动态”的，而且只能在功耗控制仿真过程中被捕获。因此，我们提出了一种自动化解决方案为了提取的POR断言以确定在功率控制仿真中所有没有复位的寄存器。采用该解决方案，通过使用被提取的POR断言我们可以在早期RTL仿真发现许多POR的潜在问题。

二：下面就MTK和Synopsys在之前的复位验证方法上作如下比较

其中在上图中联发科技提出的复位验证方法是Global Reset Assertion + Formal Techniques, synopsys提出的复位验证方法是Power-on Reset Assertions + Power-aware Simulation。

对于SOC复位方方案，形式验证技术的优势是它能穷彻底地检测所有可能的情况，但是对于复位验证来说，形式验证方法关注的是静态和结构的检查，形式验证技术在描述动态功耗控制序列时能力有限而且在验证过程中不能包括软件和固件，除此之外，现在的大多数形式验证工具都是不能进行功耗控制。设计的复杂性的限制也限制了形式验证需要降低颗粒度到更小的域去做检查。为了克服这些形式验证技术的不足，Synopsys提出的解决方案是在基于UPF的功耗仿真中采用POR断言。

三：工具流程和结果

图1描述了synopsys提出的解决方案的流程图：

该流程中有验证平台（Testbench）、RTL code、UPF code以及软件和固件。其中Testbench 结合软件和固件带着不同的资源和条件去仿真POR；RTL Code是为了提取POR断言；UPF code是为了开启这个功耗控制仿真并且为POR断言启动触发事件去做相应的检查。对于工具来说其流程可以总结为三步：

1. 解析和编译所有输入的源代码
   在这一步当中将会通过预先定义好的coding style去自动提取POR断言并且使用异步置位复位甚至将两者相结合将其绑定到寄存器上。下面是三种预先定义好的代码风格。

2. 用之前提取的POR断言做功耗控制仿真
   在这种情况下软件和固件将会联合在一起用不同的低功耗场景和复位场景去仿真设计，并且仿真器将去触发断言进行检查。最终，等待仿真结束，失败的断言将会在仿真log文件中被显示出来用于检查。

VCS NLP这种解决方案可以捕获POR在功耗仿真中的问题，通过分析和识别编码风格，POR断言是自动生成并绑定到寄存器，以检查他们是否可以在从新上电后正确复位。

通过与设计和验证团队讨论后，得出了3种复位场景如图3所示。这3个复位场景可以覆盖我们的设计的所有复位行为。以下是定义的Tmax和Twidth:

1. Tmax：上电之后，复位应该在Tmax

2. Twidth：上电之后，复位应该至少在Twidth个时间单位内被保持。

为了打开POR断言，用户需要给VCS添加一个编译选项如图4所示：

并且在UPF中使用set_design_attributes对Tmax和Twidth按照如图5所示的方式进行设置：

为了整个设计的所有断言，Tmax和Twidth的延迟值作为数据包的参数（全局）被传播整，然后，在功耗仿真中当Tmax或Twidth违例时，那么你将能够在图6和图7中可以看到相应的警告信息。并且SNPS_active_reset_duration（即Tmax）和SNPS_inactive_reset_duration（Twidth）的值会作为部分断言信息。

采用该解决方案，我们在设计中发现真正的缺陷，且这个设计已经被我们之前的形式验证技术所验证过了，这正好证明了我们所提出的方案可以克服形式验证技术中的缺点。

四：对于工具带来的挑战

在复位断言即使的要求下，工具需要去鉴别每一个本地时钟和复位信号为设计中的每一个时序逻辑，并且Tmax和Twidth必须的检查需要在上电时候被触发执行。如果在上电的时候复位信号已经在一个被断言到的状态下，那么仅仅需要对Twidth去检查；如果在上电的时候复位信号没有在一个被断言的状态下的话，那么接下来一旦复位信号被断言到的话，首先对Tmax进行检查紧随其后在对Twidth进行检查。

五：结论

在本文中，我们提出了一种在功耗仿真中自动提取POR断言去发现所有没有复位的寄存器的解决方案，并且该解决方案已被部署到多个项目中，且已被证明是能够克服形式验证在技术上的不足之处，因为该方法可以捕获那些形式验证中被遗漏的设计缺陷。根据从项目执行过程中的经验，我们发现，在功耗控制仿真中相比于传统的静态验证解决方案，POR断言验证解决方案是一种全面综合的验证解决方案。综上所述，使用自动化产生断言的低功耗仿真中去验证POR逻辑可以给设计团队带来好处同时还可以大大提高验证结果的可信度。

Automation of Power On Reset Assertion.pdf(347 KB)