得到正式的关于调试

虽然大部分的设计和验证流自动化,调试仍是问题儿童。违抗自动化,提出了一种管理噩梦由于过程的可变性。在最近的文章调试,我们研究开发团队花多少时间在调试过程的部分原因是成为一个更大的问题。这包括海外扩张等问题成为一个纯粹的功能性问题到其他领域,如性能、权力和安全。

另一个最近的文章了扩大范围的调试。这不再仅仅是一个硬件功能的问题,今天和调试有多个利益相关者,所有这些可能需要不同的数据,不同形式的可视化和不同的分析工具。

在本文中,我们将调查的方式正式的技术越来越交织在一起的调试过程中,调试自动化的原因失败的过去,和一些新的发展可能带来更多的控制下的问题。

调试和正式
正式的技术在很多方面可以帮助调试过程。“正式可以提供巨大的生产力飞跃,使你看到一个问题在一个波形,然后得到正式的工具来生成一个波形的例子,”Frank Schirrmeister说高级主管的产品营销系统和软件实现小组节奏。“那么你可以假定场景。”

即使你有一个跟踪,它可能不是非常有用的。“正式的分析可以描述失败的反例与最短路径失败,”戴夫·帕里说,首席运营官Oski技术。“结果,设计或验证工程师可以看到不当行为最简单和最直接的形式,与失败的事件主要集中在少量的周期。这是代替涉水通过成千上万的仿真周期的事件传遍导致失败。”

但是,如果你不知道问题在哪里吗?“正式是很有价值的重建和精炼错误条件部分错误数据和有限的能见度到信号,和尝试不同的场景,”戴夫Kelf说,负责营销的副总裁OneSpin解决方案。“本质上,验证工程师承担一些错误条件,假定已知或怀疑一些事情,可以问工具如何发生。能够启动分析部分指定状态的设计是正式的大优势。”

的结合模拟和正式工作在串联导致了一系列的解决方案。“完整的解决方案在某些情况下是一个静态语义,static-formal和仿真方法,“Pranav莎说,首席技术官真正的意图。“即使错误最终在模拟,发现静态分析方法会创建testbench仪表的监测和刺激一代的post-failure-detection调试过程更直接和集中”。

莎可以使用提供了一个相关的例子。”最后一点是一个很好的例子X验证,这是验证的模拟X值。预付一笔静态分析能够仪器检测X-optimism testbench, X-pessimism和X传播模拟期间,所以,如果一个大户失败是在仿真中发现,找到根源就容易得多了。”

Oski帕里提供了另一种方式,这种能力被利用。“今天的正式工具能够跟踪的具体线的识别问题RTL代码,导致失败。使用assertion-based验证知识产权定义良好的接口,一个工程师可以各个击破的更复杂的调试问题。他们可以把正式的刺激的约束和跳棋在简单的块级别使用模拟断言在更复杂的子系统或系统水平减少时间在调试时失败。这提供了更详细的了解失败的根源。”

发现的问题在模拟也可以变成正式的问题。在系统级仿真,发现“错误模拟可以复制或发布硅在正式环境中通过调整约束和/或检查的块级正式testbench并重新运行它,”帕里仍在继续。“这节省工程师试图复制长,复杂输入/事件序列的块或单位级仿真模型可以准确模拟系统级的行为。”

进一步使用正式之一是陷阱等结构性问题类型的数组的访问。”在这种情况下,该工具可以检查的操作设计,看看一个不正确的数组访问尝试,立即突显出问题,“Kelf说。“同样,零划分等问题,并行的情况下,和其他可辨认的问题导致设计错误。”

早期调试自动化的尝试
有许多在过去试图把自动化软件调试过程的某些方面。许多软件公司使用分流过程失败在一夜之间从运行自动分析和运到他们相信的人是负责创建一个错误。但这有很大的局限性,当应用于硬件交互水平的增加和并发性。“在复杂系统,潜在缺陷的数量是无限的,”补充说,首席技术官超音速。“仅仅因为我改变了一些并不意味着我负责创建缺陷。我可能只是激活一个角落里,以前从未被执行。”

一些失败的企业集成形式分析到调试过程中为了获取用户接近问题的根源。“这些解决方案是严重依赖正式的技术问题扩展,”哈利福斯特说,首席科学家验证导师图形。“另一个问题是,技术很好,如果他们包含断言,但整个行业还没有得到。没有断言,你会进入语法检查代码,以确定是什么。有技术障碍和方法论的障碍,他们遇到了。”

他们中的一些人可能会一直领先于技术曲线本身。“早期的尝试这工作好使用时由专家在形式方面,”Michael Sanie指出市场验证小组的高级主管Synopsys对此。“很多调试自动化公司失踪的关键引擎。今天,正式获得采用混合在仿真时,这真正增加价值的过程。仿真引擎的结合和正式技术扩大了调试功能。”

