【轉載】數字IC設計工程師技能樹

時間 2019-11-21

原文原文鏈接

I. 技能清單

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

語言類
- 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代碼風格一文中對新版的接口語法進行過詳細的舉例說明。這種新的接口方式修改起來更加簡單，例化模塊的時候使用也更加方便，不像舊版的接口語法因爲一個接口須要分3次描述，無故端增長了代碼行數並且閱讀和改動都很困難，尤爲是當一個模塊的接口數目超過一個屏幕的顯示範圍時Verilog-2001的這種優點更加突出。css

學習Verilog最大的問題就是，不少國內的書寫得都很很差，書中的不少例子都是爲了說明語法特徵而存在的，沒有任何實用價值，甚至不少代碼都是錯誤的（這裏錯誤的意思並非說他語法錯誤，而是說他是不可綜合的，沒法用數字電路來對等實現的）。因此，對於學習Verilog，個人建議是，隨便找一本相似語法手冊的書籍，匆匆把基本語法看過一遍，搞清楚模塊定義，接口定義，模塊例化，寄存器定義，線定義，always塊怎麼寫這些基本內容後，就開始到OpenCores網站上去下載已經通過FPGA驗證的完整開源項目代碼進行學習。先作到看懂別人寫的代碼，而後再嘗試本身去模仿，有不懂的問題再有針對性地去網上搜索答案。html

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

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

VHDL雖然我並非太瞭解，可是目前在歐洲不少國家，VHDL仍是主流的RTL設計語言。VHDL語言的嚴謹性比Verilog要好，不像Verilog中同樣存在大量符合語法卻永遠沒法綜合的語句，容易對新人形成誤導（仿真經過的代碼卻在FPGA綜合時報錯，或者FPGA實現結果與仿真不一致）。而VHDL和Verilog雖然能夠相互轉化，可是轉化過程當中仍然存在不少問題，沒法作到徹底的自動化。關於這一點我以前寫過一篇專題進行探討：如何將VHDL轉化爲Verilog。有興趣的同窗能夠去看看。node

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效率，很是有助於在大規模的數據交互過程當中定位到出錯的初始點，沒有掌握的同窗能夠多花一些時間研究一下。shell

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錄像功能，你只須要操做一次，而後使用256@q就能夠把你的動做自動重複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平臺及其工具的前提下，同時也瞭解一下其它平臺的解決方案（若是你有在MAC OS X平臺IC開發工具的使用建議或者問題，歡迎來稿）