使用MVTools低功耗验证经验分享

王福君    fujun_wang@panovasic.com

王志宇    wang.zhiyu@synopsys.com

四川虹微技术有限公司

新思科技

摘要

随着SoC芯片的集成度越来越高，功能越来越复杂，其功耗也在不断增大。功耗显然已经成为衡量一颗芯片成功与否的重要标准；而对目标市场定位为便携式电子设备的音视频处理SoC芯片而言，其对功耗的要求则更为严苛。

本文分享了我们使用Synopsys公司的低功耗验证工具MVTools进行低功耗验证的经验，通过对低功耗验证流程中几个阶段工作的把握，发现了低功耗技术实现过程中产生的一些缺陷，确保了芯片成功流片。

ABSTRACT

With the SoC chip’s more and more integrated, its functionality becomes more and more complex, and its power consumption is also growing ceaselessly. Nowadays power consumption has clearly become one of criterions to measure whether a chip is succeeded or not. The audio & video processing SoCs which are targeted at portable electronic devices need much more lower power consumption.

This paper shares the experience using Synopsys’s low-power verification tool – MVTools in certain project. By using MVTools in the several stages of the low-power verification, we found some bugs caused by implementation of low-power technology to ensure the taped-out successfully.

1.0  简介

现在的SoC设计中，功耗问题逐渐成为业界关注的焦点。因为电池技术的发展滞后于半导体技术发展，对于使用电池供电的便携式产品来说，功耗问题带来的影响更大。另外，因为几乎很难在便携式产品上增加散热配件，散热是导致大家关注功耗问题的另一个原因。开发此类芯片时，需在设计之初就对功耗进行合理规划，使用多种低功耗技术来最大程度地降低芯片功耗，延长产品的使用时间，提供产品的竞争力。

在我们的项目中，为了更好地控制功耗，使用较多的低功耗设计技术。第二节对PA_XXX项目做以简单介绍，包括设计中使用的低功耗技术以及复杂的power domain和power sequence，引出低功耗验证中的难点。第三节详细介绍了项目中验证工作面临的挑战。第四节介绍了Synopsys MV Tools工具在低功耗验证方面强大的功能和优势。第五节介绍了如何使用MV Tools对设计进行动态仿真和静态检查。第六节则对低功耗验证中发现的bug做以分析。最后，得出结论并给出一些建议。

2.0  PA_XXX SoC介绍

PA_XXX SoC的是一颗用于便携式设备的高性能、低功耗的多媒体处理芯片，采用CPU+DSP的双核多总线架构，支持多格式视频硬件解码；支持多媒体加速；支持高清电视输出；支持多格式音频解码；支持高品质的视频录制及图像拍摄；支持数据加解密；支持基于SD、USB等大批量数据传输、存储等。图1是PA_XXX SoC的系统结构框图。

图 1 – PA_XXX SoC系统结构框图

由于便携式设备大多采用电池供电，所以芯片对功耗的控制显得尤为重要，如何最大限度地降低芯片的动态静态功耗，延长电池的寿命，是我们设计中的一个重点。

PA_XXX项目中对功耗管理进行了规划，使用了较多的低功耗设计技术，如下描述：

• 
  
• 时钟关断：在系统中有两种实现时钟关断的方式，一种是通过软件配置的方式直接实现，另一种是根据电源域开启关闭与否，用硬件的方式实现时钟关断。
  
• 电源关断：由于存在漏电流，且漏电流产生的功耗较大，我们使用Power gating技术，对长时间不工作的Power Domain进行电源关断，从而降低静态功耗。在设计中，根据power mode来决定某个power domain的开或关。
  
• DVFS：DVFS技术是指根据系统的性能、负载状态动态的调整工作电压和时钟频率，使其工作在最优的频率和电压状态下。其目的是在不影响系统性能的前提下，使系统在要求的时间内以最小的功耗完成某个任务。
  
