本文轉自硬件十萬個爲什麼
曾經說過，在開始動手畫原理圖之前，需要做需求分析，專題分析等等工作。但是在真正開工之前，有反覆的方案設計的迭代過程。也有一些不是研發出身的老闆跟我抱怨，硬件工程師讓結構先設計、結構工程師說硬件工程師應該先給大致的需求，不知道應該誰先動。
工欲善其事,必先利其器是說:工匠想要使他的工作做好，一定要先讓工具鋒利。比喻要做好一件事，準備工作非常重要。語出《論語·衛靈公》：子貢問爲仁。子曰：“工欲善其事，必先利其器。居是邦也，事其大夫之賢者，友其士之仁者。” 這個準備工作，當然不只是指工具，還有動手之前的策劃、思考、評估、方案設計、架構設計等。
硬件工程師動手畫原理圖之前，需要畫的一個東東就是，用“猥瑣”（Visio）畫出電路板方案框圖。
當然，每個工程師都有自己的喜好。有的人喜歡用Visio、有的人喜歡用PPT，這都無所謂。關鍵是這個電路板的框圖不是簡單的拍腦袋就出來的。
它的誕生，就是一個電路板方案設計的過程。如果這個階段拍腦袋、回板就會拍大腿，最後只能拍拍屁股走人了。
那麼我們如何能夠完成一個電路板的方案設計過程呢？除了憑藉我們的經驗，還有什麼是我們需要做的呢？
【步驟一、建立歸檔文件夾，明確歸檔計劃】
建議自建SVN的雲服務器，講需要歸檔的文件夾，按照本企業或者本項目的需求進行設立需要的文件夾。這些自然就是我們在產品研發完成一個完整的產品，需要產生和考慮的所有維度、需要歸檔的所有內容的綱領。
github或者內網文件夾共享其實都可以，但是github速度不快有點影響設計效率，內網文件夾不便於版本管理，當服務器出現故障會影響整個團隊的開發，也不便於移動辦公。
【步驟二、建立問題跟蹤機制】
之前的系列，我們專門說過問題跟蹤，我們針對當前項目，需要建立例會的制度，根據人員情況和人員的素質不同，需要有針對性的進行例會。可能是每天晨會、也可以是每週例會，靈活把握跟蹤頻度。
但是我們需要針對項目建立該項目的問題跟蹤表格，便於整個項目過程中所有出現的問題，跟蹤閉環，避免問題跟蹤出現遺漏。
當然我們還可以計算更復雜的表格，以前我們做個一個表格可以計算每個任務的完成提前、拖延的天數，可以作爲KPI進行考覈。（這個做法不提倡）
【步驟三、需求跟蹤】
在華爲、這個部分會由SE（系統工程師、system engineer不是stupid engineer）進行分解分配。硬件工程師根據分解分配結果對照檢查，並創建單板需求跟蹤表。跟蹤表完成後需召集SE、整機結構、產品工程工藝（PCB Layout工程師、工藝工程師）、生產、測試、軟件等周邊人員評審歸檔。
當然，我們從來都是期望需求能歸檔之後不再修改。但是我們在設計過程中會發現會不可避免的進行修改。但是我們在TR3之後是應該禁止修改的，如果在TR3之後增改需求，所有的需求變更需要通過CR（需求變更電子流）進行跟蹤。
從硬件穩定的角度來說，越在項目的後期，需求的變更帶來的影響越大，帶來的設計變動，對質量的影響越大。但是隨着敏捷的思想，以及客戶需求可能在硬件長週期過程中的變化，很多場景我們不得不去變更需求。
| 序號 | 各階段介紹 | 備註 |
|---|---|---|
| 1 | Charter | 責任主體：Marketing團隊和SE; 主要工作：Charter需要回答這些問題：版本的Top N需求和主要競爭需求，主要目標客戶，完整的包需求，版本的里程碑時間點，應用的時間窗口以及在版本火車中所處的位置 |
| 2 | Charter-TR1 | 責任主體：SE團隊，同時Marketing配合完成需求的細化、澄清和修訂；主要工作：輸出設計需求（包括每個需求的輸入、輸出參數，並輸出低保真界面原型） |
| 3 | CDCP | 主要工作：近年來大部分項目都裁剪，具體作用不明 |
| 4 | TR1-TR2 | 責任主體：SE團隊；主要工作：輸出是設計規格（接口設計、高保真界面原型） |
| 5 | PDCP | 責任主體：開發代表；主要工作：主要工作：代碼規模、關鍵時間點和人力需求。質量目標、SOW（工作任務書） |
| 6 | TR2-TR3 | 責任主體：開發組；主要工作：主要工作：需求規格說明書（SRS）；系統測試用例（STC）、概要設計（HLD）、集成測試用例（ITC） |
需求的分析和理解往往不可能一步到位，研發人員的理解也有可能不能非常準確理解現場場景。所以需求跟蹤完成之後，需要進行兩輪的需求的串講、反串講。（串講，是指需求發佈者與開發者講解，反串講是指開發者理解需求之後，對需求發佈者進行講解）。
需求反串講，是設計者向SE、項目經理等角色逐條講解硬件需求，形成統一的認識。對於已有實現方案的需求，講解要包含方案。串講和反串講一定要讓SE/軟件/測試領域全程參與，提出的問題要在詳細設計開始前全部解決閉環。
【步驟四、關鍵器件分析】
我們研發一個新項目的時候，不可避免的會使用我們沒有使用過的器件，甚至是整個公司都沒有使用過的器件。
我們根據設計需求選定了基本方案之後，需要對新器件、關鍵器件進行應用分析，輸出應用分析報告，並召集相關人員、管理者、有經驗的工程師進行評審和分析。
方案分析過程中需要參考和更新器件的Bug List和設計注意事項。同時收集案例，並給出應對解決措施，提前預防已知問題。
關鍵器件不僅僅侷限於新引入的器件，還包括複雜的器件、開發人員及項目組經驗積累都不足的器件。
這個關鍵器件的分析，我們需要對器件的datasheet進行分析、尋找並Demo板、查閱廠家的errata，尋找已經產品化或者已經完成過的設計，部分電路的改動，需要動手做電路實驗、或者做電路仿真，進行驗證。
【步驟五、預佈局及結構設計】
我們根據需求，明確了必要的功能、性能、然後明確了關鍵器件，也就是電路板上面大功率器件、新器件、複雜器件都已經敲定了。那麼我們可以做一個預佈局，明確電路板尺寸，形狀的大致想法。
我們爲了實現一個準確的預佈局，需要輸出一個預佈局原理圖，要求原理圖至少包含主要器件、電源、熱敏感器件和接插件。
預佈局需要把電路板的信號流向、器件功能、主要器件的電源管腳分佈、整個電路板的電源的基本分佈和流向。
然後把相關的訴求，提供給ID工程師，給一個基本的ID設想，然後由結構工程師進行結構設計的細化。
如果是成熟的機框，則這個過程相對簡單一些，例如ATCA、VPX這種標準機框。一些個人消費電子產品這個過程反覆的可能性非常大。
爲了避免這個過程，硬件工程師在完成初步的預佈局，之後應該把自己的設計訴求，全部記錄在《結構要素圖設計說明書》中，提供給結構和ID工程師。
【步驟六、散熱評估】
硬件工程師需要提供單板佈局和器件熱耗（功耗）表、各器件散熱參數。數字器件要注意提供儘量準確的功耗數據，特別是DDR/FPGA等器件要根據使用場景進行計算。提供的器件的功耗需要準確，避免過設計，也避免散熱風險。
【步驟七、新器件導入評估】
在華爲，一個新器件的導入是非常複雜的，我們不在華爲，選擇新器件，也需要謹慎選取，並做相關評估。
這個其實應該是一個sourcing的過程：我們不但需求考慮新器件功能是否滿足我們的需求，同時需要考慮：可靠性、可採購性、成本、焊接工藝、功耗、散熱等維度。
【步驟八、背板管腳分配、板間FMEA分析】
我們需要根據背板標準，分配電路板的管腳。如果是新設計背板，需要考慮背板連接器的成本、速率、數量。
在產品設計階段，FMEA針對所有板間信號/關鍵器件展開分析，可確保無故障遺漏。用以分析所有故障影響，同時做到優化故障管理能力。在這個過程中存在着兩個標準，那就是對於嚴重故障，要求盡最大可能避免；對於需要處理的故障，要求能夠監測並定位到現場置換單元（FRU，Field Replacement Unit）。
【步驟九、歸一化分析】
歸一化作爲DFx的一項內容，需要硬件特別關注。每個產品需整理自身的BOM歸一化器件清單，常用器件選型只能在歸一化清單中選擇。歸一化清單爲本企業或者本部門使用過的器件或者採購過的器件。
儘量減少器件種類，有效減少器件種類、不但降低管理成本、同時也降低加工和採購成本。
【步驟十、可重用性分析】
所有單板都要進行可重用性分析，包含三方面內容：
1. 本單板可重用的已有電路；
2. 本單板希望能夠重用的電路；
3. 本單板完成開發後，可提供其它項目重用的電路。
【步驟十一、早期BOM審查】
1. 方案確定後就把已確定的關鍵器件，通過採購進行關鍵器件的意見反饋。
2. 所有非常規器件、非主流器件、器件必須逐一和採購進行確認，詳細評估風險，有風險的器件要選擇替代方案。
3. 有關鍵器件在設計過程中變更時，還需要與採購人員進行確認。
經過上述十一個步驟
1. 我們選定了關鍵器件、並進行了預佈局、明確了結構的設計，排除了可行性、採購、可靠性、散熱方面的風險。
通過需求跟蹤，確保所有需求能夠在設計中落實，最終設計的產品符合客戶的需求。
通過歸一化、可重用性分析，提升了整體的設計效率，並且隱性的提升了設計質量。
通過《問題跟蹤表》、建立《歸檔文件夾》，確保了交付的項目管理。
完成這些準備工作之後，我們的電路原理框圖、電路原理圖的設計纔是讓人安心和可靠的。