Re: [討論] how to be a star engineer

看板Engineer作者T3T (G.S.M.W)時間5年前 (2018/07/08 17:29)推噓7(7推 0噓 4→)

留言11則, 7人參與討論串2/3 (看更多)

※ 引述《doggob (happy)》之銘言： : 看到這個版就讓我想到，我第一份工作，第一天上班我師父就拿這份給我K。板上各位肥 : 仔應該都要拜讀一下 : 看我只有一個感想靠這樣也能發IEEE : https://ieeexplore.ieee.org/document/795608/ 轉貼一個中國華為工程師的文章硬體的看了應該會比較有感觸因為作者是硬體的 http://m.5yedu.com/d622168.html 1 10年整理600多頁的“紅寶書” 有人說，做硬體很容易，會擰螺絲會連線畫原理圖就行，但在楊勇看來，這充其量只是連線工程師、畫圖工程師，不能叫硬體工程師。硬體工程師要懂的東西很多且很雜，PI（電源完整性）、SI（信號完整性）、時序……小到電阻電容，大到協議標準，遇到問題要能夠有自己的判斷而不是茫然無措。當時楊勇所在小組的老大說過一句話，“只要是看得見的，硬體都要管”，言下之意是硬體工程師要瞭解和單板硬體相關的所有領域，並對相關的技術問題做出判斷，現在看來就是整個大硬體域。在加入華為前，楊勇已經在廣州的一家公司做了兩年的硬體了，當時做的單板規模很小、很簡單，遠不及華為單板的規模和專業性，接觸華為單板後發現自己瞭解的那點硬體知識真不夠用，於是就一邊硬啃各種文檔資料，一邊追著專家請教。在工作中逐步學習PI/SI ，學習高速設計，學習工藝，學習結構，學習散熱,學習可靠性，總之只要和硬體相關的都會去學。雖然不如該領域工程深入，但也能夠和對應領域工程師無障礙溝通並共同解決涉及的問題，到後來無論是做單板還是看別人的單板都會遊刃有餘。這麼多年的工作讓楊勇養成了一個習慣，在看器件手冊和技術文檔時，如果看到一個沒見過的技術名詞，就會立刻去google一下。即便是看不明白，也會硬著頭皮從頭到尾讀一遍，在後續的工作中再去慢慢揣摩，同時會把在這個過程中看到的相關技術資訊摘出來，專門放到兩個文檔中（一個word文檔，資訊記錄較詳細；一個是excel，方便查閱），這樣後續查閱就不需要再翻箱倒櫃了。新知識、新技術永遠在不停地發展，目前楊勇的“紅寶書”還在陸續更新中。10年來，楊勇的word文檔已經足足有六百多頁的乾貨了，細看下來，除了技術解釋，標準摘要外，典型設計、設計中易犯的錯誤、各種器件的設計注意事項、等等內容也收集在裡面。 “除了查閱的便利外，這個過程其實也是我個人學習和總結的一個過程。”現在只要是楊勇的電腦開著，他的這兩個文檔就是開著的。楊勇也無償把紅寶書分享給一些有需要的同事，希望也能方便他們的工作。 2 攻關像藝術創作，需要堅持也需要靈感問題攻關幾乎成了華為硬體人員的成長必經之路，既磨練意志也開闊眼界，這十幾年楊勇主導和參與過的攻關不計其數。 “幾年前帶領過一個晶片介面誤碼攻關，這個攻關在楊勇投入前已經攻關了月余，完全是被供應商牽著鼻子走，不斷給他們測各種資料，然後等他們答覆，反復很多次卻沒看到任何實質性的進展。” 加入並帶領攻關後，楊勇先將已有的資料梳理了一下，然後和供應商交流了幾次，基於這些資料楊勇判斷他們的方向是錯誤的，但他們卻堅持己見，認為是華為提供的參考時鐘抖動有問題，但從測量資料上分析抖動是正常的，這樣一來攻關便陷入了僵局，於是楊勇決定撇開供應商進行問題攻關。 “經過對問題的分析和測試，我們判斷DDR控制器的讀寫採樣視窗小導致了這個問題，進一步設計實驗發現是“讀”方向有問題，但是視窗到底有多大，示波器無法準確的測試。 ”通過和海思交流，楊勇利用晶片已有的寄存器很巧妙的設計了實驗，準確的測定了DDR 介面的視窗大小，出問題時的視窗確實很小，可是奇怪的是控制器啟動後都會做讀寫視窗的掃描，理論上不應該出現這個問題。於是楊勇把DDR的手冊又啃了一遍，分析了DDR的視窗掃描演算法，結合示波器的測試，最後發現是供應商集成的DDR視窗掃描演算法太簡陋，掃出來的視窗比實際的大很多，並且華為使用的某廠家DDR在高溫下視窗會縮小，至此整個問題水落石出。針對此問題供應商的演算法已無法修改，因此楊勇和工程師設計了一個巧妙的軟體演算法對視窗進行補償，同時更換某廠家最新版本的DDR晶片，徹底解決了這個問題。在最終問題定位之前，供應商始終認為是華為的問題，如果繼續由他們控制整個攻關進程，問題定位結果必然跑偏，因此攻關中要有必要的堅持。最近一次問題攻關在上個月，單板邏輯的兄弟遇到刷表出錯的問題跑來問楊勇，當時由於工作太忙無暇顧及，幫忙出了些點子就放在一邊。過了幾周正在成研出差突然就被呼到一個電話會上，原來這個問題一直沒解決，還愈演愈烈了。第二天和邏輯兄弟走讀了一上午的代碼沒有發現問題，一下進入了死胡同。這一天剛好是週末，實驗室很安靜，完全沒了思路之後決定起來走走，繞著整層樓繞圈，同時在腦子裡將這個問題現象串一遍。兩種類型的單板，C板A片出問題，X板B片出問題，幾乎完全一樣的硬體設計，邏輯設計幾乎完全一樣，差別只是邏輯中狀態機判斷條件C板B片在前，X板A片在前，問題似乎就在這裡，但是代碼上卻看不出問題，會不會是兩塊單板上兩個晶片介面走線的延時差導致出問題？立刻回去查看PCB圖，果然是這樣，兩顆晶片的延時剛好一個是A片長，一個是B片長，至此徹底打開了攻關思路，經過一周的艱苦攻關徹底解決了這個問題。攻關最常遇到的情況是感覺好像所有招使盡了卻難前進半步了，這種時候需要放鬆休息一下，攻關和創作藝術品一樣，需要靈感。平時的工作中由於時間關係，對於很多介面協定/硬體標準等瞭解並不深入，但到了攻關的時候為了解決問題，就必須沉下心來硬啃文檔，所以每次攻關結束，都會發現自己在某些領域又深入了很多，或者是對協定標準，或者是工程領域最新的技術或問題，因此雖然過程很艱辛，但對於攻關還是樂此不疲。 3 單板要是做砸了，以後沒人敢用你生活中楊勇是一個特別仔細小心，甚至有點強迫症的人，一件事件經常會反復確認，在工作中也是如此，對於關鍵問題會反復確認和分析，確保無誤。以前跟海思一個專案經理一起做晶片，對他的評價是：“你別看這個楊勇長得五大三粗的，但心思卻非常細！” 硬體絕大部分的問題攻關過程艱辛，但最終的問題根因往往很簡單，有的甚至很低級，一分鐘犯的錯誤要用千百倍的時間來解決，一個連線錯誤就要導致單板花三個月來重新改板，成本巨大。剛入職路由器時，硬體老前輩給新人說，“優秀的硬體工程師就是要一根飛線都沒有”、“好的單板就是你的品牌，板子要是做砸了，以後是沒人敢用你”。因此從做單板以來一直都謹記前輩的教誨，小心翼翼、戰戰兢兢，用如履薄冰的態度做單板設計，不放過設計中的任何一個細節，有疑問的地方都是多次確認。40Kpin規模單板的原理圖和PCB，一遍一遍，一根線一根線地點著看，查完原理圖查網表，甚至連原理圖設計工具的提示資訊也每條都確認。從楊勇的角度來說，要做一個好的單板其實沒有捷徑，就是每根線都點到，每個器件都看到，每一處設計都分析。當時楊勇所做的單板是路由器規模最大的一塊單板，編譯網表時原理圖設計工具給出的 warning和notes有幾千條，他也堅持每條都點一次確認一下，而且是編譯一次點一次，有時感覺看得都有點想吐了，但仍然堅持看完。工作辛苦細緻一點，風險就可以小一點，萬一這些無效問題中隱藏著一條真正的問題沒被看到，那就意味著單板可能要改板。曾經有 QA問楊勇如何保證單板品質，他就開玩笑說“檢視，檢視，再檢視”。因為看得很仔細，以至於當時原理圖設計工具的一些問題都被找了出來，雖然過程很辛苦，但是單板成功了就是對這些辛苦最大的獎勵，這塊單板是路由器當時最複雜的單板，如今成了路由器發貨時間最長，賺錢最多單板之一，前年才終止發貨。楊勇覺得，硬體工程師對待每一塊經自己手設計的單板，都要當藝術品一樣，設計規範整齊，精益求精。好的單板設計看起來應該給人一種很舒服的感覺，連線整齊，命名規範，標示詳細，看一眼網標名稱就知道這個信號是什麼，從哪來到哪去，方便檢視還不容易出錯，原理圖中詳細標注設計細節，這樣檢視原理圖就不用再去翻詳細設計報告和資料手冊。這麼多年來，但凡經楊勇手的單板從沒出過問題。他覺得也許強迫症是硬體工程師的必備素質之一。 -- 推 obov: 有人賣腦有人賣肝有人天天給人家幹

→

obov

-- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.210.181 ※ 文章網址: https://www.ptt.cc/bbs/Engineer/M.1531042144.A.35D.html

→

l75cm

07/09 01:31, 5年前 , 1^F

07/09 01:31, 1^F

推

pxycho

07/09 08:32, 5年前 , 2^F

07/09 08:32, 2^F

推