本文轉自：http://kellen.wang/zh/the-knowledge-base-of-a-qualified-ic-design-engineer/

剛畢業的時候，我年少輕狂，以為自己已經可以獨當一面，廟堂之上所學已經足以應付業界需要。然而在後來的工作過程中，我認識了很多牛人，也從他們身上學到了很多，從中總結了一個IC設計工程師需要具備的知識架構，想跟大家分享一下。

I. 技能清單

作為一個真正合格的數字IC設計工程師，你永遠都需要去不斷學習更加先進的知識和技術。因此，這裡列出來的技能永遠都不會是完整的。我儘量每年都對這個列表進行一次更新。如果你覺得這個清單不全面，可以在本文下留言，我會盡可能把它補充完整。

• 語言類
  • Verilog-2001/ VHDL
  • SystemVerilog/ SystemC
  • Makefile/ Perl/ Python/ Shell
  • Tcl
• 工具類
  • NCVerilog/ VCS/ ModelSim
  • SimVision/ DVE/ Verdi
  • Vim/ Emacs
  • SVN/ CVS/ Git
  • Microsoft Office
• 平臺類
  • Windows
  • Linux
  • OS X
• 其他加分專案
  • MATLAB
  • ISE/ Synplify/ Vivado/ Quartus
  • LEC/Formality
  • VMM/ UVM
  • ESL
  • ZeBu Server
  • JIRA/ Confluence
  • C/ Assembly Language
  • Computer Architecture/ ARM Architecture/ MIPS Architecture

II. 為什麼 & 怎麼辦

A) Verilog-2001/ VHDL

這裡之所以強調Verilog-2001而不是Verilog-1995，是因為在Verilog-2001中規定了很多新特性，因此可以產生更好的程式碼風格。我曾經在

學習Verilog最大的問題就是，很多國內的書寫得都很不好，書中的很多例子都是為了說明語法特徵而存在的，沒有任何實用價值，甚至很多程式碼都是錯誤的（這裡錯誤的意思並不是說他語法錯誤，而是說他是不可綜合的，無法用數位電路來對等實現的）。所以，對於學習Verilog，我的建議是，隨便找一本類似語法手冊的書籍，匆匆把基本語法看過一遍，搞清楚模組定義，介面定義，模組例化，暫存器定義，線定義，always塊怎麼寫這些基本內容後，就開始到OpenCores網站上去下載已經經過FPGA驗證的完整開源專案程式碼進行學習。先做到看懂別人寫的程式碼，然後再嘗試自己去模仿，有不懂的問題再有針對性地去網上搜索答案。

Verilog語言與軟體語言最大的區別就是，因為它是用於描述電路的，因此它的寫法是非常固定的，因為電路的變化是非常有限的。學習Verilog的時候，很多時候我們並不是在學習這門語言本身，而是學習其對應的電路特徵，以及如何對這個電路進行描述。如果心中沒有電路，那麼你是不可能寫好Verilog的。從基礎開始，一點點積累類似計時器，譯碼器這樣的小型電路描述方法是非常重要的。Verilog鼓勵在電路中進行創新，而不是在描述方法上進行創新。因此，即使是世界上最牛的Verilog高手，他寫出來的Verilog程式碼語法也都是很普通的，而他的創意則在於如何去組合這些基本的小型電路。

舉個不太恰當的例子，每個醫生都會給你開藥打針檢查身體，但是高明的醫生並不在於他用了多高難度的動作去給你扎針，或者給你開出什麼奇奇怪怪的藥吃，而是他如何快速準確的診斷出你的病情，用最合適的扎針吃藥組合去治療你。Verilog也是同樣，要學會用最規矩保守的語法，寫出執行速度最高效能最穩定的電路，而不是在語法上瞎費工夫。凡是你沒見到別人寫過的語法，都很可能是錯誤的。

VHDL雖然我並不是太瞭解，但是目前在歐洲很多國家，VHDL還是主流的RTL設計語言。VHDL語言的嚴謹性比Verilog要好，不像Verilog中一樣存在大量符合語法卻永遠無法綜合的語句，容易對新人造成誤導（模擬通過的程式碼卻在FPGA綜合時報錯，或者FPGA實現結果與模擬不一致）。而VHDL和Verilog雖然可以相互轉化，但是轉化過程中仍然存在很多問題，無法做到完全的自動化。關於這一點我之前寫過一篇專題進行探討：如何將VHDL轉化為Verilog。有興趣的同學可以去看看。

