如果您在 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 開發周期的有效方式提供了另一個理由。

審核編輯：郭婷