華為“老司機”親身經歷告訴你，華為硬件究竟是如何開發？

在國內提到硬件開發，華為無疑是最優秀的公司。同時，硬件創業者從華為出來的也非常多。這篇文章的原作者正是一名華為的“老司機”，非常詳細的介紹了華為硬件開發的流程，華為是怎么做硬件開發的，非常值得其他硬件開發者借鑒。

曾經2007年，剛工作2年的時候去一家小公司去面試。當時考題，我感覺我做得很好，面試的時候，對方對我也很認可。但是他當時說：“我需要招一個，在大公司待過的，最好知道硬件開發流程和規范的。雖然你題答得不錯，但是我們需要一個有豐富經驗的，最好在華為待過的。”

當時，我就在想“華為的規范和流程是啥樣的”，就一直想去看看。之前對華為的面試一直都不是很感興趣。之后，就很想有機會去華為看看。2008到了華為。

我能想到的華為硬件開發的幾個不一樣的點，跟大家分享一下：

•   文檔，評審，設計

•   華為的硬件領域的人員構成

•   華為的流程

•   歸一化

•   專題分析

文檔，評審，設計

當時剛入職時，三個人做一個電路板。雖然電路復雜一些，還是有一些人力過剩的，所以我就被安排去寫一個PCI轉UART的邏輯。

我當時是新員工，也急于表現自己，利用周末的時間，估計用了一周的時間，就寫完代碼，開始仿真了。我以為我的導師兼主管會表揚一下，結果沒有，他說：“你為什么沒有召集大家討論？然后再寫方案，評審？然后再動手寫代碼？”我當時是沒有理解的，覺得我一個人就搞定的事情，為啥要這樣勞師動眾？

現在回想起來：

第一、 從主管的角度，不知道新員工的個人能力，你能把做的事情講清楚了，他才放心。

第二、 從公司的角度，有一套流程來保證項目的交付。那么則不再太依賴某個人的個人能力，任何一個人的離職，都不會影響項目的交付。這也是華為最了不起的地方，把 復雜的項目拆得非常細碎，這樣不需要特別牛的人來交付項目。這是為什么華為的工程師的收入是思科的N分之一。

第三、 從效果角度，畢竟一個人的想法是有限的，把想法文檔化的過程，就是整理思路的過程；討論的過程，就是收集你自己沒有想到的過程。正式的評審，是大家達成意見的過程。提前討論，讓相關的人都參與到你的設計中，總比你設計完了，被別人指出一個致命的問題要強得多。

就是因為華為把一項工作拆散了，所以溝通，文檔，評審，討論，變得非常重要。這個工作模式的缺點，也是顯而易見，溝通成本高，工作效率低。　

華為的硬件領域的人員構成

在華為內部里面，人員角色非常多。硬件的人是對產品開發階段，端到端負責的。

做單板硬件工程師，可以涉獵最多的領域，同時也是工作內容最雜，接觸人最多，扯皮的最多的工種。但是也因為有人專門負責畫PCB、EMC、電源、邏輯，原本硬件工程師應該做的領域。那么硬件工程師就武功盡廢，變成“連連線”。

其實不然，正是由于每個人都是一個小的領域，沒有人統領，所以一個好的硬件經理的作用非常的重要，是貫穿所有領域和全部流程的關鍵角色。

正如原來華為內部論壇上有一個人比喻的，硬件工程師更像是處理器里面的“Cache”，是所有環節的中轉站。

大公司把人的分工分的這么細，也是防止某一撥掌握了太多公司的核心技術，出去單搞了。

華為的流程

其實華為的流程，很多人都知道IPD流程是從IBM來的，同時華為也去咨詢過愛立信，愛立信的硬件開發，完全沒有流程一說。

我個人理解：IPD流程已經在華為變種，結合了中國人的特點，華為的企業特點進行了變通和優化。如果華為僵硬的套用IBM的這套流程，也必定不會這么成功。　

那么概括一下華為的硬件開發流程：

需求分析→總體設計→專題分析→詳細設計→邏輯詳設→原理圖→PCB→檢視→粘合邏輯→投板→生產試制→回板調試→單元測試→專業實驗→系統聯調→小批量試制→硬件穩定→維護。

流程的根本在于，這個環節做好了，再進入下一個環節。所有的環節其實跟其他公司并沒有太大的區別，只不過嚴格把握了進入下一個環節的考核條件。令硬件工程師最糾結的是“沒有個節點跟’投板’對應”。

華為支撐IPD流程的系統是PDM(又名爬的慢)

PDM的中文名稱為產品數據管理(Product DataManagement)。PDM是一門用來管理所有與產品相關信息(包括零件信息、配置、文檔、CAD文件、結構、權限信息等)和所有與產品相關過程(包括過程定義和管理)的技術。