B) SystemVerilog/ SystemC

這兩種語言都是為了驗證而存在的。作為IC設計工程師，驗證知識不是必須的，但是掌握基本的驗證方法學有助於提高自己的debug效率和結果。我曾經在如何快速搭建模組驗證平臺一文中詳細介紹過一種我自己總結的驗證方法，這種方法就是基於SystemVerilog語法實現的。由於SystemVerilog對Verilog完全相容，就像C++對C語言的相容一樣，所以SystemVerilog（或SV）學起來其實並不算難。

SystemVerilog是一種面向物件的語言，其設計的本意是用於搭建驗證平臺，主流的VMM/UVM方法也都是基於SystemVerilog實現的，所以立志成為IC驗證工程師的同學，SystemVerilog的深入學習和流行方法論的學習都是必不可少的。

而對於那些只想做IC設計的同學而言，SystemVerilog同樣也是值得學習的。且不說本文前面提到的用於提高驗證效率的debug方法，即使只是為了做好設計，SystemVerilog也是大有用武之地。在歐美很多發達國家，很多世界頂級的IC設計公司內部都已經開始使用SystemVerilog進行RTL設計了。由於在SystemVerilog中加入了很多類似always_ff、always_comb等用於顯式表明綜合電路意圖的新語法，程式碼的可讀性更高，綜合過程中也減少了歧義，儘可能地保證了綜合結果與設計意圖的一致性。從另一個角度來說，assertion的加入也極大地提高了程式碼的debug效率，非常有助於在大規模的資料互動過程中定位到出錯的初始點，沒有掌握的同學可以多花一些時間研究一下。

C) Makefile/ Perl/ Python/ Shell

以上四種都是IC設計工程師們常用的指令碼語言，看起來似乎它們都跟IC設計的專業能力沒有絲毫關係，但是由於本行業的專業工具價格非常昂貴，專案需求差異極大，因此掌握一門得心應手的指令碼語言將對你工作效率的提升幫助極大。如果你還沒有嘗試過編寫自己的指令碼語言，那麼問問你自己，有沒有曾經為了完成一批模擬用例熬到深夜？有沒有曾經因為要比對幾萬個資料搞到眼瞎？有沒有曾經因為要修改一個全域性訊號的位元位寬而無比抓狂？要把一個hex型別資料檔案轉換為memory模型需要的特殊格式怎麼辦？沒錯，如果你掌握了指令碼語言，以上這些奇奇怪怪的需求都不是事兒，重複而細緻的體力勞動就交給計算機來完成吧。我一向信奉的口號就是：但凡做過一次的事情，就沒有必要重複第二次。

如果你已經在工作中使用過其它工程師開發的平臺或者指令碼，那麼它很可能是用這4種語言寫成的。如果執行指令碼的方式是make run，那麼很可能你用到的是一個Makefile指令碼；如果執行方式是source run，那麼這應該是一個Shell語言寫成的指令碼；如果是其它情況，那麼就得看具體這個指令碼首行是怎麼寫的了。Makefile和Shell語言比Perl/Python要更容易上手，寫起來也更加簡單，比較適合滿足一些非常簡單的批量任務需求。Perl的強項則在於它強大的文字處理能力和無所不能的CPAN庫，隨時可以滿足你的各種任性需求。Python的優點則是較好的可維護性。

關於指令碼語言的重要性，大家可以到這裡看看相關討論：Perl等指令碼語言在IC設計中有哪些用處？。

D) Tcl

嚴格來說，Tcl是一門非常單純而簡單的語言，而它的學習難點在於，只是掌握它的語法是遠遠不夠的。這種情況有點類似javascript，如果你用js來開發網頁，那麼你必須深入瞭解DOM和HTML；如果你用js來開發遊戲，那麼你必須深入瞭解Unity3D引擎的各種知識；如果你用js來開發Web App，那麼你必須會用node.js的各種庫和常見的服務端框架。

語言永遠只是工具，這句話放在Tcl上再合適不過了。在IC設計這個領域中，Tcl是一門非常常見的語言。他可以用於描述時序和管腳約束檔案，UPF資訊，也可以用來搭建簡單的工作平臺。它既是很多IC領域EDA工具預設支援的指令碼語言，也是這些工具配置和輸出的檔案格式。因此，能夠讀懂Tcl，掌握Tcl語言的基本語法，就可以幫助你更好的使用EDA工具，真可謂是Tcl在手，天下我有！