根本原因分析将是一个非常有价值的工具,任何开发团队技术可能是先进的。“我们认为,还有更多可以使用正式的在这一领域,完成“Kelf说。“一种方法可以采取可能的故障源的列表,然后使用正式的消除虚假来源精确描述真正的问题。”

虽然一些公司可能不会添加断言在一般意义上,验证IP和专门的断言是帮助解决一系列的问题。“我们鼓励我们的客户能够实例化性能监视工具和硬件到目标网络的跟踪功能,“Wingard说。“然后我们拥有丰富的过滤算法,可以接受触发系统的其他部分,从交通流检测触发点过去的目标和测量带宽和延迟。它可以定期报告这些计数器的值一些内存或做硬件跟踪你在哪里提取出组事务流和转储到一个文件中。”

采用今天
因为调试可以消耗约50%的总开发时间,你会期望每个公司使用最新的技术。然而,事实并非如此。

“问题之一是让人们相信他们需要一个解决方案,”福斯特说。“它可以教育和意识在人们意识到他们需要一个解决方案之前,尤其是当他们不保持度量看到他们的时间到哪里去了。根本原因是一个很好的指标,这可能会增加意识。我会跟踪错误的类,用了多长时间,这样我就可以分类模块对未来和说这些困难的可能性很高。”

有大量的证据表明,可以大大提高生产率。“用户通过这种调试变得更有效率,“Schirrmeister说。“真正的问题是,‘经理理解足以允许用户购买一个工具吗?工具的ROI足以使他更有效率,而不是问他在阅读获得更好的跟踪文件?我们看到越来越多的需求,尤其是对软件虚拟化的硬件上执行。用户能够看问题是很重要的。”

采用一些调试工具不会发生没有教育和培训,这可以防止或减缓收养,因为设计团队太忙想让产品出了门。“在软件仿真,确定因果关系方面的进展,这些使假设类型的分析,”福斯特解释道。“但是能够看到因果关系需要一些复杂。要真正了解其中的一些问题,你所要做的统计分析,通常无法观察这一个简单的模拟。这是通常情况下与多线程行为。”

新技术
调试系统的一个常见的方面是他们必须处理大量的数据。“我们先前宣布的使用大数据在我们调试产品,“Schirrmeister说。“我们正在处理的文件大小是巨大的跟踪文件。考虑的数据量可以失去一个模拟器在一分钟。只是下载所花费的时间要比创建它。处理网络中它是很困难的。大数据有一个角色在这。”

但大数据只是解决方案的一部分。“大数据和机器学习既可以帮助调试、“Sanie说。”以及如何管理它的数据量的一个方面。那么你需要寻找模式和学习,并将之运用于下一组数据。这不仅适用于调试,但许多EDA的派系。行业仍在工作的最好方法,我们可以做分析。”

“根本原因分析是相关的,”同意Schirrmeister。“大数据技术可以使您能够磨练成一个问题更快和数据库中的相关数据。但是我们仍然有很多事要做在机器学习我们可以给用户未经请求的建议。你想要一个观察者仿真运行,它能使你意识到发生了有趣的事情,这可能不是你的主要焦点。这些类型的分析被调查。”

肥沃的这些技术将如何保持一种猜想。“一个巨大的和新生的机会是我仿真数据使用static-formal semantics-aware和机器学习方法对故障检测和调试,“真正的意图的莎说。“已经进行了一些尝试试图减少跟踪长度,缩小设计范围为调试失败,并确定候选人修正使用正式的分析技术,但在我看来更多的是可能的。”

尽管如此,它可能容易冲昏头脑,使宣传的具体进展。“使用大数据分析可以对调试来说,但可能是有用的在合并结果从不同的验证环境提供一个更完整的报道,“表明帕里。

Schirrmeister也声称,我们保持务实。“这是研究不远。客户要求今天。我们已经讨论系统,使您能够把数据库从一长仿真运行并且使其能够访问一个更大的一群人。它的行为就像模拟器,但不是调用模拟器。正式的团队有能力你异常的跟踪和应用仿真就是很多人所说的大数据分析。我们可以做的事情,如发现信号和识别当这发生在过去。然后我们可以问发生了什么结果。使用断言和属性检查上面并不遥远。”

“调试仍然是一个开放的领域创新和我们有很多想法,我们正在“Sanie说。“调试过大已经在过去。”

当然看起来现在所有的目光集中在调试过程开发过程自动化的最后堡垒。改进了在调试自动化会严重影响开发时间和成本,这两个系统公司承受了巨大的压力。