《機(jī)載系統(tǒng)復(fù)雜電子硬件適航要求審定規(guī)范》(征求意見稿)

1T/CECC000—2024機(jī)載系統(tǒng)復(fù)雜電子硬件適航要求審定規(guī)范本文件規(guī)定了機(jī)載系統(tǒng)復(fù)雜電子硬件的需求標(biāo)準(zhǔn)、設(shè)計標(biāo)準(zhǔn)以及編碼標(biāo)準(zhǔn)。本文件適用于規(guī)范機(jī)載系統(tǒng)復(fù)雜電子硬件的設(shè)計、制造和審定流程，評估機(jī)載系統(tǒng)復(fù)雜電子硬件的生命周期完整性、可維護(hù)性、安全性。2規(guī)范性引用文件下列文件對于本文件的應(yīng)用是必不可少的。凡是注日期的引用文件,僅注日期的版本適用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改單)適用于本文件。HB/Z420-2014民用飛機(jī)機(jī)載電子硬件合格審定保證指南RTCADO-254機(jī)載電子硬件的設(shè)計保證指南RTCADO-178B-1992機(jī)載系統(tǒng)和設(shè)備認(rèn)證中的軟件注意事項3術(shù)語和定義MH/T1039-2011、GB/T25069-2022、GB/T18041-2000界定的以及術(shù)語和定義適用于本文件。3.1復(fù)雜電子硬件complexelectronichardware復(fù)雜電子硬件指由多個電子組件、模塊或子系統(tǒng)組成的電子設(shè)備。這些設(shè)備由于功能復(fù)雜性、設(shè)計多樣性和潛在隱蔽狀態(tài)，不能通過簡單、明確的驗證手段完全確認(rèn)其功能在所有情況下的正確性和可靠性。因此，它們需要通過更高級的驗證方法和工具來確保其符合性和安全性，特別是在安全關(guān)鍵系統(tǒng)中，如航空電子設(shè)備中的應(yīng)用。復(fù)雜電子硬件通常包括FPGA、ASIC和其他可編程邏輯設(shè)備。3.2跨時鐘域crossclockdomain在數(shù)字電子系統(tǒng)中，時鐘域是指由一個共同的時鐘信號控制的邏輯區(qū)域。當(dāng)一個系統(tǒng)包含多個不同頻率或相位的時鐘時，就涉及到了跨時鐘域3.3電磁兼容electromagneticcompatibility指設(shè)備或系統(tǒng)在其電磁環(huán)境中能正常工作，且不對環(huán)境中的任何設(shè)備產(chǎn)生不能承受的電磁干擾的能力。環(huán)境可靠性：指設(shè)備或系統(tǒng)在規(guī)定的環(huán)境條件下能夠持續(xù)穩(wěn)定運行的能力。4復(fù)雜電子硬件需求標(biāo)準(zhǔn)4.1需求模塊集2T/CECC000—2024需求捕獲過程對需求進(jìn)行識別、定義和記錄，包括非派生需求和派生需求，派生需求來自架構(gòu)、技術(shù)選擇，基本功能和可選功能、環(huán)境和性能需求，且經(jīng)由安全性評估，將產(chǎn)生的派生需求反饋至相應(yīng)過程，以便可以評估對系統(tǒng)需求的影響。應(yīng)向系統(tǒng)開發(fā)過程提供在此過程中發(fā)現(xiàn)的需求遺漏或錯誤。4.1.1需求模塊應(yīng)使用IBMRationalDOORS或其他需求管理專用軟件管理需求應(yīng)在一個需求模塊中捕獲需求需要按產(chǎn)品將需求適當(dāng)分組到模塊中。其目的是創(chuàng)建有意義的需求分組，從而便于管理和確認(rèn)需求。每個需求模塊應(yīng)包含以下需求屬性：ObjectIdentifier/ID、ObjectText、Requirement、Derived_Requirement、Rationale、Safety、Change_history、Validation_Method、Requirement_Status、Verification_Method、Allocation、Type_Requirement表1提供了每個必需屬性的定義。表1需求模塊強(qiáng)制屬性將該需求分配至一個較低需求層級模什么不能進(jìn)一步分解該需求，則一個說明該需求是否屬于派生需求(Pured是是需求文本–也用于非需求的標(biāo)題文是例如：該屬性可以通過列舉創(chuàng)建：Y,3T/CECC000—2024是說明該需求是否是可追溯至系統(tǒng)安全性分析(None/PSSA/Safety_Credit/VPSSA:標(biāo)簽表示該需求派生自一個PSSA。需求的原理將包含參考PSSA，該P(yáng)Safety_Credit:標(biāo)簽表示這條需求對應(yīng)的功能為其他需求安全性分析的驗VSA:標(biāo)簽表示該需求通過安全性分析否是說明是否已確認(rèn)需求(Novalidated/V是(Test/Simulation/AnThecombinationofthese是提供可接受的確認(rèn)方法列表(Analysis是是4T/CECC000—2024是onal/Interface/Timing//Hardware/Performance/Reliability/EnvironmenPerformance:表示此需求為Reliability:表示此需求是可靠性需求Environmental:表示此需求是環(huán)境性否該屬性表示在ICD文件中是否有一個注：此項雖然按照[2]的解釋為強(qiáng)制項，但存在例外情況：由于最低需求層級不需要進(jìn)行分每個需求模塊都建議包括注釋和標(biāo)題。注釋、標(biāo)題提供了關(guān)于該需求的介紹性描述。通常將需求劃分為幾段，每段都有簡短的注釋。每個模塊都應(yīng)包含注釋。注釋、標(biāo)題不屬于需求，建議在Requirement屬性中進(jìn)行適當(dāng)標(biāo)記。每個需求模塊都應(yīng)建立基線?；€用于提供一組穩(wěn)定的需求，以便審查或開發(fā)。由于需求可能會持續(xù)發(fā)生變化，因此有必要提供一條基線，這樣可以確保審核者或開發(fā)人員沒有移動目標(biāo)。需在單個項目的需求變更管理過程中評估并確認(rèn)基線之間發(fā)生的任何需求模塊變更。在建立第一條基線后，每個需求模塊都應(yīng)含有所有需求的歷史記錄該歷史記錄含有所有基線和任何已刪除的需求。不得重新使用唯一需求標(biāo)識，以確保正在討論的需求不會發(fā)生任何混淆。所有屬性都應(yīng)進(jìn)行歸檔，而不僅僅是需求文本。盡管該需求標(biāo)準(zhǔn)只要求第一條基線后的歷史記錄，但是最好記錄所有的歷史數(shù)據(jù)（包括第一條基線前的數(shù)據(jù)）。DOORS工具提供了該功能。DOORS管理員應(yīng)小心，不要使用“清除”功能，這會刪除該歷史記錄。在生產(chǎn)發(fā)布之前，應(yīng)確認(rèn)所有需求模塊需求對項目開發(fā)和生產(chǎn)階段之間的轉(zhuǎn)換點進(jìn)行生產(chǎn)發(fā)布。每條需求都需要確認(rèn)為完整和正確的，以確保待建立產(chǎn)品的設(shè)計滿足相應(yīng)的安全性和適航性需求。商業(yè)設(shè)計保證標(biāo)準(zhǔn)DO-254要求確認(rèn)這些需求。已確認(rèn)需求的“Requirement_Status”屬性需要標(biāo)記為“Validated”。4.1.2需求層級應(yīng)在一個或多個需求模塊中捕獲每個需求層級在適當(dāng)情況下，一個層級可以基于其父層級分配分成多個模塊。每個需求層級應(yīng)從其父需求層級中分解得出5T/CECC000—2024當(dāng)需求從高層級傳遞到低層級時，應(yīng)復(fù)制需求的關(guān)鍵詞。當(dāng)需求的“Derived_Requirement”屬性列標(biāo)為“No”時，此需求的測試證據(jù)就可以用于高層級需求的測試證據(jù)。如果一條需求被分配至多個低層級需求模塊，則需要評審所有子需求(而不僅是在同一模塊中的那些需求)，以確保涵蓋父需求的每個方面。4.2需求規(guī)則4.2.1使用“應(yīng)(shall)”、“將(will)”、“建議(should)”、“可能(may)”和“待定(tobedetermined)”明確區(qū)分強(qiáng)制性需求、事實陳述和設(shè)計目標(biāo)“應(yīng)”一詞用來表示強(qiáng)制性需求“是”、“曾是”和“必須”等術(shù)語不能用于表示一條需求。這些術(shù)語可用在澄清或解釋需求需要的描述性材料中，但不能用來代替“應(yīng)”。注釋和基本原理中應(yīng)避免使用“應(yīng)”一詞。在Requirement屬性中，應(yīng)將“應(yīng)”語句需求標(biāo)記為需求?！皩ⅰ币辉~應(yīng)用于表示受保證的條款或服務(wù)“將”語句的示例為“飛機(jī)接口將為裝置提供28.0±0.1VDC電源”。在該例中，“將”用于表示飛機(jī)接口提供的內(nèi)容，而相關(guān)的“應(yīng)”語句則適用于該裝置。裝置的開發(fā)人員可以依賴飛機(jī)來提供所述的電源?！皩ⅰ闭Z句通常以假設(shè)為基礎(chǔ)。在這種情況下，相關(guān)需求應(yīng)在其“基礎(chǔ)原理”章節(jié)中注明假設(shè)，并將“Assumption”屬性設(shè)置為“Y”?！皩ⅰ闭Z句并不是需求，并且禁止在Requirement屬性中將其標(biāo)記為需求?？梢杂糜谧⑨??！敖ㄗh”一詞用來表述設(shè)計目標(biāo)“建議”語句表示項目是非強(qiáng)制性的但是可取的。應(yīng)避免在設(shè)計/開發(fā)保證等級A或B程序中使用“建議”語句。在這種情況下，最好的解決方案是在相關(guān)的非需求文件中設(shè)定任何目標(biāo)，如設(shè)計說明或操作概念。可用于注釋中?！翱赡堋币辉~應(yīng)用來表示一項可能的需求“可能”語句通?；谝环N假設(shè):可否建立此假設(shè)?！按ā币辉~建議用來表示一項尚不可能決定的需求，將在未來對該需求做出決定“待定”語句的一個例子是：“在此項目中添加的縮放功能仍然待定”。在這個例子中，“待定”意思是：此項目中添加的縮放功能是否尚未決定，當(dāng)將來具備所有條件后，將對它做出決定。4.2.2基本需求規(guī)則本節(jié)定義了單條需求的方方面面，這些是創(chuàng)建明確、正確、完整且可驗證的有效需求所需的內(nèi)容。單個的需求應(yīng)含有一個“應(yīng)”字。簡明的需求應(yīng)由單個語句組成，該語句明確陳述了要完成的內(nèi)容。一致的需求不應(yīng)自相矛盾或與需求模塊中的任何其他需求相矛盾。6T/CECC000—2024完整的需求應(yīng)在邏輯上是完整的。應(yīng)確認(rèn)個別需求或一組相關(guān)需求，以確保這些需求不會含有任何未定義的輸入或輸出狀態(tài)。像“告警燈應(yīng)只在傳感器出現(xiàn)故障時點亮”這樣的簡單需求是完整的，這是因為它清晰地表明了指示燈建議亮和不建議亮的時間。應(yīng)確認(rèn)含有多個輸入或滯后的更復(fù)雜需求集，以確保該需求不會含有未指定的“無關(guān)”或“未知”狀態(tài)。為需求邏輯填寫卡諾圖通常有助于確認(rèn)完整性。明確的.1所述需求應(yīng)是明確的如果需要，建議使用基本原理來定義術(shù)語并解決需求文本中存在的任何歧義。建議避免使用使需求含糊不清的詞或短語，如大約、足夠、近似、最大化、最小化、不限于、粗略地、平順等。在需求開發(fā)期間，常見的工程實踐是使用“待定”或“待驗證”占位符來表示數(shù)值，直至可以執(zhí)行某分析。在確認(rèn)某項需求之前，應(yīng)消除這種模糊性。.2應(yīng)定義所有的需求縮略詞應(yīng)限制縮略詞的使用，因為這些縮略詞可能會對不熟悉需求集詳細(xì)情況的讀者造成困惑。為使需求簡潔需要使用縮略詞時，則應(yīng)使用相關(guān)注釋來消除不明確之處。所有縮略詞應(yīng)在需求模塊的縮略詞列表中進(jìn)行定義。.3需求模塊中所使用的命名規(guī)則一致在同一個項目中使用不同名稱的同義詞來提及相同項或行為的需求可能會造成混淆并導(dǎo)致需求重復(fù)。術(shù)語的一致使用對避免這種模糊性很重要。還應(yīng)避免整個需求層或需求和相關(guān)接口控制文檔(ICD)之間存在命名差異。必要的和非冗余的.1該需求應(yīng)是必要的“必要”定義為該需求對于需求模塊是適當(dāng)?shù)?，不能從任何其它需求中明顯地推導(dǎo)出以及它不是其它需求的組合。應(yīng)檢查對其父需求具有”弱”鏈接的非派生需求，以確保這些需求確實是必要的并且不具有“很好”的增強(qiáng)功能。.2需求不應(yīng)重復(fù)同一需求模塊中任何其他需求的內(nèi)容除了導(dǎo)致不必要的確認(rèn)和驗證工作，重復(fù)需求也還會在變更流程期間造成危險，因為這些需求可能只在一個位置處進(jìn)行變更。.3建議避免使用指定了過程的需求需求應(yīng)指明該產(chǎn)品，而不是產(chǎn)品的開發(fā)方式。難以驗證過程需求，因為這些需求不適用于產(chǎn)品，而是適用于如何開發(fā)產(chǎn)品?！坝布?yīng)根據(jù)DO-254進(jìn)行開發(fā)”等需求應(yīng)包含在工作說明書或工作指導(dǎo)書中，而不是包含在需求中。唯一標(biāo)識應(yīng)為每一個需求模塊對象分配唯一標(biāo)識。7T/CECC000—2024通過將標(biāo)識記錄到“ObjectIdentifier”屬性中來分配唯一標(biāo)識。應(yīng)為需求、標(biāo)題、注釋分配唯一標(biāo)識。在整個系統(tǒng)生命周期內(nèi)，該標(biāo)識始終分配給該對象。不得重新使用已刪除對象的“ObjectIdentifier”標(biāo)識號。由于項目需求通常被分為多個模塊，因此標(biāo)識對于該項目應(yīng)是唯一的。DOORS自動為所有對象分配唯一標(biāo)識符。標(biāo)記為一條需求每條需求的Requirement屬性應(yīng)標(biāo)記為“Y”。Requirement屬性用于區(qū)分需求和非需求。對于派生需求和非派生需求的Requirement屬性應(yīng)標(biāo)記為“Y”。非需求的Requirement屬性建議視情況標(biāo)記為“N”，“Headling”或“Delete”，但不得標(biāo)記為“Y”?？尚械男枨髴?yīng)是可行的。可行在項目限制范圍內(nèi)被定義為可實現(xiàn)。為了避免后期變更導(dǎo)致的代價，建議在項目早期和客戶或父層級所有者一起對不切實際的父需求進(jìn)行討論。0可驗證的0.1需求應(yīng)是可驗證的可驗證被定義為有明確方法來確認(rèn)產(chǎn)品符合需求。需要注意的是，”驗證”并不相當(dāng)于”測試”。通?？墒褂冒ㄔu審、檢查、建模和分析在內(nèi)的其它方法驗證一條需求。需求的編寫者應(yīng)避免使用造成需求驗證困難的詞語或短語。此類別的詞語和短語包括明顯地、容易地、靈活的、如有必要、最小化、最大化、迅速地、充分地、容易使用的、應(yīng)能夠以及應(yīng)支持。需要檢查否定式”不應(yīng)”需求，因為這些需求通常較難驗證。例如，”警告指示燈應(yīng)在檢測到故障時亮起”這一需求是可驗證的，而”除非檢測到某個故障，否則警告指示燈不應(yīng)亮起”則難以驗證，這是因為該驗證測試應(yīng)重建指示燈未亮起的每一種情形。0.2建議避免使用適用于其他需求的需求建議避免使用適用于其他需求的需求，這是因為在制定驗證程序時，這些需求適用于待驗證的其它需求這一點并不明顯。建議避免使用這類需求的示例是“第3.4節(jié)中的需求僅在該裝置處于安全模式時適用”。相反，對每個受影響的需求增加條件短語“當(dāng)該裝置處于安全模式時”則更為恰當(dāng)。在某些系統(tǒng)中，可能需要諸如環(huán)境需求之類的一般需求，但建議盡量減少其使用以確保驗證簡單易行。4.2.3性能需求本節(jié)提供了性能需求的產(chǎn)品需求標(biāo)準(zhǔn)。性能需求提供了測量值（多少、多快等并且通常與配套功能需求相關(guān)。每項性能需求應(yīng)包括測量值的容差性能需求定義為測量某個數(shù)值或作用于測量值的需求。舉個有關(guān)性能需求的例子，”該裝置應(yīng)提供28±0.2VDC”。”大于”或”小于”等短語也可作為容差。例如，”當(dāng)結(jié)溫高于75oC時，該裝置應(yīng)報告故障”是有效的。該需求標(biāo)準(zhǔn)不適用于計數(shù)值（以整數(shù)值測量的項目）。在提供公差時，務(wù)必確保邊界值定義良好，且公差不會重疊或留下間隙。時間相關(guān)需求應(yīng)有界限8T/CECC000—2024復(fù)雜的系統(tǒng)架構(gòu)通常不僅依賴于一個動作的發(fā)生，而且依賴于一個動作在特定時間內(nèi)的發(fā)生。應(yīng)檢查每條需求，以確保當(dāng)存在這種時序依賴關(guān)系時，它是有適當(dāng)界限的。這項活動可能很困難，因為它需要產(chǎn)品設(shè)計工程師與系統(tǒng)和安全性工程師一起處理復(fù)雜的高層體系結(jié)構(gòu)問題，而系統(tǒng)和安全性工程師可能不熟悉設(shè)計的底層細(xì)節(jié)。4.2.4派生需求與非派生需求派生需求由建議的架構(gòu)、技術(shù)的選擇、基本功能和選項功能、環(huán)境要求、性能要求、及系統(tǒng)安全性評估產(chǎn)生的?！癙urederived”的需求是在一些設(shè)計決策后所考慮的需求?！癛efine”的需求是來自上層級的一條需求，并且在這個需求中添加了一些附加的數(shù)據(jù)。需求的格式建議是一致的，并建議向上追溯，除非它們是派生需求。4.2.5盡管本文件中所使用的派生和非派生定義與航空領(lǐng)域相關(guān)開發(fā)和設(shè)計保證標(biāo)準(zhǔn)（如DO-254）中所使用的定義一致，但應(yīng)注意其他行業(yè)會使用與派生相反的定義，即從父需求中細(xì)化。派生需求.1非派生需求建議自由實施非派生需求將其父需求分解為更詳細(xì)的需求，但不建議強(qiáng)制實施。例如，非派生需求可能規(guī)定了需要的處理能力值、輸入/輸出帶寬等，但是該需求不建議規(guī)定滿足那些需求的處理器部件號。該選擇應(yīng)留給設(shè)計師或在派生需求中進(jìn)行規(guī)定。.2非派生需求的Derived_Requirement屬性都應(yīng)標(biāo)記為“No”Derived_Requirement屬性唯一可接受的條目是“No”，“Refine”或“Purederived”。派生需求派生需求是設(shè)計選擇的結(jié)果，因此派生需求會定義下一層級需求的實現(xiàn)方法。派生需求沒有父需求。由于派生需求仍是一條需求，因此需求標(biāo)準(zhǔn)適用于派生需求。.1派生需求應(yīng)在其Rationale中解釋派生原因由于派生需求不具有父需求，因此應(yīng)解釋創(chuàng)建該需求以及其為必要需求的原因。通常，我們將陳述“由于......而存在該派生需求”的解釋置于滿足需求標(biāo)準(zhǔn)的Rationale中。如可能，該解釋建議引用產(chǎn)生該需求的相關(guān)文件。.2在被確認(rèn)之前，派生需求應(yīng)進(jìn)行系統(tǒng)安全性評估因為派生需求是一個設(shè)計選擇，它可能影響系統(tǒng)安全性分析。例如，使用兩個冗余電源滿足安全性需求的執(zhí)行決定可能會影響（規(guī)定飛機(jī)提供多少電流的）更高級系統(tǒng)需求。.3每個派生需求的Derived_Requirement屬性要區(qū)分“Refine”和“Purederived”Refine表示是來自上層級的一條需求，并且在這個需求中添加了一些附加的數(shù)據(jù)，Purederived是在一些設(shè)計決策后所產(chǎn)生的需求。.4每個Refine需求應(yīng)追溯到父需求4.2.6需求的鏈接、參考和分配每個非派生需求都應(yīng)鏈接到其父需求9T/CECC000—2024低層級需求(子需求)分解高層級需求(父需求)。當(dāng)兩個需求集都在DOORS中可用時，應(yīng)做需求鏈接。此需求標(biāo)準(zhǔn)應(yīng)解釋為要求所有已確認(rèn)的非派生需求應(yīng)有父需求。雖然有時某個需求可能合法地具有多個父需求，但應(yīng)檢查這些需求，以確保沒有鏈接問題或父層不具有重復(fù)的需求。需求不應(yīng)具有指向相同需求層級其他需求的父鏈接不允許使用同層內(nèi)需求鏈接，這是因為它們會導(dǎo)致鏈接循環(huán)。如果需要在同層內(nèi)分解需求，則該層次結(jié)構(gòu)劃分可能不正確。該禁止項適用于在兩個需求模塊之間擴(kuò)展的內(nèi)層鏈接。與ICD相關(guān)的需求應(yīng)引用接口控制文件(ICD)的具體編號與ICD相關(guān)的需求本質(zhì)上是一個接口需求。需求應(yīng)在ICD屬性中標(biāo)注“Y”，并在需求正文中寫明ICD的具體編號。需求應(yīng)引用其來源當(dāng)需求從某個非需求中派生或部分派生時，該需求應(yīng)引用文件、架構(gòu)/設(shè)計說明、分析、白皮書、工作說明書或其派生的其它類似項目。應(yīng)在Rationale屬性列內(nèi)進(jìn)行描述。除了最低層級需求外，每條需求都應(yīng)進(jìn)行分配Allocation屬性規(guī)定了該需求分配給哪個需求模塊（或多個模塊）。在建立父-子鏈接之前，它有助于在需求開發(fā)過程的早期定義系統(tǒng)架構(gòu)，并進(jìn)行功能分配。如果不需要進(jìn)一步分解該需求，則填寫本需求模塊。4.2.7需求確認(rèn)和驗證方法確認(rèn)是一種過程，檢查需求以確保它們是完整和正確的，以便待開發(fā)產(chǎn)品達(dá)到安全性和適航性標(biāo)準(zhǔn)，同時滿足客戶、用戶、供應(yīng)商、維護(hù)人員、認(rèn)證機(jī)構(gòu)、開發(fā)人員和其它利益相關(guān)方的需要。需求確認(rèn)包括為需求確認(rèn)設(shè)置目標(biāo)，進(jìn)行需求確認(rèn)活動，識別需求確認(rèn)的方法，和提供需求確認(rèn)的數(shù)據(jù)。驗證是一種提供保證的過程，保證實施了這些需求。驗證由驗證計劃中定義的評審、分析和測試構(gòu)假設(shè)的確認(rèn)在開發(fā)過程中，通?；跓o法確認(rèn)的假設(shè)來編寫需求，直至項目壽命周期的后期。需要確認(rèn)這些假設(shè)，以使需求不是基于一個錯誤的前提。假設(shè)應(yīng)是“明確闡述的，適當(dāng)散播的，并通過支持?jǐn)?shù)據(jù)證明的?！?1應(yīng)在需求的Rationale中明確闡述所有的需求假設(shè)基于假設(shè)的需求通常與“將”語句相關(guān)，在這種語句中提供了有關(guān)接口的信息。例如：對于來自某風(fēng)扇的氣流的需求可能基于由飛機(jī)提供的冷氣溫度。需要對此假設(shè)進(jìn)行注釋，這樣一來，如果冷氣溫度范圍發(fā)生變化，則可以重新評估該需求，以查看是否需要一個更強(qiáng)力的風(fēng)扇。.2如果一條需求是基于一個假設(shè)，則它的Assuption屬性應(yīng)標(biāo)記為“Y”Assumption屬性唯一可接受的條目是“Y”和“N”。.3如果一條需求不是基于一個假設(shè)，則它的Assuption屬性應(yīng)標(biāo)記為“N”Assumption屬性唯一可接受的條目是“Y”和“N”。T/CECC000—20.4在確認(rèn)需求之前，應(yīng)確認(rèn)每條需求假設(shè)。僅在如果一條需求所基于的假設(shè)是有效的情況下，這項需求才是有效的。用與需求一樣的嚴(yán)苛度來確認(rèn)假設(shè)。在較高層級進(jìn)行確認(rèn)的假設(shè)也可能用于較低層級。一般確認(rèn)需求標(biāo)準(zhǔn).1應(yīng)根據(jù)本文件要求的需求標(biāo)準(zhǔn)來確認(rèn)每條需求通過將一條需求的Requirement_Status設(shè)置為“Validated”，將它標(biāo)記為已確認(rèn)。.2應(yīng)確認(rèn)每條需求，以確保該需求允許產(chǎn)品滿足所有適用的安全性標(biāo)準(zhǔn)此需求標(biāo)準(zhǔn)的設(shè)計目的是確保所施加的產(chǎn)品需求不會造成安全性問題。通過客戶需求、政府/軍方標(biāo)準(zhǔn)、或商務(wù)開發(fā)和設(shè)計保證標(biāo)準(zhǔn)，譬如SAEARP4754A和DO-254，來定義適用的安全性和適航性需求。每個項目都建議有一條需求確認(rèn)計劃和一個系統(tǒng)安全性評估，它們一起用來描述適當(dāng)水平的確認(rèn)細(xì)查。.3如果一條需求影響飛機(jī)安全性，則它的Safety屬性應(yīng)標(biāo)記為“PSSA”,“VSA”or“SafetyCredit”如系統(tǒng)安全性分析中所述，安全性需求包括系統(tǒng)功能可用性和完整性的最低性能需求。該需求具體描述了一個安全性需要，例如：有關(guān)監(jiān)視器或機(jī)內(nèi)測試的一條需求，即它是一項安全性需求。.4確認(rèn)過的需求如果發(fā)生變化，應(yīng)重新確認(rèn)此需求如果一條需求的任意屬性（而不是僅指需求文本）發(fā)生任何變更，則認(rèn)為該需求已發(fā)生變更。大多數(shù)項目形成了一條需求變更過程，該過程相當(dāng)于通常用來確認(rèn)需求的檢查評審。這使得在不重新評估所有模塊需求的情況下，可以對個別需求進(jìn)行變更。在所有情況下，需求變更過程需要使用與原始確認(rèn)過程保證同樣程度的嚴(yán)苛度。受控需求的變更將導(dǎo)致該需求處于未確認(rèn)的狀態(tài)，并需要將其Requirement_Status屬性設(shè)置為“Novalidated”。.5應(yīng)在需求“Changehistory”屬性中引用用來更改一條需求的變更請求單號記錄該變更請求單號可以更容易地追溯需求變更，并為已確認(rèn)的需求提供一個更清晰的譜系。在“Changehistory”屬性中可以記錄相應(yīng)的變更文件ID，以便追溯。.6如果一條需求已得到確認(rèn)，則它的Requirement_Status屬性應(yīng)標(biāo)記為“Validated”Requirement_Status屬性唯一可接受的條目是“Validated”和“Novalidated”。.7如果一條需求沒有得到確認(rèn)，則它的“Requirement_Status”屬性應(yīng)標(biāo)記為“Novalidated”Requirement_Status屬性唯一可接受的條目是“Validated”和“Novalidated”。5復(fù)雜電子硬件設(shè)計標(biāo)準(zhǔn)在概念設(shè)計過程和詳細(xì)設(shè)計過程中使用硬件設(shè)計標(biāo)準(zhǔn)定義硬件設(shè)計的規(guī)則、程序、方法、指南和標(biāo)準(zhǔn)。設(shè)計標(biāo)準(zhǔn)的目的是提供：a)硬件設(shè)計表述方法和注釋；b)設(shè)計規(guī)范和命名慣例；c)有關(guān)設(shè)計方法的指南；d)有關(guān)硬件設(shè)計工具使用的指南；T/CECC000—2024e)用于電子組件選擇的指南；f)用于評估故障保護(hù)和容錯設(shè)計結(jié)構(gòu)的指南；g)用于提供反饋至需求過程以及闡明需求的方法描述。h)用于提供電磁兼容性和環(huán)境可靠性設(shè)計標(biāo)準(zhǔn)5.1硬件設(shè)計表述應(yīng)用圖表、文本和硬件描述語言(HDL)描述復(fù)雜電子硬件。復(fù)雜電子硬件設(shè)計將分解成若干子模塊，使用文本和圖形記錄和描述這些子模塊，最終在HDL中實施。5.2設(shè)計規(guī)范和命名慣例模塊命名應(yīng)參考需求、架構(gòu)的相關(guān)描述，并準(zhǔn)確的表達(dá)它實現(xiàn)的功能。5.3設(shè)計方法的指南圖表是重要的設(shè)計表述方法。模塊框圖、數(shù)據(jù)流向圖、狀態(tài)轉(zhuǎn)換圖等應(yīng)該被用于需求向功能架構(gòu)的分解、功能架構(gòu)到代碼實現(xiàn)、設(shè)計的描述中。接口描述表格應(yīng)被用于描述芯片對外和模塊之間的端口。這些圖表將被保存在需求、架構(gòu)文檔中。5.3.1設(shè)計輸入指南架構(gòu)頂層設(shè)計在架構(gòu)設(shè)計中，使用自頂而下的設(shè)計流程。在頂層設(shè)計階段，用框圖描述芯片對外的連接關(guān)系，用表格描述啟用的芯片對外接口。使用功能框圖對芯片內(nèi)部功能模塊進(jìn)行劃分。功能框圖中應(yīng)包含主要的數(shù)據(jù)流向，以描述各模塊之間連接關(guān)系。架構(gòu)層級設(shè)計一個復(fù)雜的可編程邏輯設(shè)計內(nèi)部一般以層級方式進(jìn)行設(shè)計，這樣使得設(shè)計師能夠?qū)Ｗ⒂陔娐返囊粋€功能部分。架構(gòu)功能塊設(shè)計在完成層級設(shè)計后，進(jìn)行功能塊內(nèi)部的設(shè)計?？梢允褂昧鞒虉D描述功能的前后步驟，使用狀態(tài)機(jī)轉(zhuǎn)換圖描述狀態(tài)機(jī)切換，使用接口描述表格描述功能塊的輸入輸出接口。同步/異步設(shè)計應(yīng)首選同步設(shè)計，而不是異步設(shè)計。因為異步設(shè)計通常對于元件的延遲很敏感，很難預(yù)測和保證該延遲。靜態(tài)時序分析進(jìn)一步提高了同步設(shè)計時序的可靠性，為整體時序的一個良好整體保證，因為仿真的方法受限于仿真激勵的完整性，并不一定能夠仿真到所有的時序路徑。并且，當(dāng)設(shè)計轉(zhuǎn)移至更新一代器件，或從原目標(biāo)器件轉(zhuǎn)移至另一廠家器件時，同步邏輯設(shè)計由于對不同型號的器件的物理延遲不是那么敏感，所有更有利于移植。但對于CPLD，異步設(shè)計往往是不可避免的。時鐘設(shè)計在可編程設(shè)計中，應(yīng)避免使用門控時鐘，因為這必然會在時鐘信號的產(chǎn)生時引入組合邏輯，使得競爭冒險產(chǎn)生的風(fēng)險增加，產(chǎn)生毛刺。為了保證更好的時序，還應(yīng)盡量避免使用邏輯生成的時鐘，在生成內(nèi)部時鐘時，應(yīng)當(dāng)首先考慮使用片內(nèi)提供的專用資源，比如片內(nèi)晶振、PLL或DLL。T/CECC000—2024時鐘信號往往是片內(nèi)扇出最大的信號之一，為了進(jìn)一步保證時序，減小時鐘偏移對時序帶來的影響，應(yīng)確保時鐘信號被連接到全局網(wǎng)絡(luò)中，往往設(shè)計工具會在綜合時自動進(jìn)行相應(yīng)的連接，設(shè)計人員在綜合后需要進(jìn)行確認(rèn)。時鐘約束設(shè)計應(yīng)根據(jù)可編程器件上下游器件的時延特性及PCB走線延遲，計算得到可編程器件的輸入輸出延遲。應(yīng)根據(jù)需求，設(shè)置輸入時鐘、衍生時鐘的周期、占空比、相位參數(shù)、倍/分頻系數(shù)等參數(shù)。應(yīng)根據(jù)布局布線后的STA報告，修改邏輯內(nèi)部的時序約束，通過迭代的過程，達(dá)到最終的時序收斂。復(fù)位設(shè)計應(yīng)注意隔離不同時鐘域的復(fù)位源，以免非預(yù)期的復(fù)位源會影響相關(guān)功能的復(fù)位。在同步設(shè)計中，復(fù)位信號控制著所有相關(guān)復(fù)位域下寄存器的工作起點。對于包含有多時鐘域的設(shè)計，不同時鐘域承載的不同功能的復(fù)位信號的復(fù)位源可能不一樣。應(yīng)對復(fù)位信號進(jìn)行“異步復(fù)位，同步釋放”處理。一般而言，相比于復(fù)位信號的生效，往往復(fù)位信號的釋放更受關(guān)注，因為復(fù)位信號的釋放決定了相關(guān)復(fù)位域下的寄存器是否“同時”開始工作，使得后續(xù)的同步邏輯按照預(yù)期的工作節(jié)拍同步工作，為了保證這一點需要對復(fù)位信號進(jìn)行相應(yīng)時鐘域下的“同步釋放”處理。并且，由于“同步復(fù)位”操作往往會額外消耗組合邏輯資源，而往往復(fù)位信號會大量分布，因此占用大量組合邏輯，綜合以上考慮，為了節(jié)省邏輯資源，無特殊要求時，一般對復(fù)位信號進(jìn)行“異步復(fù)位，同步釋放”處理。復(fù)位信號應(yīng)連接到全局網(wǎng)絡(luò)中。與時鐘信號一樣，復(fù)位信號往往是片內(nèi)扇出最大的信號之一，為了進(jìn)一步保證時序，提升時序性能，復(fù)位信號最好連接到全局網(wǎng)絡(luò)中，往往設(shè)計工具會在綜合時自動進(jìn)行添加?？鐣r鐘域設(shè)計應(yīng)采用合理的方式進(jìn)行數(shù)據(jù)的跨時鐘域傳輸。在多時鐘域的設(shè)計中，信號的跨時鐘域幾乎是不可避免的，為了避免數(shù)據(jù)跨時鐘域產(chǎn)生的亞穩(wěn)態(tài)對功能產(chǎn)生不利的影響，應(yīng)對跨時鐘域的數(shù)據(jù)進(jìn)行相應(yīng)的處理。跨時鐘基本場景有：快時鐘與慢時鐘之間、單bit/多bit數(shù)據(jù)、連續(xù)/非連續(xù)、單周期/多周期等。常見的跨時鐘域方法有2-DFF、DPRAM、FIFO、握手、格雷碼等，應(yīng)根據(jù)實際場景正確的選擇跨時鐘域方法。片上資源評估應(yīng)采用合理的方式進(jìn)行數(shù)據(jù)的跨時鐘域傳輸。在多時鐘域的設(shè)計中，信號的跨時鐘域幾乎是不可避免的，為了避免數(shù)據(jù)跨時鐘域產(chǎn)生的亞穩(wěn)態(tài)對功能產(chǎn)生不利的影響，應(yīng)對跨時鐘域的數(shù)據(jù)進(jìn)行相應(yīng)的處理?？鐣r鐘基本場景有：快時鐘與慢時鐘之間、單bit/多bit數(shù)據(jù)、連續(xù)/非連續(xù)、單周期/多周期等。常見的跨時鐘域方法有2-DFF、DPRAM、FIFO、握手、格雷碼等，應(yīng)根據(jù)實際場景正確的選擇跨時鐘域方法。5.3.2綜合指南在完成HDL編碼后，轉(zhuǎn)至綜合階段。整合在Libero里的SynplifyPro是專門用于FPGA的綜合工具。QuartusII工具用于CPLD的綜合。通常，應(yīng)設(shè)置一個整體頻率。不建議使用綜合優(yōu)化選項，因為它會引起編碼和工具生成的網(wǎng)表之間的一致性檢查，除非正常選項不能實現(xiàn)性能或資源利用量。T/CECC000—2024應(yīng)在綜合完成之后，保證最后的綜合報告中沒有ERROR。應(yīng)在綜合完成之后，查看綜合報告，分析所有的WARNING，確保報告的WARNING信息，不會對功能實現(xiàn)產(chǎn)生影響。尤其要關(guān)注的WARNING類型有：DPRAM讀寫沖突、安全狀態(tài)機(jī)是否建立、寄存器的刪減應(yīng)在綜合完成之后，查看綜合過程中狀態(tài)機(jī)的編碼方式是否符合預(yù)期。5.3.3布線后指南設(shè)計師應(yīng)當(dāng)在布局布線前完成以下時序約束：a)周期約束：主時鐘和衍生時鐘周期、相位及占空比等b)Port約束：輸入延遲，輸出延遲c)偽路徑約束：對于已經(jīng)做了跨時鐘域設(shè)計的路徑，應(yīng)進(jìn)行偽路徑約束。d)多周期約束：對于有多周期約束的設(shè)計的路徑，應(yīng)添加相應(yīng)的約束。e)Port至Port：如對Port到Port的延遲有需要，應(yīng)進(jìn)行此約束。f)其他約束：網(wǎng)絡(luò)的Maxskew/Maxdelay等（如必要）設(shè)計師應(yīng)在布局布線完成后進(jìn)行STA檢查時序。設(shè)計者應(yīng)針對時序報告中約束的工作頻率檢查實際能夠達(dá)到的頻率，并確保留有足夠的余量。同時，設(shè)計師應(yīng)根據(jù)時序報告檢查是否有報告時序為例，并根據(jù)實際情況對時序約束進(jìn)行迭代，使得最終的布局布線結(jié)果滿足所有時序約束。5.3.4電子元件選擇選擇CEH元件，應(yīng)當(dāng)考慮以下標(biāo)準(zhǔn)：a)供應(yīng)商的穩(wěn)定供應(yīng)能力：盡量考慮已有成熟應(yīng)用的器件，而不是新產(chǎn)品，且供貨商能保證穩(wěn)定的產(chǎn)品供應(yīng)b)抗單粒子翻轉(zhuǎn)（SEU）：選擇FLASH等工藝的器件c)所選擇的封裝應(yīng)當(dāng)滿足環(huán)境需求：如工作溫度范圍d)片上資源：應(yīng)保證預(yù)估資源余量在30%或以上5.3.5故障保護(hù)和容錯設(shè)計在需求、架構(gòu)、詳細(xì)設(shè)計階段，應(yīng)增加設(shè)計故障保護(hù)功能以提高容錯性，比如考慮增加數(shù)據(jù)通信中的校驗、糾錯功能，內(nèi)建自測試（BIT）功能、關(guān)鍵參數(shù)的監(jiān)控功能等。5.4電磁兼容性與環(huán)境可靠性設(shè)計指南5.4.1電磁環(huán)境分析a)暗室結(jié)構(gòu)：暗室為進(jìn)行輻射發(fā)射和抗擾度試驗的核心設(shè)施，確保其屏蔽性至關(guān)重要。暗室的設(shè)計需使用高導(dǎo)電性材料，以防止外部電磁波干擾試驗結(jié)果，保證測試的準(zhǔn)確性和有效性。b)干擾源識別：識別所有可能的電磁干擾源，如天線、變頻器、開關(guān)電源等，分析其對試驗系統(tǒng)的影響程度，確保采取相應(yīng)的抑制措施以減少干擾。c)信號傳播：研究信號在電氣系統(tǒng)中的傳播路徑，評估電磁耦合可能帶來的影響，通過合理設(shè)計信號通道來降低噪聲干擾的傳遞。d)設(shè)備布局：合理安排各設(shè)備的位置和方向，減少互相之間的電磁干擾，確保高頻信號與低頻信號設(shè)備相對隔離，提升整體系統(tǒng)性能。e)噪聲管理：持續(xù)監(jiān)測電源線、接地線中的噪聲水平，實施主動噪聲抑制措施，如使用濾波器和干擾抑制裝置，以確保信號的完整性和穩(wěn)定性。T/CECC000—2024f)環(huán)境影響評估：分析外部環(huán)境因素（如溫度、濕度、振動等）對設(shè)備性能的潛在影響，確保設(shè)計在各種環(huán)境條件下均能正常運行。g)屏蔽設(shè)計：根據(jù)設(shè)備類型和工作頻率設(shè)計合適的屏蔽措施，如金屬外殼或?qū)щ娡繉?，旨在隔離電磁干擾，提高系統(tǒng)的電磁兼容性。h)可靠性測試：進(jìn)行全面的環(huán)境可靠性測試，評估設(shè)備在極端條件下的性能表現(xiàn)，確保其長期穩(wěn)定運5.4.2設(shè)備選型a)選型標(biāo)準(zhǔn)：依據(jù)電磁兼容性標(biāo)準(zhǔn)，選擇具有良好電氣性能和環(huán)境適應(yīng)性的設(shè)備，以確保其在機(jī)載系統(tǒng)中的有效運行。b)變頻器配置：針對進(jìn)氣溫度調(diào)節(jié)裝置，采用具有高性能濾波功能的變頻器，并在其輸入和輸出側(cè)分別安裝濾波器和電抗器，以有效抑制高頻噪聲和限制諧波干擾。c)電機(jī)驅(qū)動：后驅(qū)動裝置應(yīng)選用具有良好抗干擾特性的變頻驅(qū)動系統(tǒng)，配置適當(dāng)?shù)臑V波器，確保其在各種工作條件下的電磁兼容性，降低對其他設(shè)備的干擾。d)電源設(shè)計：在起動主路電源的直流輸出回路中添加L型濾波器，并在控制電源的直流輸出回路中加入LC濾波器，以顯著提高電磁兼容性并降低電源噪聲。e)控制電路：電氣控制柜內(nèi)的繼電器和接觸器應(yīng)并聯(lián)浪涌吸收電路，以有效控制交流和直流噪聲，確保系統(tǒng)運行的穩(wěn)定性和可靠性。f)控制系統(tǒng)選型：采用適合電磁環(huán)境的可編程邏輯控制器，確保其具備強(qiáng)大的抗干擾能力，能夠適應(yīng)復(fù)雜的電磁環(huán)境。g)測試設(shè)備：選用具備獨立供電和強(qiáng)抗干擾能力的測試系統(tǒng)，以確保測試數(shù)據(jù)的準(zhǔn)確性和可靠性。h)復(fù)位電路：設(shè)計復(fù)位信號處理電路時，確保實現(xiàn)“異步復(fù)位，同步釋放”的功能，以降低潛在的干擾風(fēng)險，確保系統(tǒng)在復(fù)位時的可靠性。i)設(shè)備測試：機(jī)載系統(tǒng)復(fù)雜電子綜合性測試，評估在極端條件下的性能表現(xiàn)，確保其長期穩(wěn)定運行。（機(jī)載系統(tǒng)復(fù)雜電子綜合性測試見附錄C）5.4.3電纜布線a)布線原則：遵循最短路徑原則，合理規(guī)劃電纜走向，減少電纜之間的交叉和重疊，以降低干擾耦合的可能性。b)屏蔽要求：選擇具備良好屏蔽效果的電纜，推薦使用符合EMC標(biāo)準(zhǔn)的屏蔽電纜，其具有優(yōu)異的抗干擾能力，能夠有效隔離外部電磁干擾，并減少信號在傳輸過程中的衰減。同時，需確保屏蔽層與接地系統(tǒng)良好連接，增強(qiáng)其屏蔽效果。c)絕緣材料：電纜應(yīng)采用PVC絕緣和外護(hù)套材料，以提供良好的耐化學(xué)性、阻燃性和機(jī)械保護(hù)，確保在各種環(huán)境條件下可靠運行。d)電纜類型：動力電纜使用符合電氣規(guī)范的屏蔽電力電纜，具有良好的抗干擾性，確保電力傳輸?shù)姆€(wěn)定性和可靠性。e)信號線布置：通訊電纜應(yīng)使用符合EMC標(biāo)準(zhǔn)的專用電纜，避免與高電流電源線交叉布置，確保信號傳輸?shù)那逦群涂煽啃?。f)接地處理：確保電纜接地良好，降低干擾影響，提升系統(tǒng)的整體電磁兼容性。g)走線路徑：合理規(guī)劃走線路徑，確保信號線與電源線之間保持適當(dāng)?shù)拈g距，降低電磁干擾的風(fēng)險。h)定期檢查：實施定期檢查和維護(hù)，確保布線質(zhì)量和系統(tǒng)的長期穩(wěn)定性。6復(fù)雜電子硬件編碼標(biāo)準(zhǔn)6.1命名規(guī)則6.1.1模塊名應(yīng)大寫T/CECC000—2024應(yīng)用范圍：Verilog,VHDL。6.1.2參數(shù)名(Verilog：parameter;VHDL：CONSTANT)應(yīng)大寫應(yīng)用范圍：Verilog，VHDL。6.1.3宏定義名(Verilog：define;VHDL：CONSTANT)應(yīng)大寫應(yīng)用范圍：Verilog,VHDL。6.1.4文件名與模塊名應(yīng)一致應(yīng)用范圍：Verilog,VHDL。6.1.5低有效復(fù)位信號名應(yīng)以‘_n’or‘_N’結(jié)尾應(yīng)用范圍：Verilog,VHDL。6.1.6信號名應(yīng)不超過32個字符應(yīng)用范圍：Verilog,VHDL。6.1.7子模塊調(diào)用名應(yīng)基于子模塊名，不能只有數(shù)字序號應(yīng)用范圍：Verilog,VHDL。[VerilogHDL]InstanceInstance_u2(//right.Data_out(Data_out),.Data_in(Data_in),.Clk(Clk),.Cs_n(Cs_n),…InstanceU2(//wrong.Data_out(Data_out),.Data_in(Data_in),.Clk(Clk),.Cs_n(Cs_n),…T/CECC000—20246.2源代碼設(shè)計規(guī)則使用if描述組合邏輯的時候，每個if應(yīng)有else與之配套，以防產(chǎn)生鎖存（latch）應(yīng)用范圍：Verilog,VHDL?！癷f…else”的層級應(yīng)不超過10。如果超過10，應(yīng)使用case語句應(yīng)用范圍：Verilog,VHDL。6.2.2case語句case語句的所有分支都應(yīng)定義（當(dāng)分支定義不完整時，需要定義default分支）用case語句描述組合邏輯時，所有輸出都應(yīng)被賦值，以防生成鎖存器（latches）6.2.3時鐘應(yīng)避免使用門控時鐘。應(yīng)用范圍：Verilog,VHDL。應(yīng)使用PLL資源來替代門控時鐘，或者保持原時鐘不變，使用時鐘使能信號進(jìn)行后續(xù)處理。6.2.4信號敏感列表Verilog:組合邏輯塊中，“always”過程中的敏感列表應(yīng)描述為“*”或在該過程中讀取的所有信號應(yīng)在敏感列表中列出；VHDL：過程中出現(xiàn)的所有讀取的信號都應(yīng)列入敏感列表。應(yīng)用范圍：Verilog,VHDL。always@(*)always@(Clr,D,SET)T/CECC000—2024process(Clr,D,SET)Endprocess;6.2.5函數(shù)函數(shù)底部應(yīng)有返回值。應(yīng)用范圍：Verilog,VHDL。6.3格式源代碼的格式不影響功能，但對可讀性和可維護(hù)性有重大影響。最重要的原則是確保項目中所有源代碼都有統(tǒng)一的格式。6.3.1每個HDL文件的文件頭應(yīng)包含下列信息a)ModuleNameb)FileNamec)Authord)Description：abriefdescriptionofthefunctionofthemodulee)Companyinformationf)Revision:currentrevisiong)RevisionHistory:changehistoryinformationh)Copyrightinformation：companynameandthestartyearofcopyright應(yīng)用范圍：Verilog,VHDL。//--------------------------------------------------------------------//ModuleName：LED5228//FileName：LED5228.v//Author：ZhangSan//Description：//TocollectthestatusofthePHYchip(BCM5228),anddriveexternal//ledlampstodisplaythestatusofeachport//Company：SAVICT/CECC000—2024//Revision:1.01//RevisionHistory://1.00:Sep15,2010EISCEH-701//1.01:Dec20,2010EISCEH-730//Copyright:SAVIC,20206.3.2一組定義或聲明應(yīng)在垂直方向上對齊應(yīng)用范圍：Verilog,VHDL。只需將最左側(cè)對齊。wire[7:0]Data_in;wire[7:0]Data_temp;//“Data_in”and“Data_temp”twolinesarealigned.SignalData_in:std_logic_vector(7downto0);SignalData_temp:std_logic_vector(7downto0);6.3.3Verilog中always塊，或者VHDL中的Process塊應(yīng)命名應(yīng)用范圍：Verilog,VHDL。6.3.4每個端口信號應(yīng)加注釋應(yīng)用范圍：Verilog,VHDL。6.3.5一個描述語句應(yīng)占用一行應(yīng)用范圍：Verilog,VHDL。6.3.6一行的寬度應(yīng)小于等于95個字符應(yīng)用范圍：Verilog,VHDL。6.4狀態(tài)機(jī)6.4.1復(fù)位后狀態(tài)機(jī)應(yīng)進(jìn)入確定的狀態(tài)應(yīng)用范圍：Verilog,VHDL。parameterCHECK=4’b0010;parameterWAITER=4’b0100;parameterDONE=4’b1000;T/CECC000—2024always@(posdgeclkornegedgerstn)beginif(!rstn)beginendelse…6.4.2狀態(tài)機(jī)的所有狀態(tài)都應(yīng)被執(zhí)行應(yīng)用范圍：Verilog,VHDL。case(current_state)S_IDLE:beginif(dha_frame_fsn_ready)next_state=S_RD_PERSONALITY;elsenext_state=S_IDLE;endS_RD_PERSONALITY:beginnext_state=S_RD_PARAM;endS_RD_PARAM:beginif(spi_ram_rd_addr==8'h36)next_state=S_WAIT_DONE;elsenext_state=current_state;endS_WAIT_DONE:beginif(frame_done)next_state=S_IDLE;elsenext_stateenddefault:beginnext_stateendendcaseT/CECC000—2024=current_state;=S_IDLE;endcase(current_state)S_IDLE:beginif(dha_frame_fsn_ready)next_state=S_RD_PERSONALITY;elsenext_state=S_IDLE;endS_RD_PERSONALITY:beginnext_state=S_RD_PARAM;endS_SET_ADDR:begin//ruleviolationnext_state=S_RD_PARAM;endS_RD_PARAM:beginif(spi_ram_rd_addr==8'h36)next_state=S_WAIT_DONE;elsenext_state=current_state;endS_WAIT_DONE:beginif(frame_done)T/CECC000—2024next_state=S_IDLE;elsenext_state=current_state;enddefault:beginnext_state=S_IDLE;endendcaseend6.5其他規(guī)則6.5.1對于比較和賦值語句，兩側(cè)變量應(yīng)有相同位寬應(yīng)用范圍：Verilog,VHDL。reg[3:0]Cnt;beginbeginsignalData_In：std_logic_vector(7downto0);signalCnt：std_logic_vector(3downto0);If(Data_In=(b”0000”&CT/CECC000—2024If(Data_In=b”0000_0000”)then6.5.2應(yīng)避免使用內(nèi)部三態(tài)門應(yīng)用范圍：Verilog,VHDL。三態(tài)門只能用于芯片管腳。6.5.3子模塊例化時的端口和參數(shù)（generic、parameter）的傳遞應(yīng)以名稱關(guān)聯(lián)形式應(yīng)用范圍：Verilog,VHDL。Instance_u2:Instance_TypePortmap(Data_out=>Data_out,Data_in=>Data_in,Clk=>Clk,Cs_n=>Cs_n,…);--ComplywiththeruleInstance_u2:Instance_TypePortmap(Data_out,Data_in,Clk,Cs_n,…);--violatestheruleINSTANCE_TYPEINSTANCE_TYPE_U0(T/CECC000—2024.Data_out(Data_out),.Data_in(Data_in),…);--ComplywiththeruleINSTANCE_TYPEINSTANCE_TYPE_U0(Data_out,Data_in,Clk,Cs_n,…);--violatestherule6.5.4所有進(jìn)入芯片的跨時鐘域信號應(yīng)被同步后再使用。同步技術(shù)包括異步FIFO,握手，寄存兩拍應(yīng)用范圍：Verilog,VHDL。6.5.5所有內(nèi)部跨時鐘域信號應(yīng)先同步后再使用應(yīng)用范圍：Verilog,VHDL。T/CECC000—2024復(fù)雜電子硬件設(shè)計標(biāo)準(zhǔn)實施與工具使用附錄本附錄旨在為復(fù)雜電子硬件設(shè)計項目提供詳細(xì)的設(shè)計實施和工具使用指南。通過遵循本附錄中的指導(dǎo)原則和推薦實踐，設(shè)計團(tuán)隊可以確保項目的順利進(jìn)行，提高設(shè)計質(zhì)量，并有效利用設(shè)計資源。2設(shè)計實施2.1需求分析明確項目目標(biāo)和功能需求，包括輸入輸出信號、性能指標(biāo)等。確定設(shè)計的約束條件，如尺寸、功耗、成本等。2.2架構(gòu)設(shè)計選擇合適的體系結(jié)構(gòu)，如微處理器系統(tǒng)、FPGA或ASIC實現(xiàn)。定義模塊劃分和接口，確保系統(tǒng)的模塊化和可擴(kuò)展性。2.3詳細(xì)設(shè)計使用硬件描述語言（HDL）如Verilog或VHDL進(jìn)行模塊級設(shè)計。利用仿真工具驗證設(shè)計的正確性和性能。2.4綜合與布局布線使用綜合工具將HDL代碼轉(zhuǎn)換為門級網(wǎng)表。進(jìn)行布局布線，優(yōu)化電路的速度和面積。2.5時序分析和驗證使用靜態(tài)時序分析(STA)工具檢查設(shè)計的時序是否滿足要求。根據(jù)需要調(diào)整設(shè)計以滿足時序要求。2.6物理實現(xiàn)生成制造所需的文件，如GDSII或OASIS格式。確保設(shè)計符合制造廠商的工藝要求。2.7測試與調(diào)試制定詳細(xì)的測試計劃，包括功能測試、性能測試和可靠性測試。使用邏輯分析儀、示波器等工具進(jìn)行調(diào)試。3工具使用指南3.1設(shè)計工具T/CECC000—2024HDL編輯器：選擇功能強(qiáng)大且易于使用的編輯環(huán)境，如QuartusII或Vivado。綜合工具：根據(jù)設(shè)計規(guī)模和復(fù)雜度選擇合適的綜合工具，如SynplifyPro或XilinxISE。仿真工具：使用ModelSim或VCS進(jìn)行功能仿真和時序驗證。STA工具：采用PrimeTime或XTA進(jìn)行檢查以確保滿足時序要求。3.2版本控制使用版本控制系統(tǒng)如JIRA管理源代碼和文檔，確保團(tuán)隊成員之間的協(xié)作和