但是，成也蕭何敗蕭何，正如前文一開始提到的，僅僅掌握了Tcl的語法還遠遠不是全部。不同的EDA工具對Tcl指令碼提供的命令和引數支援都是不一樣的，每當你需要為一種新工具編寫Tcl指令碼時，都必須要熟讀官方給出的使用者手冊，瞭解這種工具支援的Tcl命令結構，才能確保寫出的指令碼是可以被正確執行的。

E) NCVerilog/ VCS/ ModelSim/ iVerilog

以上三種都是比較業界比較主流的模擬工具，其中NCVerilog和VCS都只支援Linux平臺，而ModelSim貌似是同時支援Linux平臺和Windows平臺的。但是不管哪一種，我都希望大家能意識到兩件事：第一，模擬器和波形檢視器是兩回事，本條目介紹的只是模擬器，模擬器的工作原理跟波形檢視器是有天差地別的，同時由於IEEE對標準波形檔案*.vcd格式的規範，任意模擬器都是可以和任意波形檢視器組合使用的。第二，模擬器通常是沒有圖形介面的，為了更好地使用模擬器，你要熟讀自己常用模擬器的使用者手冊，瞭解一些常見需求的命令列引數，至少要做到了解如下內容：如何指定編譯的檔案型別，如何指定編譯檔案清單，如何指定索引目錄，如何指定模擬精度，如何指定臨時的巨集變數，如何指定語法檢查的嚴苛等級，如何混合編譯由多種語言寫成的工程，如何呼叫不同波形生成工具的pli介面，如何配合SDF反標進行後仿等等。

不同模擬器的功能其實都大同小異，但是是不是隻掌握一種模擬器就可以打遍天下無敵手了呢？當然不是。在實際的工程中，我們經常用到第三方IP核，有時候出於保密的需要，第三方IP核會以加密二進位制檔案的方式提供，加密二進位制檔案長啥樣呢？它們一般以“*.vp”格式命名，檔案的開頭部分就是標準的Verilog語法，但是在一行註釋之後就全部變成了亂碼。通常亂碼之前的那行註釋會指定該加密二進位制檔案支援的模擬器型別。所以你看，如果你是一個重度VCS使用者，而有一天專案經理突然塞給你一個只支援NCVerilog的加密檔案，你內心一定會有千萬只草泥馬呼嘯而過。

如果你是一個開源工具的死忠粉，那麼你可以考慮使用Icarus Verilog (iVerilog)進行模擬編譯。iVerilog編譯器和其自帶的vpp模擬器是基於C++開發的，支援Verilog全系列的IEEE標準，但遺憾的是，iVerilog目前對System Verilog的支援還相當有限。iVerilog是跨平臺的，無論你喜歡用Windows, Linux還是OS X, iVerilog都提供了非常便捷的安裝方式。

F) SimVision/ DVE/ Verdi/ ModelSim/ gtkWave

與上面的模擬器相對應，以上三種也是業界比較主流的波形檢視工具。所有的波形檢視器都必須支援標準波形檔案*.vcd格式，但是由於*.vcd格式的儲存效能並不好，冗餘資訊過多，所以各家波形檢視工具都紛紛推出了自己獨家支援的波形檔案格式，如DVE的*.vpd，Verdi的*.fsdb，ModelSim的*.wlf, SimVision的*.shm等。通常波形檢視工具獨家支援的檔案格式都具有較高的壓縮率，舉例來說的話，通常1G左右的*.vcd格式波形轉換為*.vpd格式後只有40MB左右，而轉換為*.fsdb後通常會更小，因此將標準波形檔案*.vcd轉換為其他壓縮格式更加有利於資料備份。

如果希望在模擬過程中不生產*.vcd，而是直接生成壓縮率更高的其他波形檢視器專用格式，則需要呼叫對應工具提供的pli介面，同時配合測試平臺程式碼中的系統函式呼叫（如$fsdbDumpOn等）來完成。

說了這麼多，不要以為*.vcd格式就一無是處了，再怎麼說這也是IEEE規定的標準格式，其他不同壓縮格式的波形檔案之間如果需要相互轉換，一般都是要先轉換為*.vcd後再轉到目標壓縮格式去的。另外，在晶片的量產標準化測試環節中，一般規定採用的激勵檔案格式也必須是*.vcd，所以不管你平時習慣使用什麼波形檔案格式，*.vcd的產生方法都是必須要熟練掌握的。

