复杂性对SoC设计成本和可预测性的复合影响

设计人员预测完成设计所需的时间和资源、设备的性能以及何时可以交付给客户的能力受到影响。即使使用最好的工具，一些 SoC 设计趋势也会极大地影响可预测性，从而影响总体开发成本，如图 1 所示。

图1

导致这种不可预测性危机的问题分为四大类：

系统复杂性：尽管设计人员了解各个 IP 内核，但他们仍与系统复杂性作斗争，这来自 IP 内核交互的乘法效应以及与其操作相关的信息流。

抽象级别不当：用于描述功能块的语言和技术没有规定来描述系统中的这些功能交互以及这些交互如何影响整个系统。

先进的电源管理技术：使用动态电压和频率缩放对传统设计方法施加了额外的限制。

工艺可变性：随着技术下降到 65 nm 以下，处理工艺可变性是非常不可预测的，特别是对于传统技术。

系统复杂性

复杂性看似隐蔽，因为鉴于先进工艺技术的能力，它似乎是一个容易解决的问题。随着今天大量可用的晶体管，似乎可以构建任何可以想象的东西。那么为什么处理系统复杂性如此困难呢？原因是，虽然可用晶体管的数量大致呈线性增长（不考虑利用率），但引入不确定性并因此带来可预测性挑战的系统交互会因乘法效应而增长。这种乘法效应基于 SoC 设计中的几种复合趋势。

多处理器

首先，从单处理器系统到多个异构和同构处理器的转变正在增加系统交互，从而增加了复杂性。现代 SoC 通常包含一个或两个以上的处理器。除了编程挑战之外，协调这些多处理器硬件驱动的活动给设计人员带来了困难。设计团队必须了解一些问题，包括：

对共享资源的真正需求是什么？

使用这些共享资源的合理目标是什么？

是否有可能让处理器忙于一组资源限制？

本地高速缓存过多或过少的总体影响是什么？

是否对所有预期应用程序进行了充分建模，以确保它们在所需的处理器和共享资源集合上按预期运行？

为了了解并随后预测更改对共享资源的影响，一些最先进的 SoC 设计团队已经使用 SystemC 或类似语言构建了完整的系统模型。建立和维护这种复杂程度的投资可能超出了主流 SoC 设计团队的能力范围。即使使用这种方法，预测底层硬件的实际行为的能力（避免因后期实施意外而导致的昂贵的迭代周期所必需的）也由于这些建模环境（有限的准确性）而受到限制。

接口

传统的 SoC 由人类交互时间和低性能数据移动驱动的输入和输出发生了巨大变化。SoC 上的接口数量、I/O 流量类型以及与系统中其他功能的 I/O 交互变得更加复杂。

例如，用于联网家庭的设备可能具有无线网络、传统有线网络、进出外部存储的数据移动以及同时运行的视频和音频输出服务。为每种可能的用途提供最大的能力——全速率千兆以太网，同时全速率访问磁盘控制器、无线以太网控制器和 USB 2.0——并非不合理；问题是这些接口将如何与复杂的处理功能交互？在此示例中，将 I/O 与处理功能相结合可能涉及 16 个 I/O 流与六个主要处理功能同时运行，所有这些都共享公共 DRAM。这种情况比任何一种交互本身都复杂 100 倍。

IP复用

SoC 设计团队可以奢侈地为设计中的所有 IP 使用单一标准接口的日子已经一去不复返了。几乎所有 SoC 团队都面临着解决内部开发的旧 IP、内部开发的新 IP（通常由不同的组或部门）以及可能遵循不同接口标准的外部来源 IP 的互操作性问题的挑战。

要使 IP 重用策略取得成功，各种标准之间的自动转换至关重要。实现 IP 重用，包括测试套件、制造设计/良率设计和可靠性，排除了针对每个系统使用修改 IP。修改 IP（包括接口）会给设计进度增加太多风险。设计团队必须保留大部分 IP，而是对系统中的其他 IP 进行调整，通常在自定义桥接器和总线适配器中。但是，手动执行此操作会使过程不可预测且不可扩展。一旦接口达到大于 1:1 的对应关系，交互复杂性就会迅速上升。

具有三种类型接口的简单系统（对于大多数 SoC 团队来说是典型的）涉及六种转换：三种用于请求，三种用于响应。任何界面特征的变化都会将六种转换乘以必须考虑的不同特征的数量。人为地限制这些特性是不现实的，因为这样做会导致简单功能的过度设计或妨碍复杂功能的性能。处理这种复杂性增加了可预测性的挑战。

