系統結構設計和仿真驗證 - 資深工程師FPGA設計經驗精華匯總

2015年12月16日 10:35 來源:網站整理 作者:h1654155596.7254 我要評論(0)

標簽:FPGA(602396)嵌入式技術(35715)智能工業(40960)

  做邏輯的難點在于系統結構設計和仿真驗證

  剛去公司的時候BOSS就和我講,做邏輯的難點不在于RTL級代碼的設計,而在于系統結構設計和仿真驗證方面。目前國內對可綜合的設計強調的比較多,而對系統結構設計和仿真驗證方面似乎還沒有什么資料,這或許也從一個側面反映了國內目前的設計水平還比較低下吧。以前在學校的時候,總是覺得將RTL級代碼做好就行了,仿真驗證只是形式而已,所以對HDL的行為描述方面的語法不屑一顧,對testbench也一直不愿意去學--因為覺得畫波形圖方便;對于系統結構設計更是一點都不懂了。到了公司接觸了些東西才發現完全不是這樣。

  其實在國外,花在仿真驗證上的時間和人力大概是花在RTL級代碼上的兩倍,現在仿真驗證才是百萬門級芯片設計的關鍵路徑。仿真驗證的難點主要在于怎么建模才能完全和準確地去驗證設計的正確性(主要是提高代碼覆蓋),在這過程中,驗證速度也是很重要的。

  驗證說白了也就是怎么產生足夠覆蓋率的激勵源,然后怎么去檢測錯誤。我個人認為,在仿真驗證中,最基本就是要做到驗證的自動化。這也是為什么我們要寫testbench的原因。在我現在的一個設計中,每次跑仿真都要一個小時左右(這其實算小設計)由于畫波形圖無法做到驗證自動化,如果用通過畫波形圖來仿真的話,一是畫波形會畫死(特別是對于算法復雜的、輸入呈統計分布的設計),二是看波形圖要看死,三是檢錯率幾乎為零。那么怎么做到自動化呢?我個人的水平還很有限,只能簡單地談下BFM(bus function model,總線功能模型)。

  以做一個MAC的core為例(背板是PCI總線),那么我們需要一個MAC_BFM和PCI_BFM及PCI_BM(PCI behavior model)。MAC_BFM的主要功能是產生以太網幀(激勵源),隨機的長度和幀頭,內容也是隨機的,在發送的同時也將其復制一份到PCI_BM中;PCI_BFM的功能則是仿PCI總線的行為,比如被測收到了一個正確幀后會向PCI總線發送一個請求,PCI_BFM則會去響應它,并將數據收進來;PCI_BM的主要功能是將MAC_BFM發送出來的東西與PCI_BFM接收到的東西做比較,由于它具有了MAC_BFM的發送信息和PCI_BFM的接收信息,只要設計合理,它總是可以自動地、完全地去測試被測是否工作正常,從而實現自動檢測。 華為在仿真驗證方面估計在國內來說是做的比較好的,他們已建立起了比較好的驗證平臺,大部分與通信有關的BFM都做好了,聽我朋友說,現在他們只需要將被測放在測試平臺中,并配置好參數,就可以自動地檢測被測功能的正確與否。

  在功能仿真做完后,由于我們做在是FPGA的設計,在設計時已經基本保證RTL級代碼在綜合結果和功能仿真結果的一致性,只要綜合布局布線后的靜態時序報告沒有違反時序約束的警告,就可以下到板子上去調試了。事實上,在華為中興,他們做FPGA的設計時也是不做時序仿真的,因為做時序仿真很花時間,且效果也不見得比看靜態時序分析報告好。

  當然了,如果是ASIC的設計話,它們的仿真驗證的工作量要大一些,在涉及到多時鐘域的設計時,一般還是做后仿的。不過在做后仿之前,也一般會先用形式驗證工具和通過靜態時序分序報告去查看有沒有違反設計要求的地方,這樣做了之后,后仿的工作量可以小很多。

  在HDL語言方面,國內語言很多人都在爭論VHDL和verilog哪個好,其實我個人認為這并沒有多大的意義,外面的大公司基本上都是用verilog在做RTL級的代碼,所以還是建議大家盡量學verilog。在仿真方面,由于VHDL在行為級建模方面弱于verilog,用VHDL做仿真模型的很少,當然也不是說verilog就好,其實verilog在復雜的行為級建模方面的能力也是有限的,比如目前它還不支持數組。在一些復雜的算法設計中,需要高級語言做抽象才能描述出行為級模型。在國外,仿真建模很多都是用System C和E語言,用verilog的都算是很落后的了,國內華為的驗證平臺好像是用System C寫。

  在系統結構設計方面,由于我做的設計還不夠大,還談不上什么經驗,只是覺得必須要具備一些計算機系統結構的知識才行。劃分的首要依據是功能,之后是選擇合適的,總線結構、存儲結構和處理器架構,通過系統結構劃分要使各部分功能模塊清晰,易于實現。這一部分我想過段時間有一點體會了再和大家分享,就先不誤導大家了。

  最后簡單說一下體會吧,歸結起來就多實踐、多思考、多問。實踐出真知,看100遍別人的方案不如自己去實踐一下。實踐的動力一方面來自興趣,一方面來自壓力,我個人覺得后者更重要。有需求會容易形成壓力,也就是說最好能在實際的項目開發中鍛煉,而不是為了學習而學習。在實踐的過程中要多思考,多想想問題出現的原因,問題解決后要多問幾個為什么,這也是經驗積累的過程,如果有寫項目日志的習慣更好,把問題及原因、解決的辦法都寫進去。最后還要多問,遇到問題思索后還得不到解決就要問了,畢竟個人的力量是有限的,問同學同事,問搜索引擎,問網友,都可以,一篇文章、朋友們的點撥都可能幫助自己快速解決問題。

上一頁12全文

本文導航