系统与设计
的意见

(不成熟的)的优化

左移位和敏捷之间竞争酿造在半导体开发中,这两个是无定形的发展战略?

受欢迎程度

我看到一些材料共享来自欧洲DVCon上月表明左移位和敏捷之间竞争酿造半导体的发展。作为一个左移位后的写作和提倡敏捷开发,这种比较是有点奇怪,看多。比较两个还非晶的发展战略,是定义良好和理解。

虽然这是奇怪的,比较并非完全出乎意料。在我看来,半导体行业已经过早的习惯选择和优化工具和方法在未经证实的技术。例如…

在我的15年的相对较短功能验证,我看到过几次开发工具和流程优化支持未经证实的策略。它的发生在很大程度上约束随机验证被宣布为前沿直接测试;EDA再次上涨SystemVerilog不顾e、C和c++ Python等新的可能性;再次巩固UVM解雇VMM和OVM技术。(我觉得下一个过早优化可能涉及便携式刺激工作小组,虽然这只是一个猜测!)

这些例子中的模式是类似的:

  • 创建一个错误的二分法的技术/方法与技术/方法B
  • 声明一个市场竞争
  • 选择一个赢家
  • 标准化获胜者和/或称之为“最佳实践”
  • 优化开发工具支持获胜者之前已被证明
  • 挤压行业进入一个放之四海而皆准的解决方案
  • 排斥那些抵制

它可能读有点严厉,但在我看来历史。现在左移位和错误的二分法敏捷的硬件开发

左移位从我看到的消息,是一个策略来减少投放市场的时间为我们建造的设备。团队培养并发开发过程(即左移位项目进度);同时尽早,理想情况下,结果在缩短时间表。

很难认为左移位的概念,因为它似乎是一个合情合理地解决半导体开发中常见的时间表。它的细节虽然事情变得有点模糊。团队如何转变了不同取决于你和谁说话(不幸的是,他们如何受益)。软件确认或者是转移了吗?他们是如何转移?他们使用的工具吗?谁和什么变化吗?为什么?

左移位的多样性提议建议我整个概念目前仍然存在争议。我听到不止一个人形容的辩论是一个弱点的战略和整合通过一个标准的工具流是合乎逻辑的下一步。一个标准工具流当然,可以满足我们的自然过早优化的倾向。尤其是如果它是到达通过行业协作,一个标准的工具流无疑将被视为一场胜利。

我认为减少左移位的概念标准工具流将是一种耻辱。这些显而易见的不止有一种方法优化上市时间。因此,我看到的各种定义左移位的力量。有多个工具流给开发团队根据需要选择的选项。如果经验我们发现左移位赢家能够拖大家市场更快,太棒了!如果不是,谁在乎,只要团队有什么他们需要左移位,因为他们认为合适的。

这需要我们敏捷的硬件开发。敏捷的另一个领域是一个多样化的解决方案不仅是可能的,这是保证。的核心,敏捷是一种心态,促进响应市场需求。支持,响应性,软件历史暴露了许多不同的方法。每种方法自然是根据一组团队的具体情况。一个团队如何提高他们的反应和他们走多远,这完全取决于他们。

有著名的软件团队拥抱敏捷的例子。三个这样的例子Spotify,门罗创新年代和关键的。这些组织建立自己的反应策略,选择适合的战术战略,不断优化提高响应能力的战略和战术。重要的是,他们使用的策略可能是也可能不是行业标准和文化他们已经创建了支持战略无疑是国产的。简而言之,敏捷没有规定这些团队和他们的成功当然不是产业优化的结果。

毫不奇怪,有很多敏捷团队失败的例子。我假设每次失败来自于一个团队,也有自己的解释响应能力和策略或non-strategy-for实现它。成功率与野生可变性,它应该是显而易见的,只是选择敏捷附近扮演一个微不足道的部分决定的结果。同样,宣布左移位是完全没有意义的。这些决策后发生的一切才是最重要的。

结束这个理论的讨论,让我们回到我们的习惯创造虚假的二分法和过早优化。我认为一些行业最佳实践,如约束随机验证,SystemVerilog和UVM-are优化创建的创新都源于错误的竞争。左移位和敏捷硬件开发过早优化的新机会打破这个循环。不管你看到左移位作为一个革命性的产业趋势或空洞的使命声明,有可能提供我们保持我们的选择权。同样对于敏捷,也许我们改进软件团队的方式改善了,也许我们没有。无论哪种方式,过早优化工具和流动破坏的潜力。

时左移位和敏捷的硬件,别烦选择方面,因为没有竞争,只是潜在的。是什么将决定它的使用它们的团队,不规范的人。



留下一个回复


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

Baidu