嵌入式軟體工程師該不該看ASIC工程師寫的代碼（硬體描述語言如verilog）？

01-14

在晶元公司寫軟體的軟體工程師該不該看做晶元的數字ASIC工程師寫的硬體描述語言的代碼。為什麼提問？因為我發現硬體和軟體之間交流的介面就是各種晶元寄存器，但往往寄存器的用法都是通過文檔形式記錄，這其實對雙方都帶來了不少的重複勞動。一方面硬體工程師做完設計寫完代碼後，還要花時間把寄存器的用法寫成文檔，如果項目很忙，往往壓縮的就是類似寫文檔的時間，畢竟文檔這個東西，寫得不好的話還不如不寫。另一方面因為軟體工程師對硬體寄存器用法的理解也是基於文檔，而文檔本身的不精確性，反倒經常給軟體工程師造成困惑，於是只好通過直接向硬體工程師面對面的求助，而硬體工程師對具體應用業務沒有軟體工程師了解得清楚，所以也經常不理解軟體工程師的具體需求，很多時間都被浪費在這種低效溝通上了。這讓我想起windows上的系統軟體開發之所以大家覺得比Linux上困難的原因就是，在windows上軟體工程師沒法打開黑盒子，而只好通過msdn或者codeproject或者博客等來「猜測」黑盒子里到底是什麼？如果是linux平台，那麼直接看源代碼，雖然也要花不少時間，但至少能得到一個精確的結果。所以，不知道有沒有晶元公司是採取讓軟體工程師直接看硬體代碼的辦法來解決這個問題的？

這是一個非常好的問題。確實工作中就有這樣的問題存在，前端設計人員除了寫代碼，還必須維護寄存器文檔，有時候還得給模塊的說明書文檔。文檔的維護對他們來講是一件很痛苦的事情，尤其是寄存器非常多的時候。很多寄存器總有種說都說不清的感覺，更不要說有些function需要好多個寄存器配合起來才行，在文檔中都很難體現。所以軟體那邊就得經常過來問，某個寄存器到底怎麼用，某個事情到底是什麼flow，這個問題其實一直沒什麼特別好的解法。只要IC設計者還要維護文檔就解決不了。

其實我認為理想的設計系統是不需要文檔的，因為文檔大多有歧義，而且不夠精確，有時還有錯誤。designer的代碼就已經包含了足夠精確的信息，文檔絕對屬於重複建設，一件事情要干兩遍就很可能不一致，代碼更新了文檔沒更新是常事，文檔與代碼不一致更是多得去了。但是代碼往往又過於細緻，軟體組的人短時間根本看不懂，這又是一個難題。再說他們本來也沒有這個義務。

所以我們需要一個足夠抽象，但是又相對精確的東西來描述硬體，需要高層次的建模語言，比如system C。代碼永遠是沒有歧義的，也是最好的說明書。如果能夠把5萬行的RTL代碼，用5千行的行為級語言描述出來那自然很好，軟體組的人就可以只看5千行代碼，不需要知道太多的細節，但是對寄存器的用法一清二楚。

問題又來了，5千行的行為級代碼自然可以寫，問題是先寫行為級的邏輯，再將其翻譯成RTL邏輯，同樣是重複建設。目前也沒有足夠高效可靠的工具自動將行為級邏輯轉換為RTL邏輯，所以維護兩份代碼可能更不可取，還不如維護文檔。

所以，沒有辦法，目前的通常情形仍然是通過文檔來傳遞介面信息，這個問題也解決不了。軟體組的人有時候不得不看硬體代碼，甚至有時候還得看模擬波形。尤其是軟硬體聯合模擬的時候，軟體組的人至少要看看波形，知道軟體執行了哪些步驟，死在哪個地方。

其實我覺得最終的IC設計，是沒有軟體組和硬體組的劃分的，應該只有行為級的設計者。只有一套代碼，包含所有要設計的行為，並且有足夠的指示哪些是硬體實現，哪些是軟體實現。剩下的，都是機器來做。目前的IC領域，設計能力還是太低下了。

//------------在 @Arthur Wang的評論下有人問道為什麼verilog代碼難以看懂，本人因為友善度較低無法評論，我就在這裡回答一下//

verilog代碼天生是一種很難看懂的代碼。5萬行C或許很容易看懂，但是5萬行verilog就很難看懂。之所以難是因為：

（1）verilog的並行特性，你不知道你看當前這段代碼的時候，其他代碼在執行啥，走到了哪一步，會觸發什麼事件，會比你當前看的東西早觸發還是晚觸發，會對你有什麼影響。你也很難看出一個信號是單脈衝還是多周期的，但是這些都很關鍵。但是軟體代碼一個周期只發生一件事，追蹤容易多了。

（2）硬體結構裡面大量的環路握手，看著非常容易暈，轉圈圈的結構極多。任何兩個模塊之間也肯定有握手，代碼trace著就回去了，像個迷宮。

