調板子debug的能力。
FPGA工程師大致分兩類：FPGA作為產品的工程師和IC原型驗證工程師
先說前者，不管是RTL design還是做simulation的、上板測試的都算FPGA工程師，並且往往一個工程師者隨著計畫進度會從頭做到尾，計畫的輸出就是FPGA bitfile作為產品的一部份正常工作，所以導向就是最終上板的結果。從計畫時間來看，前面coding和simulation占據一部份時間，很多程式碼還是復用之前計畫的，而debug就分單獨模組驗證、整塊FPGA驗證、軟硬體跨部門驗證、整體系統驗證等，偵錯占用的比重越來越大。
而FPGA的特點決定了偵錯不太容易，相比simulation來說困難多了，出現一個issue先定位是軟體的問題、硬體的問題，還是FPGA的問題？如果是FPGA的問題，容易復現不？如何判斷是哪一部份模組的問題？大致的問題在哪裏？如何設定debug點，使用identify/chipscope/邏輯分析儀去抓？出一個版本往往按小時算，一次設定trigger訊號可能還找不到想找的點，需要多次去抓訊號和出版本。這過程中，沒經驗的工程師是趕急趕忙地去出偵錯版本，或不知從何下手，忙很久卻勞而無功； 有經驗的先分析推測問題可能出現的地方，分步驟去驗證問題的原因，能較快地定位在issue所在。這就是核心競爭力！ 當然要做到這步需要很多的積累，比如對產品架構有整體了解，對具體模組、FPGA技能很熟悉，對常見協定如AMBA、DDR有一定經驗，要不然你又不是跳大神靠掐指一算就算出問題所在了。
IC原型驗證工程師，如另一答案所說，有的公司就是工程師兼一下把活幹了就行，有的則是正規的team專門做原型驗證，尤其是涉及到多塊大容量FPGA分割方案的。這裏FPGA與simulation相比優點就是在真實的物理環境中執行、執行速度快、能run大量的case進行回歸測試，缺點也很明顯，介入時間晚，移植到FPGA平台花的時間很長、需要處理大量的硬體相關問題如時鐘外圍器件管腳連線、debug困難等。隨著芯片規模擴大，二者各自的優缺點越來越明顯，越來越多公司開始使用Emulator，Emulator更偏向simulator的硬體化，離simulator更近，離FPGA遠多了（本人現在emulator AE）。
同樣，做原型驗證的工程師有什麽核心價值？別人搞不定的問題你能搞定，這就是價值所在，比如需要實際接硬體作為激勵源發某個特殊case才能復現的issue，重要性還很高，simulation搞不定，你在FPGA上搞定了，誰敢小瞧你？要是僅僅跑個流程，能用就行，隨便找個人都能玩通的活，公司又不是傻子給你那麽多錢幹啥？
綜上，你的薪資是公司付給你不可替代性的成本，你越不可替代，你的價碼越高，如果太低你會跳槽走人，太高公司也會找機會把你換掉。這其中有普遍性分工的因素（比如普遍性而言design給的錢比原型要高些），也有具體個人的因素（你牛就該拿高價），不宜過分強調哪個極端。
---------------------------------------------
如何提高debug的能力？來個可執行性高的方法：給上司和相關人員發信件匯報工作，整理思路並記錄過程，同時展示你的工作成果。
比如在系統聯調中出了個bug，先給上司口頭匯報下這個情況，然後去定位，到一個階段或下班前發信件，先描述下環境配置和現象，讓別人知道是怎麽回事（有些人開頭就說具體現象，聽的人不知所雲），然後你定位到這個現象發生了，稍微描寫下發生的問題；
接下來分析可能性，出現這個問題可能的原因，怎樣去確認是哪個環節發生的事情，並且你因此做了哪些操作去確認來進一步縮小範圍；
如果是哪個小範圍的問題，可以做哪些操作去進一步確認問題，比如打印中間變量結果、出測試版本加chipscope訊號去抓取數據、bypass某些旁路等；如果一次性沒找到問題的根源，那之前的操作排除了哪些可能，接下來還有哪些操作可以去做去確認，需要做的工作和工作量、時間評估、需要的資源支持評估等；
如果透過debug找到了issue所在，分析下產生的原因在哪裏，是低階錯誤、test case沒覆蓋掉、健壯性不夠、軟硬體配合、還是架構上有問題？如果是簡單地修改該怎麽做，要多少工作量，影響有多少？如果是完全解決這個issue，涉及的範圍有多廣，收益和風險在哪裏，該不該做？提出建議，讓上司等決定。
如果問題一直找不到，那可以采用什麽樣的手段規避掉，收益和風險又在哪裏？
如果問題不復現了，可能產生的風險有多大？需要記錄下來，下一次可能又會出現。
如果把一次次的信件內容同時整理下來，放在word文件裏，適當編輯下格式，加上日期、環境配置等資訊加在信件附件裏，更往上點，有專門的issue track平台在上面記錄，那就更好了。
