处理死锁

死锁问题越来越为设计变得更加复杂和异构。

而不是集成IP,面临的挑战是了解所有可能的相互作用和依赖关系。影响知识产权的选择,在设计实现方式,它是如何验证。它增加了很多未知数为投资回报已经复杂的公式。

“IP重用在纸上听起来正确的路要走,但多少返工是必要的,它开始击败IP重用的目的如果我实际上想返工所有的意图在SoC方面,“问总裁Sancheti,高级营销主任,验证小组Synopsys对此。“这是发生,通常分为两个主要的类。一是在IP水平,更多的关注于intent-level验证。你想确保IP验证它最初设计的所有关键功能。贵宾扮演一个角色在这种情况下,因为他们提供了一个详尽的环境验证所有底层协议和IP设计的关键功能,”他说。

在系统层面,重点更多的转向系统级验证,这个想法是为了确定IPs互相玩好。但终端设备的行为并不总是定义为芯片,并随着复杂性的增加也可以很错误的风险。

“在功能验证工程师的目标是确保每一个IP功能是正确的,这是做正确的事情在自己的宇宙,“Rajesh Ramanujam说,产品营销经理NetSpeed系统。“每一个IP使用硅资源,有时他们共享硅资源,但我们的目标是确保每一个IP功能是正确的。一旦你把它们放在一起在系统层面上,然而,可能会有资源争用。例如,你有这些平行宇宙,我们假设每个IP正常工作。一旦在一起,他们的冲突。有共同的资产和资源争用,这就是死锁。”

得到一个更清晰的照片,想象处理器正在等待来自处理器的数据作出反应之前,和处理器B是做同样的事情。“既不做任何错误,Ramanujam解释道。“他们都是在做正确的事情在自己的宇宙。但当他们放在一起,工程师没有考虑到他们之间可以共享的资源导致死锁。结果,没有前进,因为每个人都在等待其他的东西有一个循环回路。不幸的是,芯片得到部署,几年后,整个系统就会瘫痪。”

图1:互连和僵局。来源:NetSpeed系统

有两个主要的地方可以有效地解决。一个是在设计周期的开始。另一种是在不同的组件已经集成到一个SoC。

“架构师需要仔细考虑情况下会导致死锁和建筑师,“是甘地说,验证经理ArterisIP。“在验证方面,我总是建议IPs系统级环境中运行。你可能会打击一些死锁情况下,随机刺激。在大多数情况下,架构师/ RTL设计师突出情况下他们认为可能会导致死锁。在这种情况下,验证工程师可以使用irritators人工填满资源和运行模拟(有时是很长时间的)打击这些死锁情况。”

覆盖问题
在其根,死锁是一个问题,并不包含在验证覆盖率。

“如果一个组织能够说,“我们没有取得进展,”不是一件坏事,”哈利说福斯特,首席科学家验证导师,西门子业务。“最糟糕的事情是当一个组织没有一个线索。这是最基本的方面。例如,我们知道,我们正在取得进展如何?我们有不同的指标。最明显的一个报道,一个组织将看到,如果他们正确看待它,他们可以问他们为什么不关闭覆盖和他们是否应该搬到一个不同的策略。如果他们不能回答,如果他们甚至不知道他们不是progress-they遇到了点麻烦。很多组织都有一个问题是,他们真的不分区验证问题正确。”

一个常见的问题涉及的内部开发和第三方知识产权。

“组织犯错误当他们试图接近覆盖率过高水平,”福斯特说。“这就是他们会陷入僵局。他们没有取得进展,因为它太硬覆盖。例如,如果我等到我完全组装芯片来验证设计的一致性,我麻烦了。”

福斯特说,正确的方法是首先验证IPs和实现适当的覆盖在这一水平,但不尝试re-achieving,在一个更高的水平。“一旦我这样做我将它们组装成子系统,并使用一致性作为一个例子,我验证织物但我不验证除了织物。我只关闭相应的覆盖率IP之间的这些交互。我不想关闭覆盖在IP。一旦我得到这个工作,然后我去下一个层次的集成,与高级整合织物或其他的IP,直到我最终达到纯系统。组织有问题,他们不会关闭覆盖在一个足够低的水平。他们主要关注,“咱们去状态,我们整合一切。这是一个问题。”

方法计算
这可以归因于日益增长的复杂性和更多可能的用例。但是一些问题可以早些时候发现更好的验证计划和工具流。

“正确的决定在这个阶段将会节省我们从死锁在项目过程中,“博Zalewski说,总经理Aldec硬件部门。“是非常重要的决定方法在早期阶段,所有需要的资源在需要时可用。一个深思熟虑的验证策略以及有经验的团队将帮助避免项目失败。适当的工具组合和验证策略是非常关键的系统级设计,和使用工具的能力在多个验证模式,互连通过标准接口与不同的应用程序或数据格式,和多语言支持是必须的,以避免意外的验证阻滞剂。”

其他人也同意。弗兰克•Schirrmeister高级集团董事、产品管理系统&验证小组节奏说,僵局必须从数量的角度,从固体发动机和调试方法。

“这就是你所需要的工具,可以让你运行的一切锁步骤,在正确的准确性,“Schirrmeister说。“你需要看看软件运行在不同的处理器上,或者你需要看所有不同的IP块。你需要能够在锁定步骤中,调试它。你需要一个坚实的环境(硬件和软件)执行和调试。第二你需要编写测试和刺激你的设计,你实际上引发这些(死锁),因为你不能依赖执行软件或开关,等待错误发生。你真的想强调的角落里用例和开发测试专门领域。”