對不起，上一段最後一句是錯的，近期負責量產方面的事情，對這一塊終於加深了了解，實際量產測試環節中ATE環境目前主要使用的激勵檔案格式主要有兩種，分別是*.wgl和*.stil。這兩種檔案格式與*.vcd及*.fsdb等是有本質不同的。*.wgl和*.stil格式是基於週期數和電平向量的波形檔案，而*.vcd和*.fsdb是基於時間和變化的。換句話說，在*.wgl和*.stil裡，你會看到類似“0101010100”這樣的訊號描述，他完整記載了所有訊號隨時鐘週期數（而非時間刻度）的變化過程，如果你以10MHz的時鐘頻率來播放這個波形，那麼他產生的訊號長度就是10個100ns，如果你以100MHz來播放則長度為10個10ns，這就是基於週期數記錄波形的含義。同時，在*.wgl和*.stil波形裡，訊號是以向量的形式完整記錄的，假如波形裡有2個訊號，“11”，“10”，“00”這三個向量就表示第一個訊號在連續的三個週期裡分別是“高高低”，而第二個訊號則是“高低低”，這就是基於週期數和電平向量的完整含義。與此相對的，在類似*.vcd這樣的波形檔案裡，經常可以看到#1000 1signal這樣的表述（此處的signal通常會用類似#這樣的字元代表它的id號），它表示過了1000ns後signal變成了高電平。由此可見，*.vcd檔案本質上是通過記錄時間增量和訊號的變化沿來表示波形的。

那麼問題來了，平時我們的模擬結果都是基於時間的類*.vcd格式，如果量產測試的激勵必須是基於週期數的類*.wgl格式，要怎麼辦呢？目前市面上有一些可以將*.vcd轉換為*.wgl格式的軟體工具，但是授權收費不菲，建議有可能的話，設計人員最好在設計測試激勵時就考慮到這一點，通過指令碼或者其它方式直接生成*.wgl檔案進行交付，如果只能提供*.vcd格式，請確保激勵波形可以按統一的固定週期長度進行切割轉換，否則在進行波形格式轉換過程中可能會存在大量反覆工作和溝通問題。

同樣的，如果你希望使用開源的波形檢視器的話，gtkWave將是你的不二選擇。和iVerilog類似，gtkWave也是跨平臺的，而且簡單易用，支援*.vcd標準格式，同時獨家支援高效能壓縮格式*.lxt和*.fst（gtkWave自帶vcd轉fst的轉換器，只需在執行過程中加入引數呼叫即可）。

G) Vim/ Emacs

經常看到一些Verilog新人提出這樣一個讓人啼笑皆非的問題：“請問一般Verilog程式設計用什麼樣的軟體？

首先，Verilog是一種電路描述語言，它本質上可能跟電路圖的血緣還更近一些，至少不應該把這個描述過程說成是“程式設計”。其次，寫Verilog其實並沒有什麼專門的軟體，大部分業界的工程師都是用Vim或Emacs這樣原始粗獷的文字編輯器來寫Verilog程式碼的，如果你願意的話用Notepad或Texteditor來寫也未嘗不可，只是如果你有深入瞭解過Vim或Emacs的話，自然就會明白這麼多人選擇它們的原因所在——提高效率。

你去問Vim或Emacs的使用者，為什麼說這玩意能提高效率，多半對方回你的第一句就是：因為可以丟掉滑鼠啊。顯然這樣一個結論並不能讓人信服，而實際上這也只是它們眾多優點中的一個而已。那麼究竟為什麼可以提高程式設計效率呢？核心原因當然是，因為藉助它們，你可以用程式設計的方式來程式設計！聽起來優點拗口對不對，沒關係，請聽我解釋。