流量和带宽

复杂 SoC 中管理的流量的性质和数量也发生了很大变化。诸如视频和音频之类的速率关键流量通常与面向处理器的流量混合在一起，后者往往具有更严格的延迟要求并以突发形式出现。再加上任何实时要求，例如可能对网络流量施加的要求（必须在可用时提供千兆以太网以避免丢失数据）。在相互交互的各种功能中为这些不同的流量类型提供服务是很困难的。

然后，数据量会加剧这种复杂性。高清视频需要至少 6 倍标清视频的带宽。在真实硬件的环境中分析这一点非常耗时，例如，运行足够长时间的模拟以确定一组特定的 IP 功能及其交互是否可以正确管理视频帧是不切实际的。因此，SoC 设计团队专注于他们认为是最坏情况的几种情况，并希望一切正常。然而，希望在 SoC 设计中并不是一个可预测的数量。

操作模式

几乎所有 SoC 都以不同的模式运行。这些操作模式通常涉及以独特方式交互的各种关键 IP 功能。不同模式的数量增加了分析和确定如何正确操作一组特定交互的复杂性。

例如，机顶盒 SoC 可能具有媒体提供两个多媒体流的模式：一个流向显示和音频系统进行处理，另一个存储在磁盘上。这种模式不同于硬盘提供输出功能的模式，其中一个媒体输入被放入存储信息内的图片窗口中。另一种模式可能会在解码和显示一个或两个媒体输入时从本地磁盘向网络端口提供信息。可以很容易地看出，模式的数量极大地扩展了互操作功能和数据流的集合。确保所有这些模式都能正常运行，这使 SoC 设计团队面临的任务更加复杂。

这些系统复杂性问题相互叠加。即使设计人员需要重复设计、实现或验证的一部分的可能性很小，但在所有这些问题上累积的小百分比使得通过设计流程中的一个或多个步骤进行多次迭代几乎是必然的要求。

抽象级别不当

SoC 设计社区继续依赖于为描述由门组成的各个功能而构建的语言和工具。这是一个很大的限制，因为这些语言（Verilog 或 C/C++/SystemC）不包含描述 IP 功能所必需的语法、概念和结构，以及复杂 SoC 中的交互。

如前所述，系统是复杂功能的组合，这些功能以各种方式进行交互，具体取决于所提供的整体功能。为了正确描述和分析系统交互，设计人员必须有一种方法来描述对正确操作至关重要的系统级方面。这可能包括重要时间窗口中的带宽特征、特定操作模式内的流量并发、构成操作模式的不同交互以及交互影响彼此的方式。缺乏将这些方面捕获为可以验证的需求的方法会导致手动解释的硬件的低级表示无法按预期执行的可能性很大。

先进的电源管理技术

在 65 纳米及以下部署的复杂电源管理方法专注于控制工作频率，同时改变部分 SoC 的电源电压。虽然这种能力有巨大的好处，但整个部分可能会完全关闭以消耗“零”功率，并且对系统级设计的影响提供了额外程度的复杂性。

这不仅使时钟分配和管理变得困难，而且还对必须如何控制数据移动施加了限制，具体取决于设备的哪些部分可能正在运行、未运行或以降低的速率运行。除了关闭之外，可以以两种不同速率运行的设备的一部分使系统交互设计和分析复杂化了三倍。至少，子系统隔离、时钟管理、电源关闭和适当的子系统恢复所需的附加电路使设备设计的所有方面都复杂化。同时，补充操作点增加了系统分析的复杂性，类似于或与操作模式复杂性相一致。

过程可变性

随着工艺技术继续向 65 nm 以下移动，单个设备操作的可变性会在本地和整个设备上引入电路功能和性能的不确定性。虽然统计静态时序分析和其他技术有助于分析可变性影响，但它们不能提供减少可变性影响的解决方案。

为了适应可变性，额外的余量用于确保电路在面对可变性时能够正常工作。这种额外的余量会降低性能或功能增益，否则这些增益可能会通过更高级的流程实现。最终结果是设计团队能够满足在设计开始时设定的目标的保证较少。当然，直到设计后期才知道这一点，这可能会导致设计流程中某些步骤的迭代成本高昂。

总之，这些问题在当前 SoC 设计中引入的复杂性将可能的交互和需要考虑的情况的数量增加了几个数量级。这个因素，加上缺乏适当的方法来指定系统级交互并在适当的抽象级别对其进行分析，使得设计 SoC 成为一项非常冒险、不可预测且因此成本高昂的业务。

审核编辑：郭婷