调试:自动化的最后堡垒

有当轶事证据成为民间法的次数,然后随着时间的推移,工作是找出是否有任何事实。也许最著名的案例是声明,确认消耗了70%的开发时间和资源。多年来这个“事实”是用于几乎所有的验证报告,但没人知道数量已经从何而来。

所有的开发团队都是不同的,即使这是一个意味着图没有人试图想出一个确切的答案。在2007年,导师图形开始的一系列研究,首先使用帮助西部的研究和使用威尔逊研究小组从2010年起,和真相而闻名。2007年,它不是真的。验证消费调查显示只有46%的开发时间的结果。今天是不正确的。虽然一直在不断增加,今天站在57%左右,并没有阻止大部分论文和演讲使用虚构的数量的70%。然而,它可能是真的,最先进的设计是这个数字因为70%左右为大约20%的行业是正确的。

另一个表达“事实”是调试消耗了50%的开发时间。半导体工程想知道如果这是真的,趋势是什么,正在发生的事情的开发调试工具,可以改变这个数字在未来。

高级营销主任Michael Sanie验证小组Synopsys对此说,“保守,35%到50%的时间是花在调试和它可以超越,这取决于项目的状态或大小。在我们内部知识产权发展,35%是一个安全的赌注,但我不确定有人坐下来,数了数小时。它不是黑色和白色。当您正在调试,你可能在做其他的事。与RTL,你可能会调试RTL,testbench,报道。是所有调试?这取决于你如何定义它。”

这是第一个问题的提出一个明确的数字。“威尔逊研究,如果你问验证工程师他们花在调试的时间的百分比,这是一贯的37%在过去的两个如果不是三年,”哈利福斯特说,首席科学家验证导师图形。“但这在几个方面可能会误导人。第一,不占设计工程师在调试的时间,我们知道,设计师花一半的时间在验证其中很大一部分的时间调试。所以总可能会接近50%。”

Sanie表示同意。“有趣,验证团队越来越大,对于许多开发团队验证团队大于设计团队。如果50%的验证调试,如果团队扩大,那么这意味着调试问题是可能采取更多的正面。我们也知道扩大验证和设计的复杂性。当你混合其他技术,找出产生问题的根本原因变得更加艰难。”

福斯特还警告过度纠结的一个数字。“50%是什么意思?几年前我遇到了一个设计经理的团队组织良好,他们可以放在一起testbenches几乎没有时间。他声称他们花了85%的时间在调试,因为一切已经优化。”

尽管验证工程师支出的比例大致相同的时间在调试,福斯特认为调试增长是因为今天的需求增加。

他有很多的公司。“调试是消耗更多的开发时间由于增加了设计的复杂性,而且不只是限于验证,“Anupam问题说的首席执行官Agnisys。“需要调试是因为缺乏透明度。缺乏清晰是因为在爬在设计流程的误解。原因是缺乏具体和明确的规范,主要是在接口点,比如各个模块之间的接口芯片,硬件和软件之间的接口,接口之间的验证和确认。”

调试的复杂性
重要的是要注意,调试并不局限于任何单一组织或市场。“调试是整个行业面临的挑战,”Chi-Ping Hsu说,高级副总裁兼首席战略官EDA产品和技术节奏。“每当我们讨论高级节点和成本高,掩模成本,之类的东西,他们是一个非常小的比例的真正的挑战。真正的挑战是把所有的IPs一起来验证设计工作正常,如果没有,你需要弄清楚你做什么当你发现问题。如何调试它,当你使用别人的知识产权,和最重要的是,真的验证一切的唯一方法是将软件在验证环境吗?”

