在SoC验证重大转变

半导体工程坐下来与肯-诺森讨论其中的验证,在英特尔首席工程师;产品经理马克•克拉导师图形的设计验证技术部门;高级经理史蒂夫•Chappell CAE技术在Synopsys对此和验证;集团主管弗兰克Schirrmeister产品营销系统开发套件的节奏;营销副总裁汤姆·安德森Breker验证系统;Sandeep Pendharkar,副总裁和产品工程主管Vayavya实验室。下面摘录此讨论,举行DVCon昨日在现场观众面前。

SE:我们需要一种新的工程师桥的硬件和软件的世界吗?

Pendharkar:一些客户正在采取这种方法。经理雇佣了三个软件工程师设计验证团队的一部分。这些软件工程师用c语言编写设备驱动程序代码的验证工程师然后坐在一起,试图理解这个道理并且把它应用到块级的一面。很难让人们理解这一点,但这可能是像软件验证团队的一部分。

Schirrmeister:今天我们有很多问题是难以定义的硬件或软件。如果试图找到泄漏你的嵌入式软件,这个问题变得无论是硬件或软件问题。找到它的唯一的事就是看着虚拟平台和入住的内存没有被释放,因此必须从硬件角度进行测试。这就是为什么我想知道我们需要一个新的物种。他们需要理解双方问题必须定义在某种程度上这是一个真正的硬件软件问题。

-诺森:我们肯定认为自己开发系统engineers-they真的更像胶水工程师。胶水是了解特定的固件,你可以把它和修改它,然后使用设计。尽早获得软件的家伙真的很艰难。你可以得到建筑师。但要及早了解代码的人总是一个挑战。

Schirrmeister:我们EDA供应商正在试图做的是创造一个环境,一个moderator-let Phil-brings博士称他在硬件和软件的家伙,他们都通过不同的角度看同一个问题,而胶人成为主持人。他知道足够的关于双方是危险和挑战虚张声势的软件或硬件的家伙,这不是他们的问题。

安德森:我们需要一个共同的语言。

Schirrmeister共同语言是一个重要方面。

安德森:人们书写诊断软件验证pre-silicon的目的,客户往往是嵌入式程序员租借验证团队。验证团队成员的专家SystemVerilog和测试长椅,但是他们不一定知道如何编写嵌入式代码。租借嵌入式工程师需要学习一些关于RTL和仿真。与此同时,一些知识会沾上验证嵌入式软件团队。它可能不是一个新型的工程师,但有一个混合技能发生这种合作的结果。如果你要更多的自动化方法,有时是嵌入式的人,有时其验证的团队。

-诺森:复杂的IPs嵌入式处理器固件的验证团队专门验证的IP。但他们只是验证的IP。他们不是验证一个SoC上下文。和SoC他们会选哪一个?

Schirrmeister:如果你看看像国家仪器公司,他们做了很多测试。虽然很多事情我们做pre-silicon验证,有人在后端使用虚拟仪器或其他测试环境来测试芯片post-silicon。这个职业已经存在使用表示喜欢虚拟仪器,早些时候,一些可以应用流。

SE:我们,我们真的可以有良好的覆盖一个复杂的SoC,还是我们需要重新考虑如何应用覆盖模型?

克拉:你可以有很好的覆盖在不同级别的设计,从块水平子系统的完整的系统,但是你覆盖不同的东西。你不认为你可以重用SystemVerilog块级别的系统级模型。你没有覆盖相同的事情。

Schirrmeister:领导回流量。一个公司告诉我,他们所做的一切在系统级别更高是额外的努力。只有他们能做的事如果它使用整个验证工作。如果你真的可以和验证在更高的层面,你最好确保你有足够的自动化从那里来自动生成,并确保你没有re-verify下一层。否则它是浪费精力。问题是其他模型用于高层获奖TLM设计和验证中的是否可以有效地同步模型用于模拟,验证和TLM-based虚拟平台。一旦你的自动化水平的地方,然后你可以做这种额外的验证级别。

Pendharkar:覆盖在系统级别的概念需要加强,因为当你谈论系统级有一堆的事情你想知道如果你是做其中的验证。你要确保你所有的IPs正确行使,包括所有这些“诱导多能性”之间的交互可能验证。有很多共享资源,所以你要确保那些得到有效验证,。同样重要的系统上下文的硬件软件交互场景。当我们谈论覆盖在系统层面上,所有这些需要解决。

-诺森:你必须覆盖所有可能的相互作用?

Pendharkar:这是个好问题。这取决于你所验证。如果你跟一个消费电子公司或机顶盒制造商将不同于一辆车。

