用设计感知的可追溯性弥合需求和实现之间的脱节。
关于可追溯性的大惊小怪是什么?如果它如此重要，是否应该由合规小组来处理?对于大多数设计和验证团队成员来说，委派给一个单独的团队将是首选，但在这种情况下是不可能的。可追溯性停止了大哥组织不断地监视开发团队。更合理的方法是将可追溯性需求折叠到常规的设计和验证方法中，并通过最大限度地使用自动化来支持。
反对可追溯性的另一个论据可能是组织的客户没有强制要求支持。或者那些客户只要求满足需求的简单证据。无论如何，以安全为中心的市场，如汽车、航空航天和医疗，都希望可追溯性要求是必须具备的。反对可追溯性的最后一个原因可能是问题被夸大了。本文将分享一些例子来反驳这种一厢情愿的反对。可追溯性是每个人的问题。
路径可追溯性必须跟踪，从系统需求到验证。
在一个成功的片上系统(SoC)产品发布之后，下一个合乎逻辑的步骤是扩展产品系列。这可能是用于汽车前灯的ASIL B版本，用于防抱死刹车等关键安全系统的ASIL D版本，也可能是用于卫星应用的低功耗版本，安全性较低。重用对于降低开发成本和在这三个市场快速发布产品至关重要。一个明显的策略是参数化设计RTL，为每个目标进行局部优化，同时仍然在所有三个选项共同的大部分设计中共享设计和验证改进。
上述汽车规范需要通过奇偶校验、纠错码(ECC)和其他技巧来降低安全性。ASIL - D应用程序必须在具有冗余cpu和相关比较器的关键逻辑中支持锁步计算。同时，低功耗版本需要功率孤岛和保留逻辑。这些特殊的需求可以巧妙地嵌入到RTL中，以响应顶级条件编译开关。
然而，每个实现还必须遵守一组客户需求，这些需求与巧妙的重用策略无关。一个客户在IP上指定了一个32位的接口。另一个期望通过该IP获得更高的流量，并希望使用64位接口。由于这些客户处于不同的市场，设计团队也要考虑如何加入这些条件配置选项。随着越来越多的选择出现，编译选项从简单的原始集合演变而来，变得越来越混乱。更多的可能性为不一致创造了更多的机会，而这些不一致可能不会在验证中被发现。关键客户的选项设置错误的真正影响可能要等到对硅样品进行软件测试时才会出现。
一个安全岛，监控和控制应用ip。
SoC供应商和系统构建者可能在某些子系统中共享某种程度的架构所有权。例如，一个安全岛的设计是为了支持汽车子系统的ASIL D认证。这必须控制SoC内关键ip的在线诊断测试。安全岛隔离IP，启动诊断测试，然后在测试通过或采取补救措施处理故障时将IP恢复在线。Tier 15或oem，而不是SoC制造商，决定应该采取哪些纠正措施。为了管理这些目标，系统构建者需要对体系结构决策进行输入——例如，添加控制和状态寄存器(csr)。
虽然一些系统需求最初会很明确，但其他需求可能只有在系统原型测试期间才会出现，此时SoC设计已经在进行中。在SoC团队必须处理的其他问题中，这些情况会导致后期规范变更。当规范发生变化时，验证不一定会捕获这类问题。
在内存映射和IP寄存器映射、电源管理选项、连接配置选项等方面还有许多其他可能的疏忽。即使是管理最好的设计团队也可能无法捕捉到产品和客户变体以及设计和规范演变之间需求和实现之间的每一个脱节。
SoC设计感知的可追溯性显著减轻了这些问题。它将从系统级到体系结构派生的需求与团队在RTL中实现的需求联系起来，并通过测试来验证规范。当检查RTL的一部分或与相关需求一起的测试时，设计师或验证者更容易看到不一致。即使问题不容易测试，这个值也保持不变。开发团队对系统级需求的洞察可能足以引发危险信号。
相反，有时设计选择中的约束可能会迫使对需求进行更改。这未必是致命的。如果架构师足够早地了解变更，系统设计团队可能能够进行调整。双向可追溯性对于实现SoC供应商和系统制造商之间的这种级别的通信至关重要。
可追溯性影响到SoC设计和验证中的每个人。但它不需要带来令人痛苦的开销。它可以真正帮助避免后期危机和返工，也是与客户建立信心的绝佳工具。想了解更多?看看Harmony Trace产品．
|
|
|
|
|
|
|
|
|
留言回复