原创 可追溯性应该由谁负责？

作者： Paul Graykowski

可追溯性有什么好大惊小怪的？如果它如此重要，是否应该由合规部（compliance group）来处理？大多数设计和验证团队成员都倾向于将其委派给单独的团队，但这是不可能的。对于开发团队来说，并没有一个专门组织来持续检查可追溯性。更合理的方法是将可追溯性要求纳入常规设计和验证方法中，并最大限度地使用自动化来支持。

反对可追溯性的另一个论点可能是组织的客户没有要求支持可追溯性。或者那些客户只要求简单的需求合规证明。但无论如何，以安全为中心的市场，例如汽车、航空航天和医疗，都认为可追溯性要求是必须的。反对可追溯性的最后一个理由可能认为此问题被夸大了。本文分享一些例子来反驳这种一厢情愿的反对。可追溯性是每一个人的问题。

路径可追溯性必须从系统需求到验证进行跟踪。

在一个成功的片上系统 (SoC) 产品发布之后，下一个合乎逻辑的步骤是扩展该产品家族。这可能是一个ASIL B版本的汽车前照灯，或一个ASIL D版本的关键安全系统，如防抱死刹车，也可能是一个低功耗版本的不太强调安全性的卫星应用。IP重用对于降低开发成本和在三个市场全部快速推出产品至关重要。一个明显的策略是将设计 RTL参数化， 以针对每个目标进行局部优化，同时仍然在所有三个选项共同的大部分设计中共享设计和验证改进。

上述汽车规范需要通过奇偶校验、纠错码 (ECC) 和其他技巧来缓解安全问题。 ASIL D 应用必须支持具有冗余 CPU 和相关比较器的关键逻辑中的锁步计算。同时，低功耗版本需要电源岛和保持逻辑（retention logic）。这些特殊需要可以巧妙地融入 RTL 以响应顶级条件编译转换。

但是，每个实现还必须符合客户全部需求，而这些需求与巧妙的重用策略是无关的。一位客户在 IP 上要求 32 位接口。另一个期望通过该 IP 的流量更高，需要 64 位接口。由于这些客户处于不同的市场，设计团队也需要考虑如何将这些条件配置选项纳入其中。随着更多选择的出现，从简单的原始集合演变而来的编译选项变得越来越混乱。更多的可能性可能为无法在验证中发现的不一致创造了更多的机会。关键客户的选项设置错误的真正影响可能要等到对硅样品进行软件测试后才会显现。

安全岛，监视和控制应用 IP

SoC 供应商和系统制造商可能在某些子系统中共享某种级别的架构所有权。例如，安全岛旨在支持汽车子系统的 ASIL D 认证。这必须控制 SoC 中关键 IP 的动态诊断测试。安全岛先隔离 IP，启动诊断测试，然后在测试通过或采取补救措施处理故障后，使 IP 重新联机。 Tier 1 或 OEM，而不是 SoC 制造商，决定应该采取什么补救措施。为了管理这些目标，系统构建者需要提供架构决策信息 - 例如，添加控制和状态寄存器 (CSR)。

虽然某些系统要求从最初就很明确，但其他系统要求却可能仅在 SoC 设计已经顺利进行到系统原型测试期间才出现。这些要求条件会产生一些后期规范变更，因为 SoC 团队必须管理许多其他问题，这些后期变更的瑕疵可能会悄悄溜过。在规范发生变更时，验证也不一定能捕捉到这类问题。

在内存映射和 IP 寄存器映射、电源管理选项、绑定配置选项等方面，还有许多其他问题可能被疏忽。在产品和客户自定义变体，以及设计和规范演变方面，即使是管理最好的设计团队也可能无法捕捉到需求和实现之间的每一个脱节。

通过SoC 设计感知的可追溯性，这些问题得到显著缓解。它将从系统级到体系架构派生的需求，以及团队在 RTL 中实现的需求，和验证规范的测试连接起来。设计人员或验证人员在检查 RTL 片段或测试相关需求时，更容易发现不一致之处。即使问题可能不容易被测试出来，该测试值仍然有效。开发团队对于系统级需求的洞察力可能足以引发对危险信号的关注。

反过来，有时设计选择中的约束可能会迫使对需求进行更改。这不一定是致命的。如果架构师及早了解变更，系统设计团队可能能够适应。双向可追溯性对于实现 SoC 供应商和系统制造商之间这种级别的沟通至关重要。

可追溯性影响 SoC 设计和验证中的每个人。但它不应该是痛苦的工作。它可以真正帮助避免后期危机和返工，它是建立客户信心的绝佳工具。想了解更多？请查阅 Harmony Trace product。