使硬件设计更加敏捷

半导体工程坐下来是否需要更改硬件设计方法,与菲利普•古铁雷斯ASIC / FPGA设计经理IBM的FlashSystems存储组;丹尼斯Brophy,战略业务发展总监导师图形;集团主管弗兰克Schirrmeister产品营销系统的开发套件节奏;汤姆德舒特、高级产品营销经理仿真器解决方案Synopsys对此;,负责营销的副总裁兰迪·史密斯超音速。以下是摘录的谈话。第一部分,点击在这里。第三部分,点击在这里。

SE:敏捷如何真的看硬件方面吗?它工作吗?

古铁雷斯:最基本的概念之一敏捷是团队承诺他们将做什么在sprint。在软件方面,假设、方法和文件更容易团队成员之间的互换。作为一个团队成员完成他或她的任务,他们可以跳上另一个任务,帮助结束冲刺。在我们这边,我们有一个团队但是他们都分配自己的模块或自己的IP块。并不是简单的一个工程师在跳到另一个工程师的任务。当我们到达sprint结束时我们不能关闭一切,就进行到下一个sprint。这是一个小男人不同的软件。另外我注意到,当人们谈论敏捷他们谈论持续集成。技术成为一个重要组成部分,但它不是敏捷的一部分。关键,他们的状态显示构建,每天和他们做多个构建。 We’re certainly trying to do something similar, but we’re having a hard time getting through the flow. Our regimens can run for days. We don’t have the throughput to do continuous builds on our side.

Schirrmeister:敏捷和持续集成的区别是一个重要的点。

古铁雷斯:传统上,从芯片设计的角度来看,DV团队将列举出每周的回归。它可能运行每日回归,这是小,但在本周末将每周运行完整的回归。你发现错误的时候,你正在运行的代码几乎一个星期。如果您可以运行这些回归更频繁,你可以抓住这些漏洞。如果你推到极限,您可以运行日常回归。工程师通常不允许检查文件。他们只能做一个回归。一旦他们完成他们的回归,通过回归,然后文件进行检查。

Schirrmeister:在很多情况下我们看到,如果变化是重要的需要有一个正式的审查之前,你可以提交给回归。在硬件方面,你有你所有的测试,你看看每天晚上更新。他们没有带宽运行所有的回归在他们需要的时候,这就是它归结为你的回归速度运行。非常大的循环硬件可能是六个月。较小的循环持续集成和回归可能会在一夜之间。这就是硬件加速。它有助于将所有数据合并到前端验证管理。

史密斯:今天我们困在一个方法,虽然,我们没有足够的单元测试。非常愚蠢的方式,我们测试一遍同样的事情做的单元测试。有很多的浪费精力。在我们生活的这个世界,这是网络芯片,客户说他们有问题。这个问题经常是一些块产生一个糟糕的协议。你可以发现,在单元级别上,之前你要网络的性能水平分析你所做的。和你应该。部分原因是,我们已经告诉系统工程师去运行这个大系统测试,然后运行一个大回归,而不是找出你可以在本地测试,然后不费心去测试,后来因为你已经测试它。

Schirrmeister:仍有改进的空间。但有一个区别在范围之间的单元测试、子系统测试和系统测试。如果它运行到仿真和系统级测试,你发现一个错误在单元测试应该被发现,然后你回去打那些人因为这需要改善。这是一个不同级别的范围。如果你发现错误的单位,出事了。

Brophy:和挑战是找不工作的东西,而不是单元测试的,他们已经被证明确实有效的东西。这是一个心态的变化。他们编码的准备,除非有人证明它不工作,它的工作原理。这就是敏捷的帮助。你已经测试了它从一个测试,另一个,你会说,作为一个团队,这是规范会做什么。

Schirrmeister:我完全同意,但范围是不同的。这就是multi-verification出来的概念。你需要有系统级测试,清晰地定义什么是场景驱动系统集成到系统应该进行的方式。和你需要分成的IP,所以如果你发现一个问题在PCI协议级别水平,然后在这一水平出现了错误你需要问你的团队或跟你的IP提供商。

SE:这是发生了什么?

古铁雷斯:几年前我们将允许IP开发人员去和发展他们的IP块。在芯片层面,我们将整合这些IP块知道他们完成或基本完成。现在,随着左移位,我们被要求提供一个平台软件早。这意味着我们发展IP同时我们做顶级集成。当我们整合这些块在顶层,IP还没有完成。它不是那么容易回去IP人殴打,因为现在还没有完成。这是非常具有挑战性的。我们做知识产权开发、顶级同时开发和软件开发。

