很早之前就想對這幾個月工作經(jīng)歷寫的東西，一是作為自己的總結，二是自己也很想將自己這段時間的一些經(jīng)歷和大家分享一下，希望對初學者而言能使得他們能少走一些彎路。只是公司里的事情很多，最近經(jīng)常加班，所以一直拖到現(xiàn)在。
??能來到這家公司應該是一種緣份--緣起NIOS。當初三月份altera來我們學校建立SOPC實驗室的時候自己還不知道NIOS是什么東西，只是想在altera的FAE講完NIOS后多問他幾個時序約束的問題，然后拷一份PPT回去。但是想不到因為那一份NIOS的培訓資料，我認識了edacn上的cawan，他給我講了很多NIOS的東西，之后是丁哥在SOC版帖了位NIOS大賽的通知，然后我和隊友就去報了名，并去川大參加了NIOS的培訓，認識了峻龍的FAE----也是我現(xiàn)在的boss。在這里要謝謝cawan、丁哥、和我一起參加NIOS競賽的隊友劉科以及我的BOSS，是他們讓我有了這一段的經(jīng)歷。在公司里的幾個月，做的項目其實不多，但是收獲還是有一些，我覺得收獲最大的是設計理念的改變，這也是我這段時間最想總結的，我會在后面逐漸闡述。??
??時序是設計出來的
??我的boss有在華為及峻龍工作的背景，自然就給我們講了一些華為及altera做邏輯的一些東西，而我們的項目規(guī)范，也基本上是按華為的那一套去做。在工作這幾個月中，給我感觸最深的是華為的那句話：時序是設計出來的，不是仿出來的，更不是湊出來的。 在我們公司，每一個項目都有很嚴格的評審，只有評審通過了，才能做下一步的工作。以做邏輯為例，并不是一上來就開始寫代碼，而是要先寫總體設計方案和邏輯詳細設計方案，要等這些方案評審通過，認為可行了，才能進行編碼，一般來說這部分工作所占的時間要遠大于編碼的時間。 總體方案主要是涉及模塊劃分，一級模塊和二級模塊的接口信號和時序（我們要求把接口信號的時序波形描述出來）以及將來如何測試設計。在這一級方案中，要保證在今后的設計中時序要收斂到一級模塊（最后是在二級模塊中）。什么意思呢？我們在做詳細設計的時候，對于一些信號的時序肯定會做一些調整的，但是這種時序的調整最多只能波及到本一級模塊，而不能影響到整個設計。記得以前在學校做設計的時候，由于不懂得設計時序，經(jīng)常因為有一處信號的時序不滿足，結果不得不將其它模塊信號的時序也改一下，搞得人很郁悶。 在邏輯詳細設計方案這一級的時候，我們已經(jīng)將各級模塊的接口時序都設計出來了，各級模塊內部是怎么實現(xiàn)的也基本上確定下來了。 由于做到這一點，在編碼的時候自然就很快了，最重要的是這樣做后可以讓設計會一直處于可控的狀態(tài)，不會因為某一處的錯誤引起整個設計從頭進行。 做邏輯的難點在于系統(tǒng)結構設計和仿真驗證剛去公司的時候BOSS就和我講，做邏輯的難點不在于RTL級代碼的設計，而在于系統(tǒng)結構設計和仿真驗證方面。目前國內對可綜合的設計強調的比較多，而對系統(tǒng)結構設計和仿真驗證方面似乎還沒有什么資料，這或許也從一個側面反映了國內目前的設計水平還比較低下吧。
?  以前在學校的時候，總是覺得將RTL級代碼做好就行了，仿真驗證只是形式而已，所以對HDL的行為描述方面的語法不屑一顧，對testbench也一直不愿意去學--因為覺得畫波形圖方便；對于系統(tǒng)結構設計更是一點都不懂了。 到了公司接觸了些東西才發(fā)現(xiàn)完全不是這樣。 其實在國外，花在仿真驗證上的時間和人力大概是花在RTL級代碼上的兩倍，現(xiàn)在仿真驗證才是百萬門級芯片設計的關鍵路徑。仿真驗證的難點主要在于怎么建模才能完全和準確地去驗證設計的正確性（主要是提高代碼覆蓋），在這過程中，驗證速度也是很重要的。 驗證說白了也就是怎么產生足夠覆蓋率的激勵源，然后怎么去檢測錯誤。我個人認為，在仿真驗證中，最基本就是要做到驗證的自動化。這也是為什么我們要寫testbench的原因。在我現(xiàn)在的一個設計中，每次跑仿真都要一個小時左右（這其實算小設計）。由于畫波形圖無法做到驗證自動化，如果用通過畫波形圖來仿真的話，一是畫波形會畫死（特別是對于算法復雜的、輸入呈統(tǒng)計分布的設計），二是看波形圖要看死，三是檢錯率幾乎為零。
??那么怎么做到自動化呢？我個人的水平還很有限，只能簡單地談下BFM（bus function model，總線功能模型）。以做一個MAC的core為例（背板是PCI總線），那么我們需要一個MAC_BFM和PCI_BFM及PCI_BM（PCI behavior. model）。MAC_BFM的主要功能是產生以太網(wǎng)幀(激勵源），隨機的長度和幀頭，內容也是隨機的,在發(fā)送的同時也將其復制一份到PCI_BM中；PCI_BFM的功能則是仿PCI總線的行為，比如被測收到了一個正確幀后會向PCI總線發(fā)送一個請求，PCI_BFM則會去響應它，并將數(shù)據(jù)收進來；PCI_BM的主要功能是將MAC_BFM發(fā)送出來的東西與PCI_BFM接收到的東西做比較，由于它具有了MAC_BFM的發(fā)送信息和PCI_BFM的接收信息，只要設計合理，它總是可以自動地、完全地去測試被測是否工作正常，從而實現(xiàn)自動檢測。 華為在仿真驗證方面估計在國內來說是做的比較好的，他們已建立起了比較好的驗證平臺，大部分與通信有關的BFM都做好了，聽我朋友說，現(xiàn)在他們只需要將被測放在測試平臺中，并配置好參數(shù)，就可以自動地檢測被測功能的正確與否。 在功能仿真做完后，由于我們做在是FPGA的設計，在設計時已經(jīng)基本保證RTL級代碼在綜合結果和功能仿真結果的一致性，只要綜合布局布線后的靜態(tài)時序報告沒有違反時序約束的警告，就可以下到板子上去調試了。事實上，在華為中興，他們做FPGA的設計時也是不做時序仿真的，因為做時序仿真很花時間，且效果也不見得比看靜態(tài)時序分析報告好。 當然了，如果是ASIC的設計話，它們的仿真驗證的工作量要大一些，在涉及到多時鐘域的設計時，一般還是做后仿的。不過在做后仿之前，也一般會先用形式驗證工具和通過靜態(tài)時序分序報告去查看有沒有違反設計要求的地方，這樣做了之后，后仿的工作量可以小很多。
??在HDL語言方面，國內語言很多人都在爭論VHDL和verilog哪個好，其實我個人認為這并沒有多大的意義，外面的大公司基本上都是用verilog在做RTL級的代碼，所以還是建議大家盡量學verilog。在仿真方面，由于VHDL在行為級建模方面弱于verilog，用VHDL做仿真模型的很少，當然也不是說verilog就好，其實verilog在復雜的行為級建模方面的能力也是有限的，比如目前它還不支持數(shù)組。在一些復雜的算法設計中，需要高級語言做抽象才能描述出行為級模型。在國外，仿真建模很多都是用System C和E語言，用verilog的都算是很落后的了，國內華為的驗證平臺好像是用System C寫。
??在系統(tǒng)結構設計方面，由于我做的設計還不夠大，還談不上什么經(jīng)驗，只是覺得必須要具備一些計算機系統(tǒng)結構的知識才行。劃分的首要依據(jù)是功能，之后是選擇合適的總線結構、存儲結構和處理器架構，通過系統(tǒng)結構劃分要使各部分功能模塊清晰，易于實現(xiàn)。這一部分我想過段時間有一點體會了再和大家分享，就先不誤導大家了。??
??規(guī)范很重要
??工作過的朋友肯定知道，公司里是很強調規(guī)范的，特別是對于大的設計（無論軟件還是硬件），不按照規(guī)范走幾乎是不可實現(xiàn)的。邏輯設計也是這樣：如果不按規(guī)范做的話，過一個月后調試時發(fā)現(xiàn)有錯，回頭再看自己寫的代碼，估計很多信號功能都忘了，更不要說檢錯了；如果一個項目做了一半一個人走了，接班的估計得從頭開始設計；如果需要在原來的版本基礎上增加新功能，很可能也得從頭來過，很難做到設計的可重用性。
??在邏輯方面，我覺得比較重要的規(guī)范有這些：
??1.設計必須文檔化。要將設計思路，詳細實現(xiàn)等寫入文檔，然后經(jīng)過嚴格評審通過后才能進行下一步的工作。這樣做乍看起來很花時間，但是從整個項目過程來看，絕對要比一上來就寫代碼要節(jié)約時間，且這種做法可以使項目處于可控、可實現(xiàn)的狀態(tài)。
??2.代碼規(guī)范。
??a.設計要參數(shù)化。比如一開始的設計時鐘周期是30ns，復位周期是5個時鐘周期，我們可以這么寫：
?? parameter CLK_PERIOD = 30;
?? parameter RST_MUL_TIME = 5;
?? parameter RST_TIME = RST_MUL_TIME * CLK_PERIOD;
?? ...
?? rst_n = 1'b0;
?? # RST_TIME rst_n = 1'b1;
?? ...
?? # CLK_PERIOD/2 clk <= ~clk;
?? 如果在另一個設計中的時鐘是40ns，復位周期不變，我們只需對CLK_PERIOD進行重
??新例化就行了，從而使得代碼更加易于重用。
?? b.信號命名要規(guī)范化。
?? 1) 信號名一律小寫，參數(shù)用大寫。
?? 2) 對于低電平有效的信號結尾要用_n標記，如rst_n。
?? 3) 端口