快速仿真帮助调试效率吗?

它很好当记者设法获得独家新闻的世纪,这是午餐小组主办的情况节奏在最近的设计和验证会议(DVCon)在圣克拉拉,CA。布莱恩•贝利半导体工程师、技术编辑面板和打破了新闻的主持人人群。节奏已经开发了一种逻辑模拟器这是数量级的速度比什么都快。一些观众都感兴趣。当时与会者宣布它是一个免费的赠品,更多的人感兴趣,以及一些节奏高管。

当然,没有这样的产品存在,但它被用来证明解决流的一部分,没有处理整个流程,并不一定产生预期收益。超快,免费模拟器可能会发现bug更快,但是现在的瓶颈被移动,因为虫率将大于的速度分析和固定。因此,问题已经动摇。

“掌握验证和调试效率”的小组成员John Goodenough,工程系统副总裁手臂;大卫·莱西验证科学家惠普(hewlett - packard);Normando Montecillo副技术总监博通公司产品营销,弗兰克•Schirrmeister组主任节奏的系统开发套件。下面摘录,面板。

Montecillo:在博通,正式的团队在进度压缩发挥了巨大的作用,它是关于早期错误检测和高质量的交付RTL。我们希望能够尽快开始探索设计RTL编码。在调试我们尝试匹配的挑战与合适的工具(模拟或正式),这简化了验证的任务。正式与角落也帮助情况下,定位错误的根源,然后检查修复没有副作用。

前言:我们需要在调试是双重的。首先,我们需要减少之间的延迟发现问题并解决它。这是指获得迅速的合适人选的问题,这样就可以将固定的。第二,调试后,如何确保你不要再犯同样的错误。

莱西:我们最大的挑战是提高我们的工程师的生产力,这当然也适用于调试。我们采用的方法,如UVM- e,但周围有挑战调试维护遗留IP等融合两种方法。有多语言挑战和如何执行调试混合环境。我们也有一个新的关注混合信号验证,以及如何把知识的建模和模拟调试验证团队,只有数字处理技术。

Schirrmeister:我们看到三个趋势在调试和验证。首先是能够重用的能力验证的知识产权芯片级的子系统。二是在引擎能够执行验证,包括静态和动态引擎,虚拟的平台在模拟器上,RTL执行,模拟或FPGA。三是跨学科的重用。系统已经变得如此复杂,你需要许多专家互动——硬件、软件、电源等。

SE:是设计或调试验证更加困难?

前言:它们是同样困难。问题是,你把很多人的IP这可以来自不同的人,不同的公司和不同的地域。这是一个知识管理问题。你需要能够共享上下文信息从一个人到另一个地方。

Schirrmeister:位于testbench多达50%的bug。我得写场景,用例一直到他们在块级可能意味着什么。这就是为什么重用,包括验证重用,是如此重要。

莱西:在不同的领域有不同的挑战,这些都是解决不同类型的工具。我更熟悉的工具在验证方面,他们正在迅速推进。当我看着RTL设计师,他们更多的“老学校”和调试技术往往是不那么复杂的。

Montecillo:我的团队集中于验证块级别的,所以对于我们来说,我们可以使一个更好的质量RTL早开始。我们的目标是提供最优质的RTL我们可以到系统级的家伙。

SE:什么样的问题可以提前部署正式的检测?

Montecillo:我们发现架构和实现问题。这些同样的问题将在模拟发现,但我们可以找到他们在早期阶段更快了。如果你看错误的成本,当错误捕获后,这只虫子的成本增加。

SE:正式被用于模拟错过了发现问题。现在是在仿真开始发现bug。

Montecillo:没错。“左移位”项目之一,我们部署。我们想让设计团队部署正式的技术。

前言:有一个正式的使用模型与验证——它是关于使用正式的工具来支持更好的质量设计。它是错误的验证和确认工程师这样做时,设计团队可以避免完全通过使用正式的问题。另一个使用模型是寻找bug。我们没有成功当我们正式的验证问题。我们成功了正式的一个设计问题。我们有巨大的成功在左移位通过执行好的设计实践正式的部署。

Schirrmeister:许多问题发现在顶层互连。正式被注销,说它没有规模,但它已经长大了,这个问题比模拟尺度。

SE:什么样的工具帮错误分类吗?

前言:有多重性的技术。一个例子是促进断言从块到系统级。如果你发现一个问题在集成级别,男人做调试可能一无所知。可以通过给他们提供当地的上下文信息发生在设计和一些系统上下文。促进断言,促进性能计数器,使用抽象——不要做一个软件的家伙看波形,给他访问事务级可能意味着更多的对他的信息。