舉個例子：如果你設計的模組需要對外輸出100個暫存器，每個暫存器的位寬等於他的編號，如果使用普通的文字編輯器，你需要手工寫下output reg reg_0到output reg[99:0] reg_99這100行程式碼，即使用上覆制貼上，你也需要逐行手工修改每行程式碼裡的訊號位寬和編號。但是，如果藉助Vim編輯器的命令功能的話，你只需要寫下for ($i=0;$i<100;$i++) { print("output reg[$i:0] reg_$i\n");}，然後在同一行按shift+v，輸入:!perl回車，然後就你能看到前面輸入的那些程式碼被替換成了你本來想輸入的100行內容。 以上是一個稍微複雜的例子，可能大家平時不一定會遇到這種需求，但是以下情況呢？ > 你是否曾經忘記在每行程式碼末尾加上”,”或”;”符號，編譯失敗後才發現需要逐行補上？如果使用Vim編輯器的話，只需要用shift+v選中需要修改的行，按下:’<,'>s%$%;%g就可以了，熟練之後整個過程不超過5秒鐘。
> 你是否曾經在程式碼寫完之後被老大臭罵一頓原因是你沒有把所有的reg和wire定義都放到檔案的統一位置（如第38行）？如果使用Vim編輯器的話，只需要使用:g%^\s*reg\s*%m 38加上:g%^\s*wire\s*%m 38就可以了。
> 你是否曾經被要求刪除某個檔案中所有的註釋？只需要:%s%//.*$%%g就可以了。
> 你是否曾經需要把一個模組例化256次，然後因為每次例化的一點微小不同導致你不能直接使用for迴圈？沒關係，用qq錄影功能，你只需要操作一次，然後使用[email protected]就可以把你的動作自動重複256次啦。
> 你是否曾經遇到鍵盤壞掉了，“a”鍵經常失靈甚至沒有反應？沒關係，用:inoremap ‘ a把‘鍵重新對映為a鍵吧。

類似的例子簡直數都數不完，更多內容參見與Verilog有關的Vim實用技巧。

所以說，使用Vim或Emacs最大的好處就是，你會感覺到你的大腦比手更忙，因為從你想清楚到程式碼寫好只需要花費極短的時間。你可以把全部精力投入到程式碼的內容上，而不是程式碼輸入這個機械的過程中，就好像用打字機代替毛筆的感覺一樣。只要是你能用程式設計描述清楚的事情，Vim就可以代替你快速完成，而前提就是你要先學會大量的Vim命令和正則表示式，以保證你的表述能被編輯器正確理解。

G) SVN/ CVS/ Git

以上三種都是目前比較主流的“版本管理”工具。什麼是版本管理？簡而言之，就是一種用於記錄和查詢檔案版本改動的工具，通常都會被部署在公共伺服器上，以保證資料的安全和可恢復。在專案的開始階段，首先需要建立好版本管理的根目錄，然後由不同的工程師逐一把自己的設計檔案首次加入到版本管理的各級子目錄下。在專案執行的過程中，每當有人修改一個檔案，都需要通過版本管理工具上傳程式碼並註釋改動內容，版本管理工具會自動檢查改動內容與伺服器上的最新版本是否衝突（衝突的意思即是說，在該工程師改動這個檔案的過程中，有其它人也對該檔案的同一行程式碼進行了改動並上傳了新版本），如果沒有衝突，則會自動將新上傳的改動合併到當前最新版本，反之，則將衝突部分進行對比顯示，讓工程師手工判斷應當如何合併衝突行的內容，解決衝突後可以再次重新上傳。

SVN和Git都是跨平臺的版本管理工具，其中SVN是必須線上工作的，而Git是可以離線工作的。當你需要上傳程式碼的時候，如果你使用的是SVN，則你必須保證從你的計算機到伺服器端的通訊是暢通的，而如果你使用的是Git的話，由於Git有本機倉庫的概念，在你沒有主動與伺服器端同步之前，所有版本管理都是在本機倉庫上完成而不需要與伺服器通訊的，這樣即使是在離線環境下也可以最大限度地保證程式碼版本的可恢復性，同時也節省了在移動環境下工作時的傳輸流量。Git是開源的，最早興起於網際網路行業，目前也有逐漸在其他行業裡廣泛使用的趨勢，以之為基礎的開源社群GitHub更是為它的繁榮起到了重要的推動作用。

CVS是一款比較老的版本管理工具，只能在Linux平臺下執行，不支援目錄的遞迴新增和重新命名，用起來略有些麻煩，不過因為目前還有很多公司在用，所以這裡也順帶介紹一下，並不推薦。CVS和SVN的最大區別還是版本號的命名思想，在SVN中，任何一個檔案的修改都會導致整個工程版本號的更新，而在CVS中，版本號是跟隨檔案的。因此，在系統的某個時刻，SVN工程中所有檔案的版本號都是相同的，而CVS工程下的每個檔案都有一個自己的版本號。CVS的這種版本號設定會給工程管理帶來很多麻煩，主要是如果有一天你想把整個工程恢復到之前的某個狀態的話，要麼是你曾經記錄下了當時所有檔案各自對應的版本號，要麼是你記下了當時的準確時間，要麼是你當時給所有的檔案打上了標籤，否則幾乎是不可能的。而對SVN來說，你只需要記住當時整個工程的版本號即可。

