瀑布式开发流程不再适用于芯片设计,但统一的工具流程可能无法解决问题。系统设计中越来越多的依赖性迫使公司、人员、工具和流程变得更加协作。设计和EDA公司必须适应这种新的现实,因为任何人都不可能独自完成所有工作。此外,制造和封装中发生的事情需要预先考虑,在设计阶段设计出来的东西在制造或测试中可能不会产生足够的效果。而且用例和应用可能会对现场的性能、散热和可靠性等一切产生独特的影响。一切都在向左和向右转变,沟通需要在两个方向上进行。
"如果你考虑到众所周知的墙,你再也不能把东西扔过去,说它已经成为别人的问题,"Synopsys数字设计集团产品营销总监Shekhar Kapoor说。"你真的需要在做设计的时候解决所有这些问题。这要从RTL开始一直往下看。"
有些人认为从RTL往上的问题同样重要,包括系统设计、机械、软件、光学和许多其他过去被分开的学科。
"行业的历史曾经有很多积分工具公司和初创公司,创造积分工具,那是解决问题的最好方法,"Cadence公司负责市场和业务发展的企业副总裁Michal Siwinski说。"这开始转变为更多的端到端流程。就像我们的客户开始变得更加垂直整合一样,跨多个产品和领域的整合概念在我们的业务中变得绝对必要。"
相互依赖导致协作水平大大提高。"我们的组织已经发生了巨大的变化,"西门子业务Mentor的IC验证解决方案部门副总裁兼总经理Ravi Subramanian说。"我们看到这种情况不仅发生在我们工作中的'做什么'上,而且还发生在'怎么做'和'谁'需要做的问题上。我在所有这些方面看到的是越来越多的领域的引入,这些领域要么合并,要么需要在定义'需要做什么'和'如何做'之间进行一些合作。这最终是要求公司,以及公司内部的团体,以以前没有的方式进行工作和合作。"
界定流程变得越来越困难。"几乎在每一个场景中,因为客户使用流程的方式千差万别,所以没有一个流程,是许多不同的味道,"Cadence的Siwinski说。"解决一个移动手机的问题,和解决一个数据中心机架的问题是完全不同的。所涉及的工具是一样的,相当一部分技术是相似的,但是优化,进而推动的需求,会有很大的不同。"
依赖性
业界早已意识到硬件和软件之间的依赖性,而且随着时间的推移,这些依赖性越来越紧密。"我们终于有了所有的工具来允许这种合作发生,"Synopsys公司产品营销高级总监Johannes Stahl说。"但它需要管理层的关注来实现它并影响设计。我仍然看到一些公司的软件团队在等待芯片。他们用一些上一代硅片工作,他们不想参与硅片前的工作。所以在一些公司里,进化已经成功地发生了,而在另一些公司里,进化还在继续。"
软件和硬件需要拉近距离,才有可能愿意合作。"程序员是否意识到他们所做的事情会影响到你的权力包络?"Imperas软件公司的营销副总裁Kevin McDermott问道。"他们经常有这种象牙塔的观点,认为他们可以不考虑硬件在引擎盖下的表现。但如果我们能在他们做出某些选择时给予他们反馈和见解,他们就会意识到自己何时走错了路。将其与进入一个硬件板或构建一个FPGA原型的相关努力进行比较。你不能那么细化,也不能那么分离。如果你提供即时的反馈,这将是一个硬件/软件的权衡。"
随着接触点的增加,让它们保持分离将完成团队在优化方面的成本。"左边的转变,以及软件开发周期与硬件开发周期的平行化,正在发生变化,"Synopsys公司虚拟原型的产品营销高级职员Pat Sheridan说。"这些团队之间的接触点越来越多。考虑一下功率分析,在这里,你要确定软件执行的关键窗口,在那里你要分析功率。这是一个非常明显的例子。很多其他的接触点会在验证流程中。"
其他人也有类似的看法。"今天的SoC正在成为软件工作负载驱动,"Mentor的Subramanian说。"因此,计算机架构师不是孤立地工作,看一套东西,你实际上必须看工作负载,这将是功率和性能的基准,并驱动SoC架构。"
功率本身在很大程度上取决于许多其他因素。"电源是多学科任务的一个很好的例子,"Synopsys的Sheridan说。"在电子系统或SoC中,有许多人参与对功率或能效的理解。你有架构师,你有软件团队,你有硬件人员从验证的角度来看,然后你有实施团队。所有这些不同的层次都可以对提高功率和使系统更节能产生各自的影响。"
验证正一步步接近一切。"我们看到实施人员越来越接近验证人员,"Stahl说。"但有一个不同的重点。验证团队主要对快速探索RTL的变化感兴趣。实施团队想知道他们可以从后端流程中挤出什么。所以,他们有一些互动,事情要合作,团队要一起讨论。这个话题可能是最有趣的话题之一,你必须让许多不同的人在一个房间里讨论权力流。"
随着时间的推移,越来越多的团队被拉近了距离。"当涉及到芯片封装接口时,可以看到协同工作的问题,"Fraunhofer IIS的自适应系统工程部门的先进系统集成的组长和高效电子学的部门主管Andy Heinig说。"通常情况下,基于公司内部的组织结构有独立的设计和生产主题的孤岛,存在很大的差距。这在两个课题之间建立了巨大的障碍。通常系统工程师会画出一个可能的解决方案的草图,但没有机会构建系统,因为基本技术无法按照图纸结合。目标必须是提供所有必要的信息。"
这包括其他领域,如测试,这可以被认为是SoC的另一个用例。"重要的是不要在测试时烧毁芯片,"Synopsys公司产品营销高级总监Robert Ruiz说。"测试会产生更多的活动,增加功耗,或者更有可能产生IR降,因为一般来说,与标准任务模式相比,芯片会在更高的功耗下进行测试。"
在后端有越来越多的依赖性。"为制造而设计(DFM)过去是,现在仍然是一个问题,"Synopsys公司营销总监Shekhar Kapoor说。"有越来越多的制造规则,你需要在流程的早期考虑到。产量设计(DFY)是另一个。我们必须在前面考虑所有的DFx问题,从融合的角度和相关的角度。你需要一些东西把它们都联系在一起,因此就有了通用数据模型的整个概念,这是一项非常基础的技术。"
最近,包装也变得紧密结合起来。"有很多工具已经被放在了分层设计,以及大规模的分层分析中,"Kapoor说。"现在,当你把它们抽象到3D-IC级别时,就会产生更多的复杂性。你需要了解对IP件的影响。高速接口会影响你如何对设计进行分区。我们需要在芯片级使用的技术,如分层楼层规划,而现在它们必须考虑到这些接口。而这对分析方面也有自己的影响,比如热。"
它一直延续到系统。" 我们有一些人,他们正在构建解决方案,回来说,我需要在这个特定的设备中定义外壳,"Subramanian说。"这需要一路走来,关于早期的知识,但也将多个学科结合在一起。这方面的两个新驱动力是在物联网边缘领域以及汽车领域。"
图1:整个设计流程中的系统级考虑因素。
验证的影响
随着时间的推移,验证已经从单纯的RTL功能验证扩散到也是多学科的。"这对于动态功率分析尤为重要,"Sheridan说。"系统上运行的软件正在定义活动的关键窗口,这将是最重要的理解。让仿真和模拟团队与做功率分析的人员一起工作,确实有助于你关注软件活动的正确窗口,然后你可以根据正确的信息做出决策。"
许多后端实施任务也正在变得矢量驱动。"实施往往更注重细节,"Stahl说。"他们会使用较小的向量集,但它们需要是正确的。验证人员更多的是看整体情况。他们在看功率时,会采取一百万次的循环。他们正在寻找大的变化和大的系统效应。他们需要的是数量,而实施人员则有质量方面的考虑。"
通用引擎
随着时间的推移,引擎之间的距离越来越近,从而使迭代周期最小化。前期掌握更多的信息可以让我们更早地做出决策,降低在流程后期发现问题的风险,"Ruiz说。"准确性来自于你所使用的引擎。设计决策会应用约束条件。你何时做出这些决策取决于你在哪里能获得最大的收益。你可以决定在前期做出哪些决策,哪些决策可能最好推迟到流程的下游部分。"
这也可能受到正在进行的设计类型的影响。"你希望系统设计在系统设计周期中尽可能长的时间内保持开放和灵活,"MZ Technologies的首席执行官Anna Fontanelli说。"你需要避免局部优化,而是要考虑系统感知的优化。"
除了优化设计之外,公司还要考虑如何优化流程。"这取决于公司是否试图推动信封,"Siwinski说。"当有人试图推陈出新,创造最好的产品时,他们必须在前期做出一些这样的决定。有时,他们会通过增加另一个重新旋转来降低风险,或者确保他们达到一个早期的原型--甚至只是有一个特定的项目,可能不会见天日。他们会考虑到这个实现可能不值得生产。但我看到他们还是会走得非常快。在其他情况下,你不需要推动功率/性能曲线,你有更多的灵活性,人们可以将一些决定推迟到以后。"
关键的问题是何时做出这些决定。"这真的归结为你想在产品开发过程的哪个阶段回答什么问题,"Subramanian说。"然后你必须看看做出这些决定需要什么信息。左移的概念是关于在时间上更早地做一些事情。我们需要找到切实可行的方法来更早地回答这些问题,因为要更早地回答这些问题往往需要拥有正确的模型,拥有正确的分析能力。这正在推动新的能力和工具的创建,由周期中更早地可用的模型类型所驱动。"
转变EDA
历史上,EDA一直是在点工具和完全集成的流程之间摆动的钟摆。今天,这个钟摆正在远离完全集成的流程,考虑到相互依存的程度越来越高,这听起来可能是反直觉的。
"几乎永远不可能在内部拥有所有的引擎来进行你所需要的所有分析和优化,"Kapoor说。"如果你从芯片级,到SoC级,再到系统级(随着异构系统的发展,系统级预计会有很大的增长)进行推断,它包含了很多东西。它包含了芯片设计、板内设计、多物理学、计算算法等方面的经验。公司在某些领域会有优势,比如实施或分析,但需要有很多合作关系,以确保你能让整个系统发挥作用。我们需要有信息的交流,标准的接口,共享所有这些接口,以及技术。这一切都将是非常基础和需要的。"
Subramanian同意这一点。"你看看你想要解决的每个领域或问题,然后你看看相互之间的依赖性。这些解决方案需要提供给客户,以便能够解决他们的问题,而这可能只有通过将两个领域整合在一起才有可能。客户都希望有一个能用的解决方案,不管是一家EDA公司的还是多家公司的。他们并不关心。他们希望有一个能用的解决方案,他们希望工具能够互操作,并且能够创建流程。现在的实际情况是,情况并不总是如此,但大客户在推动这方面的工作方面非常有效。"
越来越多的公司在一起工作,同一公司内部的团体也在一起工作。这正在改变许多公司的经营方式。但是,假设没有人能够成为所有领域的专家,EDA公司如何选择在哪些领域投资,在哪里合作?"这是摆在所有公司面前的问题。"Subramanian说。而目前,还没有明确的答案。