系统分解对于处理复杂性是必要的，但是在纯功能空间中思考是困难的。
当我在写一篇关于PLM和半导体的文章时，我回顾了我在EDA开发中最喜欢的一个主题——验证与验证。我围绕它做了大量的演示，并试图说服EDA行业内的人员以及客户，让他们了解进行自上而下的功能建模和分析的优点。每个人都使用的V图是有缺陷的，会导致不必要的模拟和仿真。
我还深入参与了许多与系统级设计相关的研究工作，创建新的抽象级别，以及如何在这些抽象和当前行业使用的抽象之间进行映射。
在这两种情况下，最困难的地方之一是区分功能分区和结构分区。EDA行业诞生于PCB行业，在PCB行业中，所有的东西都已经在结构上进行了划分。你购买的组件是构建块，你组装它们来创建你想要的功能。当时的设计师对德州仪器公司的TTL 7400系列数据本烂熟于心，我还记得我上大学时得到第一本数据本的那一天。那是圣经。
这坚定地确立了该行业的结构等级概念，并且它仍然牢固地存在。这也恰好是PLM系统工作的首选方式。考虑到机械系统的性质，这也不应该是一个令人惊讶的事情，这就是这项技术的起源。
高级设计和验证工具存在的一个大问题是，它们本质上是功能性的，而不是结构性的。行为不是以同样的方式孤立起来的。例如，当您描述一个处理系统的行为时，您不需要将处理器与总线、内存和I/O进行分区。这些是实现中可能存在也可能不存在的结构部分。您定义了系统应该具有的功能。第一个问题是，很少有人知道如何功能性地思考。甚至大多数规范(本应是最终的功能文档)也常常从提供框图开始，试图从结构上划分问题。
从行为开始的第二个问题是，您必须以某种方式在流中的某个点上将功能映射到结构上。从本质上讲，这是高级合成(HLS)的一个方面，而且它很困难。在这里，您正在为一个函数定义自定义的硅。我们已经假设这个函数已经被划分了，并且您所合成的是一个叶级函数。有没有想过为什么HLS在扩展到更大的系统部分时会遇到问题?
如果你要取两个函数，并试图提出一个最佳解决方案，你必须确定函数的哪些部分是公共的，可以共享的，你必须计算出它们之间的所有时间依赖关系。此过程不可伸缩。
在90年代，当这类研究进行时，也出现了基于平台的设计概念。这本质上是一个预先设计的平台，可以在其上添加一小块自定义逻辑以获得所需的性能。再一次，映射问题很困难。一些部分被映射到固定的功能，其他部分成为在可用处理器上运行的软件，而其他部分则被合成为自定义逻辑。
现代FPGA设备也面临类似的问题，这些设备包含大量针对cpu、AI处理器、各种通信块等的强化功能。将设计映射到这些元素上是很明显的，因为输入已经在结构上进行了分区以与它们对齐，或者用户需要自己手动提供映射。
为了获得比现在更好的验证，您必须添加一个功能视图。验证本质上是两个模型的比较。其中一个是设计，另一个是验证团队开发的测试平台。您基本上不希望它们之间出现任何单点故障。否则，在两个模型中都会产生相同的问题，bug就会逃脱。黑箱验证意味着您无法看到硬件正在做什么。任何核查专家都会告诉你，这是一种效率低下的核查手段，在某些方面，白盒核查可能更好。
从结构设计转向功能设计已经太迟了，但验证已经朝着这个方向前进，这应该是一个目标。功能规范——可能来自PLM系统——应该是驱动验证的东西，它成为安全、可靠性和质量的焦点。它是可以持续跟踪的东西，是唯一可以为进度、风险等提供明确指标的东西。设计流程无法提供这些。
半导体行业在很多方面都是独一无二的。PLM管理的系统与其他部分最大的不同之处在于失败的代价。带着一款不能工作的产品去生产要花很多钱，更重要的是，要花很多时间。与此同时，我们都知道，达到100%的信心意味着你永远不会进入制造业。
另一个不同之处在于，人们对电子设备的期望会随着时间的推移而变化。仅仅验证最初指定的功能是否有效是不够的。预计电子技术将适用于未来任何设想的功能。这意味着核查永远无法完全发挥作用。它的一部分可以是黑箱，自上而下的功能验证，但如果我们希望硬件在制造后能够适应变化和增加新需求，那么必须保留一个白箱，自下而上的验证的方面。
我相信每个工程团队都认为他们所做的是独特的、特殊的、不同的，因此他们应该能够以自己的方式做事。当我看到PLM时，我看到了一些不足以处理半导体行业的复杂性以及对它的要求。我不确定高管们可能渴望的简化观点是否真的存在，但这不会阻止他们朝着这个方向慢慢前进。
如果他们这样做了，在我看来，他们可能会在硅领域取得更多的成功。但他们也会有一些推迟的问题，这些问题只有在未来试图改变任何事情时才会被发现。
|
|
|
|
|
|
|
|
留下回复