華為所有的器件資料，產品部件，工具，文檔，原理圖，PCB，邏輯代碼等都存在這個系統上。但是系統過于龐雜，其實比較難使用，跟服務器歸檔、SVN歸檔、也容易搞混淆。

有朋友感慨，說他感受到了“精細化流程管理，讓每個人都是螺絲釘”；也有前同事感慨“團隊開發是戰無不勝的；也有朋友說“信息安全啊”。

歸一化

器件歸一化

硬件工程師一般都能夠理解，在一個板子上面的，盡可能的選擇成本更低的器件，選擇更少種類的器件，便于集中采購，同時也便于加工。但是其他公司可能沒有對器件歸一化的工作做得那么細致和嚴格。　

第一， 由于華為整個公司使用的器件種類非常的多，所以如果減小一個器件編碼，帶來的收益是十萬人民幣到幾百萬，而其他公司可能達不到這個高的收益。所以如果能減少一個編碼，寧愿選擇可能成本更高的器件。但是這個也需要按照每年的器件直接成本收益*器件發貨數量，與編碼成本+加工成本差異，進行對比的。

不過器件歸一化之后，器件的價格又可以跟供應商重新談價格，這個收益是迭代的。所以，有時即使是成本占優，也會傾向去器件歸一化的結論。例如，逐步去除了5%精度的電阻，歸一化到1%。　

第二， 器件歸一化，都是需要進行專題分析的。因為也有工程師為了歸一化，對電路原理沒有充分分析，導致的歸一化帶來“問題引入”。

所以，當時我的部門當時有一個表格，“器件歸一化分析.xls”的excel表格，把每個器件，原來選型，歸一化的選型，更改的原因，都做好記錄和原因分析。一是讓每個做歸一化的員工都充分考慮分析，二是問題都有記錄，便于評審，三是出了問題，好打板子。　　

單板歸一化

除了器件歸一化，更高一個層次的歸一化，就是單板歸一化。(單板這個概念，我稍微澄清一下，我剛到華為的時候，也覺得這個詞很奇怪。因為通信設備，都是機框，背板，加各個功能模塊的電路板，各個功能模塊的電路就叫做“單板”，硬件工程師，一般也叫做“單板硬件”)　

單板歸一化帶來的好處，首先是電路的種類少，電路的種類少的好處有兩個：一是生產成本降低，二是硬件維護成本降低，三是軟件開發和維護的成本降低。

第一、單板歸一化的先決條件首先是處理器歸一化。其實，華為的有的產品這點做得其實不好，X86、MIPS、ARM、PPC全部都用個遍，所以一個硬件平臺，需要配備各種軟件人員，操作系統搞N套，VxWorks和Linux，BIOS各種配套。

第二、單板的歸一化，要注意產品的衍生。第一個版本的機框上的單板所實現的功能，如果后續的產品可以使用，應該直接可以用，不需要再開發。如果不注意這點，第一個版本的單板，到第二版本時，發現不能相互借用。反過來，再修改第一個版本的電路板，來適應新版本。有時問題更糟糕，就是完全不能兼容，只好重新開發。單板的規劃顯得非常重要。

第三、單板歸一化時，雖然電路部分兼容了，但是結構件不兼容。對于市場人員的配置來說，仍然是兩種配置。一樣是失敗的。

平臺歸一化

那么如果發現不同的硬件平臺的架構雷同，功能類似。那么機框也可以歸一化。只需要制作不同的電路功能模塊，就可以實現不同的功能需求。

但是不同的硬件形態都是有他存在的意義的，如果強行歸一，市場未必會接受這種事情的發生。例如用一個運營商的平臺去歸一一個企業應用或者家庭應用的產品，可能就未必能夠成功。

網絡架構歸一化

這個說法是我自己想的，早在08年的時候，華為就在討論“云管端戰略”了，當時不是很理解。當我們一個運營商平臺部門，跟“服務器”的部門合并的時候，似乎理解了點什么。

當X86處理器足夠強大的時候，所有的運算，不管是否性價比最高，都送到云端進行處理，那么所有中間的存儲和計算都顯得不重要了。那么整個網絡的結構，就是終端+管道+云存儲和云計算。

既然計算和存儲設備都是一樣的，那作為運算和存儲的設備，也就不需要那么多樣化了。這時網絡存儲設備，和服務器就顯得尤為重要。

這也是華為成立IT產品線，做重點戰略投資的重要原因。所以現在也就不需要那么多網絡節點和網絡平臺了，只需要超強的處理和存儲能力和寬廣的通道，多樣的終端。

專題分析

