HW和SW:谁领导谁?

过去,技术是在软件开发的世界萧条,直到他们被社区的硬件。然后他们精抛光,成为完全集成到硬件开发和验证流程。例子是绒毛和正式的。其次是试图迁移方法,如面向对象编程,这是今天大多数验证语言的基础和方法,如SystemVerilog和UVM。创建一个统一的硬件软件语言称为SystemC。这一目标可能没有被完成,但是SystemC看到广泛应用在虚拟原型。

并非所有这些技术迁移成功的最初设想,但他们仍然有重大影响。在过去的几年中,已经有越来越多的人重视的迁移一些硬件的软件开发方法。敏捷开发、持续集成和好友编程的例子。

越来越多的硬件和软件之间的依赖。它已成为难以讨论电源管理没有讨论之间的接口中定义的政策功能提供的硬件和软件。

集团主管弗兰克Schirrmeister产品营销系统的开发套件节奏20年前,回忆了类似的尝试。“我在1994年发表了一篇题为VLSI-design传输软件工程方法:统计方法。所谓的软件危机开始1968年当项目跑过去时间和预算,导致低效率的低质量的软件不符合要求。我和托马斯·德马科和弗雷德布鲁克斯,“神秘人月”的作者,他们的反应是惊人的:“请不要乱用硬件方法。硬件是完美的芯片是出去没有bug。软件的错误。软件应该学习硬件。”

在硬件世界有许多人害怕通过采用更多的软件工程实践的概念。“这是一个巨大的警钟克莱斯勒吉普了黑客攻击,导致140万年回忆说,“安德烈亚斯Kuehlmann说,高级副总裁和通用软件的完整性Synopsys对此。“安全团队是害怕,因为他们知道他们有他们的软件问题。这软件是他们从他们的供应商。供应链没有软件质量控制。没有安全控制。所有的事情已经到位,在硬件方面没有软件。”

目前还不清楚,硬件方面确实有安全方面的完全控制,但生产力呢?“2013年和2015年的IBS报告显示,软件开发成本飞涨,”哈利福斯特指出首席科学家导师图形。“当我们搬到每个节点,90 nm之间的员工和16/14nm显示增加17%所需的软件工程师。软件世界生产力改进的时机已经成熟。硬件还做了大量的工作。当看的晶体管数量每工程师从1985年到现在,我们已经五个数量级。显然我们是在生产设计。我们还没有看到一个巨大的设计工程师的数量上升。面临的挑战是在软件”。

Kuehlmann是完全同意。“大多数软件开发是如此原始的手工发展,手工测试,测试自动化几乎没有。这是一个不成熟的过程。“然而,行业似乎沾沾自喜这些问题。

接口的问题
越来越多的接口问题。这可以通过固定更好的规范,这样的团队可以独立工作,或通过寻找方法来提高团队之间的沟通可以发现问题并解决。这两个需要大量修改现有的设计和开发实践两岸的栅栏。

“规范是一个问题,我们有机会在这一领域,”福斯特说。“这经常涉及到一些非常简单,是由于没有域之间的一个可执行的规范。这些虫子逃离,直到他们带来很大的痛苦。我们没有任何域之间的正式规范。”

来源:导师图形

这是一个领域软件领先?“我一直支持使用要求或规范管理工具硬件设计了一段时间,”兰迪·史密斯说,负责营销的副总裁超音速。“这似乎非常缓慢地通过硬件设计团队。使用这些工具的好处是你捕捉specification-why的原因做出某些决定,如果以后你要改变一个规范,你就会知道这些影响是什么。它还极大地改善了您在发展中你的测试方法,因为你可以看到需求的目的是什么,而不是试图看看有人实现相比对的目的是什么。”

但一个规范应该创建并冻结在一个项目的开始吗?“我们中的许多人已经烧毁了足够多次的规范问题,我们理解我们做出的决定在发展早期猜测,在最好的情况下,“说,首席顾问XtremeEDA。“我们还没有发现的是,这些规范的很多问题都是由于决策之前我们有正确的信息。不要让所有的决定。等到你有正确的信息,然后把你的股份在地上。”

约翰逊说:“硬件软件划分,特别是半导体公司,是每个人都明白作为一个生产力的障碍。然而,大多数仍坚持认为整合团队是低效率的。也许它归结为权力斗争。组织没有进取心集成软件和硬件团队,尽管他们知道这是正确的做法。”

变化正在发生,但进展缓慢。“有越来越多的人意识到实践的采用不同的团队,“指出Ranjit Adhikary,营销总监ClioSoft。“有试图从每个团队使用的最佳实践,适应满足每个团队的需求。”

和越来越多的意识到双方学习其他的东西。

“已经变得明显,对于一些硬件专门化,软件技术提供重要的好处,”David Kelf说负责营销的副总裁OneSpin解决方案“例如,正在应用于面向对象编程UVMtestbenches,看起来越来越像软件协议栈。不计时的算法分析SystemC正在验证中软件的ide。和Agile-incremental方法被用于设计”。

采用软件开发实践
集成的硬件和软件团队的动机是什么?史密斯看到很多。“我们需要硬件设计总体上更有效率,如果工具和方法变得更加相似,它可能有更灵活的工程资源,工作问题。例如,你可以将软件工程师工作在硬件问题,至少你在哪里工作在一个较高的水平。”

虽然这听起来像一段,史密斯不同意。“我们做硬件和基于语言设计已经做了很长一段时间。在那种程度上,它看起来很像软件设计。有很多共同的范式。例如,合成看起来像一个编译器。是有道理的,我们会发现许多方面分享技术,有利于一个。”

