其中验证(第3部分)

专家在餐桌上,第3部分:新验证问题需要反思整个方法。

受欢迎程度

功能验证已经由工具要求硬件看起来像二十年前的系统被设计。这些限制将芯片置于风险和新的解决问题的方法是姗姗来迟。半导体工程与弗兰克Schirrmeister坐下,集团董事、产品营销系统开发套件节奏;高级主管Maruthy Vedam系统验证工程英特尔;营销副总裁汤姆·安德森Breker;创始人兼首席执行官Vayavya实验室副总裁和John Goodenough设计技术手臂,谈论其中验证第一部分提供了对其中验证小组成员观点,以及它如何与约束随机生成和UVM。第二部分讨论用例和声明,更比明显的场景,它需要深入分析。下面摘录,谈话。

SE:我们需要新的报道形式跟踪系统级的概念?

前言:我们使用的术语是统计范围。系统级意味着人们关注问题等我测试这个工作的同时。这是不够的。你必须知道你的关键问题,这可以从系统不同。事件排序问题的东西,即使是架构师可能没有考虑。

Vedam:当我们在集成我们进入一个非常有趣的情况。复杂的国家数量的增加主要是因为并发性。集成层每个特定的功能知识产权最重要的,这决定了它可以或不能作为一个整体。这几乎创造了一个指数。这是一个用例理解我们需要测试并确保我们得到的概念报道。报道可以生成大量的数据。可能会很难理解理解我们需要的数据测试,并确保覆盖可以代表适当很重要,这样我们可以做出更好的决策。

前言:对,我不是短的方法生成测试,我理解所有这些周期短我跑模拟,模拟或硅,我明白如果我做。

Schirrmeister:你知道的事情,你需要排除不相关这个特殊的设计在这个特定的使用模型。从学术报道的角度来看,你可能没有覆盖所有但重要的是知道你不需要。

前言:与客户谈话永远是具有挑战性的,因为你知道他们会说“你有一个错误,你为什么没找到吗?“你必须有数据能够反应。有时你可以看到没有触发这个事件的所有周期的验证,我们跑,这导致了持续改进。

Schirrmeister:你的挑战是有多个引擎,如模拟、仿真、原型。这些每一个都有不同的特征从准确性的角度来看,有它运行在一个环境的情况下而不是在另一个。这可能发生的方法之一是当你忘了初始化内存。硬件工作有时取决于内存的状态。这意味着有不同的东西,你可以找到在不同程度的准确性。

前言:的一个挑战UVM当从块级仿真环境子系统之间必须有适合的环境。否则你可以运行相同的载荷,得到不同的结果。虽然不同的行为可以帮助你找到错误,这是一个例外。

帕蒂尔:我们试图定义的质量验证?是有区别的度量为和完整性,大多数时候你不担心完整性,你关心质量。你能捕捉的整个场景集或者至少是有趣的吗?

Vedam:同意。我可以认为我们从未做过验证。关键是要知道我们在哪里,即明确理解验证是什么悬而未决。所以在某种意义上“完整性”是一种高质量的度量!客户不希望完全验证的一滴。特别是在产品开发生命周期的早期,他们更喜欢部分验证下降更快,只要他们清楚地理解哪些特性是保证工作,哪些是“风险”。

SE:如何掩盖了许多问题与软件?

Schirrmeister:硅首次成功意味着你可以用软件解决所有的问题。会有勘误表芯片或列表用这个芯片你不应该做什么。芯片的软件交付是一个配对结合硬件和面具的一些问题。

Vedam:如果你把你交付作为一个系统,然后你有软件屏蔽的问题,这不是一个问题。

前言:除非它降解性能然后它可能是一个性能问题。

安德森:如果勘误表,你不能把这个范围内的数字除以这个范围内的数字,那么结果会非常混乱。你可以描述与芯片或做任何事在软件但杀死性能。这并不工作。

SE:性能和安全性是其他领域,我们需要开始验证吗?

安德森:性能、功率、安全都是功能的一部分。如果你失败了在这些方面你没有你预期的产品。

前言:UVM提供了一种构建验证环境。验证一块你需要多个验证环境。UVM不能做这一切。它并非灵丹妙药。它构建一个类的验证环境。为了安全,你需要另一个验证环境和一些人使用正式数据着色和应用技术。权力经常使用其中的动态模拟。他们不会尝试使用UVM。

Schirrmeister:我们需要注意定义的对象被证实。如果你是块级验证,您可以构建一个UVM验证环境。但也有其他验证范围,如子系统和系统。每一个都有不同的引擎和你想做不同的事情。块级别的我们使用模拟,因为我们需要调试的洞察力,我们使用形式验证,但在更高的层次上,我们需要更多的周期运行,因此你需要硬件辅助技术和一些物品你只能做硅。

SE:这不是一个新问题。公司一直以各种不同的方式解决它。它已经迅速成为一个公共问题。将在12 - 18个月在哪里?

前言:我们正在积极推动我们的EDA合作伙伴为我们提供的一些片段,我们需要为这个难题。我想知道如何自动化其中验证这样我可以让我的工程师更有效的,能够测量他们在做什么。

Schirrmeister:IP提供商和子系统供应商有不同的需求。每当标准化,和我们现在谈论刺激跨引擎移植,那么它就是一个明确的信号,意味着人们想要确保它们不会局限于一个专有的解决方案。他们想要确保他们的内部挑战是听到他们想知道它是可伸缩的。在最近的Accellera会议有一些很酷的人们所演示。问题是放在桌上,我们愿意回应,我们与客户是活跃的。

前言:这个问题我们已经是一个可伸缩性的问题。我们面临的挑战是通过验证的体积以最有效的方式。其中验证砂箱的一部分。

Vedam:这是一个效率的事情。我希望EDA供应商来帮助我们的系统视图,为大家带来一个标准化的视图系统意味着什么以及产品生命周期和为他们能够与它交互,这样您就可以最大化重用。

前言:目前我们的问题是可伸缩性的另一边是我得到更有效地模拟运行周期,我已经把这个问题在其他地方。现在我必须得到更有效的调试。

Schirrmeister:18个月以后,我冒昧,我们将不得不面对大数据工具和Splunk等公司,EDA从来没有听说过的公司,能够查看日志文件模拟试图理解所有生成的数据。

前言:我们已经投资了很多在过去的两年里为我们构建一个大数据的后端验证基础设施。

安德森:有一个解决方案,今天适合自动化的生成C测试是可伸缩的。我认为有证据表明它与越来越多的采用加速在这个空间和更多的供应商提供解决方案。我们不认为缺乏一个标准作为一个障碍,但很可能在一年或两年后,其中验证可能会成为一个相当标准的方法。

帕蒂尔:如果我看看这个工具提供者,然后标准化很重要,因为如果我们去多个客户账户和创建自定义的解决方案,那么它会使事情变得复杂。重要的是,它符合到尽可能多的流动。人们必须相信,他们必须知道的真正好处。它产量在过去不可能吗?这是铰接成为主流。



留下一个回复


(注意:这个名字会显示公开)

Baidu