-诺森:如果你不知道它会进入,你必须。这是困难的问题。我们需要找出如何越来越得到等效质量。

Schirrmeister:你少做一些只处理相关的部分。

-诺森:没错。

Pendharkar答案取决于你和谁说话有很大的不同。一些工程师会问,‘为什么我需要运行所有的测试用例吗?如果有一个错误,他们只会推出一个软件补丁。但是我其他的人交谈,他们如此偏执,每个测试用例,从仿真开始,他们希望能够到post-silicon繁殖。这是因为他们没有达到事半功倍的方法。另一种选择是过度设计。

克拉手动:这样做,他们可以保证覆盖100%的测试,他们写道。

Chappell:我们讨论了共同的语言。当我们说语言的语法。不过,它并不是一个语法。语言是我们交流的方式。也许保险范围,我们可以开始之间的通信软件和硬件人。如果你得到在规划过程的早期,“这就是我们要实现从验证的角度来看,这是你功能覆盖率和代码覆盖的地方,你去做你的用例覆盖,我怎么分,考虑到不同的引擎,对我来说是可用的。有报道方面,还有平台方面。”

-诺森:它必须是无缝的。我不在乎如果它是一个工具或三个工具,只要是无缝的。

Chappell:穿过所有的抽象层次,硬件和软件之间的线条开始模糊。他们之间的模糊模拟和仿真。

Schirrmeister:这可以追溯到汤姆和我争论这个讨论的开始。必须有你做什么在一个引擎的无缝集成。

SE:这些会帮助开发芯片的成本?SoC验证估计高达80%到85%的负阻元件。

安德森:如果你回顾15年前,当人们并验证他们hand-wrote每个测试。然后约束随机验证出现和自动化,在很大程度上,与测试台上发生了什么。我们看到,无论是一个图表或其他技术,自动生成测试用例的想法你使用来验证一个SoC,处理器上运行模拟,类似的自动化。你10或15嵌入式工程师租借到测试运行模拟和仿真,代之以自动化。导致节省了时间和美元储蓄。

Schirrmeister:参考点是很重要的。我会非常小心在声称降低成本。我们要做的是控制成本,提高生产率来处理的复杂性。复杂性仍在增长速度比我们所有的工具和方法的效率。如果参考点不增加复杂性,并降低成本。但复杂性增长如此之快,绝对成本没有减少。验证仍然是一个未装订的问题。我不知道谁来了,他们说一切都是在验证完成。他们都出汗当他们实际tapeout,希望他们没有错过了一件事改变自己的职业。

克拉:即使是基于技术,可以让你更快地覆盖目标比约束随机测试,客户不要说现在他们就完成了。什么通常是导致它们剥洋葱的层和说,“我不覆,我以为我是我需要扩大我的目标,进一步验证。最后你填满时间尽可能多的验证完成,因为它是一个无限的问题。

Schirrmeister:自动化并帮助处理复杂性,设计师不能做手工。你得到足够的通过自动化测试,下面的测试。

克拉:但是如果人们想利用一些新的自动化领域,他们也愿意超越今天可用。标准委员会和社区都是很好的帮助我们与互操作性,但也许一些自动化要求我们超越标准。一个标准是创建一个通用交换今天我们已经知道的东西。我们不是寻找增量地更好。我们正在寻找的东西是10或100 x更有效率。我们应该有一个小组会议标准是否阻碍了我们前进的步伐。

Chappell:我们还需要看看我们解决问题的一部分。当你看着验证的总体费用,不管你是使用基于或直接测试,您仍然需要写你的试验台。序列的哪一部分你要上运行模拟与仿真?你如何设置您的原型和模拟平台?如果你正在寻找生产率和验证的性能降低总成本,你必须看看整体大局。你需要一个无缝的学习曲线。

Pendharkar:我们寻找降低成本或提高质量的验证。我愿意相信这是关于改善的质量验证。希望自动的成本是照顾。

安德森是的,产品召回的成本是什么?客户想要的。他们想让我们发现错误和更快。

Schirrmeister:他们会喜欢便宜,。

-诺森:自动化无疑是我们需要做的事情。我看不出验证规程消失与生产软件。坦率地说,你不能做很多事情在pre-silicon生产软件。很多生产用例与用户体验,时间、艺术复杂的事情,即使基础设施可以将花费数周时间。所以请不要依靠生产软件来解决所有的问题。

Schirrmeister:但是我看到很多人使用Linux测试操作系统。有些公司做具体的、有针对性的操作系统。这绝对是一个增长领域EDA来处理这个问题。

Chappell:它回来引擎你要用。你不会在模拟引导Linux。如果你有一个非常快模拟器可以这样做。