考虑到相似,越来越有兴趣在硬件中使用敏捷开发的世界。使用“敏捷在几个成功的硬件项目,”福斯特说。“有一个密尔/航空公司传统上一直是一个严格的开发过程,搬到敏捷开发,特别是使用scrum。”

敏捷是一种不同的方式管理你的工程资源”似乎更有效率更少的错误和更少的资源需要完成实现,”史密斯说。“它还会让你的资源分配更容易,因为人们得到更多的交叉训练,在这样的方法。”

约翰逊指出,他从上层管理人员得到最常见的问题是敏捷如何提高软件/硬件共同发展?“重点倾向于开发框架,scrum是最受欢迎的。这是一个巨大的一步,凝聚整个团队,他们的工作步调。我们俯瞰是更基本的有关的沟通改进。”

约翰逊提供了一些例子,包括构建团队,软件和硬件开发人员同一报告链的一部分来帮助避免资源冲突。“这是一个根本性的改变与敏捷和scrum。同样,在硬件和软件团队与其他领导创造机会分享近期的目标。”

Kuehlmann承认有硬件和软件之间的区别。“你不能以同样的方式开发硬件软件,因为你不能每次都带出来。这并不意味着你不能有scrum和冲刺。但如果你读了敏捷宣言,客户是在一个高度增量的过程,和不同的硬件。”

大量的怀疑仍然存在。“大多数硬件工程师们困在硬件和软件是根本不同的想法和做法不翻译,”约翰逊说。“我听说多次当硬件开发人员谈论敏捷开发。假设仍然是敏捷不能工作因为它来自软件。只有当我们谈论具体的实践——测试驱动开发和结对编程,例如,人们开始意识到潜在的和放松警惕。”

Kuehlmann补充道:“你小跨职能团队形式,你有15分钟的站立会议,你冲刺两个或四个星期。这是一个聪明的组织原则,但这不是一场革命。它只是使用有趣的语言为我所做的一切。我和客户谈谈敏捷,他们认为这是一个过分吹嘘的方法。只是好操作用于大型组织的原则。”

也许它需要一个硬件的限制方面考虑。“敏捷可能适合RTL实现,但在我看来这对建筑设计分崩离析,”福斯特说。“重要的是考虑列车的产品,在定义的架构必须以这样一种方式,它不需要重构时添加新的特性或功能。敏捷并不擅长这个。这不是适合硬件架构设计。”

这是一个分歧开始的地方。“在物理设计方面,我们一直能够处理ECOs,这有点像一个敏捷方法,它允许将微小的变化迅速吸收整个系统,”史密斯说。“我们不是一个简单的方法来做,在架构或系统级设计。任何改变似乎波及一切,不一定是那么容易吸收。灵活应用于硬件系统设计和架构层面更重要的。”

大多数似乎都同意的一个领域是敏捷非常适用于验证。“敏捷测试开发工作得很好,”福斯特说。“在现实验证是一个软件项目。验证团队经常测试方面的事情不是很清楚功能或用例,所以一个迭代的过程很有道理。”

最近,配对编程的概念在软件开发中已变得很流行。”有两个程序员编写软件程序并排在一台计算机,经理看到显著的好处,”解释说,总裁兼首席执行官Oski技术。“这提供了提高设计质量、减少缺陷,减少人员风险,加强技术技能和改善团队沟通,在传统的实践。”

约翰逊表示同意。“成功的敏捷团队的心态更紧密联系生产力,在我们生产现在签字之前我们可以交付给我们的客户一天”。效率是次要的,甚至牺牲,为了生产力。一个特定的例子是结对编程。结对是更有效率。我所知道的生产团队,对每一行代码,他们这样做是因为配对生产高质量代码更快。现在试着想象一个ASIC,作为一对每一行写。“不可能!不是有效的!”

Singhal指出这可以适用于硬件开发的一种方式。“每个硬件设计师将搭配形式验证工程师。新的设计方案好处硬件设计和形式验证在许多方面。正式的验证一直是白盒测试方法,在一个正式的验证工程师需要知道里面的设计来有效的形式验证。通过与设计师搭配正式的工程师,他或她会了解尽可能多的关于设计的硬件设计师。这些知识将有利于写作的过程端到端检查来验证完成设计功能。”

另一种方法是使用持续集成。”的优点之一是,它使问题位于和调试前,”福斯特说。”之后,在这个过程中,有太多的利益相关者参与分类的过程,但持续集成解决了这个问题,指向最后一个人在改变,让他们弄清楚问题是什么。”

持续集成已成为一个司机为EDA行业。”“左移位”都是关于持续集成的硬件和软件,“Schirrmeister说。“这是硬件/软件co-debug驾驶感兴趣。过去,软件不能长大直到硅回来,但现在竞相推出的早期代表可以验证硬件的软件。这可能是变化的关键。一些元素设计的硬件和软件之间的混合,是硬件的一部分签字。”

结论
两边有很多聪明的人,在一天结束的时候,产品的成功取决于硬件和软件。成功的公司需要找到一些方法,使团队更紧密的在一起,找到最好的开发方法原本独立的发展。

“我们得到芯片是一个魔术,没有“Kuehlmann说。“我们使用一套验证工具,从多边形级别应用,电气,RTL,系统级。他们协同工作。这是一个拼凑。当我们发现一个洞,我们把另外一块。”

和紧密集成软件系统的成功发挥着越来越大的作用,我们可能需要更多的补丁。