H) ISE/ Synplify/ Vivado/ Quartus

ISE和Vivado都是Xilinx旗下的FPGA工具，其中ISE比較老，官方已經停止更新了，目前最新的版本是14.7，而Vivado作為新一代的FPGA工具一直在繼續更新。Quartus則是Altera旗下的FPGA工具，功能和ISE/ Vivado大同小異。筆者平日裡對FPGA工具的接觸並不多，但從有限的接觸體會而言，Quartus比ISE/ Vivado更適合用於學習，入門的門檻更低一些，操作介面也更加簡單易學（但千萬不要使用6.2版本以下Quartus中自帶的波形模擬工具，那是垃圾）。

學習FPGA有助於幫助大家理解“正確的設計 != 正確的RTL”，而是“正確的設計 == 正確的RTL + 正確的時序約束”這一重要理念（很多同學一直無法從軟體程式設計的思維中跳出來，也是因為一直沒能理解好這個理念）。正確的時序約束通常包括管腳約束和時鐘約束，任何一項約束出錯都會導致綜合出來的電路無法按照預設的頻率和時序進行工作。Quartus支援的約束檔案格式是*.sdc。ISE和Vivado支援的約束檔案格式有所不同，ISE支援的是*.ucf，Vivado支援的是*.xdc，但由於Xilinx家的工具中內建了約束檔案互相轉換的指令碼，因此只需一個命令就可以在兩個軟體的工程之間無縫切換。從時序約束的思想上來說，Quartus與ISE/ Vivado在很多細節上都有所不同，所以從一個平臺遷移到另一個平臺的過程中依然會有一個學習過程，例如說：Quartus在時鐘定義上不太區分管腳輸入時鐘和內部時鐘，但在ISE中則不允許使用管腳輸入時鐘直接驅動暫存器，而是必須首先經過BUFG/ PLL/ DCM等時鐘IP處理後輸出方可以使用。Quartus對於輸入輸出的同步資料訊號偏移offset in/out和ISE的定義也正好相反，使用過程中需要尤其注意。最後一句話送給FPGA新手們，千萬記住，如果你在設計FPGA工程的時候沒有新增任何時序約束或時鐘約束，請不要問我為什麼電路工作不正確，本段話的第一句已經回答你們了。

在學習FPGA的過程中，掌握訊號探針工具（signal probe)的使用是非常必要的，有了它們，大家就可以像在模擬軟體裡那樣，把真實FPGA硬體裡的物理訊號取樣抓取到波形檢視工具中去進行debug。Xilinx家的訊號探針工具叫ChipScope，而Quartus家的叫SignalTap。相對來說，SignalTap比ChipScope要好用很多，例如說，SignalTap抓取波形的時候，訊號名稱可以自動識別，而ChipScope會把訊號名稱自動命名為序號，需要使用者手動使用別名進行修改，而其中一旦有一個訊號名稱寫錯，就得把該訊號以後的全部訊號名稱重新輸入一次。

I) Windows/ Linux/ OS X

相信大多數人的個人計算機使用的都是以上系統或類似以上系統的其他系統吧。以上3個系統，對於專業的數字IC前端設計人員而言，工作的方便程度（注意，是專業人員的方便程度，而非學習曲線的陡峭程度，這裡是指均已達到熟練掌握的前提下對於工作效率的幫助）由方便到困難分別是：Linux > Windows > OS X。在Windows下，你可能需要的工具有Cygwin（模擬Linux shell，帶有大部分GNU工具），Modelsim，Debussy(更名Verdi後的版本沒有對應的Windows版本), Quartus, ISE等。在Linux下，你可能需要的工具包括Bash/Csh/Tcsh，Modelsim，Quartus，ISE，VCS，Simvision，DVE，NCVerilog，Formality，LEC,Synplify等。而在OS X下（筆者不幸就位於該平臺下），你可以使用的工具就只剩下Bash/Csh/Zsh，iVerilog，gtkWave這些選擇了。

從以上內容不難看出，在工具的多樣性角度而言，Linux完爆其它平臺，這也是為什麼絕大多數IC開發公司的伺服器都選擇部署在Linux下的主要原因之一。對於個人電腦而言，大部分同學會選擇使用虛擬機器來兼顧不同平臺的工具選擇，個人建議大家最好在熟練掌握Linux平臺及其工具的前提下，同時也瞭解一下其它平臺的解決方案