完成一個大的硬件工程，需要考慮的事情很多。所以，這對工程師的要求就高了些。且看下面是一個很牛叉的硬件工程師做的分享，希望能幫助到各位。

一、成本現象一

程序只要穩定就可以了，代碼長一點，效率低一點不是關鍵。

點評：CPU的速度和存儲器的空間都是用錢買來的，如果寫代碼時多花幾天時間提高一下程序效率，那么從降低CPU主頻和減少存儲器容量所節約的成本絕對是劃算的。CPLD/FPGA設計也類似。

現象二

面板上的指示燈選什么顏色呢?我覺得藍色比較特別，就選它吧！

點評：其它紅綠黃橙等顏色的不管大小(5mm以下)封裝如何，都已成熟了幾十年，價格一般都在5毛錢以下，而藍色卻是近三四年才發明的東西，技術成熟度和供貨穩定度都較差，價格卻要貴四五倍。目前藍色指示燈只用在不能用其它顏色替代的場合，如顯示視頻信號等。

現象三

這點邏輯用74XX的門電路搭也行，但太土，還是用CPLD吧，顯得高檔多了

點評：74XX的門電路只幾毛錢，而CPLD至少也得幾十塊，(GAL/PAL雖然只幾塊錢，但公司不推薦使用)。成本提高了N倍不說，還給生產、文檔等工作增添數倍的工作。

現象四

我們的系統要求這么高，包括MEM、CPU、FPGA等所有的芯片都要選最快的

點評：在一個高速系統中并不是每一部分都工作在高速狀態，而器件速度每提高一個等級，價格差不多要翻倍，另外還給信號完整性問題帶來極大的負面影響。

現象五

這板子的PCB設計要求不高，就用細一點的線，自動布吧

點評：自動布線必然要占用更大的PCB面積，同時產生比手動布線多好多倍的過孔，在批量很大的產品中，PCB廠家降價所考慮的因素除了商務因素外，就是線寬和過孔數量，它們分別影響到PCB的成品率和鉆頭的消耗數量，節約了供應商的成本，也就給降價找到了理由。

二：低功耗設計現象一

我們這系統是220V供電，就不用在乎功耗問題了

點評：低功耗設計并不僅僅是為了省電，更多的好處在于降低了電源模塊及散熱系統的成本、由于電流的減小也減少了電磁輻射和熱噪聲的干擾。隨著設備溫度的降低，器件壽命則相應延長(半導體器件的工作溫度每提高10度，壽命則縮短一半)。

現象二

這些總線信號都用電阻拉一下，感覺放心些

點評：信號需要上下拉的原因很多，但也不是個個都要拉。上下拉電阻拉一個單純的輸入信號，電流也就幾十微安以下，但拉一個被驅動了的信號，其電流將達毫安級，現在的系統常常是地址數據各32位，可能還有244/245隔離后的總線及其它信號，都上拉的話，幾瓦的功耗就耗在這些電阻上了(不要用8毛錢一度電的觀念來對待這幾瓦的功耗)。

現象三

這款FPGA還剩這么多門用不完，可盡情發揮吧

點評：FGPA的功耗與被使用的觸發器數量及其翻轉次數成正比，所以同一型號的FPGA在不同電路不同時刻的功耗可能相差100倍。盡量減少高速翻轉的觸發器數量是降低FPGA功耗的根本方法。

現象四

這些小芯片的功耗都很低，不用考慮

點評：對于內部不太復雜的芯片功耗是很難確定的，它主要由引腳上的電流確定，一個ABT16244，沒有負載的話耗電大概不到1毫安，但它的指標是每個腳可驅動60毫安的負載(如匹配幾十歐姆的電阻)，即滿負荷的功耗最大可達60*16=960mA，當然只是電源電流這么大，熱量都落到負載身上了。

現象五

降低功耗都是硬件人員的事，與軟件沒關系

點評：硬件只是搭個舞臺，唱戲的卻是軟件，總線上幾乎每一個芯片的訪問、每一個信號的翻轉差不多都由軟件控制的，如果軟件能減少外存的訪問次數(多使用寄存器變量、多使用內部CACHE等)、及時響應中斷(中斷往往是低電平有效并帶有上拉電阻)及其它針對具體單板的特定措施都將對降低功耗作出很大的獻。