其他人也看到了IP重用相关的问题。“调试一直参与一个洋葱剥皮,但洋葱的过程现在有很多,更多的层,”戴夫·帕里说,首席运营官Oski技术。”同时,设计已经在规模和复杂性和产品生命周期缩短,已存在的知识产权的使用,通过购买第三方的知识产权和内部重用,已经扩散。这可以进一步延长调试时间这些遗留的细微差别和特质/购买IP核可能不是很好理解,和一个运行良好的核心在之前的设计可能不完全在一个新的函数。一个可以产生一种虚假的安全感,核心是“好的”的逻辑。”

调试不是一个单一的问题。”这个问题不仅仅是关于项目的大小也不同类型的数据和目标执行调试工程师,”博Zalewski说,硬件部门的总经理Aldec。“调试解决方案的复杂性生长更快安全性至关重要的项目,比如航空电子或汽车。这些通常不需要设计修改和速度测试,生成大量的数据。这些超大数据集需要非常复杂的调试工具的体系结构。甚至简单的调试需要先进的实用工具来可视化分析和与黄金模式。”

确实有许多数据类型和目标。”SoC包含多个建模域,”福斯特说。“功能、时钟、电源、安全、软件还有其他物理问题如液压、传感器…调试正在增加,因为所有其他的今天必须做的事情,他们都需要共同运作的解决一个设计师的问题。”

今天大多数的设计混合在某种方式。“模拟和混合信号设计的非常不同,需要调试,添加一个新类型的背景下,“Sanie指出。“他们是完全不同的,当我们增加力量和抽象…这是一个n维的问题。”

使任务更简单的一个方法是查看不同的问题。“分区签字过程验证漏洞管理复杂性的新的和成功范例billion-gate soc,“Pranav莎说,首席技术官真正的意图。“这引起了EDA公司专注于为个人提供完整的验证解决方案范围较窄的验证问题,一次一个。这是一个重大的观念的转变,从之前的方法销售通用工具模拟器和断言的形式验证。这种新的范式福利分析以及调试。分析的结果是与verification-problem上下文,可操作的数据,提出了正确的方式,允许系统的调试工作流程。”

但并不是所有的问题都可以以这种方式隔离。一些问题需要一个发现的过程,始于可视化和经过发现直到找到问题根源,可以纠正。没有一个正确的方法。有两种基本方法。首先是发现一个问题,然后试图找到问题的根源,并确定一个解决方案。第二种方法是分析一个系统,试图发现类的问题使用广泛的分析技术。(这两个将在本系列文章中讨论)。

第二组问题是调试不能存在一个抽象层次。观察信号波形可能有利于某些类的问题,但其他问题不出现,直到整个应用软件运行在完整的硬件系统。此时,系统不能运行在一个软件模拟器,甚至可能不是一个模拟器。原型可能是唯一的方式获得足够达到系统能够行使的问题。捕获跟踪在这个阶段可能出现这么多数据,分析问题变得站不住脚,以及引起许多其他问题。专业的建筑功能或性能的硬件系统可能变得必要能够更清楚地了解是怎么回事。

调试过程
这一切开始于验证。“首先你注意到一些不工作然后你创建一个假设可能是错误的或者什么问题可能是,“说,首席技术官超音速。“问题在于,没有足够的工具,找到合适的假设可以花很长时间。”

可以做任何优化调试是很重要的一个项目。“从管理的角度来看,调试是阴险的,它是不可预测的,”福斯特说。“我能把指标编写testbenches等各种流程,构建测试,可以在类似的项目一致,但调试可以在地图由于其广泛的方差。这是一个管理的噩梦。”

也可能有几个不同的起点。考虑范围。“当你开始使用覆盖率度量关闭,你花了很多时间在调试报道,“Sanie指出。“是什么原因导致你的刺激不能激活吗?如果它能被激活但不传播呢?所有这些添加层的复杂性。然后您可以添加正式在此之上。如果您使用的是正式的bug狩猎,这是整个调试过程本身。调试不仅仅是波形查看。”

