如果您在 DO-254 指導(dǎo)下使用 FPGA 進(jìn)行設(shè)計，那么這些指導(dǎo)原則是必須的。

需求可追溯性是一種經(jīng)過充分驗證的軟件開發(fā)實踐，它改進(jìn)了軟件項目管理，使軟件團(tuán)隊能夠在預(yù)算內(nèi)按時交付高質(zhì)量的應(yīng)用程序。然而，雖然軟件工程師已經(jīng)廣泛接受和采用，但需求可追溯性在 FPGA 領(lǐng)域仍然是一個相對較新的概念。

出于實現(xiàn) DO-254 合規(guī)性的需要，商業(yè)航空 FPGA 團(tuán)隊已開始采用需求可追溯性。從事 DO-254 程序的 FPGA 團(tuán)隊必須提供證明，證明最終的 FPGA 設(shè)備是根據(jù)需求設(shè)計和測試的，而需求可追溯性是證明的關(guān)鍵部分。

關(guān)于 FPGA 開發(fā)，需求跟蹤是電路卡需求、FPGA 需求、概念設(shè)計、HDL 源代碼、綜合和 P&R 文件、驗證測試用例、測試臺代碼、仿真腳本和仿真結(jié)果（日志文件、波形和代碼覆蓋率報告）。

雖然 DO-254 中沒有明確定義，但需求可追溯性在正確完成時會提供顯著的好處。建立可追溯性改進(jìn)了變更管理，促進(jìn)了更好的項目管理，并提供了一種有效的方式來組織、連接和跟蹤所有 FPGA 設(shè)計和驗證元素。

以下是您需要在 DO-254 指導(dǎo)下進(jìn)行 FPGA 開發(fā)的需求可追溯性的五個主要原因。

1. 暴露需求覆蓋差距

在 FPGA 需求捕獲過程中，運行從電路卡組件 （CCA） 到 FPGA 需求的下游可追溯性會暴露 FPGA 需求未涵蓋的 CCA 需求。圖 1 中的示例表明 CCA-002 和 CCA-007 均未涵蓋在任何 FPGA 要求中。這是由于以下任一原因造成的：相關(guān)的 FPGA 要求未正確鏈接到 CCA-002 和 CCA-007 要求，或者 CCA-002 和 CCA-007 要求未正確分配給 FPGA。無論哪種方式，都必須采取適當(dāng)?shù)拇胧﹣砑m正這種覆蓋差距。

圖 1：下游可追溯性。

同樣，在 FPGA 設(shè)計生命周期的其余部分，運行下游可追溯性會暴露尚未由 HDL 功能實現(xiàn)的 FPGA 需求、尚未被測試場景覆蓋的 FPGA 需求以及尚未被覆蓋的測試場景。由測試臺實現(xiàn)。了解是否存在覆蓋差距有助于跟蹤項目狀態(tài)。下游可追溯性很容易暴露 FPGA 開發(fā)周期中的需求覆蓋差距。

2. 暴露未使用的HDL函數(shù)

在多個項目中重復(fù)使用 HDL 設(shè)計源有幾個優(yōu)點，但一個常見的缺點是會出現(xiàn)未使用的 HDL 功能。運行從 HDL 設(shè)計到 FPGA 要求的上游可追溯性很容易暴露出不符合任何 FPGA 要求的 HDL 功能。這是因為：HDL 功能沒有正確鏈接到相關(guān)的 FPGA 要求，或者根本沒有使用 HDL 功能。HDL 代碼中未使用的功能可能會導(dǎo)致意外的設(shè)備行為，必須將其刪除或更新。

3. 啟用變更影響分析

需求的變化可能會導(dǎo)致其他項目元素的變化，例如 HDL 設(shè)計、綜合和布局布線文件、測試用例、測試臺和測試結(jié)果。在變更發(fā)生之前，組織會執(zhí)行變更影響分析，以評估變更對項目其余部分的連鎖反應(yīng)。

可追溯性是暴露因需求變更而受到影響的項目元素的有效方式。影響分析示例如圖 2 所示。CCA-041 需求描述的更改會影響 3 個 FPGA 需求，即：

FPGA-011

FPGA-021

FPGA-022

圖 2：影響分析。

必須評估這些 FPGA 要求是否仍完全涵蓋 CCA-041（考慮 CCA 要求的變化）。如果任何受影響的 FPGA 要求需要進(jìn)一步修改，那么與之相關(guān)的設(shè)計和驗證元素也需要進(jìn)行評估。如圖 3 所示，對 FPGA-011 的更改會影響以下設(shè)計和驗證元素，如果需要，還必須對所有這些元素進(jìn)行評估和修改。

? 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：測試結(jié)果可追溯性。

如果沒有建立從 CCA 到 FPGA 設(shè)計和驗證元素的可追溯性，影響分析將難以管理和分析。由于項目元素之間存在可追溯性，因此很容易進(jìn)行影響分析。

4. 改進(jìn)測試管理

衡量測試用例結(jié)果是通過還是失敗的機制是確定驗證完整性的關(guān)鍵要素。在測試用例、測試臺、測試狀態(tài)、日志文件和波形之間建立可追溯性可實現(xiàn)更有效的測試管理。此外，借助可追溯性，還可以確定和跟蹤哪個測試套件實現(xiàn)了最大的代碼覆蓋率。關(guān)鍵是擁有某種類型的工具自動化，這樣每次回歸后，矩陣都會自動填充適當(dāng)?shù)臏y試結(jié)果。

5. 協(xié)助審查和審計

在審查和審計期間，需求可追溯性矩陣可用作確定所有 FPGA 設(shè)計和驗證元素的相關(guān)性的地圖。需求跟蹤矩陣可以回答以下問題：

我們是否有針對每個 FPGA 要求的 HDL 設(shè)計源代碼？

我們是否有針對每個 FPGA 需求的測試用例和測試臺？

我們是否驗證了所有 FPGA 要求？我們有多少失敗的測試？

特定測試套件的累積代碼覆蓋率是多少？

在各個測試和回歸期間生成的日志文件和波形在哪里以及在哪里？

如果特定的 FPGA 要求需要修改，哪些設(shè)計和驗證元素會受到影響？

在可追溯性矩陣的幫助下，申請人和認(rèn)證機構(gòu)都能夠輕松地參考所有設(shè)計和驗證工件并將其與需求相關(guān)聯(lián)。

圖 4：需求可追溯性矩陣。

顯然，需求可追溯性的原因是令人信服的。但請記住，如果沒有適當(dāng)?shù)墓ぞ撸勺匪菪钥赡芎茈y創(chuàng)建和管理?？勺匪菪允且豁棻仨氃谡麄€項目期間進(jìn)行管理和維護(hù)的持續(xù)活動。少于 100 個需求的小型項目可能很簡單，而電子表格可能足以管理可追溯性。但是，使用電子表格管理具有數(shù)百或數(shù)千個需求的大型項目的可追溯性可能會讓人不知所措。這為考慮Spec-Tracer改進(jìn)變更管理、促進(jìn)更好的項目管理以及提供組織、連接和跟蹤 FPGA 開發(fā)周期的有效方式提供了另一個理由。

審核編輯：郭婷