三：系統效率現象一

這主頻100M的CPU只能處理70%，換200M主頻的就沒事了

點評：系統的處理能力牽涉到多種多樣的因素，在通信業務中其瓶頸一般都在存儲器上，CPU再快，外部訪問快不起來也是徒勞。

現象二

CPU用大一點的CACHE，就應該快了

點評：CACHE的增大，并不一定就導致系統性能的提高，在某些情況下關閉CACHE反而比使用CACHE還快。原因是搬到CACHE中的數據必須得到多次重復使用才會提高系統效率。所以在通信系統中一般只打開指令CACHE，數據CACHE即使打開也只局限在部分存儲空間，如堆棧部分。同時也要求程序設計要兼顧CACHE的容量及塊大小，這涉及到關鍵代碼循環體的長度及跳轉范圍，如果一個循環剛好比CACHE大那么一點點，又在反復循環的話，那就慘了。

現象三

這么多任務到底是用中斷還是用查詢呢?還是中斷快些吧

點評：中斷的實時性強，但不一定快。如果中斷任務特別多的話，這個沒退出來，后面又接踵而至，一會兒系統就將崩潰了。如果任務數量多但很頻繁的話，CPU的很大精力都用在進出中斷的開銷上，系統效率極為低下，如果改用查詢方式反而可極大提高效率，但查詢有時不能滿足實時性要求，所以最好的辦法是在中斷中查詢，即進一次中斷就把積累的所有任務都處理完再退出。

現象四

存儲器接口的時序都是廠家默認的配置，不用修改的

點評：BSP對存儲器接口設置的默認值都是按最保守的參數設置的，在實際應用中應結合總線工作頻率和等待周期等參數進行合理調配。有時把頻率降低反而可提高效率，如RAM的存取周期是70ns，總線頻率為40M時，設3個周期的存取時間，即75ns即可;若總線頻率為50M時，必須設為4個周期，實際存取時間卻放慢到了 80ns。

現象五

一個CPU處理不過來，就用兩個分布處理，處理能力可提高一倍

點評：對于搬磚頭來說，兩個人應該比一個人的效率高一倍;對于作畫來說，多一個人只能幫倒忙。使用幾個CPU需對業務有較多的了解后才能確定，盡量減少兩個CPU間協調的代價，使1+1盡可能接近2，千萬別小于1。

四：可靠性設計現象一

這塊單板已小批量生產了，經過長時間測試沒發現任何問題

點評：硬件設計和芯片應用必須符合相關規范，尤其是芯片手冊中提到的所有參數(耐壓、I/O電平范圍、電流、時序、溫度PCB布線、電源質量等)，不能光靠試驗來驗證。公司有不少產品都有過慘痛的教訓，產品賣了一兩年，IC廠家換了個生產線，咱們的板子就不轉了，原因就是人家的芯片參數發生了點變化，但并沒有超出手冊的范圍。如果你以手冊為準，那他怎么變化都不怕，如果參數變得超出手冊范圍了還可找他索賠(假如這時你的板子還能轉，那你的可靠性就更牛了)。

現象二

這部分電路只要要求軟件這樣設計就不會有問題

點評：硬件上很多電氣特性直接受軟件控制，但軟件是經常發生意外的，程序跑飛了之后無法預料會有什么操作。設計者應確保不論軟件做什么樣的操作硬件都不應在短時間內發生永久性損壞。

現象三

用戶操作錯誤發生問題就不能怪我了

點評：要求用戶嚴格按手冊操作是沒錯的，但用戶是人，就有犯錯的時候，不能說碰錯一個鍵就死機，插錯一個插頭就燒板子。所以對用戶可能犯的各種錯誤必須加以保護。

現象四

這板子壞的原因是對端的板子出問題了，也不是我的責任

點評：對于各種對外的硬件接口應有足夠的兼容性，不能因為對方信號不正常，你就歇著了。它不正常只應影響到與其有關的那部分功能，而其它功能應能正常工作，不應徹底罷工，甚至永久損壞，而且一旦接口恢復，你也應立即恢復正常。