断言的难题

能够很好的证明和普遍同意,断言设计和验证团队可以提供巨大的好处,减少甚至消除调试,但其使用仍不无处不在。

的部分原因是,断言不能随便捡起,验证主管大卫•拉森指出突触的设计。“这是因为断言语法不是简单的比行为代码和断言的行为也不同。行为代码由一系列指令,执行一个接一个,而断言包含任何指令,而是指定目的信号行为有自己的一套符号。他们还积极。”

此外,他说,断言是很难学习,很难写,很难调试。他们肯定是有价值和值得学习,但大多数工程师不愿意花时间学习如此深奥的东西。在SystemVerilog家庭的功能,断言丑陋的表妹。

Hemendra Talesara,验证技术专家在突触设计指出,尽管使用断言越来越多,他们仍然发现很多项目,他们不习惯。“这是特别痛苦的,当一个人实现了巨大的生产力获得通过使用它们。考虑到调试是一个瓶颈在所有验证tasks-assertions可以完全消除调试和诊断时间在很多情况下。他们就像一个监督机构寻找任何违规行为的设计。他们国旗问题源头,抓住问题,否则会被错过了。断言在集成的一个块和帮助检查知识产权下一个级别的层次结构,通过最小化集成支持的必要性。写在声明性样式,断言提供额外的文档。设计师的节省时间和精力需要写很多倍。”

那么,为什么不是每个人都使用它吗?

他建议几个简单的技术原因。”对于那些在过去没有使用断言,语法和应用可能是复杂的。其次,他们总是不知道从哪里开始。虽然可以编写更复杂的断言和跳棋对于复杂的协议,只是开始使用简单的断言可以使一个人的生活很简单。”

断言SystemVerilog语言的一部分,Talesara说,这意味着不需要额外的工具使用断言在基于仿真的验证。一些培训是必需的。然而,一旦一个工程师熟悉写断言,这个过程并不比写其他更复杂的代码。对于许多简单的断言,它可以像写注释的代码一样简单。还可以开发一个简单的图书馆断言作为方法论的一部分。大多数供应商工具有一个预定义的断言图书馆要求工程师学习如何实例化它。

只是为了演示它的简单,他提出两个例子的断言。第一个抓住了一个非常简单的行为,而第二个只是稍微复杂。“一旦你习惯了符号和语法,很容易写。声明式和接近规范,需要很少的代码来表达它比如果你有Verilog编写它。”

“通常避免使用断言一个工程师的原因是缺乏熟悉和/或时间来学习如何创建和使用断言。管理没有坚持的原因是,他们还没有完全掌握了巨大的成本效益。团队需要理解,开始是很容易的。帕累托定律(80/20规则)适用。你不需要走极端试图实施复杂的断言。简单的断言与简单的准则是容易学,容易应用和有大的回报,”Talesara补充道。

断言的进化
产品管理主管皮特•荷迪节奏回忆道,当断言是第一次怀孕,开始先介绍-产权规范语言后来SystemVerilog断言——他们的想法是,设计师会使用它们。“设计师会写断言,因为他们有自我记录的设计和它的优势将是一个简单的方法为设计者有效地完成模块的单元测试之后再把他们集成,进一步验证。的作品,很多人纠结,因为使用模型并没有真正流行起来。”

“那么你必须验证团队带头创建断言的,”他继续说。“这是当你开始看到一些形式验证专家出现,其余的大部分的验证工程师继续从直接测试约束随机但基本上坚持testbenches和仿真”。

推动节奏,验证应用程序开始来到地上,荷迪说,“如何为一个特定的自动化验证已知的和良好的验证问题。成为应用于诸如连接验证。高层与模拟连接是乏味的,您可以很容易地编写断言;断言可以为您自动创建验证应用程序从一个高级连接规范。这样的方式,我们已经申请正式的验证来绕过这个问题,人们真的不喜欢写断言,或者只有一个子集的专家真的会写很多断言。”

