来自sondrel

在SoC开发早期，产品经理、系统架构师和其他技术利益相关方会讨论和阐述产品需求。每个团队都想拥有适合自己的理想模型，比如，产品经理通常关注的是产品的最终用途和应用领域。而系统架构师则关注的是需求的功能、执行和实现。

在“需求获取阶段”，我们会识别、制定和记录所有已知的功能和测试指标，这其中也包含一个清晰完整的性能指标提案。另外，还会涉及到那些目前尚未被完全理解或是后期可能会纳入的功能，并藉此确定和规划完成这些功能的定性及定量所需的任务。

在计划完成之后或者在计划开始时尽可能完成，基于设计团队的输入信息，系统架构的需求会贯穿整个需求分析阶段。架构设计规格书是这一迭代过程的输出。它将包含所有功能的架构设计，功耗估计，以及确定芯片的性能和面积。

初始阶段的设计实现，确保了规范和架构更高的准确性和有效性。此外，还确定了指导设计选择所需的敏感性。

架构分析包括架构探索、IP选择/规范、需求验证和项目执行计划的生成，主要任务将在后期进行阐述。

候选架构的架构探索是一个重要的组成部分。通过建模方案和评估已知或参考用例，动态允许定义系统原型，并提供资源分配（内存、总线布局数据/控制路径等）来完善架构设计。

虽然在该过程中会评估和验证功能的各个方面（连通性、时序和性能等）以确保设计的正确性，但在后期阶段会使用更详细和准确的模型来确定和纠正在架构实施期间的潜在错误。

本文的其余部分涵盖了架构阶段的模型使用。

SoC架构研究的初始部分是一种用于获取Soc所需执行的一个或多个应用实例和数据流的缜密的方法。在产品定义阶段早期为了与利益相关方沟通并就需求达成一致，准确完整的用例描述很必要。

系统架构师拟定出产品需求，以便技术和非技术方面的利益相关者能够在未获得过多的技术细节的情况下，了解产品意图和架构选择。

图 1 以 8 个步骤概述了这一协作过程：

1.产品经理针对潜在的SoC解决方案进行市场分析、行业趋势和产品需求定义。

2.通常通过演示文稿、电子表格或文档，向系统架构师传达产品用例方面的需求。

3.在建模流程中，需要将需求转换为DSL的形式。

4.工具生成可执行规范和可视化用例。

5.工具还生成架构研究用例所需的精确到时钟周期的 SystemC 模型。

6.系统架构师核查仿真结果，并将这些结果逐步收敛到优化后的SoC架构。

7.系统架构师与产品经理交流检查结果。

8.产品经理可以决定修改这些需求，或与系统架构师协作，进一步改进侯选SoC架构。

行业趋势表明，基于视觉的应用越来越普遍，将传统的计算机视觉技术和基于神经网络的人工智能推理技术结合起来，融合了两个阶段的结果。

图 2 显示了典型的自主视觉用例数据流图，包含节点处理和边缘计算数据流。具体阶段包括：

•帧曝光——摄像机传感器拍摄视野快照的时间间隔。图像传感器可以配置为全局快门或滚动快门模式，每种模式都有与之相关的曝光周期。

•帧接收——通过 MIPI CSI-3 等实时接口将成行的图像像素发送到SoC的时间间隔。

•图像调节——在实际计算阶段之前，基于接收到的数据而对图像进行的任何预处理、过滤或汇总步骤。

•传统的计算机视觉——公认的视觉处理算法，例如针对立体视觉的摄像机校准、运动估计或单应运算。

•计算成像——通过像素云或深度图估计等定制的处理步骤增强了视觉算法。

•人工智能推理——基于神经网络的图像处理，用于语义分割、对象分类等。

•数据融合——末级传感器融合和跟踪，也可能包括格式化或打包处理。

•数据发送——可以恒定或可变的数据速率，按照总线和接口标准或通过 MIPI CSI-3 等实时接口进行。

与每个处理阶段中相关的为需要指定的参数，以便可以正确配置动态模拟模型。这些参数通常描述了：

1.读取直接存储器访问的特征：块数、块大小、内存地址和内存访问模式。