（3）輸入輸出List極多，邏輯複雜性高。一個module幾時上百個輸入輸出那是常事，你有見過軟體代碼裡面的函數帶幾百個參數的嗎？

（4）有些湊出來的邏輯極其難以理解。硬體裡面有時候為了構造一個處於某個時間區間的信號，會拿一些邏輯不太相關的信號來湊出來，如果不對著波形看根本理解不了，這些timing上的技巧屬於非功能性的，也加大了對代碼的理解難度。

不知道你們公司的開發流程是怎麼樣的。在我們公司的標準流程里，寄存器列表和說明是比代碼先寫完的，文檔評審完成後代碼才可以開始動手。所以你的問題是什麼？

不應該，

IC設計工程師寫好文檔和寄存器描述是其工作責任，寄存器描述以及文檔也是被證明的合適的軟硬溝通的介面。從硬體到操作寄存器來實現某些功能，這個是屏蔽許多沒必要了解的細節的，對於上層工程師更為高效。

在沒有寄存器描述和文檔的情況下，ic設計工程師看別人的代碼都是一件有工作量的事情，更別說是軟體或者嵌入式工程師來看代碼了。

//==================================//

補充一下

1 系統級別的問題往往不是看局部代碼能夠明白的。比如一顆視頻處理晶元的開流，上電reset後，strap pin 狀態，analog 器件是否需要calibration，模塊時鐘頻率配置，gating順序，模塊打開順序，輸出管腳狀態，這些都不是從代碼中能夠看的出的。只能通過設計人員給的SW UG來確定。

2 模塊級，哪些寄存器是硬體清的，那些寄存器的更新是用硬體信號鎖的，哪些信號的低位配置需要寫高位才生效的，哪些地址是shadow 的，哪些寄存器是debug的，文檔寫的好，一目了然，看代碼比較麻煩，有嚴格coding style的還能猜猜，改的一塌糊塗的那就呵呵了。

3 另外，文檔是大家來review的，是一種自然語言，可以方便leader manger等不會太了解細節的人介入，雖然是一種冗餘，但對於項目流程而言是一種約束，也方便大家分工職責明確。

4 驗證要看代碼的，他和designer都是要從RTL邏輯層次上面保證function 正確的。

這個取決於你的想發展成什麼樣的工程師，很多事情沒有絕對的應該不應該。

如果你想混混日子，那就沒必要看。因為你是軟體工程師嘛

如果想發展的好一點，實際上是應該的。體現在幾點：

1 不同的寄存器配置可以實現同樣的功能，在後面是不同的電路做支持，如果你看懂了電路你可以寫出來高效的代碼。這裡看懂不是說每個verilog文件看一遍，是大概有個概念，怎麼怎麼回事

2 如果你沒看過電路，可能無法對硬體的開發提出意見。一般開發新ip，會招來ic，架構，軟體來一起商量介面。你隨便說什麼都要，人家一口回絕說達不到，或者說面積太大，就否定了你的想法。然後你在做driver的時候就很抑鬱。而且太不專業，ic的人不願意跟你說太多。要是大家都是技術人，互相探討一下，ic的人會願意多跟你說些事情，你的工作就好做很多。

3 經常上了os有bug，你說是軟體bug還是硬體bug吧，往往的情況是軟體bug多。但是如果你大概知道點硬體是怎麼工作的，有些可能是硬體bug你可以讓硬體的人幫你看，不是對你也有好處。

4 硬體可能是非常不給力，比如剛剛來個了新人接手，還不是很熟悉，這種情況軟體難道還罷工了？本來ic開發就是互相幫助的事情，沒有說哪個事情一定是哪邊做的。

5 理解了硬體才能更好的做軟體呀，比如做os的人難道cpu怎麼工作不應該了解下？做gpu的人，graphic pipeline就是硬體的工作pipeline啊，會graphic pipeline應該是學computer graphic的人的基本功了吧。

某些大神只要有許可權就是擋不住的，以前公司有人從軟體bug一直看到verilog里賦值阻塞非阻塞寫錯了

其實verilog也不難，花兩個月就能學會，學會就再也不會被狀態寄存器，通用寄存器，標誌寄存器，一級緩存，二級緩存，三級緩存支配了，而且操作系統源碼也能很清楚的明白

看了就不再被動了。

有時間的話，想學就學，有些道理是相通的。

學過嵌入式，FPGA，VHDL等，工作後沒直接用到，算是對思維的訓練。

建議看看，最好能夠理解。這樣整體上溝通效率也會提升一些。

我覺得沒啥，我們項目組的軟體工程師看verilog，看信號眼圖，原理圖pcb，量時序，分析通信協議很正常。我覺得底層軟體工程師本來也可以做硬體工程師的，只不過寫代碼更擅長而已。如果不了解底層硬體通信，怎麼能保證底層c代碼的正確性？

從晶元設計轉行到嵌入式軟體。。。默默看你們怎麼說