Schirrmeister:所以你谈论新的IP开发,因为很少有完整的绿地开发没有任何重用。的一个讨论DAC是系统级测试帮助ip级别测试,尤其是新病例。重用有垂直的三个案例从IP到子系统系统级重用。系统级测试可以提供洞察如何测试IP,反之亦然。第二个概念是水平的重用。虚拟RTL,仿真、FPGA甚至整个左移位。最后一个级别的重用是学科之间重用。电源关闭的家伙他视图。相干的人他的缓存一致性的概念。人有自己的软件集成。 And these guys have a hard time talking at the chip level, so Agile is an advance to the next level of continuous integration. That becomes so fast at some point that it’s becoming Agile.

古铁雷斯:当我们的IP块集成到顶层和运行他们自己的东西,我们的目标是让这个东西启动并运行。但问题是,如果你把它运行在实验室里,有一个倾向于减少验证。如果是在实验室运行几天,你真的需要运行这些测试吗?这是我们需要密切监控。

德舒特:如果你看看这些单元测试和信息在较小的项目,这是矛盾我听到客户。你可以看看各个部分,但软件是非常复杂的。大部分的问题是当你发现系统或子系统。软件的另一个问题是,它需要大量的组件运行。所以你可以验证一个IP块的上下文中一些验证IP。但真正的问题是当你把东西放在一起,启动一个操作系统,你看看初始化IP和IP的方向。那才是真正的问题。问题是,所有的碎片需要承担的工作。如果你是被迫工作系统,因为软件需要,但IP尚未完全证实,我不确定的敏捷方法做更多的单元测试非常有帮助。这是矛盾的一点。 You want it as early as possible and the software needs all the components to run.

Schirrmeister:这是所有scope-dependent。敏捷的块级作品。UVM一起验证管理工作,所有这些事情让事情在一起。它给你指示板。但它有实际困难的扩展系统的水平。范围是一个问题。这就是我们处理水平重用。它是如此之大,一些软件不能被测试的大多数街区。如果你想验证环境的重新整合,这是非常复杂的。在块级别,敏捷工作。 But at the system level, you have to make sure you haven’t broken anything.

史密斯:我们还需要找到一种有效的分级方法。有一个不同的子系统和模块之间的区别,并与软件系统。很久以前,有分层输入/输出方法,至少当你定义一个街区你知道你必须测试输入和输出和检查功能是正确的。你可以做,分层次的范围定义你需要的工作。我们知道,在块级别。当你达到一个更高的层次,你不能使用一个CPU测试一致性。这不是要帮助。所以你必须拿出你需要分析子系统是什么,什么是依赖,什么是块需要包含在测试。这是你如何在敏捷的环境中。你思考的子系统,以及独特的关于一个特定子系统和测试需要设计子系统。

Schirrmeister:你说块、子系统、系统和软件。我认为总有一双硬件和软件。即使有一块是块+司机。它的子系统以及一些软件。然后SoC和各种各样的软件,即使在一些部分不知道其他人存在。这就是我们看到的在水平重用。如果所有这些事情都是集成的早期,它把硬件的人更大的压力。

史密斯:这些都是输入。当你谈论软件驱动程序,会设置一些标志,你阻止关注。这是一个输入。如果你定义的所有输入和输出在单元测试级别,您需要验证的输入,输出,过程是正确的。这个过程是简单的,因为它是独立的一部分。

Brophy:我们已经花费了大量的时间讨论过程和工具在个人行为,这是敏捷宣言的一部分。把人群和不自然的方式结合在一起,在硬件设计上的一大实验对于敏捷和硬件。我看的浪费量验证周期使用目前的工具和技术,推进设计工作。约束随机,我们发明了在早期,生成大量的刺激,没有告诉你你是否有设计工作。还有其他柔和的元素,如连接第一要对吧?我还是回到,我们学到了什么?”和“我们看什么呢?“我们一直在谈论两组。如果我们继续在同一弧我们在现在,保持相同级别的交互是不治疗或帮助。可能稳定是通过这两组进团队。你知道你的标准是什么? Is it code coverage? 100% coverage closure? It ran in a lab for 10 days? I subscribe that if it ran well in the lab, you may be further along to something that works in the end than trying to hit these other metrics. Those point to an area of under-exercised design, but if a design won’t be used for a particular configuration, it’s okay to under-exercise. Are we willing to change the way individuals work together? It’s worked for the software guys, and I’ve seen some efforts where the hardware guys are willing to get work done adopting those techniques.