别人同意,有多个工具,可以用来帮助在调试过程。“调试是独立于可视化,”弗兰克Schirrmeister解释道,高级主管的产品营销系统和软件实现群节奏。“可视化使用波形和每个人都会使用它们。他们一直等一些改进显示事务和包含的软件到相同的图。然后有很多的改进,如将UML图。UML终于发现了在EDA,但不是在设计流程。UML的可视化帮助场景。它提供了一种一致的场景用图形表示的UML类图表示是无处不在的。当你定义一个场景中你可以设置断点,如“当这些四个街区已经按顺序执行的,去看看软件在哪里。”

Schirrmeister分离这从另一个阶级的工具。“根源分析(RCA),你可以通过系统跟踪,做事情,比如点击一行代码或者信号,找到最后一次接触。这种类型的功能允许您在这个问题上和提供指导的问题。”

另一个类的调试工具甚至不被认为适用于调试。“最好的形式的调试是预防错误,”指出Sanie。“一旦你编写代码,你可以开始寻找bug。传统上,看起来像棉絮被认为是一个设计工具,和类似的时钟域交叉(CDC)作为验证工具。所以调试是一个连续体。调试是使用不同的技术在设计的不同阶段,加上早期错误检测。”

培养完全一致。“发展最活跃的领域之一是避免错误。如果有愚蠢的错误,在设计发现的验证流程,那么它将花费我更多的查找和调试他们而不是确保他们永远在第一位。”

然而,这里有一些希望。“这个调试噩梦的出路是坚持标准和规范自动化,“说Agnisys问题。”这是一个例子:十年前开发团队花费无数的时间用于在实验室调试寄存器和中断,现在有更好的工具,自动规范,这个区域的设计需要很少的调试。同样的,早些时候的时间花在调试专用总线之间的交易不同的ip,但现在与坚持像AXI和接口标准IP-XACT总线标准,调试时间最小化。规范的自动化和标准化不存在无处不在,但无论他们存在的时间花在调试是最小化。”

一个扩大的问题
今天调试不一样甚至10年前。“过去,我们可以单独的物理和功能,但现在我们有了电力问题会影响功能的,所以我们必须模拟方面,”福斯特指出。“当你开始担忧,混合的复杂性显著上升,反映在所需的努力。”

另外一个问题就是,调试所需的数据可能不同的这些担忧。最近导师和有限元分析软件宣布一个API,允许电力信息从一个模拟器转移到权力分析工具不需要传统的干预一步跟踪数据写入一个文件。

“这使用一组不同的数据比我所需要的功能调试,“Wingard解释道。“这将是伟大的如果所有调试所需的相同的数据和接口。对权力分析感兴趣转换活动和切换率。这就是他们关心的。功能或性能调试你需要更多的数据。您可能感兴趣的数据差别很大。如果我找一个性能问题,我真的不关心的数据位移动。他们是一个障碍。我关心的事务,可能地址,因为它影响记忆系统的调度,而如果我看着几个处理器之间的交互,谁正在做某种同步,也许我关心数据很多。”

性能和功率比功能调试调试需要不同的方法。“当公司花时间在自顶向下的设计,这是因为性能和力量,“Schirrmeister说。“这是关于硬件架构和你强调设计与随机数据代表诸如峰值流量。在你看着线程的系统级和任务,你需要进程负载或内存负载信息。”

礼貌:弗兰克•Schirrmeister节奏;罗伯•凯的手臂。手臂Techcon 2015

“性能是一回事,人们希望看到,包括他们正在使用的资源,”说,首席执行官治之。。“这是现在扩展到电力。今天,设计团队时间预算和预算。这不仅适用于那些团队开发新的芯片,但问题也同样适用于设备使用标准部件。他们真的想知道权力配置文件,这样他们就可以优化软件运行的方式来减少力量。”

但不仅仅是权力和性能。Davidmann提醒我们,“这是另一个领域的软件变得越来越重要和相关的安全。人们试图了解如何开发一种软件,这种软件能够满足这些挑战和我们需要的工具来帮助。”