“專題分析”是設計硬件最核心的工作，而不是畫原理圖。因為今天是周末，寫點輕松點的，先說個故事，傳說哈，大家當笑話聽。

早期，我大中華自研的潛艇，都是海藍色的，跟軍艦一樣顏色“藍灰色”。后來我大海軍去參觀前蘇聯的軍事演習，發現俄國人的潛艇不是藍色的，是黑色的。于是 回來大討論，為啥俄國人的潛艇是黑色的。

猜想：一定是黑色在夜里面不容易被發現，所以油漆成黑色的。于是全國油漆大運動。后來才知道，原來俄國人的黑色不 是油漆，是黑色的橡膠，消聲瓦。于是我們也貼橡膠，可是我們貼了橡膠之后就潛艇跑不動了，因為我們的潛艇的動力不如別人。(以上故事純屬虛構，如有雷同， 請把發生時間改為清朝。)

為啥在這里說這個照葫蘆畫瓢失敗的故事呢。我覺得很多硬件工程師有個誤區，覺得自己的核心競爭力是在于會使用幾個軟件(cadence、Protel)， 畫畫原理圖，畫畫PCB。我早期的一份工作就這樣，最大的本事就是照葫蘆畫瓢，抄Demo板，抄以前成熟的電路，如果碰到了新的電路設計，一般是按照參考 電路先畫出電路，再通過調試，去嘗試，碰到問題，再去解決問題。　

那么我現在的觀念是，硬件工程師最值錢的地方是在于懂硬件原理，懂得電路分析，模電數電原理，電磁場理論，而不是會使用畫圖軟件。

那么華為是怎樣做電路設計的呢？為什么會有專題分析的說法呢？為什么電路設計的時候要做專題分析？

第一、 例行的，每個電路一般都會做幾個必選的專題：電源、時鐘、小系統；把每個管腳怎么用，怎么接，對接的管腳的電平是否滿足要求，都需要文檔化，分析清楚。在選用新器件的話，對應硬件工程師的工作量還是比較大的。但是如果是其他公司，直接按照推薦電路設計就完事了。

電源專題，需要分析電源需求，每種電源的電壓范圍，電流需求，動態響應，上電時序；時鐘專題，針對每個時鐘的輸入的電平標準，頻率，抖動等參數，時鐘時序，并按照各種時鐘解決方案進行優化;

第二、 當電路設計過程中，碰到一些新的問題，之前團隊中沒有接觸過的問題，或者認為是重點，難點的內容，會專門做這個問題點的專題分析：例如我們做過的一些雙 BIOS啟動，攝像頭的紅外LED的驅動，主備倒換啊，之類的，就會把一個問題點分析透，然后再動手做畫原理圖。

第三、 那么在開發硬件的時候，Demo只是作為參考，每一個依據都是來自于datasheet，除了看芯片的數據手冊之外，還要仔細查看數據手冊的勘誤表 errata，核對datasheet與Demo的差一點，如果器件有checklist還得核對checklist。

曾經開發AMD的時候，datasheet、Demo、checklist，三個文檔對不上的情況。也出現過，一個比較難復現的問題，后來查看了Errata，發現是廠家芯 片升級了，修正了bug，而我們還在采購老版本的芯片。

第四、 由于項目本身有交付時間要求，那么在有限時間內其實不可能做到每個問題點都做得深入透徹。

那么問題來了：是怎么做到的呢？首先，每個項目都有《問題跟蹤表》，而硬件團隊由于事情非常的雜，所以把這個表要用的非常好，不然丟東拉西很正常。我曾經把這個表應用到家里裝修。

這個表的原理很簡單，就是記錄，問題內容，責任人，完成狀態，完成時間。但是只要你堅持用，你會發現，你問題不會跟蹤丟，做事情會比較有條理， 而且會有成就感。用了這個表以后，發現問題之后，先記錄下來，即使現在不解決，那么也會識別他要不要解決，什么時候解決。

其次、問題分優先級，任何項目都 是帶著風險前進的，那么識別出高風險的問題，優先解決高風險的問題，帶著低風險的問題繼續走。這也是華為電路設計中“0歐姆”電阻用的比較多的有一個原因，識別出風險之后，但是又分析不清楚，或者來不及分析，只好做兼容設計。這里不得不感慨一句，在你的設計過程中，你馬虎對待，沒有分析清楚的問題，最后一定會暴露出來。

所以，在“菊花廠”做硬件工程師，“專題分析”是設計硬件最核心的工作，而不是畫原理圖。通過這個方法，用1~2個月做電路分析，而用1~2周時間畫原理圖，取代了，畫圖，調試，改版，再調試，在改版的形式。多快好省，是不可能同時實現的，那么硬件工程師有責任做很好的折衷和權衡。