注册 登录
ET创芯网论坛(EETOP) 返回首页

路科验证的个人空间 http://blog.eetop.cn/?1561828 [收藏] [复制] [分享] [RSS]

日志

当前的功耗验证为什么让人不满意?

已有 323 次阅读2018-12-1 22:54 |个人分类:验证前沿资讯|系统分类:芯片设计

rockeric.com

功能验证持续发展,但功耗验证,作为一种新的关注点,仍处于30年前功能验证所处的困境。那么,功耗验证何时能够赶上如今功能验证的脚步,且需要采取哪些措施才能实现呢?这是业界仍在努力解决的问题,然而并非所有人认为这些问题需要答案。

                 



功能层面所产生的错误会危害操作的正确性甚至安全性,而功耗漏洞在大多数情况下只会导致效率低下。当然,也并非仅仅只是效率低下,有些功耗漏洞可能导致产品故障加速老化。对于某些行业而言,低效率甚至会导致设备的宕机。


虽然移动设备行业在功耗分析方面处于领先地位,但它已经不再是高功耗所导致损失最大的行业了。

 

验证是比较对于同一事物的两个独立派生的描述,以找出它们的不同之处。而功耗验证却需要一个次要模型(second model),它定义了对于任何给定操作,其相对应的功耗应该是怎样的。到目前为止,业界还不存在这样的模型。

 

单一类型的功耗漏洞也同样不存在,但是存在一些常见的功耗漏洞所带来的影响

功耗优化或错误定义的功耗控制电路所产生的功能错误

电流尖峰或电流快速变化引起的故障

•由于老化或过度使用储存电荷而导致的故障

•产生无效结果的冗余活动

当然影响远不止这些,不同类型的漏洞具有不同的重要级别,具体取决于最终应用程序。

 

UltraSoC首席执行官鲁珀特·贝恩斯(Rupert Baines)描述了一个典型的功耗困境。 “系统中的哪些元素可以在不影响性能的情况下进入睡眠状态?你怎么才能知道它进入睡眠状态?就像海森堡原理一样,在检查某些东西是否处于睡眠状态时,这个时候你检查的这个行为就会把它唤醒。即使开发人员认为系统运行正常,但在使用嵌入式分析IP检测时,却可能会发现待测模块根本不会进入睡眠状态,那是因为无论这些模块初始状态如何,它们的睡眠状态都会由于过多的系统检测而被打断

 

功耗优化也会产生问题。“关于功耗问题是如何产生的,时钟门控就是一个很好的示例,”OskiTechnology应用工程部的副总裁Roger Sabbagh说。“当某特定寄存器的参数值没有更新或是下游逻辑不会使用更新后的参数值时,时钟门控就会通过关闭该特定寄存器的时钟来降低开关功耗。但是,在某些特殊情况下,对于一个设计来说正确的操作应该是开启时钟然而时钟门控却将其关闭了,那么这个时候就会出现错误。时序电路等价验证(SEC)可以通过检测初始设计和带有时钟门控的设计在行为上的不同来发现这些特殊情况下的错误。

 

在该示例中是存在次要模型(second model )的,但是在大多数情况下,没有什么东西能与功耗行为进行比较,因此必须使用其他度量指标。“要考虑功耗分析的起点,”Cadence公司Digital& Signoff Group的产品管理总监Rob Knoth这样说到,“假设每个线路光切换状态就要花费50%的时间,然后才检查功耗,这会让人非常悲观,放在今天你是不可能流片出来的。有这样一种改进方法是假使一定数量的时钟线路上的状态切换从数据线路中分离出来,这样会更好一点。当然你也可以通过改变活动因子来让一个电路处于空闲或是忙碌状态,但这样效果就没那么好。功耗已然成为对抗生命周期的一个权衡对象。你必须在流片之前准确设计和验证流程,否则你就得不到最后的成品。”

 

其他度量指标正在不断演变。“考虑时钟门控效率,”ANSYS产品管理总监Preeti Gupta说,“给定一个空闲模式矢量或活动模式矢量,亦或是一个持续的最坏情况功率矢量,并且计算出设计中每个寄存器的时钟门控效率。对于一个寄存器,你可以把它的数据信号,时钟信号和控制信号作为矢量。我可以通过观察控制信号并找出它关断了多少个时钟周期,但是当时钟没有关断且数据没有变化时会发生什么呢?观察报告可能会显示你是否在设计中内置了足够的逻辑来协助综合识别应该进行时钟门控的寄存器。那些确定的控制逻辑关断每个模块的频率如何?而我是否有控制权,效果又如何呢?现在我们不妨谈谈控制信号的能力,设计团队可以在寄存器或逻辑框架基础上对冗余的行为进行描述和量化。”

 

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

关闭

站长推荐上一条 /2 下一条

小黑屋|手机版|Archiver|ET创芯网 ( 京ICP备:10050787号 京公网安备:110105001212 )

GMT+8, 2019-4-26 22:35 , Processed in 0.027784 second(s), 9 queries , Redis On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

返回顶部