• Deep Sleep：在一些特殊的场景，包括CPU在内，整个系统处于不工作状态，只留有一个用于唤醒功能的Power Domain或一个模块处于工作状态（如RTC），这种状态我们称为深度睡眠（Deep Sleep）。在进入深度睡眠前，系统需要对当前的工作状态进行备份（包括各个模块的配置信息，时钟频率等），以保证在唤醒后系统恢复到深度睡眠前的场景和工作状态。

同时，根据实际的应用场景考虑，我们将芯片划分了多个power domain（如图2所示），随之衍生出复杂的power mode和power sequence（如图3所示）。

图 2 – PA_XXX SoC Power Domains

图 3 – PA_XXX SoC Power Mode

由图3可以看出，power sequence较多且情况较复杂。我们将常用的合法的power sequence列在表1中，如果穷举所有的可能，则情况更为复杂，具体要根据testcase来制定需要捕获的Power sequence。

表1 PA_XXX SoC Power Sequence

3.0  验证的难度

当设计中引入了多种低功耗技术后，验证工作相应地增加了难度。结合PA_XXX项目，我们认为以下几个方面对验证工作提出了挑战。

• 
  
• 传统的仿真器无法理解电压/功耗的概念。在传统设计中，信号的状态只会固定在1’b0或1’b1，当这样的情况出现在一个多电压域的设计中时，传统的仿真器会让寄存器保持原有的状态，但实际在真实的芯片上，它的状态已经改变，仿真器的结果不能真实的反映芯片工作的真实情况。
  
• Low Power Intent文件检查。为实现上述的低功耗技术，设计中会引入多种Specail Cell，传统的验证方法难以检查Isolation Cell/Level Shifter的摆放位置，难以检查使用Switch Cell后电源的连接，仿真器无法推断出一个Switch Cell，也无法在电源关掉后插入‘Z’或‘X’状态，等等。
  
• Power State检查。传统的验证方法无法检查Power State的正确性。
  
• 电源域唤醒（恢复）功能验证。传统的验证方法无法模拟电源域休眠再唤醒的过程，更无法验证功能的正确性。
  
• Power Sequence捕获。设计中存在着复杂的Power Sequence，传统的验证方法无法判断验证工作已经覆盖到所有的Power sequence。

要解决上述这些问题，唯一的途径是使用下一代的验证工具，它要能够识别功耗设计意图文件（Power Intent）并检查其正确性；可以智能地捕获电源或电压的变化，并根据变化做出相应的反应；可以抓取power sequence信息，并检查power sequence的覆盖情况。

4.0  Synopsys工具的优势

Synopsys公司的MV Tools正是针对低功耗验证开发的专项验证工具，它可以完美解决上面我们提出问题。MV Tools支持完整的基于UPF的低功耗验证流程（见图4）。与其它公司的低功耗验证工具相比，MV Tools在以下几个方面拥有优势：

• 
  
• 支持UPF Flow，可以与整个IC设计流程中的其它EDA工具（如DC、Formality，ICC）无缝的结合；
  
• 解决了新引入的低功耗验证问题，大大加速验证工作；
  
• 大量的成功案例；
  
• 强大的客户群，为工具稳定和改进提供了保障。

图 4 – UPF Flow

5.0  MV Tools的应用

MV Tools工具包括两个部分，即动态仿真工具MVSIM和静态检查工具MVRC。图5为基于UPF的使用MV Tools工具的验证流程。

图 5 – 基于Mvtools和UPF低功耗验证流程

与普通的验证环境相比，低功耗验证环境中的输入内容有所不同。上图蓝色虚线框中的内容为低功耗验证环境中必备内容：

• 
  
• Design：Design为SoC芯片的设计内容，在低功耗验证的不同阶段，内容可能是RTL代码文件或网表文件；
  
• Testbench：测试工作台，在其中调用设计文件，施加测试激励等；
  
• Power Intent：功耗意图文件，在低功耗验证的不同阶段，内容可能是UPF、UPF’或者UPF’’；
  
• Setup File：archpro.ini，Mvtools的初始化文件，其中包括设置 UPF_ON_OFF(state based or value based)，设计库文件的路径和文件，simulation mode (TRANSPARENT/ACCURATE/PROTECED) 等；
  