2.处理特征：任务执行其处理所需的延迟。

3.写入直接存储器访问的特征：块数、块大小、内存地址和内存访问模式。

图 3 显示了该信息最好以表格形式描述，其中行表示处理任务，列表示与任务相关的参数。

用例图也可能有一个嵌入式子图，这通常是人工智能应用程序用神经网络计算图来描述算法的情况。图 4 显示了尺寸较大的用例图中的子图。描述子图的方法采用相同的表格格式，可能出现在大图的任何部分，而不仅仅是人工智能处理技术。

如图 3 所示，以表格格式捕获的用例参数足以描述处理阶段之间的数据流和给定阶段的处理延迟的应用意图。将图形绘制到表左侧的另一个好处是能够直观地理解数据流，以及处理阶段中节点之间的关系。该方法甚至对于大型图表也适用，并提供了易于获得的补充信息（如果需要）。

独立于应用用例的部分为硬件平台的模型。如用例模型所规定的，该硬件平台的模型将进行数据传输和处理延迟。在通常情况下，该硬件平台模型具有以下功能：

1.生成并启动符合协议的本地内存、全局内存或任何输入/输出设备相关的事务。

2.在各级分层互连中仿真仲裁延迟。

3.按照选定的联合电子设备工程委员会内存标准，在内存控制器模型中仿真内存访问延迟。

图 4 显示了硬件平台的框图。除了仿真模型之外，该硬件平台构成了制定片上系统架构规范的基础。

到目前为止，我们定义了两种仿真结构——应用用例模型和硬件平台模型。我们现在需要明确说明如何将用例映射到硬件平台子系统，也就是硬件平台模型中的子系统会运行应用用例模型的哪些任务。图 6 显示了将用例的任务映射到硬件平台的子系统的全仿真模型。

图 6 中的全系统模型为用于用例和硬件平台探索的动态性能模型。

在仿真过程中，会遍历用例图中的所有节点，其中，子系统的主处理器会生成并启动一个或多个从处理器的内存事务。因此，由于争用、管线阶段或未完成的事务而导致的延迟会应用于每项事务，这些事务会将这些延迟时间累计到现行任务的总持续时间中。

图 7 中的时间仿真视图显示了在单次遍历应用用例期间的每项任务的持续时间。我们将整个链的持续时间定义为用例延迟。可视化地显示硬件平台、应用用例和时间模拟视图便于直观地了解，因此通常对不同的利益相关者十分有效。

现在，进行单次遍历不再有效。因此，我们决定对环境的设置情况进行一些健全性检查。为了进行全面的系统性能探索，需要进行多次遍历。在该设置中，我们分两个仿真阶段进行。瞬态阶段为充注管道时的状态，然后是管道充满时的稳定状态。因此，系统处于最大的争用状态。

图 8 突出显示了在系统处于最大争用状态时的模拟的部分情况。在稳态期间，我们会收集度量指标，以了解系统的性能特征和界限。这将指导用例和硬件平台进一步优化和探索。

图 9 显示了硬件平台的两种配置情况和生成的时间视图。我们通过使用直接流接口设置用于低延迟的系统，从而避免在 DDR 内存中进行数据交换。

再者，可视化地显示这两个系统的好处是有助于清晰查看，以便所有的利益相关者都能够在获得一些指导的情况下理解这些系统。

完整的架构探索方法涉及用例和平台需求、模拟的度量指标、关键性能指标和报告。

图 10 按照以下顺序显示了信息流：

1.首先定义应用用例。在这里，用于捕获用例的表格形式至关重要，如图 3 所示。

2.声明与应用实例相关的用例需求。

3.将用例需求转换为关键性能指标，这些指标是仿真运行的预期测量阈值。

4.从仿真过程中收集仿真的测量指标。

5.通过检查测量指标是否满足其关键性能指标而生成用例性能汇总报告。

类似流程适用于硬件平台需求，其中：

1.首先定义硬件平台。

2.说明平台需求。

3.从需求中提取平台的关键性能指标。

4.收集平台的仿真测量指标。

5.通过比较测量指标和关键性能指标生成平台的性能汇总信息。

作者：Piyush Singh, SOC Architect