EEPW论坛

如果您在 DO-254 指导下使用 FPGA 进行设计，那么这些指导原则是必须的。

需求可追溯性是一种经过充分验证的软件开发实践，它改进了软件项目管理，使软件团队能够在预算内按时交付高质量的应用程序。然而，虽然软件工程师已经广泛接受和采用，但需求可追溯性在 FPGA 领域仍然是一个相对较新的概念。

出于实现 DO-254 合规性的需要，商业航空 FPGA 团队已开始采用需求可追溯性。从事 DO-254 程序的 FPGA 团队必须提供证明，证明最终的 FPGA 设备是根据需求设计和测试的，而需求可追溯性是证明的关键部分。

关于 FPGA 开发，需求跟踪是电路卡需求、FPGA 需求、概念设计、HDL 源代码、综合和 P&R 文件、验证测试用例、测试台代码、仿真脚本和仿真结果（日志文件、波形和代码覆盖率报告）。

虽然 DO-254 中没有明确定义，但需求可追溯性在正确完成时会提供显着的好处。建立可追溯性改进了变更管理，促进了更好的项目管理，并提供了一种有效的方式来组织、连接和跟踪所有 FPGA 设计和验证元素。

以下是您需要在 DO-254 指导下进行 FPGA 开发的需求可追溯性的五个主要原因。

1. 暴露需求覆盖差距

在 FPGA 需求捕获过程中，运行从电路卡组件 （CCA） 到 FPGA 需求的下游可追溯性会暴露 FPGA 需求未涵盖的 CCA 需求。图 1 中的示例表明 CCA-002 和 CCA-007 均未涵盖在任何 FPGA 要求中。这是由于以下任一原因造成的：相关的 FPGA 要求未正确链接到 CCA-002 和 CCA-007 要求，或者 CCA-002 和 CCA-007 要求未正确分配给 FPGA。无论哪种方式，都必须采取适当的措施来纠正这种覆盖差距。

图 1：下游可追溯性。

同样，在 FPGA 设计生命周期的其余部分，运行下游可追溯性会暴露尚未由 HDL 功能实现的 FPGA 需求、尚未被测试场景覆盖的 FPGA 需求以及尚未被覆盖的测试场景。由测试台实现。了解是否存在覆盖差距有助于跟踪项目状态。下游可追溯性很容易暴露 FPGA 开发周期中的需求覆盖差距。

2. 暴露未使用的HDL函数

在多个项目中重复使用 HDL 设计源有几个优点，但一个常见的缺点是会出现未使用的 HDL 功能。运行从 HDL 设计到 FPGA 要求的上游可追溯性很容易暴露出不符合任何 FPGA 要求的 HDL 功能。这是因为：HDL 功能没有正确链接到相关的 FPGA 要求，或者根本没有使用 HDL 功能。HDL 代码中未使用的功能可能会导致意外的设备行为，必须将其删除或更新。

3. 启用变更影响分析

需求的变化可能会导致其他项目元素的变化，例如 HDL 设计、综合和布局布线文件、测试用例、测试台和测试结果。在变更发生之前，组织会执行变更影响分析，以评估变更对项目其余部分的连锁反应。

可追溯性是暴露因需求变更而受到影响的项目元素的有效方式。影响分析示例如图 2 所示。CCA-041 需求描述的更改会影响 3 个 FPGA 需求，即：

FPGA-011

FPGA-021

FPGA-022

图 2：影响分析。

必须评估这些 FPGA 要求是否仍完全涵盖 CCA-041（考虑 CCA 要求的变化）。如果任何受影响的 FPGA 要求需要进一步修改，那么与之相关的设计和验证元素也需要进行评估。如图 3 所示，对 FPGA-011 的更改会影响以下设计和验证元素，如果需要，还必须对所有这些元素进行评估和修改。

• HDL_002_interrupt_unit.vhd

• HDL_003_interrupt_unit.vhd

• HDL_006_interrupt_contr.vhd

• TST-003

• TB_003_testbench.vhd–tag 到 HDL 源代码

–tag 到 HDL 源代码

–tag 到 HDL 源代码

–tag 到测试用例

–tag 到测试台

图 3：测试结果可追溯性。

如果没有建立从 CCA 到 FPGA 设计和验证元素的可追溯性，影响分析将难以管理和分析。由于项目元素之间存在可追溯性，因此很容易进行影响分析。

4. 改进测****理

衡量测试用例结果是通过还是失败的机制是确定验证完整性的关键要素。在测试用例、测试台、测试状态、日志文件和波形之间建立可追溯性可实现更有效的测****理。此外，借助可追溯性，还可以确定和跟踪哪个测试套件实现了最大的代码覆盖率。关键是拥有某种类型的工具自动化，这样每次回归后，矩阵都会自动填充适当的测试结果。

5. 协助审查和审计

在审查和审计期间，需求可追溯性矩阵可用作确定所有 FPGA 设计和验证元素的相关性的地图。需求跟踪矩阵可以回答以下问题：

我们是否有针对每个 FPGA 要求的 HDL 设计源代码？

我们是否有针对每个 FPGA 需求的测试用例和测试台？

我们是否验证了所有 FPGA 要求？我们有多少失败的测试？

特定测试套件的累积代码覆盖率是多少？

在各个测试和回归期间生成的日志文件和波形在哪里以及在哪里？

如果特定的 FPGA 要求需要修改，哪些设计和验证元素会受到影响？

在可追溯性矩阵的帮助下，申请人和认证机构都能够轻松地参考所有设计和验证工件并将其与需求相关联。

图 4：需求可追溯性矩阵。

显然，需求可追溯性的原因是令人信服的。但请记住，如果没有适当的工具，可追溯性可能很难创建和管理。可追溯性是一项必须在整个项目期间进行管理和维护的持续活动。少于 100 个需求的小型项目可能很简单，而电子表格可能足以管理可追溯性。但是，使用电子表格管理具有数百或数千个需求的大型项目的可追溯性可能会让人不知所措。这为考虑Spec-Tracer改进变更管理、促进更好的项目管理以及提供组织、连接和跟踪 FPGA 开发周期的有效方式提供了另一个理由。