• LIB：Library文件（库文件），SoC设计中设计到的所有库文件，比如CPU库文件，memory的库文件以及PLL/PHY的库文件等。

低功耗验证流程与设计实现（implementation）流程相对应。无论是使用MVSIM做低功耗仿真，还是使用MVRC做静态检查，低功耗验证流程都会经历三个步骤，即：RTL+UPF阶段，Gate+UPF’阶段和Gate+UPF’’阶段。在后面两个阶段，验证的设计文件和UPF文件来自于设计实现的输出，如图13所示。下面详细说明低功耗的仿真与静态检查。

图 6 – 低功耗验证流程与设计实现流程的对应关系

5.1     使用MVSIM做动态仿真

5.1.1            验证思路

低功耗验证的目的是保证芯片设计在加入低功耗机制后仍然能够正确地工作，并正确实现了定义的低功耗策略，因此，在仿真时，我们将关注以下几个方面：

• 
  
• 时钟关断
  
• 电源关断
  
• DVFS
  
• 睡眠/唤醒功能
  
• Power sequence的捕获及检查

5.1.2            制定Testcase

根据上节的分析，在制定testcase时要覆盖到上面所述的所有情况，同时要覆盖各个Power Domain之间切换，各个电压频率模式切换，以及芯片中各个数据通路。Testcase制定是否合理精炼对验证工作有着重要作用。

5.1.3            MVSIM仿真的基本步骤

从图5我们可以归纳出基于MVSIM的仿真步骤：

1. 
   
2. 产生Multi-Voltage Database；
   
3. 执行制定的Testcase，run simulation；
   
4. Debug design。

5.1.4            Power sequence检查

为了对Power sequence进行捕获和检查，我们在MVSIM的仿真中结合了APF（ArchPro Power Format）文件，下面是一段APF文件的实例代码。在APF文件中，我们会对合法的power sequence进行描述，最终通过对Mvsim图形界面进行数据库分析，就可以判断是否我们关心的power sequence都已经出现。

ClockDef clk;

Sequence LpSeq;

initsection

PA_XXX.statemachine = {

Full= Normal,

(PA_XXX_top.u0_system_top.u0_PD_IP.CDSP_ISO==1)@clk;

Normal= Full,

(PA_XXX_top.u0_system_top.u0_PD_IP.CDSP_ISO==0 && PA_XXX_top.u0_system_top.u0_PD_IP.MDSP_ISO==1)@clk;

Idle= Operation, (PA_XXX_top.u0_system_top.u0_PD_IP.CPU_ISO==0)@clk;

Operation= Backup_Hiberate,

(PA_XXX_top.u0_system_top.u0_PD_IP.VIDEO_ISO==1 && PA_XXX_top.u0_system_top.u0_PD_IP.CPU_ISO==1)@clk;

Sleep= Backup_Hiberate,

(PA_XXX_top.u0_system_top.u0_PD_IP.CPU_ISO==1)@clk

……

};

clk.signal = “PA_XXX.u0_system_top.u0_PD_IP.CLK_SOURCE”;

clk.clocktype = posedge;

LpSeq.voltagestatetable = PA_XXX;

LpSeq.sequences["lp_sq1"]={”Full”,”Operation”,”Sleep”, Operation”};

LpSeq.sequences["lp_sq2"]={”Full”,”Operation”,”Sleep”, “Hiberate”, “Operation”};

LpSeq.sequences["lp_sq3"]={”Full”,”Normal”,”Operation”,”Sleep”, “Backup_Hiberate”,”Operation”};

LpSeq.sequences["lp_sq4"]={”Full”,”Operation”,”Sleep”, “Hiberate”, “Operation”,”Full”};

LpSeq.sequences["lp_sq5"]={”Full”,”Normal”,”Sleep”,”Idle”,Operation”,”Normal”,”Full”};

…..

endinitsection

5.1.5            MVSIM仿真优化

