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

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