迈克尔•Sanie验证营销高级总监Synopsys对此接受问题参数用来对付断言他们是困难的。“很多困难已经消失。它是一种标准SystemVerilog的一部分。技术上来说,这并不是说困难。将更难以编写一个地产正式检查,是一样的,但方式不同。如果您定义一个属性模型检测工具,正式的工具可以调试,找出错误。你会做同样的努力也许更多的如果你写一个模型或属性而非断言。”

他观察到,许多工程经理想要写断言他们的团队。“他们想分配一些时间和花费一些精力来开发断言,因为它能缓解压力。但是如果你带下来的人发展RTL,这不是他最喜欢的事情。就是这么简单…断言写作就像服用维生素——它不好吃,但它不是那么糟糕。你仍然可以往下咽。但它确实照顾很多以后的麻烦。这是一个良好实践。”

Sanie指出,虽然有技术为理念的断言,这些技术的问题是,它给了一大堆的想法却给了大量的假阳性。“有些技术——我们致力于一些——带来一些正式的知识。它试图更好地理解设计当它提供这些候选人(断言)他们都好。大部分现在没有人可以真的帮助他们,最大的问题是它post-factum。你不能拿走的。如果你可以做到,而你做设计的更好。”

真正推动事情的发展,他强调说,将会有一个相结合的技术和方法,这是非常轻。“断言的方法和改进形式验证——有很多机会改进设计方法。正确的方法不仅使和方便设计师写断言还必须提供正式的技术使用尽可能早的设计师,因为它是同样的想法。这是不同的工具使用。一个是写断言,一个是关于使用他们,但有一个方法的概念设计团队力量尽可能早地开始寻找bug。这将会改变人们做验证的方式。事实上,这是发生在我们讲话。人们意识到他们需要更正式。断言可能仍然是一种痛苦,但他们仍然至少关注它,他们写出来,代码审查,多做静态和正式检查前,因为重要的是尽早赶上这些bug。早些时候你发现一个错误并修复它,越便宜。”

哈里·福斯特首席科学家验证导师图形有自己的承担为什么那么多工程师可能不愿接纳断言。

“仍有怀疑的ROI,”他说。“很多人认为有很多的努力,但还没试过。那些常常尝试做一种特别的方式,产生很少的结果。”

第二个原因是有一个过程的缺乏了解。“谁是利益相关者?谁写断言?他们占了测试计划或不呢?人们不知道这些类型的基本东西,因为如果你仔细想想,EDA公司通常促进工具和语言。他们不促进过程,很多人都困惑于如何做到这一点,”福斯特继续说道。

断言惊恐的第三个方面,他说,很多组织缺乏建筑技巧需要利用它。“这是基础,因为它超越教学有人断言语言:它会有效地你把断言,等。有多个同行评议的行业研究——不是EDA——尊敬的会议,发现团队断言添加到设计有更少的错误。这是很重要的,因为如果你仔细想想,你能做什么来防止错误与发现他们提高生产力。”

这要追溯到很多团队缺乏投资——回到关于ROI的他们不清楚所以他们不建立必要的技能在组织内。

“断言让工程师考虑的设计以不同的方式比他们实际实现的方式设计和思维过程发现bug,他们通常不会考虑,”他补充道。

巧合的是,导师图形发布了一个工具本周,福斯特说自动生成断言通过分析模拟痕迹,对于那些不想写。

采用宽松的路径断言
禁止统一授权管理,没有任何东西会采用/学习写断言容易吗?

突触的拉森指出,采用断言的困难之一是,可以没有断言验证。“程序代码可以做任何断言,尽管用更少的优雅和力量,所以很少有团队看到需要加入断言潮流。”

他还说,断言有相同的障碍constrained-random交叉,coverage-driven验证过,这是一个全行业的觉醒到他们如何可以用来达到充分验证的终点线更快和更少的努力。

此外,它将断言更容易被采纳,如果使用它们解决的困难。一种方法是让他们更容易理解和调试。一个强大的断言调试器可以很长一段路要解决这个困难。节奏,导师图形和Synopsys对此都有断言调试器调试工具,拉尔森总结道。

额外的资源
免费的课程assertion-based验证和其他话题。