MVSIM通过PLI接口与仿真器进行交互，在VCS中使用VPI（Verilog）和VHPI（VHDL）。通过PLI访问使不少仿真优化选项失效。最典型的是，使用VPI访问设计时会让runtime性能降低。为了得到更高的性能，对回归模式的设置进行了优化，如果启用PLI，对它的性能影响也很大。另一方面，如果在debug模式（全部访问选项都被打开）或仿真时，因为使用了其它的PLI，此时启用PLI访问，对性能的影响不是十分明显。

目前，在MVSIM中提供的是通过PLI对整个设计的访问。设计允许被部分访问，可以通过PLI表文件（.tab）来控制。有时候，并不是设计中所有的模块都需要通过VPI访问。

在这样的情况下，如果测试向量对设计有类似的访问需求（severity and scope），可以先生成pli_learn.tab文件，在仿真时使用该pli_learn.tab文件。操作分两步：第一步+vcs+learn+pli生成learn.tab，第二步+apply+learn应用第一步生成learn.tab。下面是代码示例。

vcs +v2k -l transcript.log -full64 \

-f apdb/ev/cmdfile_1 \

+vpi \

-P ${ARCHPRO_ROOT}/templates/mvsim_vcs.tab \

-load “libmvsim-vcs.so:mvsimInit”

simv +vcs+learn+pli

@rm -rf csrc

vcs +v2k -l transcript.log -full64 \

-f apdb/ev/cmdfile_1 \

+vpi \

+applylearn \

-load “libmvsim-vcs.so:mvsimInit”

多数情况下，下面三种情形可能导致仿真变慢：

(a) 使能强制访问；

(b) 大量调用PLI，强制设置power domain中内部信号为x态；

(c) 装载MVDB库文件消耗了过多的额外内存。

我们下面介绍的dgate模式可以克服上述问题。在archpro.ini文件中进行如下设置可使能该模式：

[MVSIM]

performance_mode = dgate3

当使能这种模式后，在domain的边缘和domain中的某些内部信号上，会使用”disconnect gate”。当这个domain被关闭后，disconnect gate的输出为”X”. 以此”X”态传播，可以对于其他power domain进行corruption。这样可以避免force domain中所有的内容（信号），也可以减少对PLI的调用。

当使用这种模式时，MVSIM运行中使用的access文件已经被从apdb/ev/mvsim_vcs.tab文件中移除了，该文件现在由MVDBGEN产生并优化，生产的文件只会罗列被MVSIM访问的信号名，访问的权限也会降低。

目前，这种模式只能在纯Verilog设计中使用。在UPF_ON_OFF=yes和UPF_ON_OFF=no两种模式下都能使用。但是，使用它还有较多的限制条件，描述如下：

1. 不支持电平有效的retention；

2. 不支持备份功能；

3.不支持VHDL及混合设计

4. Disconnect gates会忽略驱动的strenth.

5. 在power domain的边缘，Inout ports 不能被corrupt.

6.不支持SystemVerilog

7. 如果clock的产生模块在其中一个power domain中，当关闭此电源域，日志文件中会出现不正确的clock wiggling assertion.

5.2     使用MVRC做静态检查

MVRC是一个用于多电压规则检查的静态验证工具，它使用TCL接口，能够对RTL、网表以及带PG（Power-Ground）信息的网表做规则检查。MVRC在使用时同样要先执行mvcmp和mvdbgen，产生Multi-Voltage数据库，然后使用MVRC提供的TCL脚本命令，检查我们关心的内容。在验证过程中，根据MVRC的标准流程，我们完成了如下的工作。

5.2.1            Power Intent Consistency Check（RTL）

Power Intent Consistency Check用于确认UPF文件中基于PST(power state table)的isolation单元和level shifter单元符合规则，实际上就是将PST作为golden的参照标准，去检查UPF和设计是否存在问题。在实际验证过程中，我们使用了如下两条命令对RTL阶段的UPF文件和设计进行检查：

report_protection –critique

report_architecture

5.2.2           Architectural Checks (RTL & Netlist)