Schirrmeister:人类的大脑并不理解所有方面从软件到硬件的混合信号。作为一个供应商,我们试图提供正确的窗口到正在发生的事情。

莱西:在谈到分流和调试,我们看看自动化。团队可能一夜之间运行10000 - 15000测试。如果你有一个失败率达到1%,这是100例,让我们看一看。我们有一个脚本,自动重播失败测试提供更多的调试信息。工程师可以立即深入研究的问题。

Montecillo:正式的人们喜欢调试,因为它是很容易的。我们没有模拟的问题,他们要看长仿真跟踪和试图找到问题的根源。我们通常处理的周期,因此,寻找根本原因是容易得多。

前言:当你达到一定级别后测圆法的复杂性的连续路径的深度,你打爆炸和反例生成变得具有挑战性。

Montecillo:当你使用抽象,分区和其他技术。但是如果问题太大,我们可能会应用仿真任务。

观众提问:我相信你得到你测量。有没有人有任何想法如何衡量生产力相关的调试?

莱西:我们没有任何正式的指标,但我们有一个觉得事情的类型有所不同。搬到UVM调试增强剂。我们现在有一致性的所有组件,这意味着我可以去帮助别人调试一个组件,我知道如何绕过他们的代码。

前言:我们测量时间根源分析。我们不适用这个均匀;而不是集中在大的问题。我们也从目击跟踪次分流。但是有文化问题。工程师是聪明的人,他们讨厌不可信。你必须证明指标可以增强而不是被视为一个约束措施。所以真正的障碍不是什么指标,但是如何部署它们。不完整的数据集是很容易过早下结论。从生产力指标签署指标是非常不同的。

莱西:工程师知道使他们最痛苦。他们知道需要最长的,感觉浪费时间。这是我们关注的焦点,努力增加更多的自动化。

观众提问:为什么我们不能专注于问题的根源和不太可能bug会注入。

莱西:我们已经开始使用一些更复杂的特点SystemVerilog这样我们不需要重复的代码。我们使用代码评审减少bug和提供反馈给年轻的工程师。

Schirrmeister:提高抽象层次和使用高水平的合成意味着有不同的方面,你可以比你之前的验证。

前言:第一步是确保你有良好的RTL编码标准执行它。但这并不是真正的问题。这是未知的未知的问题。

观众提问:正式允许您验证很多事情没有刺激,但正式处理复杂性的限制。

Montecillo我们使用各种技术,如分区,抽象。这些关键步骤你必须做正式使用。

莱西:你不要把整个芯片和把它在模拟。你把它分成小块,专注于设计的小块。正式的没有什么不同,当你有一个大问题。

Montecillo:你可以移动之间的代码块。一个检查程序一块变成了约束在另一个块的输入。所以即使我分区块成小块,我也创造了为验证它适合的块。

前言:正式不是免费的午餐。相同数量的工作写正式的环境,因为它是编写约束随机的。它可以说是更加结构化的这意味着稍微不那么容易糟糕的编码习惯。你最终是有限的功能设计和验证工程师。

观众提问:Testbench启动太慢了。你怎么处理这个?

莱西:我们知道当事情将会做好准备,并确保他们对齐。与移动UVM很快我们可以有一个初始验证环境。我们已经从在一两个星期有一些东西在一天的大部分地区我们的环境。这部分是因为的重用,但即使对于新的环境,我们有模板,所以更结构化的环境确实是有帮助的。

前言:开始使用正式和规范testbench架构。

Montecillo:如果你的设计团队是一个testbench坐在那里等待,然后使用正式的可视化设计。你不需要约束或跳棋,就定义一个场景和要求的工具让你跟踪。一旦创建了一个跟踪可以操纵它,开始问问题。你有能力去探索设计之前你有testbench。

观众提问:我们可以养几个模拟许可证?我们不能正式的工具。

莱西:我们从工程师说,事情太痛苦,想要一个更好的方式去做。他们开始使用他们喜欢的脚本语言和想出了一个解决方案。

Montecillo:首先招聘高质量工程师。他们创造更少的错误。也有一个好的方法是很重要的。

SE:如果有一个额外的工具,它将帮助,那是什么?

前言:当你得到一个失败,一个自动数据手册会弹出相关的规格为每个页面所涉及的IPs和系统规范和指导你正确的路线。

Montecillo今天我们真正想要的:有两个工具。第一个是过度约束分析工具和第二个是连续的深度分析工具。

莱西:我最大的项目是现有调试功能在所有工作工具,多语言或混合信号。

Schirrmeister:很容易生成tb的数据但是能够理解这个的数据量是很困难的。这是我们需要解决的问题。