最重要的是,他说,设计团队需要考虑如何将这些错误是可以避免的,首先,他们需要使用正式工具路由出那些确实存在。

会正式
皮特•荷迪产品管理系统&验证组主任调子,指出僵局验证通常是进行正式的验证工具,可以使用不同的应用程序,根据不同的性质、范围和子系统的设计阶段验证。死锁可以发生在一系列电路从简单的有限状态机(FSMs)特别复杂的协议,缓存一致性协议。

“从根本上说,基于属性的僵局验证的形式验证是一个很好的解决方案,因为非常具体的交易的时机可能引发死锁的必要条件。这通常是难以实现constrained-random模拟不确定性事件的时机,但正式详尽练习每一个可能的一系列事件暴露可能发生的一切,”他说。然后,验证公共行业标准协议的实现包括缓存一致性,荷迪说这是很常见的使用正式属性验证结合assertion-based验证IPs (ABVIPs)全面检查design-under-test坚持协议。

Sancheti同意:“形式验证是成为一个大的一部分原因很简单,与正式或结构等技术,你能做的是做的非常的专用测试特定的接口问题,你可能有。然而,正式的并不意味着系统级验证,但当涉及到具体,界面层测试或验证,您可以应用正式的技术。你没有测试整个系统在这种情况下。”

仍然有很多情况下,当使用传统的验证方法。然而,副总裁罗杰Sabbagh应用工程Oski技术说,验证系统级硬件死锁的缺席的挑战不是通过传统的验证方法来解决。“设计团队依靠SoC RTL软件模拟和仿真器(ICE)来验证系统级需求,如没有死锁。然而,由于现代设计的复杂性,个别案例场景中使用这些方法的覆盖预测低和微妙的死锁错误可能在验证过程中生存下来。”

他认为验证control-oriented死锁等问题更适合形式验证,因为正式的可以提供完整的覆盖,相当于通过模拟所有可能的场景留下没有bug。然而,他承认正式模型检查患有指数与解决PSPACE-complete问题相关的挑战,这证明没有死锁的RTL模型整个系统以其众多的州是不切实际的。

相反,这可能是解决建筑形式验证。Sabbagh说,这种方法利用正式的详尽的分析能力与抽象的建筑模型探索所有角落病例克服复杂性障碍,使设计行为的深入分析。“这形式有效的系统级需求的一个强大的组合验证有用目标区域不受传统的验证方法,如僵局。”

,因为方法不依赖RTL模型的可用性,它可以部署在设计的早期阶段允许架构缺陷检测和固定之前传播在整个设计实现。相比之下,修复晚期建筑bug发现通过全芯片模拟或仿真可能需要许多RTL设计更改自修复这些类型的错误常常有连锁反应,横跨许多块。最好早点找到这些错误,避免代码流失会导致重大挫折验证成熟度和导致昂贵的项目延迟,他说。

ArterisIP甘地还认为正式的验证可以用来梳理架构死锁,虽然功能验证系统或多个块级别也可以结合特定的交通和irritators的帮助下,打击死锁情况。同样,在模拟器上运行可以打了死锁,因为你可以跑快得多,可以发送更多的交易可能死锁情况。

但正式的也有其局限性。导师的福斯特说正式破裂高技术集成级别,除非创建一个抽象模型的设计,和建筑方面被证明。“当你超越designer-sized块,需要巨大的能力,也超出了工具在这一点上,因为你已经遇到了状态爆炸。在这一点上需要的是正式的专业知识如何抽象设计,还有一袋形式验证专家使用的技巧。这些交互方面的问题的一部分我们讨论在一个完整的SoC -这个IP和IP之间的交互也是硬件和软件交互。你绝对需要模拟或FPGA原型。你需要什么东西,因为你不会得到足够的模拟周期。”

Ramanujam补充说,正式的技术目前在市场上并不针对死锁。这需要一个依赖图。“功能缺陷验证,功能验证中使用的正式技术总是确保IP安全规范,”他说。“建筑师需要提供正式的工具他们希望IP如何工作的规范功能。正式的技术使用,随着黄金基准并确保数学的IP是正确的反对。同样,在僵局方面,你想要一个正式的技术验证死锁。你需要一个规范的系统中可能发生的所有依赖项,所有的资源可以共享,给出的数据需要在一个特定的格式。

Ramanujam强调这是一种预防措施,而不是事后,应该部署之前创建的IP。“一旦你构建一个IP,如何确保不会发生死锁?这并不存在。你必须回去和运行多个模拟从用例,和压力的IP在多个不同的方式,以确保不会发生死锁。空间是巨大的。这之前需要部署IP建造,它是免费的死锁,因为你已经正式证明所有的依赖。”

结论
今天的挑战与建筑系统已经从IP集成级别,因为现在的问题是IP模块之间的交互,而不仅仅是功能是否正确。

”多次出现的问题,如交互,不是很好理解,“导师的福斯特说。“例如,我可以去买一堆IPs和集成。在我心里我知道我想要的,但我没有意识到,当“这个”“这”会影响这其他IP。这是一个困难的事情。”

有关的故事
验证的断裂点
根据设计的复杂性,内存分配或其他问题,很多方法可以失去动力。
系统覆盖未定义
是什么意思有验证系统和如何衡量风险?该行业仍挠挠头。
便携式刺激状态报告
早期版本的20年来首次新语言正在审查随着最后期限的临近。