Architectural Check用于对从一个关断的电源域输出到一个有效的电源域的信号进行检查，这个（这些）信号可以是穿过关断的电源域的信号，也可以是本身源于这个电源域的信号。在这个阶段，MVRC check不再考虑PST，而是将经过实现后的设计与UPF intent文件进行对照检查。在实际验证过程中，我们使用了下面的命令，当使用这条命令时，Critical functional signals和UPF控制信号会被自动检查。

report_architecture –island_order

如果还希望检查其它信号，则增加-signal命令选项。

report_architecture –island_order –signal <signal_root_pin>

5.2.3           Structural Checks (Netlist)

Structural Checks用于对网表级的isolation单元和level shifter单元相关信息进行检查。常见的问题包括，冗余的level shifter单元，缺失isolation单元或level shifter单元，isolation单元和level shifter单元互换，经isolation单元箝位输出的信号极性错误等。在实际验证过程中，我们使用了下面的命令来检查上述的可能出现的问题。

report_protection –intent

如果需要对power switch单元进行检查，使用下面的命令。

report_power_switch

5.2.4           PG-Netlist checks (PG-Netlist)

在这个阶段，MVRC可以对power switch单元，isolation单元以及level shifter单元的完整性进行验证，检查这些特殊单元是否没有连接，或者是否按照UPF文件的描述正确的连接，实际验证中主要使用如下命令。

report_protection_pg

report_switch_pg

6.0  Bug示例

6.1     Restore Error

在进入深度睡眠模式之后又被唤醒后，VIC（中断控制器）工作异常。经过debug后发现，软件在进入深度睡眠前只对前一个模式中相应的寄存器配置信息进行了备份，并没有对VIC的配置信息进行备份，而VIC在深度睡眠前使用边沿有效，而VIC默认的是电平有效。所以系统在唤醒后，VIC为电平有效，而原来产生的一个中断一直没有清掉，导致VIC看到还有中断就产生了一个irq送给CPU，这是一个错误的行为。

6.2     UPF Error

在UPF的描述中，电源域PER的输出信号RESET_WDT应被isolation cell箝位为0，但文档描述为1，所以导致UPF文件中的RESET_WDT箝位值为1。

6.3     DVFS Error

在某个DVFS的case中有这样的一段操作：“配置CPU core clock和bus clock的比例，由2改为3，再将CPU core clock的分频系数由默认的3改为2”，软件在实际操作过程时，在配置完CPU core clock分频系数后，需要读CLK_LOAD_EN寄存器是否为1，然后在读这个寄存器是否为0（该寄存器为硬件自己清零，但需要几个Clock周期）。但在CPU core clock的分频系数由默认的3改为2后，硬件在CPU执行读CLK_LOAD_EN寄存器是否为1前已经将该寄存器清零，所以程序一直在循环的执行读操作，而无法向下运行，而实际中这样的错误只会出现在CPU core clock的分频系数修改的情况。

6.4     Clock在切换时出现高频时钟

在某个变频的case中，某个时钟在频率切换过程中出现了高频时钟，这是时钟控制单元设计本身的问题。

7.0  结论及建议

在设计中实现低功耗技术后，传统的仿真工具和验证方法已经不能满足需求，我们需要使用新的仿真工具和方法；同时低功耗技术的加入也会引入新的bug，bug的发现又需要新工具和新方法的支持。在项目中，我们使用了Synopsys公司开发的基于UPF流程的MV Tools，发现了传统验证方法无法发现的bug，大大加速了项目的验证，为设计做了充分的保证。

8.0  致谢

感谢余德君、魏丹在低功耗验证工作中的通力合作，感谢徐栋磊、郑元吉、何祥、周磊以及其他同事的大力协助和支持。另外，还要感谢Synopsys工程师王志宇，他为我们的低功耗验证工作提出了很多宝贵的意见和建议，给予了我们极大的支持和帮助。

转自：http://www.synopsys.com.cn/information/snug/2010/low-power-verification-experience-using-mvtools